From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcnTW-0006PW-7G for qemu-devel@nongnu.org; Fri, 01 Jul 2011 19:50:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcnTV-000809-5Q for qemu-devel@nongnu.org; Fri, 01 Jul 2011 19:50:18 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:51857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcnTU-0007zq-Uv for qemu-devel@nongnu.org; Fri, 01 Jul 2011 19:50:17 -0400 From: Paul Brook Date: Sat, 2 Jul 2011 00:50:13 +0100 References: <9F6FE96B71CF29479FF1CDC8046E1503165EEB@039-SN1MPN1-003.039d.mgd.msft.net> <201107012159.35919.paul@codesourcery.com> <1309561546.14501.251.camel@pasglop> In-Reply-To: <1309561546.14501.251.camel@pasglop> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201107020050.13733.paul@codesourcery.com> Subject: Re: [Qemu-devel] device assignment for embedded Power List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: Wood Scott-B07421 , "joerg.roedel@amd.com" , Alexander Graf , "qemu-devel@nongnu.org" , "blauwirbel@gmail.com" , Yoder Stuart-B08248 , "alex.williamson@redhat.com" , Scott Wood , "dwg@au1.ibm.com" , "armbru@redhat.com" > On Fri, 2011-07-01 at 21:59 +0100, Paul Brook wrote: > > > On Fri, 1 Jul 2011 18:03:01 +0100 > > > > > > Paul Brook wrote: > > > > Basically you should start by implementing full emulation of a device > > > > with similar characteristics to the one you want to passthrough. > > > > > > That's not going to happen. > > > > Why is your device so unique? How does it interact with the guest system > > and what features does it require that doen't exist in any device that > > can be emulated? > > Do you guys only support PCI pass-through by doing full emulation of the > all possible supported PCI devices first ? :-) Absolutely not. My point is that dynamic (user-driven) device creation is effectively a prerequisite for a passthrough device. If you just want to make a very specific use-case then this doesn't need any code in qemu at all. We just make the user provide the device tree themselves. If it doesn't match then they loose. If you do choose an ugly qemu then the changes are it'll be changed/removed once we do dyamic device creation properly. There have already been discussions about dynamic device creation, so this this isn't completely hypothetical. If you integrate it properly, then you need to realise then there's a fair chunk of infrastructure and user interface required. Most of which has nothing to do with device passthrough. Trying to implement both at the same time is just going to cause confusion and complicate things. It's already a hard problem, combining it with something else is just going to cause you and everyone else even more pain. Paul