ladybird/Kernel/Bus/VirtIO/Device.cpp

170 lines
6.3 KiB
C++
Raw Normal View History

/*
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
* Copyright (c) 2021, the SerenityOS developers.
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <Kernel/Bus/VirtIO/Device.h>
#include <Kernel/Sections.h>
namespace Kernel::VirtIO {
UNMAP_AFTER_INIT ErrorOr<void> Device::initialize_virtio_resources()
{
TRY(m_transport_entity->locate_configurations_and_resources({}, *this));
// NOTE: We enable interrupts at least after the m_register_bases[0] ptr is
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 05:50:04 -03:00
// assigned with an IOWindow, to ensure that in case of getting an interrupt
// we can access registers from that IO window range.
m_transport_entity->enable_interrupts({});
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 05:50:04 -03:00
// NOTE: Status bits should be set to 0 to keep them in sync, because
// we reset the device shortly afterwards.
m_status = 0;
m_transport_entity->reset_device({});
set_status_bit(DEVICE_STATUS_ACKNOWLEDGE);
set_status_bit(DEVICE_STATUS_DRIVER);
return {};
}
UNMAP_AFTER_INIT VirtIO::Device::Device(NonnullOwnPtr<TransportEntity> transport_entity)
: m_class_name(transport_entity->determine_device_class_name())
, m_transport_entity(move(transport_entity))
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 05:50:04 -03:00
{
}
void Device::set_status_bit(u8 status_bit)
{
m_status |= status_bit;
m_transport_entity->set_status_bits({}, m_status);
Kernel: Introduce the IOWindow class This class is intended to replace all IOAddress usages in the Kernel codebase altogether. The idea is to ensure IO can be done in arch-specific manner that is determined mostly in compile-time, but to still be able to use most of the Kernel code in non-x86 builds. Specific devices that rely on x86-specific IO instructions are already placed in the Arch/x86 directory and are omitted for non-x86 builds. The reason this works so well is the fact that x86 IO space acts in a similar fashion to the traditional memory space being available in most CPU architectures - the x86 IO space is essentially just an array of bytes like the physical memory address space, but requires x86 IO instructions to load and store data. Therefore, many devices allow host software to interact with the hardware registers in both ways, with a noticeable trend even in the modern x86 hardware to move away from the old x86 IO space to exclusively using memory-mapped IO. Therefore, the IOWindow class encapsulates both methods for x86 builds. The idea is to allow PCI devices to be used in either way in x86 builds, so when trying to map an IOWindow on a PCI BAR, the Kernel will try to find the proper method being declared with the PCI BAR flags. For old PCI hardware on non-x86 builds this might turn into a problem as we can't use port mapped IO, so the Kernel will gracefully fail with ENOTSUP error code if that's the case, as there's really nothing we can do within such case. For general IO, the read{8,16,32} and write{8,16,32} methods are available as a convenient API for other places in the Kernel. There are simply no direct 64-bit IO API methods yet, as it's not needed right now and is not considered to be Arch-agnostic too - the x86 IO space doesn't support generating 64 bit cycle on IO bus and instead requires two 2 32-bit accesses. If for whatever reason it appears to be necessary to do IO in such manner, it could probably be added with some neat tricks to do so. It is recommended to use Memory::TypedMapping struct if direct 64 bit IO is actually needed.
2022-09-23 05:50:04 -03:00
}
ErrorOr<void> Device::accept_device_features(u64 device_features, u64 accepted_features)
{
VERIFY(!m_did_accept_features);
m_did_accept_features = true;
if (is_feature_set(device_features, VIRTIO_F_VERSION_1)) {
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
accepted_features |= VIRTIO_F_VERSION_1; // let the device know were not a legacy driver
}
if (is_feature_set(device_features, VIRTIO_F_RING_PACKED)) {
dbgln_if(VIRTIO_DEBUG, "{}: packed queues not yet supported", m_class_name);
accepted_features &= ~(VIRTIO_F_RING_PACKED);
}
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
// TODO: implement indirect descriptors to allow queue_size buffers instead of buffers totalling (PAGE_SIZE * queue_size) bytes
if (is_feature_set(device_features, VIRTIO_F_INDIRECT_DESC)) {
// accepted_features |= VIRTIO_F_INDIRECT_DESC;
}
if (is_feature_set(device_features, VIRTIO_F_IN_ORDER)) {
accepted_features |= VIRTIO_F_IN_ORDER;
}
dbgln_if(VIRTIO_DEBUG, "{}: Device features: {}", m_class_name, device_features);
dbgln_if(VIRTIO_DEBUG, "{}: Accepted features: {}", m_class_name, accepted_features);
m_transport_entity->accept_device_features({}, accepted_features);
set_status_bit(DEVICE_STATUS_FEATURES_OK);
m_status = m_transport_entity->read_status_bits();
if (!(m_status & DEVICE_STATUS_FEATURES_OK)) {
set_status_bit(DEVICE_STATUS_FAILED);
dbgln("{}: Features not accepted by host!", m_class_name);
return Error::from_errno(EIO);
}
m_accepted_features = accepted_features;
dbgln_if(VIRTIO_DEBUG, "{}: Features accepted by host", m_class_name);
return {};
}
ErrorOr<void> Device::setup_queue(u16 queue_index)
{
auto queue = TRY(m_transport_entity->setup_queue({}, queue_index));
dbgln_if(VIRTIO_DEBUG, "{}: Queue[{}] configured with size: {}", m_class_name, queue_index, queue->size());
TRY(m_queues.try_append(move(queue)));
return {};
}
ErrorOr<void> Device::setup_queues(u16 requested_queue_count)
{
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
VERIFY(!m_did_setup_queues);
m_did_setup_queues = true;
auto* common_cfg = m_transport_entity->get_config(ConfigurationType::Common).release_value_but_fixme_should_propagate_errors();
if (common_cfg) {
auto maximum_queue_count = m_transport_entity->config_read16(*common_cfg, COMMON_CFG_NUM_QUEUES);
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
if (requested_queue_count == 0) {
m_queue_count = maximum_queue_count;
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
} else if (requested_queue_count > maximum_queue_count) {
dbgln("{}: {} queues requested but only {} available!", m_class_name, m_queue_count, maximum_queue_count);
return Error::from_errno(ENXIO);
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
} else {
m_queue_count = requested_queue_count;
}
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
} else {
m_queue_count = requested_queue_count;
dbgln("{}: device's available queue count could not be determined!", m_class_name);
}
dbgln_if(VIRTIO_DEBUG, "{}: Setting up {} queues", m_class_name, m_queue_count);
for (u16 i = 0; i < m_queue_count; i++)
TRY(setup_queue(i));
// NOTE: Queues can only be activated *after* all others queues were also configured
for (u16 i = 0; i < m_queue_count; i++)
TRY(m_transport_entity->activate_queue({}, i));
return {};
}
void Device::finish_init()
{
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
VERIFY(m_did_accept_features); // ensure features were negotiated
VERIFY(m_did_setup_queues); // ensure queues were set-up
2021-04-18 05:30:03 -03:00
VERIFY(!(m_status & DEVICE_STATUS_DRIVER_OK)); // ensure we didn't already finish the initialization
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
set_status_bit(DEVICE_STATUS_DRIVER_OK);
dbgln_if(VIRTIO_DEBUG, "{}: Finished initialization", m_class_name);
}
bool Device::handle_irq(Badge<TransportInterruptHandler>)
{
u8 isr_type = m_transport_entity->isr_status();
if ((isr_type & (QUEUE_INTERRUPT | DEVICE_CONFIG_INTERRUPT)) == 0) {
dbgln_if(VIRTIO_DEBUG, "{}: Handling interrupt with unknown type: {}", class_name(), isr_type);
return false;
}
if (isr_type & DEVICE_CONFIG_INTERRUPT) {
dbgln_if(VIRTIO_DEBUG, "{}: VirtIO Device config interrupt!", class_name());
if (handle_device_config_change().is_error()) {
set_status_bit(DEVICE_STATUS_FAILED);
dbgln("{}: Failed to handle device config change!", class_name());
}
}
if (isr_type & QUEUE_INTERRUPT) {
dbgln_if(VIRTIO_DEBUG, "{}: VirtIO Queue interrupt!", class_name());
Kernel: Finish base implementation of VirtQueues This commit includes a lot of small changes and additions needed to finalize the base implementation of VirtIOQueues and VirtDevices: * The device specific driver implementation now has to handle setting up the queues it needs before letting the base device class know it finised initialization * Supplying buffers to VirtQueues is now done via ScatterGatherLists instead of arbitary buffer pointers - this ensures the pointers are physical and allows us to follow the specification in regards to the requirement that individual descriptors must point to physically contiguous buffers. This can be further improved in the future by implementating support for the Indirect-Descriptors feature (as defined by the specification) to reduce descriptor usage for very fragmented buffers. * When supplying buffers to a VirtQueue the driver must supply a (temporarily-)unique token (usually the supplied buffer's virtual address) to ensure the driver can discern which buffer has finished processing by the device in the case in which the device does not offer the F_IN_ORDER feature. * Device drivers now handle queue updates (supplied buffers being returned from the device) by implementing a single pure virtual method instead of setting a seperate callback for each queue * Two new VirtQueue methods were added to allow the device driver to either discard or get used/returned buffers from the device by cleanly removing them off the descriptor chain (This also allows the VirtQueue implementation to reuse those freed descriptors) This also includes the necessary changes to the VirtIOConsole implementation to match these interface changes. Co-authored-by: Sahan <sahan.h.fernando@gmail.com>
2021-04-15 06:39:48 -03:00
for (size_t i = 0; i < m_queues.size(); i++) {
if (get_queue(i).new_data_available()) {
handle_queue_update(i);
return true;
}
}
dbgln_if(VIRTIO_DEBUG, "{}: Got queue interrupt but all queues are up to date!", class_name());
}
return true;
}
void Device::supply_chain_and_notify(u16 queue_index, QueueChain& chain)
{
auto& queue = get_queue(queue_index);
VERIFY(&chain.queue() == &queue);
VERIFY(queue.lock().is_locked());
chain.submit_to_queue();
auto descriptor = TransportEntity::NotifyQueueDescriptor { queue_index, get_queue(queue_index).notify_offset() };
if (queue.should_notify())
m_transport_entity->notify_queue({}, descriptor);
}
}