According to the VirtIO 1.0 specification:
"Non-transitional devices SHOULD have a PCI Device ID in the range
0x1040 to 0x107f. Non-transitional devices SHOULD have a PCI Revision ID
of 1 or higher. Non-transitional devices SHOULD have a PCI Subsystem
Device ID of 0x40 or higher."
It also says that:
"Transitional devices MUST have a PCI Revision ID of 0. Transitional
devices MUST have the PCI Subsystem Device ID matching the Virtio
Device ID, as indicated in section 5. Transitional devices MUST have the
Transitional PCI Device ID in the range 0x1000 to 0x103f."
So, for legacy devices, we know that revision ID in the PCI header won't
be 1, so we probe for PCI_SUBSYSTEM_ID value.
Instead of using the subsystem device ID, we can probe the DEVICE_ID
value directly in case it's not a legacy device.
This should cover all possibilities for identifying VirtIO devices, both
per the specification of 0.9.5, and future revisions from 1.0 onwards.
Now that the old PCI::Device was removed, we can complete the PCI
changes by making the PCI::DeviceController to be named PCI::Device.
Really the entire purpose and the distinction between the two was about
interrupts, but since this is no longer a problem, just rename it to
simplify things further.
I created this class a long time ago just to be able to quickly make a
PCI device to also represent an interrupt handler (because PCI devices
have this capability for most devices).
Then after a while I introduced the PCI::DeviceController, which is
really almost the same thing (a PCI device class that has Address member
in it), but is not tied to interrupts so it can have no interrupts, or
spawn interrupt handlers however it wants to seems fit.
However I decided it's time to say goodbye for this class for
a couple of reasons:
1. It made a whole bunch of weird patterns where you had a PCI::Device
and a PCI::DeviceController being used in the topic of implementation,
where originally, they meant to be used mutually exclusively (you
can't and really don't want to use both).
2. We can really make all the classes that inherit from PCI::Device
to inherit from IRQHandler at this point. Later on, when we have MSI
interrupts support, we can go further and untie things even more.
3. It makes it possible to simplify the VirtIO implementation to a great
extent. While this commit almost doesn't change it, future changes
can untangle some complexity in the VirtIO code.
For UHCIController, E1000NetworkAdapter, NE2000NetworkAdapter,
RTL8139NetworkAdapter, RTL8168NetworkAdapter, E1000ENetworkAdapter we
are simply making them to inherit the IRQHandler. This makes some sense,
because the first 3 devices will never support anything besides IRQs.
For the last 2, they might have MSI support, so when we start to utilize
those, we might need to untie these classes from IRQHandler and spawn
IRQHandler(s) or MSIHandler(s) as needed.
The VirtIODevice class is also a case where we currently need to use
both PCI::DeviceController and IRQHandler classes as parents, but it
could also be untied from the latter.
There's no need for generated files in SysFS to tell you their precise
file size when you stat() them.
I noticed when profiling "find /" that we were spending a chunk of time
generating and throwing away SysFS content just so we could tell you
exactly how large it would be. :^)
This is a bug that went unnoticed for a long time, so the exposed values
in SysFS PCI device directories were incorrect because the assigned PCI
address was simply the host bridge always.
Also, the bus typing should really be two hexadecimal digits and not 4
digits.
Instead of each PhysicalPage knowing whether it comes from the
supervisor pages or from the user pages, we can just check in both
sets when freeing a page.
It's just a handful of pointer range checks, nothing expensive.