From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qcmn9-0002rP-Rm for qemu-devel@nongnu.org; Fri, 01 Jul 2011 19:06:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qcmn7-0003CT-Pl for qemu-devel@nongnu.org; Fri, 01 Jul 2011 19:06:31 -0400 Received: from gate.crashing.org ([63.228.1.57]:43229) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qcmn7-0003CH-BM for qemu-devel@nongnu.org; Fri, 01 Jul 2011 19:06:29 -0400 From: Benjamin Herrenschmidt In-Reply-To: <201107012159.35919.paul@codesourcery.com> References: <9F6FE96B71CF29479FF1CDC8046E1503165EEB@039-SN1MPN1-003.039d.mgd.msft.net> <201107011803.01887.paul@codesourcery.com> <20110701124915.5343a033@schlenkerla.am.freescale.net> <201107012159.35919.paul@codesourcery.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 02 Jul 2011 09:05:46 +1000 Message-ID: <1309561546.14501.251.camel@pasglop> Mime-Version: 1.0 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: Paul Brook 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 ? :-) > I'm also extremely sceptical of anything that only works in a kvm environment. > Makes me think it's an unmaintainable hack, and almost certainly going to > cause you immense amounts of pain later. See above question... Cheers, Ben. > > > I doubt you're going to get generic passthrough of arbitrary devices > > > working in a useful way. > > > > It's usefully working for us internally -- we're just trying to find a way > > to improve it for upstream, with a better configuration mechanism. > > I don't believe that either. More likely you've got passthrough of device > hanging off your specific CPU bus, using only (or even a subset of) the > facilities provided by that bus. > > > > Basically you have to emulate everything that is different between the > > > host and guest. > > > > Directly assigning a device means you don't get to have differences between > > the actual hardware device and what the guest sees. The kind of thin > > wrapper you're suggesting might have some use cases, but it's a different > > problem from what we're trying to solve. > > That's the problem. You've skipped several steps and gone startigh for > optimization before you've even got basic functionality working. > > You've also missed the point I was making. In order to do device passthrough > you need to define a boundary allong which the emulated machine state can be > fully replicated on the host machine. Anything inside this boundary is (by > definition) that same on both the host and guest systems (we're effectively > using host hardware to emulate a device for us). Outside that boundary the > host and guest systems will diverge. > > For a device that merely responds to CPU initiated MMIO transfers this is > pretty simple, it's the point at which MMIO transfers are generated. So the > guest gets a proxy device that intercepts accesses to that memory region, and > the host proxies some way for qemu to poke values at the host device. > > > > Once you've done all the above, host device passthrough should be > > > relatively straightforward. Just replace the emulation bits in the > > > above device with code that pokes at a real device via the relevant > > > kernel API. > > > > That's not what we mean by direct device assignment. > > Maybe, but IMO but it's a necessary prerequisite. You're trying to run before > you can walk. > > > We're talking about directly mapping the registers into the guest. The > > whole point is performance. > > That's an additional step after you get passthrough working the normal way. > We already have mechanisms (or at least patches) for mapping file-like objects > into guest physical memory. That's largely independent of device passthrough. > It's a relatively minor tweak to how the passthrough device sets up its MMIO > regions. > > Mapping host device MMIO regions into guest space is entirely uninteresting > unless we already have some way of creating guest-host passthrough devices. > Creating guest-device passthrough devices isn't going to happen until the can > create arbitrary devices (within the set emulated by qemu) that interact with > the rest of the emulated machine in a similar way. > > Paul