qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Wed, 18 May 2011 12:11:11 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]