From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: KVM call minutes 2013-01-29 - Port I/O Date: Wed, 30 Jan 2013 22:55:43 +0200 Message-ID: <20130130205543.GB6544@redhat.com> References: <871ud4gfoa.fsf@elfo.elfo> <5109065B.4060803@suse.de> <51095EA3.3000703@suse.de> <20130130202024.GE6001@redhat.com> <51098381.8080106@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Maydell , KVM devel mailing list , Juan Quintela , Alexander Graf , qemu-devel , =?iso-8859-1?Q?Herv=E9?= Poussineau , Gerd Hoffmann , Anthony Liguori , qemu-ppc , David Gibson , Alon Levy To: Andreas =?iso-8859-1?Q?F=E4rber?= Return-path: Content-Disposition: inline In-Reply-To: <51098381.8080106@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 09:33:05PM +0100, Andreas F=E4rber wrote: > Am 30.01.2013 21:20, schrieb Michael S. Tsirkin: > > On Wed, Jan 30, 2013 at 06:55:47PM +0100, Andreas F=E4rber wrote: > >> Am 30.01.2013 12:48, schrieb Peter Maydell: > >>> On 30 January 2013 11:39, Andreas F=E4rber 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 > >>>> -> " 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, > >> > >> One remark on "same way as memory regions", me not knowing all the g= ory > >> hardware details myself. > >> > >> PIO often contradicts the normal MemoryRegion usage. I.e., for an MM= IO > >> device you would have a continuous region from say 0xa0000000 to > >> 0xa007ffff inclusive and within that region you have some kind of sp= arse > >> registers. With ISA ports you often have dense overlapping ranges, s= ay, > >> 0x3-0x6 byte-reads foo, while 0x4 word-write does bar. > >=20 > > Hmm on x86 this is what happens with cf8..cfb range registers for exa= mple. > > We plan handle this ATM using memory region priorities. > > Same would work for prep won't it? >=20 > Hm, my point was that iiuc a MemoryRegion is per-address-range whereas > for I/O ports we seem to have per-data-width mappings. > Priorities would allow us to say: >=20 > 0x1 - 0xff is one region > 0x8-0xab is a region with higher priority >=20 > but fallback for, e.g., word-access at 0xa0 to the lower-priority regio= n > being unsupported today, no? I.e., the region being opaque. No, MemoryRegion takes data width into account too. See 'PIIX3: reset the VM when the Reset Control Register's RCPU bit gets set' as one example. >=20 > Having said that, for the purposes of this discussion PReP is pretty > much a PC with a PowerPC CPU in it, unlike the modern CHRP machines. >=20 > Andreas >=20 > >> This is handled by having lists of (offset, length, size, handler) > >> quadruplets and consolidating those into MemoryRegions and aliases (= cf. > >> patches) that then have a validation function to check whether a > >> particular access is valid and by whom it should be handled - that's > >> what MemoryRegionPortio[] and similar APIs are good for. > >> > >> So yes, it might be possible to have a device declare its ports at > >> PCIDevice or DeviceState level, but it can't be directly passed thro= ugh > >> to MemoryRegion API in most cases, or conflicts would arise. At leas= t > >> that was my experience with PReP. >=20 > --=20 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrn= berg