From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMn5P-0003xM-CC for qemu-devel@nongnu.org; Wed, 18 May 2011 16:11:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMn5O-0004Q3-1g for qemu-devel@nongnu.org; Wed, 18 May 2011 16:11:15 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:41703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMn5N-0004Pu-MF for qemu-devel@nongnu.org; Wed, 18 May 2011 16:11:14 -0400 Message-ID: <4DD427DE.7040306@web.de> Date: Wed, 18 May 2011 22:11:10 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E610.1080201@siemens.com> <4DD4199E.2000702@codemonkey.ws> <4DD41DBB.2020108@web.de> <4DD41F2D.3030600@codemonkey.ws> <1305748942.29268.54.camel@x201> In-Reply-To: <1305748942.29268.54.camel@x201> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig76BA3908D58FC4FDD316961E" Sender: jan.kiszka@web.de Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: Peter Maydell , Avi Kivity , qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76BA3908D58FC4FDD316961E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2011-05-18 22:02, Alex Williamson wrote: > On Wed, 2011-05-18 at 14:34 -0500, Anthony Liguori wrote: >> On 05/18/2011 02:27 PM, Jan Kiszka wrote: >>> On 2011-05-18 21:10, Anthony Liguori wrote: >>>> On 05/18/2011 10:30 AM, Jan Kiszka wrote: >>>> You really don't need to register 90% of the time. In the case of a= PC >>>> with i440fx, it's really quite simple: >>>> >>>> if an I/O is to the APIC page, >>>> it's handled by the APIC >>> >>> That's not that simple. We need to tell apart: >>> - if a cpu issued the request, and which one =3D> forward to APIC >> >> Right, but what I'm saying is that this logic lives in=20 >> kvm-all.c:kvm_run():case EXIT_MMIO. >> >> Obviously for TCG, it's a bit more complicated but this should be=20 >> handled way before there's any kind of general dispatch. >> >>> - if the range was addressed by a device (PCI or other system bus >>> devices) =3D> forward to MSI or other MMIO handlers >> >> The same is true for MSI. Other MMIO handlers can be handled as=20 >> appropriate. For instance, once an I/O is sent to the PCI bus, you ca= n=20 >> walk each PCI device's BAR list to figure out which device owns the I/= O=20 >> event. >> >> For ISA, it's a little trickier since ISA doesn't do positive decoding= =2E=20 >> You need each ISA device to declare what I/O addresses it handles. >=20 > Do we only need to handle CPU based I/O with this API? I would think w= e > would be layering memory regions and implementing them as a hierarchy > that reflects the actual hardware layout we're emulating. An access > from an I/O device may get a different translation to memory than a CPU= > (IOMMU). We also might have a system with two VGA devices that both > register 0xa0000 with a switch in the chipset that decides which one > sees the accesses, just as real hardware does. ISTR a presentation at > one of the first KVM forums from you that talked about this type of > model. Thanks, IIUC, that switch is present in every PCI bridge. It can forward legacy VGA I/O request to its devices or ignore them. Jan --------------enig76BA3908D58FC4FDD316961E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk3UJ94ACgkQitSsb3rl5xQA2QCgwaJZGdc/BJjnqEykJrBZRhhO 6GMAoMRjTbjcnL+wDdsvLaYolhkJFXWt =BHaY -----END PGP SIGNATURE----- --------------enig76BA3908D58FC4FDD316961E--