Hi,
I had a look at your patches regarding I/O port registration but they are
unfortunately not correct. You seem to have a misconception of how port I/O
works in the x86 architecture and assume that it behaves much like memory.
That's not the case.
You already suspected that you were doing something wrong when you tried to
adapt the VGA ports 0x1ce/0x1cf. Those ports highlight how things really
behave--it's possible to have a 16-bit port at address N and another 16-bit
port at address N+1 and those ports do not overlap. A classic and very
widespread example found in real hardware is the IDE data port (typically at
0x1F0) which is accessed as 16-bit or 32-bit, yet is completely separate from
the ports at addresses 0x1f1/0x1f2/0x1f3 (feature register/sector count/sector
number).
VirtualBox models this behavior. The I/O port registration via
PDMDevHlpIOPortRegister() determines the range of I/O addresses which a device
responds to, but it is up to the device to deal with byte/word/dword accesses
to each individual address.
In reality, it is possible to have even more interesting behavior. As an
example, consider the CONFIG_ADDRESS PCI register at 0xCF8 (you came across
that one too). The PCI 2.2 specification says in section 3.2.2.3.2, Software
Generation of Configuration Transactions: "[...] the only I/O Space consumed by
this register is a DWORD at the given address. I/O devices that share the same
address but use BYTE or WORD registers are not affected because their
transactions will pass through the host bridge unchanged." VirtualBox does not
model the case where different devices respond to different-size accesses at
the same address because it never comes up with the hardware we emulate. I
should also point out that the CONFIG_DATA register at 0xCFC *does* behave
somewhat more like memory and responds to accesses within the entire
0xCFC-0xCFF range... but that is more of an exception than the rule.
Your patch tries to change the CONFIG_ADDRESS (0xCF8) registration to cover 4
consecutive I/O addresses, but as you can see in the quote above, that would
directly contradict the PCI specification which states that the PCI host bridge
does not respond to port I/O in the 0xCF9-0xCFB range. In theory, a completely
different device could respond to I/O accesses in that range.
The bottom line is that architecturally, the I/O port address and the access
size are considered independently. In VirtualBox, the port address alone
determines which device will handle the access, and it's then up to the device
to decide what it does with the access size. This is a slightly simplified
version of the actual hardware behavior, but it's sufficient to emulate all
common hardware.
Regards,
Michal
---------------
Hi,
we had for VBox@Genode/Nova to implement our own version of the IO
Monitor. During usage we detected some minor issues in the ACPI, PCI and
VGA device model between announced/registered IO ports access width and
its actual access width usage.
Please review the patches and tell me whether they/some of them make
sense to you. They are in the first place non-critical, however our IOM
implementation complains/deny access by guests to device models if the
i/O access width is bigger than registered by the device model.
_______________________________________________
vbox-dev mailing list
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
