From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org, mrenzmann@otaku42.de
Subject: Re: [Qemu-devel] PCI access virtualization
Date: Thu, 5 Jan 2006 14:25:32 +0000 [thread overview]
Message-ID: <200601051425.33430.paul@codesourcery.com> (raw)
In-Reply-To: <1136456096.4464.90.camel@gimli>
> 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.
Paul
next prev parent reply other threads:[~2006-01-05 14:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-05 10:14 [Qemu-devel] PCI access virtualization Michael Renzmann
2006-01-05 14:25 ` Paul Brook [this message]
2006-01-05 17:40 ` Mark Williamson
2006-01-05 18:10 ` Paul Brook
2006-01-05 21:13 ` Jim C. Brown
2006-01-06 1:54 ` Mark Williamson
2006-01-06 13:27 ` Paul Brook
2006-01-06 14:23 ` Mark Williamson
2006-01-05 16:25 ` Mark Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200601051425.33430.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=mrenzmann@otaku42.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).