WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] RE: GPL Win PV driver issues

To: Steve Ofsthun <sofsthun@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] RE: GPL Win PV driver issues
From: Luciano Rocha <strange@xxxxxxxxxxxxx>
Date: Fri, 14 Dec 2007 19:36:59 +0000
Cc: Andy Grover <andy.grover@xxxxxxxxxx>, cgriffin@xxxxxxxxxx, James Harper <james.harper@xxxxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 14 Dec 2007 11:37:27 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4762D7C5.70504@xxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1197579906.25317.21.camel@xxxxxxxxxxxxxxxxxxxxx> <AEC6C66638C05B468B556EA548C1A77D0131A4CB@trantor> <4762D7C5.70504@xxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.14 (2007-03-31)
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

Attachment: pgpl6OR22PuPy.pgp
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel