[vbox-dev] Patches for access width of IO ports in acpi, pci, vga device model

[Alexander Boettcher]

Hi,

I see. Thanks for clarification.

Alex.

On 10.03.2014 13:00, Michal Necasek wrote:
> 
>    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 at 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.
>