Daniel P. Berrange wrote:
> 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.
I think you mean for your Xen usage model, you require both QEMU and PV
access to all of your devices. Certainly Xen itself does not require
this restriction. I'm not suggesting that anyone that uses Xen would
need to play by any new rules. I'm suggesting that Xen should be
flexible enough to allow specification of different device visibility
options. If you want to see every emulated device as a PV device, you
should be able to.
> 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..
So today, the PV blkfront driver should be modified to claim resources
for the IDE controller? How do you share the IDE controller for CD-ROM use?
The PV netfront driver should scan the PCI bus for another NIC with the
same MAC and claim those resources?
What if you want more PV devices than QEMU is willing to emulate?
What if you want to run emulated device drivers and PV drivers at the
same time?
I don't quite understand how this can be an "easy" solution for the
general case (of an arbitrary guest OS).
Steve
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home