[Top][All Lists]

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

Re: [Qemu-ppc] [Qemu-devel] [PATCH 05/58] PPC: Add CPU local MMIO region

From: Alexander Graf
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 05/58] PPC: Add CPU local MMIO regions to MPIC
Date: Wed, 14 Sep 2011 12:11:48 +0200

Am 14.09.2011 um 12:07 schrieb Peter Maydell <address@hidden>:

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

Yeah, I tend to agree in general. I'm not 100% sure in this case, as it's 
almost an in-cpu device. But it would be nice to pass this information on the 
mmio callbacks.

However, right now this is the only way to do it, as we don't have the pretty 
flexible one implemented yet ;).



reply via email to

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