Re: [Qemu-devel] [RFC] Memory API

[Anthony Liguori <anthony@codemonkey.ws>]

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.
>