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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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 toask> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.> JamesNow, 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
-----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----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
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@lists.xensource.com http://lists.xensource.com/xen-devel
> > I''ve been thinking about this. Isn''t it possible to allow both QEMUand> PV devices to exist, and create a combined HW/PV driver? I.e., adriver> for both the emulated device under Windows (as a later version thanthe> one shipped in Windows). Then, if really running under Xen, the driver > instructs dom0 to optionally terminate the QEMU server side and usethe> PV approach for communication. > > As the emulated devices are well understood (and there''s QEMU''ssource),> 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
> > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> It is *required* that both the QEMU and PV devices co-exist at thesame> time for PV to be usable in the general case. Requiring modificationsto> 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 asthe> 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 itis> impossible for the non-PV driver to activate itself. Likewise if thenon-> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Hmmm... that''s something I hadn''t thought of doing. The approachI''ve> > implemented, and it works well, is to create a filter for thewindows> > PCI device which simply removes the drivers from the busenumerations.> > As far as windows is concerned, the moment you specify ''/GPLPV'' onthe> > 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 ifthat> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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! _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > 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 capabilitiescould be> very beneficialCompared to a physical CDROM, I found a virtualised (even qemu virtualised) CDROM was much faster. James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 bothQEMU> > 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 versionthan> > the > > > one shipped in Windows). Then, if really running under Xen, thedriver> > > instructs dom0 to optionally terminate the QEMU server side anduse> > 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 thatit> > 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 boththe> > emulated PCI disk/network adapter, and the Xen PV device. I don''tthink> > 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 membershippassword.> 8-( > > I''m guessing that there is no chance that the win2003 drivers willwork> 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 totrack> > 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 compilingthe> > > 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 sideand> > use > > > > the > > > > > PV approach for communication. > > > > > > > > > > As the emulated devices are well understood (and there''sQEMU''s> > > > source), > > > > > would this be hard to do? > > > > > > > > > > > > > The way I''ve implemented the driver for the Xen PCI device isthat> > it > > > > becomes a bus driver and enumerates the things under ''devices''in> > > > xenstore (eg vbd, vif, console) and then drivers attach tothose.> > > > > > > > For your idea to work, a single driver would need to attach toboth> > the > > > > emulated PCI disk/network adapter, and the Xen PV device. Idon''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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> Meh! me and my bad eyesight. *sigh* > > Thanks for leading the blind. :) > > I have a machine all setup to test with xen 3.2-rc4Looking 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
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
> 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 forthe> 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 (ifi''m> right this is some java compiler, a quick > installation of SDK-JAVA.EXE was only possible from mirrors, as thems-> 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel