From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCcfV-000550-Iq for qemu-devel@nongnu.org; Sun, 09 Feb 2014 17:16:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCcfJ-00033g-Se for qemu-devel@nongnu.org; Sun, 09 Feb 2014 17:16:05 -0500 Received: from mail-ea0-x230.google.com ([2a00:1450:4013:c01::230]:41559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCcfJ-00033V-Ls for qemu-devel@nongnu.org; Sun, 09 Feb 2014 17:15:53 -0500 Received: by mail-ea0-f176.google.com with SMTP id h14so2589524eaj.21 for ; Sun, 09 Feb 2014 14:15:52 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52F7FE12.5070507@redhat.com> Date: Sun, 09 Feb 2014 23:15:46 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1391420690-23745-1-git-send-email-edgar.iglesias@gmail.com> <52F7834B.8060004@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 00/22] Steps towards per CPU address-spaces List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell , =?UTF-8?B?QW5kcmVhcyBGw6RyYg==?= =?UTF-8?B?ZXI=?= Cc: QEMU Developers , Blue Swirl , Anthony Liguori , pcrost@xilinx.com, "Edgar E. Iglesias" , Aurelien Jarno , Richard Henderson Il 09/02/2014 15:21, Peter Maydell ha scritto: > Consider a board model which puts together some RAM and > devices. It ought to have the same interface for passing this > up to the CPU whether it's doing so directly or via some SoC > container device. For the SoC container case, this has to be > by passing a MemoryRegion, since the SoC will want to add > some devices of its own to that region. So the interface for > passing things to the CPU should also be a MemoryRegion > (which the CPU then turns into an AddressSpace for its own > internal use.) I haven't look closely at those final patches either, but I think I agree with Peter. It's certainly okay if Andreas picks up these patches, since there's no formal MAINTAINER for the memory API. However, I'd prefer to first apply the patch to fix exec.c in order to keep bisection as clean as possible. Thanks! Paolo