From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmwv-0000UR-FK for qemu-devel@nongnu.org; Wed, 18 May 2011 16:02:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMmwu-0002t6-Kx for qemu-devel@nongnu.org; Wed, 18 May 2011 16:02:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:8076) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmwu-0002se-Ds for qemu-devel@nongnu.org; Wed, 18 May 2011 16:02:28 -0400 From: Alex Williamson In-Reply-To: <4DD41F2D.3030600@codemonkey.ws> 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> Content-Type: text/plain; charset="UTF-8" Date: Wed, 18 May 2011 14:02:22 -0600 Message-ID: <1305748942.29268.54.camel@x201> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Jan Kiszka , Avi Kivity , qemu-devel 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 => forward to APIC > > Right, but what I'm saying is that this logic lives in > kvm-all.c:kvm_run():case EXIT_MMIO. > > Obviously for TCG, it's a bit more complicated but this should be > handled way before there's any kind of general dispatch. > > > - if the range was addressed by a device (PCI or other system bus > > devices) => forward to MSI or other MMIO handlers > > The same is true for MSI. Other MMIO handlers can be handled as > appropriate. For instance, once an I/O is sent to the PCI bus, you can > walk each PCI device's BAR list to figure out which device owns the I/O > event. > > For ISA, it's a little trickier since ISA doesn't do positive decoding. > You need each ISA device to declare what I/O addresses it handles. Do we only need to handle CPU based I/O with this API? I would think we 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, Alex