Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O

[Andreas Färber]

Am 30.01.2013 12:48, schrieb Peter Maydell:
> On 30 January 2013 11:39, Andreas Färber <address@hidden> 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.
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