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@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
