From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3o7y-0007GR-2O for qemu-devel@nongnu.org; Wed, 14 Sep 2011 07:59:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3o7s-00014G-D3 for qemu-devel@nongnu.org; Wed, 14 Sep 2011 07:59:42 -0400 Message-ID: <4E709711.7030601@redhat.com> Date: Wed, 14 Sep 2011 14:59:13 +0300 From: Avi Kivity MIME-Version: 1.0 References: <1315989802-18753-1-git-send-email-agraf@suse.de> <1315989802-18753-6-git-send-email-agraf@suse.de> <4E708062.3020208@siemens.com> In-Reply-To: <4E708062.3020208@siemens.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 05/58] PPC: Add CPU local MMIO regions to MPIC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Peter Maydell , Alexander Graf , qemu-devel Developers , Blue Swirl , qemu-ppc@nongnu.org, Aurelien Jarno 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