[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] PCI access virtualization

From: Paul Brook
Subject: Re: [Qemu-devel] PCI access virtualization
Date: Thu, 5 Jan 2006 14:25:32 +0000
User-agent: KMail/1.8.3

> Background: I'm one of the developers of MadWifi, which is a linux
> driver for WLAN cards based on Atheros chipsets. QEMU could be a great
> help in testing distribution-specific issues, as well as issues related
> to SMP operation. The only downside is that it's not easily possible to
> emulate the necessary WLAN hardware.
> Now, if it would be possible to allow a VM to access physical PCI
> devices on the host, it could make use of non-emulated hardware for this
> purpose. Even more, thanks to the SMP emulation that recently went into
> QEMU, it would be possible to test the compatibility of the driver with
> SMP systems, even if the host is just a UP system.
There are two problems:

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

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]