Re: RE: GPL Win PV driver issues

[Steve Ofsthun <sofsthun@virtualiron.com>]

James Harper wrote:
>> hg URL: http://xenbits.xensource.com/ext/win-pvdrivers.hg
>>
>> Hi James and Clyde,
>>
>> I'm pleased to report that the net driver now sends and receives
>> packets, and gets an IP via DHCP. I have not done any stress or
>> performance work yet, however.
> 
> w00t!

Congrats, this is great news.

>> One issue is that the driver has the same mac address as the qemu net
>> device. The approach you were taking was the "XenHide" driver, that
>> would hide (filter out) emulated devices in favor of pv ones. I'd like
>> to get xenhide filtering out the qemu net device, but also wanted to
> ask
>> the other implementers of winpv drivers if there is a better or
>> preferred way to accomplish this?

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.

I think the official Xen approach has been to use guest OS boot options
to "hide" QEMU devices.  Hiding QEMU devices automatically after the
fact (say in response to a PV driver being loaded) is difficult since
the emulated devices don't support device removal as far as the guest OS
is concerned.

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.

> Xenhide still may not do the trick in your case. It will prevent Windows
> from seeing the device, but the tap device will still be there and
> attached to the bridge, which may cause problems of its own...

In our case, only QEMU flagged devices will create emulation
infrastructure (tap, etc).

> I have a scsiport driver working nicely now... almost... it crashes
> occasionally and of course it won't write out a crash dump for me :)

In our environment we just mark the system disk as QEMU only and dump to
that.  Can't you do something similar?  Bring your PV disk up as a
second disk in Windows.  If you don't want Windows to see a second copy
of the system disk, just hack your driver to ignore that disk for debug.

> James

Now, generally speaking we are not too happy with this particular
deviation from the standard Xen code.  We just wanted a solution that
was controlled by dom0, not the frontend drivers or the guest OS
environment.  We haven't submitted these particular changes since they
are tied to our own management stack.  As we merge up to 3.2.0, we will
once again be revisiting this code.  Any suggestions that might make
these changes more acceptable would certainly be welcome.

Steve