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

[Anthony Liguori]

Andreas Färber <address@hidden> writes:

> Am 29.01.2013 16:41, schrieb Juan Quintela:
>> * Portio port to new memory regions?
>>   Andreas, could you fill?
>
> MemoryRegion's .old_portio mechanism requires workarounds for VGA on
> ppc, affecting among others the sPAPR PCI host bridge:
> http://git.qemu.org/?p=qemu.git;a=commit;h=a3cfa18eb075c7ef78358ca1956fe7b01caa1724
>
> Patches were posted and merged removing all .old_portio users but one:
> hw/ioport.c:portio_list_add_1(), used by portio_list_add()
>
> hw/isa-bus.c:    portio_list_add(piolist, isabus->address_space_io, start);
> hw/qxl.c:    portio_list_add(qxl_vga_port_list,
> pci_address_space_io(dev), 0x3b0);
> hw/vga.c:        portio_list_add(vga_port_list, address_space_io, 0x3b0);
> hw/vga.c:        portio_list_add(vbe_port_list, address_space_io, 0x1ce);
>
> Proposal by hpoussin was to move _list_add() code to ISADevice:
> http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.html

Okay, a couple things here:

There is no such thing as "PIO" as a general concept.  What leaves the
CPU and what a bus interprets are totally different things.

An x86 CPU has a MMIO capability that's essentially 65 bits.  Whether
the top bit is set determines whether it's a "PIO" transaction or an
"MMIO" transaction.  A large chunk of that address space is invalid of
course.

PCI has a 65 bit address space too.  The 65th bit determines whether
it's an IO transaction or an MMIO transaction.

For architectures that only have a 64-bit address space, what the PCI
controller typically does is pick a 16-bit window within that address
space to map to a PCI address with the 65th bit set.

Within the PCI bus, transactions are usually routed to devices via
positive decoding.  The device lists what address regions it wants to
handle (via BARs) and the PCI bus uses those to determine who to send
transactions to.

There are some exceptions though.  Specifically:

1) A chipset will route any non-positively decoded IO transaction (65th
   bit set) to a single end point (usually the ISA-bridge).  Which one it
   chooses is up to the chipset.  This is called subtractive decoding
   because the PCI bus will wait multiple cycles for that device to
   claim the transaction before bouncing it.

2) There are special hacks in most PCI chipsets to route very specific
   addresses ranges to certain devices.  Namely, legacy VGA IO transactions
   go to the first VGA device.  Legacy IDE IO transactions go to the first
   IDE device.  This doesn't need to be programmed in the BARs.  It will
   just happen.

3) As it turns out, all legacy PIIX3 devices are positively decoded and
   sent to the ISA-bridge (because it's faster this way).

Notice the lack of the word "ISA" in all of this other than describing
the PCI class of an end point.

So how should this be modeled?

On x86, the CPU has a pio address space.  That can propagate down
through the PCI bus which is what we do today.

On !x86, the PCI controller ought to setup a MemoryRegion for downstream
PIO that devices can use to register on.

We probably need to do something like change the PCI VGA devices to
export a MemoryRegion and allow the PCI controller to device how to
register that as a subregion.

Regards,

Anthony Liguori

>
> 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.
>
> Regards,
> Andreas
>
> -- 
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg