From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLA5Y-0006s2-Sx for qemu-devel@nongnu.org; Fri, 31 Jul 2015 09:11:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZLA5S-0004Cj-Tm for qemu-devel@nongnu.org; Fri, 31 Jul 2015 09:11:04 -0400 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:37308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZLA5S-0004CK-MB for qemu-devel@nongnu.org; Fri, 31 Jul 2015 09:10:58 -0400 Received: by wibud3 with SMTP id ud3so31464625wib.0 for ; Fri, 31 Jul 2015 06:10:58 -0700 (PDT) Sender: Paolo Bonzini References: <55B63805.8050603@virtualopensystems.com> From: Paolo Bonzini Message-ID: <55BB73E0.6030408@redhat.com> Date: Fri, 31 Jul 2015 15:10:56 +0200 MIME-Version: 1.0 In-Reply-To: <55B63805.8050603@virtualopensystems.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Towards an Heterogeneous QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Pinto , qemu-devel@nongnu.org Cc: Jani Kokkonen , VirtualOpenSystems Technical Team , Claudio Fontana On 27/07/2015 15:54, Christian Pinto wrote: > From the user point of view there is usually an operating system > booting on the Master processor (e.g. Linux) at platform startup, > while the other processors are used to offload the Master one from > some computation or to deal with real-time interfaces. It is the > Master OS that triggers the boot of the Slave processors, and > provides them also the binary code to execute (e.g. RTOS, binary > firmware) by placing it into a pre-defined memory area that is > accessible to the Slaves. Usually the memory for the Slaves is > carved out from the Master OS during boot. Once a Slave is booted the > two processors can communicate through queues in shared memory and > inter-processor interrupts (IPIs). In Linux, it is the > remoteproc/rpmsg framework that enables the control (boot/shutdown) > of Slave processors, and also to establish a communication channel > based on virtio queues. > > Currently, QEMU is not able to model such an architecture, mainly > because only a single processor can be emulated at one time, and the > OS binary image needs to be placed in memory at model startup. Hi, you may be interested in the "multi-arch" patches here: http://thread.gmane.org/gmane.comp.emulators.qemu/351808 These do roughly what you are saying, though in a single QEMU process. Paolo