Am 30.01.2013 21:20, schrieb Michael S. Tsirkin: > 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? Hm, my point was that iiuc a MemoryRegion is per-address-range whereas for I/O ports we seem to have per-data-width mappings. Priorities would allow us to say: 0x1 - 0xff is one region 0x8-0xab is a region with higher priority but fallback for, e.g., word-access at 0xa0 to the lower-priority region being unsupported today, no? I.e., the region being opaque. Having said that, for the purposes of this discussion PReP is pretty much a PC with a PowerPC CPU in it, unlike the modern CHRP machines. Andreas >> 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. -- 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
