On Fri, Dec 14, 2007 at 07:36:59PM +0000, Luciano Rocha wrote:
> 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.
It is *required* that both the QEMU and PV devices co-exist at the same
time for PV to be usable in the general case. Requiring modifications to
the Dom0 config file of a VM before PV can be used is not practical.
The admin in charge of the Dom0 cannot be assumed to be the same as the
admin in charge of the DomU. The DomU admin needs to be able to switch
to/from the PV drivers at will, without having to get Dom0 admin to do
magic config changes for them.
The easy solution is for the PV drivers to grab the PCI resources associated
with the emulated devices. So once the PV driver has loaded, then it is
impossible for the non-PV driver to activate itself. Likewise if the non-PV
driver is loaded, then the PV driver will be unable to grab the PCI resources
and can thus disable itself. No special Dom0 config required..
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home