GPL Win PV driver issues

GPL Win PV driver issues

[Andy Grover]

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.

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?

Clyde, you said at the Xen Summit that you were interested in
contributing to the GPL winpv driver effort, but there were some legal
issues. I think an initial, safe step would be if your team could answer
questions about how your driver is implemented, such as how it handles
the issue above. I'd also invite you and everyone else to review the
code (hg url above) and please pass on any comments you have.

Thanks -- Regards -- Andy

RE: GPL Win PV driver issues

[James Harper]

> 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!

> 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?

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...

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 :)

James

Re: RE: GPL Win PV driver issues

[Steve Ofsthun]

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

Re: RE: GPL Win PV driver issues

[Luciano Rocha]

[-- Attachment #1.1: Type: text/plain, Size: 1723 bytes --]

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 #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RE: GPL Win PV driver issues

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Luciano Rocha schreef:
> As the emulated devices are well understood (and there's QEMU's source),
> would this be hard to do?

Do you mean something like a 'fallback' method? Or more something like
provide the options in your configuration file, and if they are not
present don't create the devices?



Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYty5YH1+F2Rqwn0RCgsNAJwNG88aeD1Tezk2+5/3YPS8222ZfgCdFtNL
qeisKiF0V8I31nRI1+odqRI=
=VZrj
-----END PGP SIGNATURE-----

Re: RE: GPL Win PV driver issues

[Luciano Rocha]

[-- Attachment #1.1: Type: text/plain, Size: 1109 bytes --]

On Fri, Dec 14, 2007 at 08:42:49PM +0100, Stefan de Konink wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Luciano Rocha schreef:
> > As the emulated devices are well understood (and there's QEMU's source),
> > would this be hard to do?
> 
> Do you mean something like a 'fallback' method? Or more something like
> provide the options in your configuration file, and if they are not
> present don't create the devices?

Let's see if I can make it clear:

I'm not sure of the current type of devices emulated by qemu, but lets
suppose PIIXn for hard-disks/cdroms and ne2k for network.

What I suggest is develop drivers for windows for those devices. The
drivers would work with bare hardware, but when running under Xen (how
to check that, I currently don't know), it would inform the
hypervisor/dom0 that it will switch then to the fast-path method
(ring-buffers, direct hypercalls, etc., instead of emulated PIO).

So there would be no need to hide the "qemu" devices, nor toggle
switches for when the para-virtualized drivers are installed or not.

-- 
lfr
0/0

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

Re: RE: GPL Win PV driver issues

[Daniel P. Berrange]

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  -=| 

Re: RE: GPL Win PV driver issues

[Steve Ofsthun]

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

RE: RE: GPL Win PV driver issues

[James Harper]

> 
> 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?
> 

The way I've implemented the driver for the Xen PCI device is that it
becomes a bus driver and enumerates the things under 'devices' in
xenstore (eg vbd, vif, console) and then drivers attach to those.

For your idea to work, a single driver would need to attach to both the
emulated PCI disk/network adapter, and the Xen PV device. I don't think
this is possibly under the windows driver model.

But I've only been writing windows drivers for a few months now, so
there's probably a lot of stuff I don't know :)

James

RE: RE: GPL Win PV driver issues

[James Harper]

> 
> Let's see if I can make it clear:
> 
> I'm not sure of the current type of devices emulated by qemu, but lets
> suppose PIIXn for hard-disks/cdroms and ne2k for network.

That's pretty much right.

> What I suggest is develop drivers for windows for those devices. The
> drivers would work with bare hardware, but when running under Xen (how
> to check that, I currently don't know), it would inform the
> hypervisor/dom0 that it will switch then to the fast-path method
> (ring-buffers, direct hypercalls, etc., instead of emulated PIO).
> 
> So there would be no need to hide the "qemu" devices, nor toggle
> switches for when the para-virtualized drivers are installed or not.

The other problem with this is that Windows always likes to use 'signed'
drivers over 'unsigned' drivers, regardless of version numbers, so
keeping them installed is a pain.

James

RE: RE: GPL Win PV driver issues

[James Harper]

> 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..

Hmmm... that's something I hadn't thought of doing. The approach I've
implemented, and it works well, is to create a filter for the windows
PCI device which simply removes the drivers from the bus enumerations.
As far as windows is concerned, the moment you specify '/GPLPV' on the
boot command line, the disk device is gone.

James

RE: RE: GPL Win PV driver issues

[Andy Grover]

On Sat, 2007-12-15 at 09:21 +1100, James Harper wrote:

> Hmmm... that's something I hadn't thought of doing. The approach I've
> implemented, and it works well, is to create a filter for the windows
> PCI device which simply removes the drivers from the bus enumerations.
> As far as windows is concerned, the moment you specify '/GPLPV' on the
> boot command line, the disk device is gone.

I'm starting to warm up to this method. Seems like not changing dom0's
config file is a good thing.

I'll try adding support to xenhide to filter out ioemu net, and if that
works, then problem solved, eh?

-- Andy

RE: RE: GPL Win PV driver issues

[James Harper]

> > Hmmm... that's something I hadn't thought of doing. The approach
I've
> > implemented, and it works well, is to create a filter for the
windows
> > PCI device which simply removes the drivers from the bus
enumerations.
> > As far as windows is concerned, the moment you specify '/GPLPV' on
the
> > boot command line, the disk device is gone.
> 
> I'm starting to warm up to this method. Seems like not changing dom0's
> config file is a good thing.
> 
> I'll try adding support to xenhide to filter out ioemu net, and if
that
> works, then problem solved, eh?
> 

Yep. And it should be pretty obvious where you need to make changes.

I think my concern about having both network devices attached to the
bridge is probably unwarranted... with only qemu drivers you have the
tapX device and the unused vif device. Once the PV drivers become live
you'll have the vif device and the unused tapX device. Should be fine.

Only one way to find out though :)

James

Re: RE: GPL Win PV driver issues

[Mark Williamson]

> The PV netfront driver should scan the PCI bus for another NIC with the
> same MAC and claim those resources?

Well, presumably, it can get more useful information from Xen with appropriate 
tools support: e.g. query out what PCI devices have PV counterparts so it 
knows what it *can* grab.  Then the admin in the domU can be responsible for 
the decision of which PV devices to enable?

Cheers,
Mark

> 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@lists.xensource.com
> http://lists.xensource.com/xen-devel



-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

Re: RE: GPL Win PV driver issues

[Daniel P. Berrange]

On Sat, Dec 15, 2007 at 04:09:50AM +0000, Mark Williamson wrote:
> > The PV netfront driver should scan the PCI bus for another NIC with the
> > same MAC and claim those resources?
> 
> Well, presumably, it can get more useful information from Xen with appropriate 
> tools support: e.g. query out what PCI devices have PV counterparts so it 
> knows what it *can* grab.  Then the admin in the domU can be responsible for 
> the decision of which PV devices to enable?

I would have suggested the NIC driver just grab all ne2k & rtl8139 nics, but
actually since Dom0 knows exactly what emulated NIC correspond to the PV
nic it could trivially write this into XenStore. Then as you suggest the 
PV driver can look this up directly rather than having to use hueristics

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  -=| 

Re: RE: GPL Win PV driver issues

[Daniel P. Berrange]

On Fri, Dec 14, 2007 at 04:51:09PM -0500, Steve Ofsthun wrote:
> 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:
> 
> 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?

I would venture to suggest that any PV disk driver also provide the neccessary
CDROM capabilities. During installation of guests, even on baremetal, the 
CDROM is a serious bottleneck on install time so much so that I never install
off CDROM anymore instead using network sources. The emulated CDROM amplifies
this problem, so having the PV drivers support CDROM capabilities could be
very beneficial

Regards,
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  -=| 

RE: RE: GPL Win PV driver issues

[James Harper]

> 
> I would venture to suggest that any PV disk driver also provide the
> neccessary
> CDROM capabilities. During installation of guests, even on baremetal,
the
> CDROM is a serious bottleneck on install time so much so that I never
> install
> off CDROM anymore instead using network sources. The emulated CDROM
> amplifies
> this problem, so having the PV drivers support CDROM capabilities
could be
> very beneficial

Compared to a physical CDROM, I found a virtualised (even qemu
virtualised) CDROM was much faster.

James

RE: RE: GPL Win PV driver issues

[Brian Wolfe]

I wish I could help out a bit by compiling for nt2k pro but
unfortunately MS wants me to buy their developers subscription for $1k+
USD. 8-( I can't afford that kind of cash. *sigh*

If anyone can front me the necessary installables for compiling the
windows PV drivers I'm willing to have a go at helping out. :) 


On Sat, 2007-12-15 at 09:17 +1100, James Harper wrote:
> > 
> > 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?
> > 
> 
> The way I've implemented the driver for the Xen PCI device is that it
> becomes a bus driver and enumerates the things under 'devices' in
> xenstore (eg vbd, vif, console) and then drivers attach to those.
> 
> For your idea to work, a single driver would need to attach to both the
> emulated PCI disk/network adapter, and the Xen PV device. I don't think
> this is possibly under the windows driver model.
> 
> But I've only been writing windows drivers for a few months now, so
> there's probably a lot of stuff I don't know :)
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

RE: RE: GPL Win PV driver issues

[James Harper]

Assuming nothing has changed in the last 6 months or so, the DDK is
available at no cost on the MS web site, but it is a bit tricky to track
down.

Have another look around...

James

> -----Original Message-----
> From: Brian Wolfe [mailto:brianw@terrabox.com]
> Sent: Wednesday, 2 January 2008 06:06
> To: James Harper
> Cc: xen-devel
> Subject: RE: [Xen-devel] RE: GPL Win PV driver issues
> 
> I wish I could help out a bit by compiling for nt2k pro but
> unfortunately MS wants me to buy their developers subscription for
$1k+
> USD. 8-( I can't afford that kind of cash. *sigh*
> 
> If anyone can front me the necessary installables for compiling the
> windows PV drivers I'm willing to have a go at helping out. :)
> 
> 
> On Sat, 2007-12-15 at 09:17 +1100, James Harper wrote:
> > >
> > > 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?
> > >
> >
> > The way I've implemented the driver for the Xen PCI device is that
it
> > becomes a bus driver and enumerates the things under 'devices' in
> > xenstore (eg vbd, vif, console) and then drivers attach to those.
> >
> > For your idea to work, a single driver would need to attach to both
the
> > emulated PCI disk/network adapter, and the Xen PV device. I don't
think
> > this is possibly under the windows driver model.
> >
> > But I've only been writing windows drivers for a few months now, so
> > there's probably a lot of stuff I don't know :)
> >
> > James
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel

RE: RE: GPL Win PV driver issues

[Brian Wolfe]

I burned 2 hours attempting to track it down but every link redirected
me to look in the MSDN area which is behind an MSDN membership password.
8-(

I'm guessing that there is no chance that the win2003 drivers will work
under nt2kpro?

On Wed, 2008-01-02 at 13:45 +1100, James Harper wrote:
> Assuming nothing has changed in the last 6 months or so, the DDK is
> available at no cost on the MS web site, but it is a bit tricky to track
> down.
> 
> Have another look around...
> 
> James
> 
> > -----Original Message-----
> > From: Brian Wolfe [mailto:brianw@terrabox.com]
> > Sent: Wednesday, 2 January 2008 06:06
> > To: James Harper
> > Cc: xen-devel
> > Subject: RE: [Xen-devel] RE: GPL Win PV driver issues
> > 
> > I wish I could help out a bit by compiling for nt2k pro but
> > unfortunately MS wants me to buy their developers subscription for
> $1k+
> > USD. 8-( I can't afford that kind of cash. *sigh*
> > 
> > If anyone can front me the necessary installables for compiling the
> > windows PV drivers I'm willing to have a go at helping out. :)
> > 
> > 
> > On Sat, 2007-12-15 at 09:17 +1100, James Harper wrote:
> > > >
> > > > 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?
> > > >
> > >
> > > The way I've implemented the driver for the Xen PCI device is that
> it
> > > becomes a bus driver and enumerates the things under 'devices' in
> > > xenstore (eg vbd, vif, console) and then drivers attach to those.
> > >
> > > For your idea to work, a single driver would need to attach to both
> the
> > > emulated PCI disk/network adapter, and the Xen PV device. I don't
> think
> > > this is possibly under the windows driver model.
> > >
> > > But I've only been writing windows drivers for a few months now, so
> > > there's probably a lot of stuff I don't know :)
> > >
> > > James
> > >
> > > _______________________________________________
> > > Xen-devel mailing list
> > > Xen-devel@lists.xensource.com
> > > http://lists.xensource.com/xen-devel
> 

RE: RE: GPL Win PV driver issues

[James Harper]

http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx

That page details the instructions that I followed. Remember that you
want 6000, not 6001, unless you'd like to do development for Windows
2008 :)

It does say that it is _also_ available via an MSDN Subscription, but it
is also available for free. You do have to set up an account to get it
though, and you do have to use Microsofts own downloader.

I'll put the above link in the PV driver docs.

James

> -----Original Message-----
> From: Brian Wolfe [mailto:brianw@terrabox.com]
> Sent: Wednesday, 2 January 2008 14:32
> To: James Harper
> Cc: xen-devel
> Subject: RE: [Xen-devel] RE: GPL Win PV driver issues
> 
> I burned 2 hours attempting to track it down but every link redirected
> me to look in the MSDN area which is behind an MSDN membership
password.
> 8-(
> 
> I'm guessing that there is no chance that the win2003 drivers will
work
> under nt2kpro?
> 
> On Wed, 2008-01-02 at 13:45 +1100, James Harper wrote:
> > Assuming nothing has changed in the last 6 months or so, the DDK is
> > available at no cost on the MS web site, but it is a bit tricky to
track
> > down.
> >
> > Have another look around...
> >
> > James
> >
> > > -----Original Message-----
> > > From: Brian Wolfe [mailto:brianw@terrabox.com]
> > > Sent: Wednesday, 2 January 2008 06:06
> > > To: James Harper
> > > Cc: xen-devel
> > > Subject: RE: [Xen-devel] RE: GPL Win PV driver issues
> > >
> > > I wish I could help out a bit by compiling for nt2k pro but
> > > unfortunately MS wants me to buy their developers subscription for
> > $1k+
> > > USD. 8-( I can't afford that kind of cash. *sigh*
> > >
> > > If anyone can front me the necessary installables for compiling
the
> > > windows PV drivers I'm willing to have a go at helping out. :)
> > >
> > >
> > > On Sat, 2007-12-15 at 09:17 +1100, James Harper wrote:
> > > > >
> > > > > 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?
> > > > >
> > > >
> > > > The way I've implemented the driver for the Xen PCI device is
that
> > it
> > > > becomes a bus driver and enumerates the things under 'devices'
in
> > > > xenstore (eg vbd, vif, console) and then drivers attach to
those.
> > > >
> > > > For your idea to work, a single driver would need to attach to
both
> > the
> > > > emulated PCI disk/network adapter, and the Xen PV device. I
don't
> > think
> > > > this is possibly under the windows driver model.
> > > >
> > > > But I've only been writing windows drivers for a few months now,
so
> > > > there's probably a lot of stuff I don't know :)
> > > >
> > > > James
> > > >
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@lists.xensource.com
> > > > http://lists.xensource.com/xen-devel
> >

RE: RE: GPL Win PV driver issues

[Brian Wolfe]

Meh! me and my bad eyesight. *sigh*

Thanks for leading the blind. :)

I have a machine all setup to test with xen 3.2-rc4


On Wed, 2008-01-02 at 15:20 +1100, James Harper wrote:
> http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx
> 
> That page details the instructions that I followed. Remember that you
> want 6000, not 6001, unless you'd like to do development for Windows
> 2008 :)
> 
> It does say that it is _also_ available via an MSDN Subscription, but it
> is also available for free. You do have to set up an account to get it
> though, and you do have to use Microsofts own downloader.
> 
> I'll put the above link in the PV driver docs.
> 
> James
> 
> > -----Original Message-----
> > From: Brian Wolfe [mailto:brianw@terrabox.com]
> > Sent: Wednesday, 2 January 2008 14:32
> > To: James Harper
> > Cc: xen-devel
> > Subject: RE: [Xen-devel] RE: GPL Win PV driver issues
> > 
> > I burned 2 hours attempting to track it down but every link redirected
> > me to look in the MSDN area which is behind an MSDN membership
> password.
> > 8-(
> > 
> > I'm guessing that there is no chance that the win2003 drivers will
> work
> > under nt2kpro?
> > 
> > On Wed, 2008-01-02 at 13:45 +1100, James Harper wrote:
> > > Assuming nothing has changed in the last 6 months or so, the DDK is
> > > available at no cost on the MS web site, but it is a bit tricky to
> track
> > > down.
> > >
> > > Have another look around...
> > >
> > > James
> > >
> > > > -----Original Message-----
> > > > From: Brian Wolfe [mailto:brianw@terrabox.com]
> > > > Sent: Wednesday, 2 January 2008 06:06
> > > > To: James Harper
> > > > Cc: xen-devel
> > > > Subject: RE: [Xen-devel] RE: GPL Win PV driver issues
> > > >
> > > > I wish I could help out a bit by compiling for nt2k pro but
> > > > unfortunately MS wants me to buy their developers subscription for
> > > $1k+
> > > > USD. 8-( I can't afford that kind of cash. *sigh*
> > > >
> > > > If anyone can front me the necessary installables for compiling
> the
> > > > windows PV drivers I'm willing to have a go at helping out. :)
> > > >
> > > >
> > > > On Sat, 2007-12-15 at 09:17 +1100, James Harper wrote:
> > > > > >
> > > > > > 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?
> > > > > >
> > > > >
> > > > > The way I've implemented the driver for the Xen PCI device is
> that
> > > it
> > > > > becomes a bus driver and enumerates the things under 'devices'
> in
> > > > > xenstore (eg vbd, vif, console) and then drivers attach to
> those.
> > > > >
> > > > > For your idea to work, a single driver would need to attach to
> both
> > > the
> > > > > emulated PCI disk/network adapter, and the Xen PV device. I
> don't
> > > think
> > > > > this is possibly under the windows driver model.
> > > > >
> > > > > But I've only been writing windows drivers for a few months now,
> so
> > > > > there's probably a lot of stuff I don't know :)
> > > > >
> > > > > James
> > > > >
> > > > > _______________________________________________
> > > > > Xen-devel mailing list
> > > > > Xen-devel@lists.xensource.com
> > > > > http://lists.xensource.com/xen-devel
> > >
> 

RE: RE: GPL Win PV driver issues

[James Harper]

> Meh! me and my bad eyesight. *sigh*
> 
> Thanks for leading the blind. :)
> 
> I have a machine all setup to test with xen 3.2-rc4

Looking forward to hearing the results. I don't have a 3.2 platform to
test with at the moment...

James

Re: RE: GPL Win PV driver issues

[Stephan Seitz]

[-- Attachment #1.1.1: Type: text/plain, Size: 1689 bytes --]

Hi James,

i'm currently trying to build your pv drivers from hg repository.

my test system is a XP SP2 x64 running on xen3.2 x86_64.

after hours of MSDN searches ;) if found the WDK Ver 6000 (just for the list: do not search for WDK, search for DDK - as
i'm no windows guru, the difference wasn't really clear to me)

after a first try, i found "jvc" missing to the build environment (if i'm right this is some java compiler, a quick
installation of SDK-JAVA.EXE was only possible from mirrors, as the ms-java sdk has reached its end of lifetime 20 days
ago...)

the output is full of
   [somenumber]>Compiling - [....\386] for all platforms
   [somenumber]>NMAKE : warning U4006: special macro undefined : '$<'



   BUILD: Done

        51 files compiled - 51 Errors -       0 LPS



could you please give me a hint what i am doing wrong here, maybe the previously missing "jvc" is *not* java?


Thanks is advance!

Stephan



James Harper schrieb:
>> Meh! me and my bad eyesight. *sigh*
>>
>> Thanks for leading the blind. :)
>>
>> I have a machine all setup to test with xen 3.2-rc4
> 
> Looking forward to hearing the results. I don't have a 3.2 platform to
> test with at the moment...
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


