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 09:08:36 -0600 Message-ID: <87d2wm674b.fsf@codemonkey.ws> References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> <878v7a24xr.fsf@blackfin.pond.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andreas =?utf-8?Q?F=C3=A4rber?= , KVM devel mailing list , "Michael S. Tsirkin" , Juan Quintela , Alexander Graf , qemu-devel , =?utf-8?Q?Herv=C3=A9?= Poussineau , Gerd Hoffmann , qemu-ppc , David Gibson , Alon Levy To: Markus Armbruster , Peter Maydell Return-path: Received: from mail-ie0-f177.google.com ([209.85.223.177]:50149 "EHLO mail-ie0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752294Ab3A3PIk convert rfc822-to-8bit (ORCPT ); Wed, 30 Jan 2013 10:08:40 -0500 Received: by mail-ie0-f177.google.com with SMTP id 16so1356886iea.36 for ; Wed, 30 Jan 2013 07:08:39 -0800 (PST) In-Reply-To: <878v7a24xr.fsf@blackfin.pond.sub.org> Sender: kvm-owner@vger.kernel.org List-ID: Markus Armbruster writes: > Peter Maydell writes: > >> On 30 January 2013 11:39, Andreas F=C3=A4rber wro= te: >>> 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 >>> -> " 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. >> >> 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... >> >> 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. > > Makes sense me, but I'm naive, too :) > > For me, "I/O ports" are just an alternate address space some devices > have. For instance, x86 CPUs have an extra pin for selecting I/O > vs. memory address space. The ISA bus has separate read/write pins f= or > memory and I/O. > > This isn't terribly special. Mapping address spaces around is what > devices bridging buses do. > > I'd expect a system bus for an x86 CPU to have both a memory and an I= /O > address space. There is no such thing as a "system bus". There is a bus that links the CPUs to each other and to the North Bridge. This is QPI on modern systems. Sometimes there's a bus to link the North Bridge to the South Bridge. On modern systems, this is QPI. On the i440fx, the i440fx is both the South Bridge and North Bridge and the link between the two is internal to the chip. The South Bridge may then export one or more downstream interfaces. In the i440fx, it only exports PCI. Behind the PCI bus, there may be bridges. On the i440fx, there is a IS= A Bridge which also acts as a Super I/O chip. It exposes a downstream IS= A bus. sysbus is a relic of poor modeling. A major milestone in QEMU's evolution will be when sysbus is completely removed. Regards, Anthony Liguori > > I'd expect an ISA PC's sysbus - ISA bridge to map both directly. > > I'd expect an ISA bridge for a sysbus without a separate I/O address > space to map the ISA I/O address space into the sysbus's normal addre= ss > space somehow. > > PCI ISA bridges have their own rules, but I've gotten away with ignor= ing > the details so far :)