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
