From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53534) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmVW-0001QW-P0 for qemu-devel@nongnu.org; Wed, 18 May 2011 15:34:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMmVV-0006C0-Lm for qemu-devel@nongnu.org; Wed, 18 May 2011 15:34:10 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:49144) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMmVV-0006Bu-JE for qemu-devel@nongnu.org; Wed, 18 May 2011 15:34:09 -0400 Received: by yxk8 with SMTP id 8so766567yxk.4 for ; Wed, 18 May 2011 12:34:08 -0700 (PDT) Message-ID: <4DD41F2D.3030600@codemonkey.ws> Date: Wed, 18 May 2011 14:34:05 -0500 From: Anthony Liguori 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> In-Reply-To: <4DD41DBB.2020108@web.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Avi Kivity , qemu-devel 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. > >> elif the I/O is in ROM regions: >> if PAM RE or WE >> redirect to RAM appropriately >> else: >> send to ROMs >> elif the I/O is in the PCI windows: >> send to the PCI bus >> else: >> send to the PIIX3 >> >> For x86, you could easily completely skip the explicit registration and >> just have a direct dispatch to the i440fx and implement something >> slightly more fancy than the above. >> >> And I think this is true for most other types of boards too. > > This all melts down that we need to stop accepting memory region > mappings from everywhere at core level, but properly dispatch them up > the device tree. A device should register against its bus which can then > forward or handle the mapping directly. And that handling requires a > central tool box to avoid reinventing wheels. > > That's a worthwhile change, though a much bigger one than I was > originally hoping to get away with. Agreed and as long as we've got the right long term vision in mind, we don't have to do everything up front. Regards, Anthony Liguori > Jan >