Re: KVM call minutes 2013-01-29 - Port I/O

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Jan 30, 2013 at 09:33:05PM +0100, Andreas Färber wrote:
> 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@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...
> >>>
> >>> 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.

No, MemoryRegion takes data width into account too.
See 'PIIX3: reset the VM when the Reset Control Register's RCPU bit gets
set' as one example.

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