From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wxk4p-0004cV-Qz for qemu-devel@nongnu.org; Thu, 19 Jun 2014 17:41:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wxk4h-0006ye-0R for qemu-devel@nongnu.org; Thu, 19 Jun 2014 17:40:59 -0400 Message-ID: <53A358E1.5040706@suse.de> Date: Thu, 19 Jun 2014 23:40:49 +0200 From: Alexander Graf MIME-Version: 1.0 References: <1401884936-12907-1-git-send-email-agraf@suse.de> <1401884936-12907-5-git-send-email-agraf@suse.de> <53A2FA33.8070802@linaro.org> In-Reply-To: <53A2FA33.8070802@linaro.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/5] PPC: e500: Support platform devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Auger , qemu-ppc@nongnu.org Cc: qemu-devel@nongnu.org On 19.06.14 16:56, Eric Auger wrote: > On 06/04/2014 02:28 PM, Alexander Graf wrote: >> For e500 our approach to supporting platform devices is to create a simple >> bus from the guest's point of view within which we map platform devices >> dynamically. >> >> We allocate memory regions always within the "platform" hole in address >> space and map IRQs to predetermined IRQ lines that are reserved for platform >> device usage. >> >> This maps really nicely into device tree logic, so we can just tell the >> guest about our virtual simple bus in device tree as well. > Hi Alex, > > this "qemu_add_machine_init_done_notifier" was the qemu mechanism I > missed in my patch. You light my way ;-) > > One first comment is it would make much sense to reuse your code in arm > virt.c too. I am currently doing the exercise. Do you think it would be > possible to share a common helper code, outside of e500 machine code? Yes, definitely :). I was mostly doing it in e500.c as a starting point. The second implementation (virt.c apparently) would then go in and commonalize everything it thinks should be common. I'm not 100% sure where the right line is here though. For the implementation today I just throw everything into a new virtual platform bus for the guest. But there's no reason I couldn't detect "this is the first UART in my system" and put it in place where the real first UART would be in CCSR. So yeah, again, I'm not 100% sure where the right line of distinction between board specific and generic code is here :). Alex