From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] KVM call minutes 2013-01-29 - Port I/O Date: Wed, 30 Jan 2013 16:11:39 +0200 Message-ID: <20130130141139.GB2236@redhat.com> References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> <20130130123156.GA406@redhat.com> <87y5fa6bx2.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Peter Maydell , Andreas =?iso-8859-1?Q?F=E4rber?= , Juan Quintela , KVM devel mailing list , qemu-devel , Alexander Graf , =?iso-8859-1?Q?Herv=E9?= Poussineau , Gerd Hoffmann , qemu-ppc , Alon Levy , David Gibson To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:7526 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752126Ab3A3OI0 (ORCPT ); Wed, 30 Jan 2013 09:08:26 -0500 Content-Disposition: inline In-Reply-To: <87y5fa6bx2.fsf@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jan 30, 2013 at 07:24:57AM -0600, Anthony Liguori wrote: > "Michael S. Tsirkin" writes: >=20 > > On Wed, Jan 30, 2013 at 11:48:14AM +0000, Peter Maydell wrote: > >> On 30 January 2013 11:39, Andreas F=E4rber wrot= e: > >> > Proposal by hpoussin was to move _list_add() code to ISADevice: > >> > http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg00508.ht= ml > >> > > >> > 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 welcom= e. > >>=20 > >> 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... > > > > All programming is done by the OS, devices do not register > > with controller. > > > > Each bridge has two ways to claim an IO transaction: > > - transaction is within the window programmed in the bridge > > - subtractive decoding enabled and no one else claims the transacti= on >=20 > And there can only be one endpoint that accepts subtractive decoding = and > this is usually the ISA bridge. >=20 > Also note that there are some really special cases with PCI. The leg= acy > VGA ports are always routed to the first device with a DISPLAY class > type. >=20 > Likewise, with legacy IDE ports are routed to the first device with a= n > IDE class. That's the only reason you can have these legacy devices = not > behind the ISA bridge. >=20 > Regards, >=20 > Anthony Liguori Yes. And to futher clarify that, 'routed' in the sense that the spec specifies the addresses for each class, it's a hard-coded set of addresses. The hardware never looks at the class, each device of simply knows which addresses to claim and whether it's enabled. What happens if you have more than one VGA adapter on a bus? As long as only one is enabled, you are fine. If more than one is enabled, bad things will happen including possibly overheating. Also, it's not just the class that specifies the addresses, it's the programming interface too. =46or example for display, hardcoded addresses are used for legacy subl= ass 0x0 and for programming ifc 0x0 - vga compatible adapter and 0x1 - 8514 compatible adapter. But again - it specifies this to the OS. > > > > At the bus level, transaction happens on a bus and an appropriate d= evice > > will claim it. > > > >> 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, 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. > >>=20 > >> -- PMM