From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42072) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qcccg-0000op-Pp for qemu-devel@nongnu.org; Fri, 01 Jul 2011 08:15:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qcccd-00058g-AG for qemu-devel@nongnu.org; Fri, 01 Jul 2011 08:15:02 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:48589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qcccc-00058R-Ua for qemu-devel@nongnu.org; Fri, 01 Jul 2011 08:14:59 -0400 Received: by yia25 with SMTP id 25so1532582yia.4 for ; Fri, 01 Jul 2011 05:14:57 -0700 (PDT) Message-ID: <4E0DBA3F.1000603@codemonkey.ws> Date: Fri, 01 Jul 2011 07:14:55 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <9F6FE96B71CF29479FF1CDC8046E1503165EEB@039-SN1MPN1-003.039d.mgd.msft.net> <201107011216.36181.paul@codesourcery.com> <9CFF2A09-213A-4127-992A-B153B789C5C0@suse.de> <201107011255.24733.paul@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] device assignment for embedded Power List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Wood Scott-B07421 , "qemu-devel@nongnu.org" , "dwg@au1.ibm.com" , "blauwirbel@gmail.com" , Yoder Stuart-B08248 , "alex.williamson@redhat.com" , Paul Brook , "joerg.roedel@amd.com" , "armbru@redhat.com" On 07/01/2011 07:02 AM, Alexander Graf wrote: > > On 01.07.2011, at 13:55, Paul Brook wrote: > >> >>> But the real challenge is how to expose the device to the guest device >>> tree. Especially when it comes to links between dt nodes, interrupt maps, >>> etc. We basically have 3 choices there: >>> >>> * take the host device tree pieces and modify them >>> * provide device tree chunks for each device (manually or through qdev >>> parameters) * use the device tree as machine config file and base >>> everything on it (solves the linking problem) >>> >>> The main question is which one would be the cleanest solution. And how >>> would it be implemented. >> >> I don't think any of this is specific to device passthrough. It occurs as >> soon as you have any user-configurable parts of the machine (or even just a >> nontrivial selection of machine variants). My guess is the only reason you >> haven't hit it before is because you're only emulated a single hard-coded >> SoC/board. > > Well, the real reason we haven't hit this before is that we don't have any devices in Qemu that are generic. We only have specific device emulation. This however would be a device that can handle hundreds of different backing devices, all with different requirements. > > The infrastructure we have today simply isn't made for this. The question is how can we model it so that it will? :) Our infrastructure is quite capable of handling this. It has many other problems but I think the only thing really missing is the way to have lists of parameters. That seems easy to solve though. Regards, Anthony Liguori > > > Alex >