From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35557) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WxjMQ-0007lL-PZ for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:55:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WxjMH-0008IU-Ox for qemu-devel@nongnu.org; Thu, 19 Jun 2014 16:55:06 -0400 Sender: Paolo Bonzini Message-ID: <53A34E0A.9020201@redhat.com> Date: Thu, 19 Jun 2014 22:54:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1401884936-12907-1-git-send-email-agraf@suse.de> In-Reply-To: <1401884936-12907-1-git-send-email-agraf@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/5] Platform device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf , qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org, eric.auger@linaro.org Il 04/06/2014 14:28, Alexander Graf ha scritto: > > But do we need that level of complexity for normal devices usually? In a > normal platform world (SoCs, PV machines) we have a flat memory layout we > can plug our device memory into. We also have a flat IRQ model where we > can plug our device IRQs into. > > So the idea for platform devices arose. A platform device is really just a > device that exposes its qemu_irq slots and memory regions to the world. > > That allows us to write machine specific code that maps a platform device > wherever the machine thinks fits nicely. It also allows that same machine > to generate a device tree entry for platform devices easily, as it is fully > aware of the interrupt lines and places it was mapped to. > > A device (read: user) may or may not explictly request to be mapped at a > specific IRQ and/or memory address. If no explicit mapping is requested, > platform devices can get mapped at convenient places by the machine. > > The actual pressing issue this solves is that today it's impossible to spawn > serial ports from the command line. With this patch set, it's possible to > do so. But it lays the groundwork for much more... I have more than a suspect that you and Peter Crosthwaite are trying to do the same. I hope that memory region QOMification can get into 2.1, that can be a starting point that we can work from. Paolo