From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: KVM call minutes 2013-01-29 - Port I/O
Date: Wed, 30 Jan 2013 14:31:56 +0200
Message-ID: <20130130123156.GA406@redhat.com>
References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de>
	<CAFEAcA_R2SnZ0aOaxFyavSEaq=RDMgWj5V53dAtn+yFEUvEj_g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: KVM devel mailing list <kvm@vger.kernel.org>,
	Juan Quintela <quintela@redhat.com>, qemu-devel <qemu-devel@nongnu.org>,
	Alexander Graf <agraf@suse.de>,
	=?iso-8859-1?Q?Herv=E9?= Poussineau <hpoussin@reactos.org>,
	Gerd Hoffmann <kraxel@redhat.com>, Anthony Liguori <anthony@codemonkey.ws>,
	qemu-ppc <qemu-ppc@nongnu.org>, David Gibson <david@gibson.dropbear.id.au>,
	Andreas =?iso-8859-1?Q?F=E4rber?= <afaerber@suse.de>,
	Alon Levy <alevy@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Return-path: <qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org>
Content-Disposition: inline
In-Reply-To: <CAFEAcA_R2SnZ0aOaxFyavSEaq=RDMgWj5V53dAtn+yFEUvEj_g@mail.gmail.com>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org
List-Id: kvm.vger.kernel.org

On Wed, Jan 30, 2013 at 11:48:14AM +0000, Peter Maydell wrote:
> On 30 January 2013 11:39, Andreas F=E4rber <afaerber@suse.de> 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
> >   =3D> above patches add dependency on ISABus to machines
> >      -> "<benh> 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.
>=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 transaction

At the bus level, transaction happens on a bus and an appropriate device
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