From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Euh1W-0005Td-L2 for qemu-devel@nongnu.org; Thu, 05 Jan 2006 21:08:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Euh1V-0005Se-Hu for qemu-devel@nongnu.org; Thu, 05 Jan 2006 21:08:10 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Euh1V-0005ST-Ca for qemu-devel@nongnu.org; Thu, 05 Jan 2006 21:08:09 -0500 Received: from [131.111.8.137] (helo=ppsw-7.csi.cam.ac.uk) by monty-python.gnu.org with esmtp (Exim 4.34) id 1Euh3A-0000XK-Rk for qemu-devel@nongnu.org; Thu, 05 Jan 2006 21:09:53 -0500 From: Mark Williamson Subject: Re: [Qemu-devel] PCI access virtualization Date: Fri, 6 Jan 2006 01:54:44 +0000 References: <1136456096.4464.90.camel@gimli> <200601051740.49151.mark.williamson@cl.cam.ac.uk> <200601051810.54954.paul@codesourcery.com> In-Reply-To: <200601051810.54954.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601060154.45653.mark.williamson@cl.cam.ac.uk> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org > > Could maybe have the (inevitable) kernel portion of the code grab the > > interrupt, and not ack it until userspace does an ioctl on a special file > > (or something like that?). There are patches floating around for > > userspace IRQ handling, so I guess that could work. > > This still requires cooperation from both sides (ie. both the host and > guest drivers). True. > IIUC PCI cards don't really have "DMA engines" as such. The PCI bridge just > maps PCI address space onto physical memory. A Busmaster PCI device can > then make arbitrary acceses whenever it wants. I expect the default mapping > is a 1:1 mapping of the first 4G of physical ram. I was under the impression that the on-card bus-mastering engines were often one of a few standard designs - this was suggested to me by someone more knowledgeable than myself but must admit I don't have any hard evidence that it's the case ;-) A "half way" solution would, I guess, be to code up a partial emulator for the device, emulating key operations (by translating them and reissuing to the device) whilst allowing other operations to pass directly through. > > How about something like this?: > > I'd imagine you could get away with a special header file with different > > macro defines (as for Xen, above), just in the driver in question, and a > > special "translation device / service" available to the QEmu virtual > > machine - could be as simple as "write the guest physical address to an > > IO port, returns the real physical address on next read". The > > virt_to_bus (etc) macros would use the translation service to perform the > > appropriate translation at runtime. > > That's exactly the sort of thing I meant. Ideally you'd just implement it > as a different type of PCI bridge, and everything would just work. I don't > know if linux supports such heterogeneous configurations though. I think that wouldn't be sufficient due to the way Linux behaves - virtual to physical address conversion will be done within the guest driver and then issued directly to the hardware, so a bridge driver won't be able to fix up the DMA addressing correctly. I guess with some header file hacks it'd be possible to make the conversion macros themselves switchable, so that (in principle) any driver could be loaded in "native" or "QEmu passthrough" mode by specifiying an optional load-time argument - that would be cool. Making it automatically switch would be a bit tricky though... maybe the macros could be made to switch on the basis of the module PCI ID table :-D *evil grin* Cheers, Mark