[Top][All Lists]

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

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

From: Avi Kivity
Subject: Re: [Qemu-ppc] [PATCH 05/58] PPC: Add CPU local MMIO regions to MPIC
Date: Wed, 14 Sep 2011 14:59:13 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 09/14/2011 01:22 PM, Jan Kiszka wrote:
>  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.

That, plus SMRAM.

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.

For that we need a full conversion.

error compiling committee.c: too many arguments to function

reply via email to

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