From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57545) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMnYP-0000K9-OT for qemu-devel@nongnu.org; Wed, 18 May 2011 16:41:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMnYO-0001hk-Kk for qemu-devel@nongnu.org; Wed, 18 May 2011 16:41:13 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:46518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMnYO-0001hZ-Gv for qemu-devel@nongnu.org; Wed, 18 May 2011 16:41:12 -0400 Received: by yib19 with SMTP id 19so790856yib.4 for ; Wed, 18 May 2011 13:41:11 -0700 (PDT) Message-ID: <4DD42EE5.8000705@codemonkey.ws> Date: Wed, 18 May 2011 15:41:09 -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> <4DD41F2D.3030600@codemonkey.ws> <4DD426F7.60301@web.de> In-Reply-To: <4DD426F7.60301@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 03:07 PM, Jan Kiszka wrote: > On 2011-05-18 21:34, 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. > > Hmm, checking again, I think the APIC should not show up here at all. We > really need to filter it out very early at CPU level, i.e. when creating > the iotlb (or when dispatching a KVM EXIT_MMIO). It's cpu local, nothing > the chipset will ever see. > > I really wonder now why I dropped the idea of handling per-cpu regions > as a special case in tlb_set_page. It looks trivial, could even be done > with a linear per-cpu list before looking at any chipset mappings. Yup, I agree this is the right way to do it. Regards, Anthony Liguori > > Jan >