On Fri, Dec 14, 2007 at 02:21:41PM -0500, Steve Ofsthun wrote:
<snip>
> At Virtual Iron, we currently manage domains directly (no xend, xm,
> etc). To deal with PV driver devices we have marked devices in xenstore
> as being QEMU devices or PV "accelerated" devices. Devices are allowed
> to show up as both, but they don't default that way. This allows us to
> control visibility on a device by device basis. This has been useful
> for development but is not really visible to our customers. Our product
> just allows either all QEMU or all PV, but not both or any mix.
<snip>
> In the specialized case of boot devices, we need to access the QEMU
> device from the BIOS boot sequence. We chose not to change the BIOS to
> access the PV devices via Xenbus, etc. Instead we added a probe limit
> option to QEMU devices that basically says that devices are only allowed
> to respond to device probes X times. For booting with the current BIOS
> we limit IDE probes to 1 (the BIOS only). This allows all BIOS access
> to the device to proceed, but the guest OS probe will fail to detect the
> emulated device. As the guest OS boots, it only sees the device via the
> PV drivers.
I've been thinking about this. Isn't it possible to allow both QEMU and
PV devices to exist, and create a combined HW/PV driver? I.e., a driver
for both the emulated device under Windows (as a later version than the
one shipped in Windows). Then, if really running under Xen, the driver
instructs dom0 to optionally terminate the QEMU server side and use the
PV approach for communication.
As the emulated devices are well understood (and there's QEMU's source),
would this be hard to do?
--
lfr
0/0
pgpl6OR22PuPy.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home