From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkhb-0004sr-By for qemu-devel@nongnu.org; Wed, 18 May 2011 13:38:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMkha-0003BO-At for qemu-devel@nongnu.org; Wed, 18 May 2011 13:38:31 -0400 Received: from david.siemens.de ([192.35.17.14]:24432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMkhZ-0003B9-Vv for qemu-devel@nongnu.org; Wed, 18 May 2011 13:38:30 -0400 Message-ID: <4DD40411.1010106@siemens.com> Date: Wed, 18 May 2011 19:38:25 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3C5B9.1080908@redhat.com> <4DD3D236.90708@siemens.com> <4DD3E271.2010903@codemonkey.ws> <4DD3E53F.202@redhat.com> <4DD3F218.2040807@redhat.com> <4DD3F6EF.5000007@siemens.com> <4DD3F87E.7090505@redhat.com> <4DD3FDAF.3010009@codemonkey.ws> In-Reply-To: <4DD3FDAF.3010009@codemonkey.ws> Content-Type: text/plain; charset=UTF-8 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: Avi Kivity , qemu-devel On 2011-05-18 19:11, Anthony Liguori wrote: > On 05/18/2011 11:49 AM, Avi Kivity wrote: >> On 05/18/2011 07:42 PM, Jan Kiszka wrote: >>> On 2011-05-18 18:21, Avi Kivity wrote: >>>> On 05/18/2011 06:26 PM, Avi Kivity wrote: >>>>>> This is about registration. Right now you can only register IO >>>>>> intercepts in the chipset, not on a per-CPU basis. We could just as >>>>>> easily have: >>>>>> >>>>>> CPUState { >>>>>> MemoryRegion apic_region; >>>>>> }; >>>>>> >>>>>> per_cpu_register_memory(env,&env->apic_region); >>>>>> >>>>> >>>>> >>>>> Right. Or all memory per-cpu, with two sub-regions: >>>>> >>>>> - global memory >>>>> - overlaid apic memory >>>>> >>>>> for this, we need to have well defined semantics for overlap (perhaps >>>>> a priority argument to memory_region_add_subregion). >>>> >>>> Or even >>>> >>>> cpu_memory_region >>>> | >>>> +-- global memory map (prio 0) >>>> | | >>>> | +-- RAM (prio 0) >>>> | | >>>> | +-- PCI (prio 1) >>> >>> It depends on the chipset and its configuration (via PAM e.g.) in what >>> region which takes precedence. Fixed prios do not help here. > > It's really layering. > > To implement PAM in a robust way, you need a certain set of memory > accesses to first flow through the chipset before going to the next > location with the ability to intercept. > > We do something rather weird today by changing registrations first > saving the current registrations. It would be much more elegant to just > intercept the I/O requests and redirect accordingly. That's what I implemented already, though using the current API with some tweaks (filtering PhysMemClient) and then facing massive slot fragmentation problems on KVM side. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux