> > 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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel