From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:57378)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QMkHC-0006tP-3b
	for qemu-devel@nongnu.org; Wed, 18 May 2011 13:11:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QMkHB-0007Fk-6x
	for qemu-devel@nongnu.org; Wed, 18 May 2011 13:11:14 -0400
Received: from mail-gy0-f173.google.com ([209.85.160.173]:47779)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <anthony@codemonkey.ws>) id 1QMkHB-0007Fg-1h
	for qemu-devel@nongnu.org; Wed, 18 May 2011 13:11:13 -0400
Received: by gyg4 with SMTP id 4so707229gyg.4
	for <qemu-devel@nongnu.org>; Wed, 18 May 2011 10:11:12 -0700 (PDT)
Message-ID: <4DD3FDAF.3010009@codemonkey.ws>
Date: Wed, 18 May 2011 12:11:11 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
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>
In-Reply-To: <4DD3F87E.7090505@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [RFC] Memory API
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Avi Kivity <avi@redhat.com>
Cc: Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel <qemu-devel@nongnu.org>

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.

Regards,

Anthony Liguori

>
> The priorities are determined by the device code.
>