Re: [Qemu-devel] PCI access virtualization

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

> - IRQ sharing. Sharing host IRQs between native and virtualized devices is
> hard because the host needs to ack the interrupt in the IRQ handler, but
> doesn't really know how to do that until after it's run the guest to see
> what that does.

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.

> - DMA. qemu needs to rewrite DMA requests (in both directions) because the
> guest physical memory won't be at the same address on the host. Inlike ISA
> where there's a fixed DMA engine, I don't think there's any general way of

I was under the impression that you could get reasonably far by emulating a 
few of the most popular commercial DMA engine chips and reissuing 
address-corrected commands to the host.  I'm not sure how common it is for 
PCI cards to use custom DMA chips instead, though...

> There are patches that allow virtualization of PCI devices that don't use
> either of the above features. It's sufficient to get some Network cards
> working, but that's about it.

I guess PIO should be easy to work in any case.

> > I vaguely heard of a feature present in Xen, which allows to assign PCI
> > devices to one of the guests. I understand Xen works different than
> > QEMU, but maybe is would be possible to implement something similar.
>
> Xen is much easier because it cooperates with the host system (ie. xen), so
> both the above problems can be solved by tweaking the guest OS drivers/PCI
> subsystem setup.

Yep, XenLinux redefines various macros that were already present to do 
guest-physical <-> host-physical address translations, so DMA Just Works 
(TM).

> If you're testing specific drivers you could probably augment these drivers
> to pass the extra required information to qemu. ie. effectively use a
> special qemu pseudo-PCI interface rather than the normal piix PCI
> interface.

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.

Cheers,
Mark