"Michael S. Tsirkin" <m...@redhat.com> writes: > On Wed, Jan 30, 2013 at 11:48:14AM +0000, Peter Maydell wrote: >> On 30 January 2013 11:39, Andreas Färber <afaer...@suse.de> wrote: >> > Proposal by hpoussin was to move _list_add() code to ISADevice: >> > http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html >> > >> > Concerns: >> > * PCI devices (VGA, QXL) register I/O ports as well >> > => above patches add dependency on ISABus to machines >> > -> "<benh> no mac ever had one" >> > => PCIDevice shouldn't use ISA API with NULL ISADevice >> > * Lack of avi: Who decides about memory API these days? >> > >> > armbru and agraf concluded that moving this into ISA is wrong. >> > >> > => I will drop the remaining ioport patches from above series. >> > >> > Suggestions on how to proceed with tackling the issue are welcome. >> >> How does this stuff work on real hardware? I would have >> expected that a PCI device registering the fact it has >> IO ports would have to do so via the PCI controller it >> is plugged into... > > All programming is done by the OS, devices do not register > with controller. > > Each bridge has two ways to claim an IO transaction: > - transaction is within the window programmed in the bridge > - subtractive decoding enabled and no one else claims the transaction
And there can only be one endpoint that accepts subtractive decoding and this is usually the ISA bridge. Also note that there are some really special cases with PCI. The legacy VGA ports are always routed to the first device with a DISPLAY class type. Likewise, with legacy IDE ports are routed to the first device with an IDE class. That's the only reason you can have these legacy devices not behind the ISA bridge. Regards, Anthony Liguori > > At the bus level, transaction happens on a bus and an appropriate device > will claim it. > >> My naive don't-know-much-about-portio suggestion is that this >> should work the same way as memory regions: each device >> provides portio regions, and the controller for the bus >> (ISA or PCI) exposes those to the next layer up, and >> something at board level maps it all into the right places. >> >> -- PMM -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
