From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O Date: Wed, 30 Jan 2013 07:59:41 -0600 Message-ID: <87vcae6ab6.fsf@codemonkey.ws> References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: KVM devel mailing list , qemu-devel , Alexander Graf , Benjamin Herrenschmidt , qemu-ppc , =?utf-8?Q?Herv=C3=A9?= Poussineau , David Gibson , Gerd Hoffmann , Alon Levy , "Michael S. Tsirkin" To: Andreas =?utf-8?Q?F=C3=A4rber?= , Juan Quintela Return-path: Received: from mail-ia0-f169.google.com ([209.85.210.169]:59703 "EHLO mail-ia0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753766Ab3A3N7q convert rfc822-to-8bit (ORCPT ); Wed, 30 Jan 2013 08:59:46 -0500 Received: by mail-ia0-f169.google.com with SMTP id j5so2381905iaf.28 for ; Wed, 30 Jan 2013 05:59:45 -0800 (PST) In-Reply-To: <5109065B.4060803@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Andreas F=C3=A4rber 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=3Dqemu.git;a=3Dcommit;h=3Da3cfa18eb075c7ef7835= 8ca1956fe7b01caa1724 > > 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, s= tart); > 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, 0x3= b0); > hw/vga.c: portio_list_add(vbe_port_list, address_space_io, 0x1= ce); > > 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. =46or 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 transact= ions go to the first VGA device. Legacy IDE IO transactions go to the fi= rst IDE device. This doesn't need to be programmed in the BARs. It wil= l 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 downstrea= m 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 > =3D> above patches add dependency on ISABus to machines > -> " no mac ever had one" > =3D> 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. > > =3D> I will drop the remaining ioport patches from above series. > > Suggestions on how to proceed with tackling the issue are welcome. > > Regards, > Andreas > > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N= =C3=BCrnberg