2021-01-02 14:53:05 -03:00
/*
2021-04-15 06:39:48 -03:00
* Copyright ( c ) 2021 , the SerenityOS developers .
2021-01-02 14:53:05 -03:00
*
2021-04-22 05:24:48 -03:00
* SPDX - License - Identifier : BSD - 2 - Clause
2021-01-02 14:53:05 -03:00
*/
Kernel/PCI: Simplify the entire subsystem
A couple of things were changed:
1. Semantic changes - PCI segments are now called PCI domains, to better
match what they are really. It's also the name that Linux gave, and it
seems that Wikipedia also uses this name.
We also remove PCI::ChangeableAddress, because it was used in the past
but now it's no longer being used.
2. There are no WindowedMMIOAccess or MMIOAccess classes anymore, as
they made a bunch of unnecessary complexity. Instead, Windowed access is
removed entirely (this was tested, but never was benchmarked), so we are
left with IO access and memory access options. The memory access option
is essentially mapping the PCI bus (from the chosen PCI domain), to
virtual memory as-is. This means that unless needed, at any time, there
is only one PCI bus being mapped, and this is changed if access to
another PCI bus in the same PCI domain is needed. For now, we don't
support mapping of different PCI buses from different PCI domains at the
same time, because basically it's still a non-issue for most machines
out there.
2. OOM-safety is increased, especially when constructing the Access
object. It means that we pre-allocating any needed resources, and we try
to find PCI domains (if requested to initialize memory access) after we
attempt to construct the Access object, so it's possible to fail at this
point "gracefully".
3. All PCI API functions are now separated into a different header file,
which means only "clients" of the PCI subsystem API will need to include
that header file.
4. Functional changes - we only allow now to enumerate the bus after
a hardware scan. This means that the old method "enumerate_hardware"
is removed, so, when initializing an Access object, the initializing
function must call rescan on it to force it to find devices. This makes
it possible to fail rescan, and also to defer it after construction from
both OOM-safety terms and hotplug capabilities.
2021-09-07 06:08:38 -03:00
# include <Kernel/Bus/PCI/API.h>
2021-06-25 03:46:17 -03:00
# include <Kernel/Bus/PCI/IDs.h>
2021-08-27 06:24:50 -03:00
# include <Kernel/Bus/VirtIO/Console.h>
# include <Kernel/Bus/VirtIO/Device.h>
# include <Kernel/Bus/VirtIO/RNG.h>
2021-04-18 10:06:35 -03:00
# include <Kernel/CommandLine.h>
2021-06-22 12:40:16 -03:00
# include <Kernel/Sections.h>
2021-01-02 14:53:05 -03:00
2021-08-27 06:18:13 -03:00
namespace Kernel : : VirtIO {
2021-01-02 14:53:05 -03:00
2021-08-27 06:18:13 -03:00
UNMAP_AFTER_INIT void detect ( )
2021-01-02 14:53:05 -03:00
{
2021-04-18 10:06:35 -03:00
if ( kernel_command_line ( ) . disable_virtio ( ) )
return ;
2022-02-04 14:48:13 -03:00
MUST ( PCI : : enumerate ( [ & ] ( PCI : : DeviceIdentifier const & device_identifier ) {
2021-09-23 04:20:54 -03:00
if ( device_identifier . hardware_id ( ) . is_null ( ) )
2021-01-02 14:53:05 -03:00
return ;
2021-06-12 10:07:44 -03:00
// TODO: We should also be checking that the device_id is in between 0x1000 - 0x107F inclusive
2021-09-23 03:14:51 -03:00
if ( device_identifier . hardware_id ( ) . vendor_id ! = PCI : : VendorID : : VirtIO )
2021-01-02 14:53:05 -03:00
return ;
2021-09-23 03:14:51 -03:00
switch ( device_identifier . hardware_id ( ) . device_id ) {
2021-07-03 04:24:28 -03:00
case PCI : : DeviceID : : VirtIOConsole : {
2021-09-23 04:20:54 -03:00
auto & console = Console : : must_create ( device_identifier ) . leak_ref ( ) ;
2021-09-04 02:42:31 -03:00
console . initialize ( ) ;
2021-01-22 13:56:19 -03:00
break ;
}
2021-07-03 04:24:28 -03:00
case PCI : : DeviceID : : VirtIOEntropy : {
2021-09-23 04:20:54 -03:00
auto & rng = RNG : : must_create ( device_identifier ) . leak_ref ( ) ;
2021-09-04 02:42:31 -03:00
rng . initialize ( ) ;
2021-01-02 14:56:36 -03:00
break ;
}
2021-07-03 04:24:28 -03:00
case PCI : : DeviceID : : VirtIOGPU : {
2021-06-12 10:07:44 -03:00
// This should have been initialized by the graphics subsystem
break ;
}
2021-04-15 06:17:49 -03:00
default :
2021-09-23 03:14:51 -03:00
dbgln_if ( VIRTIO_DEBUG , " VirtIO: Unknown VirtIO device with ID: {} " , device_identifier . hardware_id ( ) . device_id ) ;
2021-04-15 06:17:49 -03:00
break ;
}
2022-02-04 14:48:13 -03:00
} ) ) ;
2021-01-02 14:53:05 -03:00
}
2021-12-08 10:00:18 -03:00
static StringView determine_device_class ( PCI : : DeviceIdentifier const & device_identifier )
2021-08-27 05:41:27 -03:00
{
2021-09-23 04:20:54 -03:00
if ( device_identifier . revision_id ( ) . value ( ) = = 0 ) {
2021-09-04 13:10:00 -03:00
// Note: If the device is a legacy (or transitional) device, therefore,
// probe the subsystem ID in the PCI header and figure out the
2021-09-23 04:20:54 -03:00
auto subsystem_device_id = device_identifier . subsystem_id ( ) . value ( ) ;
2021-09-04 13:10:00 -03:00
switch ( subsystem_device_id ) {
case 1 :
2021-09-19 15:02:53 -03:00
return " VirtIONetAdapter " sv ;
2021-09-04 13:10:00 -03:00
case 2 :
2021-09-19 15:02:53 -03:00
return " VirtIOBlockDevice " sv ;
2021-09-04 13:10:00 -03:00
case 3 :
2021-09-19 15:02:53 -03:00
return " VirtIOConsole " sv ;
2021-09-04 13:10:00 -03:00
case 4 :
2021-09-19 15:02:53 -03:00
return " VirtIORNG " sv ;
default :
dbgln ( " VirtIO: Unknown subsystem_device_id {} " , subsystem_device_id ) ;
VERIFY_NOT_REACHED ( ) ;
2021-09-04 13:10:00 -03:00
}
}
2021-09-23 04:20:54 -03:00
auto id = device_identifier . hardware_id ( ) ;
2021-09-04 13:10:00 -03:00
VERIFY ( id . vendor_id = = PCI : : VendorID : : VirtIO ) ;
switch ( id . device_id ) {
case PCI : : DeviceID : : VirtIONetAdapter :
2021-09-19 15:02:53 -03:00
return " VirtIONetAdapter " sv ;
2021-09-04 13:10:00 -03:00
case PCI : : DeviceID : : VirtIOBlockDevice :
2021-09-19 15:02:53 -03:00
return " VirtIOBlockDevice " sv ;
2021-09-04 13:10:00 -03:00
case PCI : : DeviceID : : VirtIOConsole :
2021-09-19 15:02:53 -03:00
return " VirtIOConsole " sv ;
2021-09-04 13:10:00 -03:00
case PCI : : DeviceID : : VirtIOEntropy :
2021-09-19 15:02:53 -03:00
return " VirtIORNG " sv ;
2021-09-04 13:10:00 -03:00
case PCI : : DeviceID : : VirtIOGPU :
2021-09-19 15:02:53 -03:00
return " VirtIOGPU " sv ;
default :
dbgln ( " VirtIO: Unknown device_id {} " , id . vendor_id ) ;
VERIFY_NOT_REACHED ( ) ;
2021-08-27 05:41:27 -03:00
}
}
2021-09-04 02:42:31 -03:00
UNMAP_AFTER_INIT void Device : : initialize ( )
2021-01-02 14:53:05 -03:00
{
2021-09-04 02:42:31 -03:00
auto address = pci_address ( ) ;
2021-01-02 14:53:05 -03:00
enable_bus_mastering ( pci_address ( ) ) ;
2021-09-23 03:14:51 -03:00
auto capabilities = PCI : : get_device_identifier ( address ) . capabilities ( ) ;
2021-01-02 14:53:05 -03:00
for ( auto & capability : capabilities ) {
2021-09-28 14:18:51 -03:00
if ( capability . id ( ) . value ( ) = = PCI : : Capabilities : : ID : : VendorSpecific ) {
2021-01-02 14:53:05 -03:00
// We have a virtio_pci_cap
2022-02-03 11:25:15 -03:00
Configuration config { } ;
2021-04-15 06:12:06 -03:00
auto raw_config_type = capability . read8 ( 0x3 ) ;
if ( raw_config_type < static_cast < u8 > ( ConfigurationType : : Common ) | | raw_config_type > static_cast < u8 > ( ConfigurationType : : PCI ) ) {
2021-09-19 12:28:27 -03:00
dbgln ( " {}: Unknown capability configuration type: {} " , m_class_name , raw_config_type ) ;
2021-04-15 06:12:06 -03:00
return ;
}
2022-02-03 11:25:15 -03:00
config . cfg_type = static_cast < ConfigurationType > ( raw_config_type ) ;
2021-04-15 06:12:06 -03:00
auto cap_length = capability . read8 ( 0x2 ) ;
if ( cap_length < 0x10 ) {
2021-09-19 12:28:27 -03:00
dbgln ( " {}: Unexpected capability size: {} " , m_class_name , cap_length ) ;
2021-01-02 14:53:05 -03:00
break ;
}
2022-02-03 11:25:15 -03:00
config . bar = capability . read8 ( 0x4 ) ;
if ( config . bar > 0x5 ) {
dbgln ( " {}: Unexpected capability bar value: {} " , m_class_name , config . bar ) ;
2021-01-02 14:53:05 -03:00
break ;
}
2022-02-03 11:25:15 -03:00
config . offset = capability . read32 ( 0x8 ) ;
config . length = capability . read32 ( 0xc ) ;
dbgln_if ( VIRTIO_DEBUG , " {}: Found configuration {}, bar: {}, offset: {}, length: {} " , m_class_name , ( u32 ) config . cfg_type , config . bar , config . offset , config . length ) ;
if ( config . cfg_type = = ConfigurationType : : Common )
2021-04-15 06:12:06 -03:00
m_use_mmio = true ;
2022-02-03 11:25:15 -03:00
else if ( config . cfg_type = = ConfigurationType : : Notify )
2021-04-15 06:12:06 -03:00
m_notify_multiplier = capability . read32 ( 0x10 ) ;
2022-02-03 11:25:15 -03:00
m_configs . append ( config ) ;
2021-01-02 14:53:05 -03:00
}
}
2021-04-15 06:12:06 -03:00
if ( m_use_mmio ) {
2021-09-18 05:54:31 -03:00
for ( auto & cfg : m_configs ) {
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
auto mapping_io_window = IOWindow : : create_for_pci_device_bar ( pci_address ( ) , static_cast < PCI : : HeaderType0BaseRegister > ( cfg . bar ) ) . release_value_but_fixme_should_propagate_errors ( ) ;
m_register_bases [ cfg . bar ] = move ( mapping_io_window ) ;
2021-09-18 05:54:31 -03:00
}
2021-04-15 06:12:06 -03:00
m_common_cfg = get_config ( ConfigurationType : : Common , 0 ) ;
m_notify_cfg = get_config ( ConfigurationType : : Notify , 0 ) ;
m_isr_cfg = get_config ( ConfigurationType : : ISR , 0 ) ;
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
} else {
auto mapping_io_window = IOWindow : : create_for_pci_device_bar ( pci_address ( ) , PCI : : HeaderType0BaseRegister : : BAR0 ) . release_value_but_fixme_should_propagate_errors ( ) ;
m_register_bases [ 0 ] = move ( mapping_io_window ) ;
2021-04-15 06:12:06 -03:00
}
2021-01-02 14:53:05 -03:00
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: We enable interrupts at least after the m_register_bases[0] ptr is
// assigned with an IOWindow, to ensure that in case of getting an interrupt
// we can access registers from that IO window range.
PCI : : enable_interrupt_line ( pci_address ( ) ) ;
enable_irq ( ) ;
2021-05-15 09:14:06 -03:00
reset_device ( ) ;
set_status_bit ( DEVICE_STATUS_ACKNOWLEDGE ) ;
2021-01-02 14:53:05 -03:00
set_status_bit ( DEVICE_STATUS_DRIVER ) ;
}
2021-09-23 04:20:54 -03:00
UNMAP_AFTER_INIT VirtIO : : Device : : Device ( PCI : : DeviceIdentifier const & device_identifier )
: PCI : : Device ( device_identifier . address ( ) )
2021-09-23 04:50:45 -03:00
, IRQHandler ( device_identifier . interrupt_line ( ) . value ( ) )
2021-09-23 04:20:54 -03:00
, m_class_name ( VirtIO : : determine_device_class ( device_identifier ) )
2021-09-04 02:42:31 -03:00
{
2021-09-19 12:28:27 -03:00
dbgln ( " {}: Found @ {} " , m_class_name , pci_address ( ) ) ;
2021-09-04 02:42:31 -03:00
}
2021-08-27 06:18:13 -03:00
void Device : : notify_queue ( u16 queue_index )
2021-01-02 14:53:05 -03:00
{
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: notifying about queue change at idx: {} " , m_class_name , queue_index ) ;
2021-04-15 06:12:06 -03:00
if ( ! m_notify_cfg )
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
base_io_window ( ) . write16 ( REG_QUEUE_NOTIFY , queue_index ) ;
2021-01-02 14:53:05 -03:00
else
2021-04-15 06:12:06 -03:00
config_write16 ( * m_notify_cfg , get_queue ( queue_index ) . notify_offset ( ) * m_notify_multiplier , queue_index ) ;
2021-01-02 14:53:05 -03:00
}
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
auto Device : : mapping_for_bar ( u8 bar ) - > IOWindow &
{
VERIFY ( m_use_mmio ) ;
VERIFY ( m_register_bases [ bar ] ) ;
return * m_register_bases [ bar ] ;
}
2022-04-01 14:58:27 -03:00
u8 Device : : config_read8 ( Configuration const & config , u32 offset )
2021-01-02 14:53:05 -03:00
{
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
return mapping_for_bar ( config . bar ) . read8 ( config . offset + offset ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
u16 Device : : config_read16 ( Configuration const & config , u32 offset )
2021-01-02 14:53:05 -03:00
{
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
return mapping_for_bar ( config . bar ) . read16 ( config . offset + offset ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
u32 Device : : config_read32 ( Configuration const & config , u32 offset )
2021-01-02 14:53:05 -03:00
{
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
return mapping_for_bar ( config . bar ) . read32 ( config . offset + offset ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
void Device : : config_write8 ( Configuration const & config , u32 offset , u8 value )
2021-01-02 14:53:05 -03:00
{
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
mapping_for_bar ( config . bar ) . write8 ( config . offset + offset , value ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
void Device : : config_write16 ( Configuration const & config , u32 offset , u16 value )
2021-01-02 14:53:05 -03:00
{
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
mapping_for_bar ( config . bar ) . write16 ( config . offset + offset , value ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
void Device : : config_write32 ( Configuration const & config , u32 offset , u32 value )
2021-01-02 14:53:05 -03:00
{
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
mapping_for_bar ( config . bar ) . write32 ( config . offset + offset , value ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
void Device : : config_write64 ( Configuration const & config , u32 offset , u64 value )
2021-01-02 14:53:05 -03:00
{
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
mapping_for_bar ( config . bar ) . write32 ( config . offset + offset , ( u32 ) ( value & 0xFFFFFFFF ) ) ;
mapping_for_bar ( config . bar ) . write32 ( config . offset + offset + 4 , ( u32 ) ( value > > 32 ) ) ;
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
u8 Device : : read_status_bits ( )
2021-01-02 14:53:05 -03:00
{
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg )
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
return base_io_window ( ) . read8 ( REG_DEVICE_STATUS ) ;
2021-04-15 06:12:06 -03:00
return config_read8 ( * m_common_cfg , COMMON_CFG_DEVICE_STATUS ) ;
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
void Device : : mask_status_bits ( u8 status_mask )
2021-01-02 14:53:05 -03:00
{
2021-05-14 15:11:26 -03:00
m_status & = status_mask ;
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg )
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
base_io_window ( ) . write8 ( REG_DEVICE_STATUS , m_status ) ;
2021-01-02 14:53:05 -03:00
else
2021-04-15 06:12:06 -03:00
config_write8 ( * m_common_cfg , COMMON_CFG_DEVICE_STATUS , m_status ) ;
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
void Device : : set_status_bit ( u8 status_bit )
2021-01-02 14:53:05 -03:00
{
m_status | = status_bit ;
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg )
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
base_io_window ( ) . write8 ( REG_DEVICE_STATUS , m_status ) ;
2021-01-02 14:53:05 -03:00
else
2021-04-15 06:12:06 -03:00
config_write8 ( * m_common_cfg , COMMON_CFG_DEVICE_STATUS , m_status ) ;
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
u64 Device : : get_device_features ( )
2021-01-02 14:53:05 -03:00
{
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg )
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
return base_io_window ( ) . read32 ( REG_DEVICE_FEATURES ) ;
2021-04-15 06:12:06 -03:00
config_write32 ( * m_common_cfg , COMMON_CFG_DEVICE_FEATURE_SELECT , 0 ) ;
auto lower_bits = config_read32 ( * m_common_cfg , COMMON_CFG_DEVICE_FEATURE ) ;
config_write32 ( * m_common_cfg , COMMON_CFG_DEVICE_FEATURE_SELECT , 1 ) ;
u64 upper_bits = ( u64 ) config_read32 ( * m_common_cfg , COMMON_CFG_DEVICE_FEATURE ) < < 32 ;
2021-01-02 14:53:05 -03:00
return upper_bits | lower_bits ;
}
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
IOWindow & Device : : base_io_window ( )
{
VERIFY ( m_register_bases [ 0 ] ) ;
return * m_register_bases [ 0 ] ;
}
2021-08-27 06:18:13 -03:00
bool Device : : accept_device_features ( u64 device_features , u64 accepted_features )
2021-01-02 14:53:05 -03:00
{
VERIFY ( ! m_did_accept_features ) ;
m_did_accept_features = true ;
if ( is_feature_set ( device_features , VIRTIO_F_VERSION_1 ) ) {
2021-04-15 06:39:48 -03:00
accepted_features | = VIRTIO_F_VERSION_1 ; // let the device know were not a legacy driver
2021-01-02 14:53:05 -03:00
}
if ( is_feature_set ( device_features , VIRTIO_F_RING_PACKED ) ) {
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: packed queues not yet supported " , m_class_name ) ;
2021-01-02 14:53:05 -03:00
accepted_features & = ~ ( VIRTIO_F_RING_PACKED ) ;
}
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;
}
2021-04-15 06:22:02 -03:00
if ( is_feature_set ( device_features , VIRTIO_F_IN_ORDER ) ) {
accepted_features | = VIRTIO_F_IN_ORDER ;
}
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Device features: {} " , m_class_name , device_features ) ;
dbgln_if ( VIRTIO_DEBUG , " {}: Accepted features: {} " , m_class_name , accepted_features ) ;
2021-01-02 14:53:05 -03:00
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg ) {
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
base_io_window ( ) . write32 ( REG_GUEST_FEATURES , accepted_features ) ;
2021-01-02 14:53:05 -03:00
} else {
2021-04-15 06:12:06 -03:00
config_write32 ( * m_common_cfg , COMMON_CFG_DRIVER_FEATURE_SELECT , 0 ) ;
config_write32 ( * m_common_cfg , COMMON_CFG_DRIVER_FEATURE , accepted_features ) ;
config_write32 ( * m_common_cfg , COMMON_CFG_DRIVER_FEATURE_SELECT , 1 ) ;
config_write32 ( * m_common_cfg , COMMON_CFG_DRIVER_FEATURE , accepted_features > > 32 ) ;
2021-01-02 14:53:05 -03:00
}
set_status_bit ( DEVICE_STATUS_FEATURES_OK ) ;
m_status = read_status_bits ( ) ;
if ( ! ( m_status & DEVICE_STATUS_FEATURES_OK ) ) {
set_status_bit ( DEVICE_STATUS_FAILED ) ;
2021-09-19 12:28:27 -03:00
dbgln ( " {}: Features not accepted by host! " , m_class_name ) ;
2021-01-02 14:53:05 -03:00
return false ;
}
m_accepted_features = accepted_features ;
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Features accepted by host " , m_class_name ) ;
2021-01-02 14:53:05 -03:00
return true ;
}
2021-08-27 06:18:13 -03:00
void Device : : reset_device ( )
2021-01-02 14:53:05 -03:00
{
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Reset device " , m_class_name ) ;
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg ) {
2021-05-14 15:11:26 -03:00
mask_status_bits ( 0 ) ;
2021-01-02 14:53:05 -03:00
while ( read_status_bits ( ) ! = 0 ) {
// TODO: delay a bit?
}
return ;
}
2021-04-15 06:12:06 -03:00
config_write8 ( * m_common_cfg , COMMON_CFG_DEVICE_STATUS , 0 ) ;
while ( config_read8 ( * m_common_cfg , COMMON_CFG_DEVICE_STATUS ) ! = 0 ) {
// TODO: delay a bit?
}
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
bool Device : : setup_queue ( u16 queue_index )
2021-01-02 14:53:05 -03:00
{
2021-04-15 06:12:06 -03:00
if ( ! m_common_cfg )
2021-01-02 14:53:05 -03:00
return false ;
2021-04-15 06:12:06 -03:00
config_write16 ( * m_common_cfg , COMMON_CFG_QUEUE_SELECT , queue_index ) ;
u16 queue_size = config_read16 ( * m_common_cfg , COMMON_CFG_QUEUE_SIZE ) ;
2021-01-02 14:53:05 -03:00
if ( queue_size = = 0 ) {
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Queue[{}] is unavailable! " , m_class_name , queue_index ) ;
2021-01-02 14:53:05 -03:00
return true ;
}
2021-04-15 06:12:06 -03:00
u16 queue_notify_offset = config_read16 ( * m_common_cfg , COMMON_CFG_QUEUE_NOTIFY_OFF ) ;
2021-01-02 14:53:05 -03:00
2022-01-21 06:51:02 -03:00
auto queue_or_error = Queue : : try_create ( queue_size , queue_notify_offset ) ;
if ( queue_or_error . is_error ( ) )
2021-01-02 14:53:05 -03:00
return false ;
2022-01-21 06:51:02 -03:00
auto queue = queue_or_error . release_value ( ) ;
2021-01-02 14:53:05 -03:00
2021-04-15 06:12:06 -03:00
config_write64 ( * m_common_cfg , COMMON_CFG_QUEUE_DESC , queue - > descriptor_area ( ) . get ( ) ) ;
config_write64 ( * m_common_cfg , COMMON_CFG_QUEUE_DRIVER , queue - > driver_area ( ) . get ( ) ) ;
config_write64 ( * m_common_cfg , COMMON_CFG_QUEUE_DEVICE , queue - > device_area ( ) . get ( ) ) ;
2021-01-02 14:53:05 -03:00
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Queue[{}] configured with size: {} " , m_class_name , queue_index , queue_size ) ;
2021-01-02 14:53:05 -03:00
m_queues . append ( move ( queue ) ) ;
return true ;
}
2021-08-27 06:18:13 -03:00
bool Device : : activate_queue ( u16 queue_index )
2021-04-15 06:17:49 -03:00
{
if ( ! m_common_cfg )
return false ;
config_write16 ( * m_common_cfg , COMMON_CFG_QUEUE_SELECT , queue_index ) ;
config_write16 ( * m_common_cfg , COMMON_CFG_QUEUE_ENABLE , true ) ;
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Queue[{}] activated " , m_class_name , queue_index ) ;
2021-04-15 06:17:49 -03:00
return true ;
}
2021-08-27 06:18:13 -03:00
bool Device : : setup_queues ( u16 requested_queue_count )
2021-01-02 14:53:05 -03:00
{
2021-04-15 06:39:48 -03:00
VERIFY ( ! m_did_setup_queues ) ;
m_did_setup_queues = true ;
2021-01-02 14:53:05 -03:00
if ( m_common_cfg ) {
2021-04-15 06:12:06 -03:00
auto maximum_queue_count = config_read16 ( * m_common_cfg , COMMON_CFG_NUM_QUEUES ) ;
2021-04-15 06:39:48 -03:00
if ( requested_queue_count = = 0 ) {
2021-01-02 14:53:05 -03:00
m_queue_count = maximum_queue_count ;
2021-04-15 06:39:48 -03:00
} else if ( requested_queue_count > maximum_queue_count ) {
2021-09-19 12:28:27 -03:00
dbgln ( " {}: {} queues requested but only {} available! " , m_class_name , m_queue_count , maximum_queue_count ) ;
2021-01-02 14:53:05 -03:00
return false ;
2021-04-15 06:39:48 -03:00
} else {
m_queue_count = requested_queue_count ;
2021-01-02 14:53:05 -03:00
}
2021-04-15 06:39:48 -03:00
} else {
m_queue_count = requested_queue_count ;
2021-09-19 12:28:27 -03:00
dbgln ( " {}: device's available queue count could not be determined! " , m_class_name ) ;
2021-01-02 14:53:05 -03:00
}
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Setting up {} queues " , m_class_name , m_queue_count ) ;
2021-01-02 14:53:05 -03:00
for ( u16 i = 0 ; i < m_queue_count ; i + + ) {
if ( ! setup_queue ( i ) )
return false ;
}
2021-04-15 06:17:49 -03:00
for ( u16 i = 0 ; i < m_queue_count ; i + + ) { // Queues can only be activated *after* all others queues were also configured
if ( ! activate_queue ( i ) )
return false ;
}
2021-01-02 14:53:05 -03:00
return true ;
}
2021-08-27 06:18:13 -03:00
void Device : : finish_init ( )
2021-01-02 14:53:05 -03:00
{
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
2021-04-15 06:39:48 -03:00
2021-01-02 14:53:05 -03:00
set_status_bit ( DEVICE_STATUS_DRIVER_OK ) ;
2021-09-19 12:28:27 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Finished initialization " , m_class_name ) ;
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
u8 Device : : isr_status ( )
2021-01-02 14:53:05 -03:00
{
2021-04-15 06:12:06 -03:00
if ( ! m_isr_cfg )
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
return base_io_window ( ) . read8 ( REG_ISR_STATUS ) ;
2021-04-15 06:12:06 -03:00
return config_read8 ( * m_isr_cfg , 0 ) ;
2021-01-02 14:53:05 -03:00
}
2022-04-01 14:58:27 -03:00
bool Device : : handle_irq ( RegisterState const & )
2021-01-02 14:53:05 -03:00
{
u8 isr_type = isr_status ( ) ;
2021-06-05 03:00:18 -03:00
if ( ( isr_type & ( QUEUE_INTERRUPT | DEVICE_CONFIG_INTERRUPT ) ) = = 0 ) {
2021-09-07 09:59:18 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Handling interrupt with unknown type: {} " , class_name ( ) , isr_type ) ;
2021-06-05 03:00:18 -03:00
return false ;
}
2021-04-15 06:12:06 -03:00
if ( isr_type & DEVICE_CONFIG_INTERRUPT ) {
2021-09-07 09:59:18 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: VirtIO Device config interrupt! " , class_name ( ) ) ;
2021-04-15 06:12:06 -03:00
if ( ! handle_device_config_change ( ) ) {
set_status_bit ( DEVICE_STATUS_FAILED ) ;
2021-09-07 09:59:18 -03:00
dbgln ( " {}: Failed to handle device config change! " , class_name ( ) ) ;
2021-04-15 06:12:06 -03:00
}
}
2021-01-02 14:53:05 -03:00
if ( isr_type & QUEUE_INTERRUPT ) {
2021-09-07 09:59:18 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: VirtIO Queue interrupt! " , class_name ( ) ) ;
2021-04-15 06:39:48 -03:00
for ( size_t i = 0 ; i < m_queues . size ( ) ; i + + ) {
2021-06-05 03:00:18 -03:00
if ( get_queue ( i ) . new_data_available ( ) ) {
handle_queue_update ( i ) ;
return true ;
}
2021-01-02 14:53:05 -03:00
}
2021-09-07 09:59:18 -03:00
dbgln_if ( VIRTIO_DEBUG , " {}: Got queue interrupt but all queues are up to date! " , class_name ( ) ) ;
2021-01-02 14:53:05 -03:00
}
2021-06-05 03:00:18 -03:00
return true ;
2021-01-02 14:53:05 -03:00
}
2021-08-27 06:18:13 -03:00
void Device : : supply_chain_and_notify ( u16 queue_index , QueueChain & chain )
2021-04-23 22:05:51 -03:00
{
auto & queue = get_queue ( queue_index ) ;
VERIFY ( & chain . queue ( ) = = & queue ) ;
VERIFY ( queue . lock ( ) . is_locked ( ) ) ;
chain . submit_to_queue ( ) ;
if ( queue . should_notify ( ) )
notify_queue ( queue_index ) ;
}
2021-01-02 14:53:05 -03:00
}