-- 
Stephan Seitz
Senior System Administrator

*netz-haut* e.K.
multimediale kommunikation

zweierweg 22
97074 würzburg

fon: +49 931 2876247
fax: +49 931 2876248

web: www.netz-haut.de <http://www.netz-haut.de/>

registriergericht: amtsgericht würzburg, hra 5054

[-- Attachment #1.1.2: s_seitz.vcf --]
[-- Type: text/x-vcard, Size: 335 bytes --]

begin:vcard
fn:Stephan Seitz
n:Seitz;Stephan
org:netz-haut e.K.
adr:;;Zweierweg 22;Wuerzburg;Bayern;97074;Deutschland
email;internet:s.seitz@netz-haut.de
title:Senior System Administrator
tel;work:+49-931-287-6247
tel;fax:+49-931-287-6248
x-mozilla-html:FALSE
url:http://www.schwarz-mode.de/files/
version:2.1
end:vcard


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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

RE: RE: GPL Win PV driver issues

[James Harper]

> i'm currently trying to build your pv drivers from hg repository.
> 
> my test system is a XP SP2 x64 running on xen3.2 x86_64.

Unfortunately we don't yet support x64. I've had a quick look at it, and
managed to get it to compile, but it doesn't work.

> after hours of MSDN searches ;) if found the WDK Ver 6000 (just for
the
> list: do not search for WDK, search for DDK - as
> i'm no windows guru, the difference wasn't really clear to me)
> 
> after a first try, i found "jvc" missing to the build environment (if
i'm
> right this is some java compiler, a quick
> installation of SDK-JAVA.EXE was only possible from mirrors, as the
ms-
> java sdk has reached its end of lifetime 20 days
> ago...)
> ...
> could you please give me a hint what i am doing wrong here, maybe the
> previously missing "jvc" is *not* java?

I can't imagine why anything called jvc would be required?
Are you definitely in the correct build environment? From there you
should just be able to type 'build' or 'bld'.

James