Re: [Qemu-devel] [PATCH 05/58] PPC: Add CPU local MMIO regions to MPIC

[Jan Kiszka]

On 2011-09-14 12:07, Peter Maydell wrote:
> On 14 September 2011 09:42, Alexander Graf <address@hidden> wrote:
>> The MPIC exports a register set for each CPU connected to it. They can all
>> be accessed through specific registers or using a shadow page that is mapped
>> differently depending on which CPU accesses it.
>>
>> This patch implements the shadow map, making it possible for guests to access
>> the CPU local registers using the same address on each CPU.
> 
>> +static int get_current_cpu(void)
>> +{
>> +  return cpu_single_env->cpu_index;
>> +}
> 
> This is the standard way of doing this (we use it on ARM as well), but
> it's pretty clearly a hack. "which master sent this memory transaction"
> is an attribute that ought to be passed down to the MMIO read/write
> functions, really (along with other interesting things like "priv or
> not?" and probably architecture specific attributes like ARM's
> "secure/non-secure"); this matches how hardware does it where the
> attributes are passed along as extra signals in the bus fabric.
> (Sometimes hardware also does this by having buses from the different
> cores be totally separate paths at the point where this kind of device
> is connected, before merging together later; we don't really support
> modelling that either :-))
> 
> Not a nak, just an observation while I'm thinking about it.

Same problem has to be solved on x86. The way the local APIC is hooked
up right now is totally broken, just works by chance because normal
guests don't seriously stress the architecture.

If we start dispatching CPU memory accesses via per-CPU memory roots,
the problem can be solved without passing additional source information
to the callbacks.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux