Re: [Qemu-devel] PCI access virtualization

[Mark Williamson <mark.williamson@cl.cam.ac.uk>]

> > 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