Andreas Färber <afaerber@xxxxxxx> 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 -- 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
