On Wed, Jan 30, 2013 at 06:55:47PM +0100, Andreas Färber wrote: > Am 30.01.2013 12:48, schrieb Peter Maydell: > > On 30 January 2013 11:39, Andreas Färber <afaerber@xxxxxxx> 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... > > > > 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, > > One remark on "same way as memory regions", me not knowing all the gory > hardware details myself. > > PIO often contradicts the normal MemoryRegion usage. I.e., for an MMIO > device you would have a continuous region from say 0xa0000000 to > 0xa007ffff inclusive and within that region you have some kind of sparse > registers. With ISA ports you often have dense overlapping ranges, say, > 0x3-0x6 byte-reads foo, while 0x4 word-write does bar. Hmm on x86 this is what happens with cf8..cfb range registers for example. We plan handle this ATM using memory region priorities. Same would work for prep won't it? > This is handled by having lists of (offset, length, size, handler) > quadruplets and consolidating those into MemoryRegions and aliases (cf. > patches) that then have a validation function to check whether a > particular access is valid and by whom it should be handled - that's > what MemoryRegionPortio[] and similar APIs are good for. > > So yes, it might be possible to have a device declare its ports at > PCIDevice or DeviceState level, but it can't be directly passed through > to MemoryRegion API in most cases, or conflicts would arise. At least > that was my experience with PReP. > > Andreas > > > 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 > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
