writing PV block drivers for Windows

writing PV block drivers for Windows

[James Harper]

I'm now at the stage where I can think about writing some PV block
drivers for Windows. I have working event channel and xen store
subsystems (but they'll probably need some more refinement once things
progress), and the Windows XenPCI driver enumerates devices as they are
added to xenstore.

This leaves me with a few questions...

1. I assume that the qemu virtual BIOS uses the virtual ATA for
communications. Once my Windows drivers are loaded at boot time (part of
the bootstrap process I assume), I need to turn off the emulated ATA
interface so that windows doesn't detect that (two access methods to the
same block device can't be a good idea!)... how might I get xen/qemu to
turn that off at a given point... by writing something into xenstore?
 
2. I'm presently planning on writing the vbd driver as a Windows SCSI
miniport driver, which means windows would see the vbd driver as a scsi
disk. It appears that Xen has a fairly simple idea of single block
devices, without the concept of buses and controllers. Windows, however,
likes controller buses with devices hanging off them. So I can create
one virtual scsi HBA, and just put all the virtual devices on that, or I
can create one virtual HBA per virtual device... any suggestions? I'm
not sure that it really matters either way, although the first way seems
like it would be tidier...

3. Would the xen list admins consider a new mailing list for a gpl'd
windows pv driver development? Would you consider providing a place to
host it under the source control you use (I forget which one :)? Failing
that I'll just put it up on SourceForge.

Thanks

James

Re: writing PV block drivers for Windows

[Andy Grover]

James Harper wrote:
> 3. Would the xen list admins consider a new mailing list for a gpl'd
> windows pv driver development? Would you consider providing a place to
> host it under the source control you use (I forget which one :)? Failing
> that I'll just put it up on SourceForge.

See
http://lists.xensource.com/archives/html/xen-devel/2007-09/msg00457.html
and http://www.microsoft.com/whdc/devtools/ddk/ServerSP1DDKEULA.mspx

It seems they're explicitly trying to disallow people from writing GPLed
Windows drivers. (see section 3b, the "Excluded License" sure sounds
like the GPL.) IANAL, but for a truly GPL-able driver, you need to avoid
using the WDK (samples, build env) entirely. The WDK docs are available
through MSDN website, however. Given the existence of projects like
Wine, I'm sure it's possible, but just not nearly as easy as using the WDK.

If I'm wrong, somebody please speak up...

Regards -- Andy

RE: Re: writing PV block drivers for Windows

[James Harper]

> It seems they're explicitly trying to disallow people from writing
GPLed
> Windows drivers. (see section 3b, the "Excluded License" sure sounds
> like the GPL.) IANAL, but for a truly GPL-able driver, you need to
avoid
> using the WDK (samples, build env) entirely. The WDK docs are
available
> through MSDN website, however. Given the existence of projects like
> Wine, I'm sure it's possible, but just not nearly as easy as using the
> WDK.
> 
> If I'm wrong, somebody please speak up...

I can understand the situation with the samples, so I've been careful
not to use them in any way which could mean that my drivers could be
considered a 'derived work'.

But I can't see anything that would indicate that a driver that compiles
under the WDF could be covered by the Microsoft license...

Does anyone have any contacts at MS that could answer these questions?

Thanks

James

Re: Re: writing PV block drivers for Windows

[James Smart]

James Harper wrote:
> I can understand the situation with the samples, so I've been careful
> not to use them in any way which could mean that my drivers could be
> considered a 'derived work'.
> 
> But I can't see anything that would indicate that a driver that compiles
> under the WDF could be covered by the Microsoft license...

Then pay very close attention to paragraph (c) in section 3, because if you
then get WQHL certification on the driver, and such certification is a
mandated in many situations for sales and support, then it doesn't matter
where the source came from.

-- james s

Andy's EULA link : http://www.microsoft.com/whdc/devtools/ddk/ServerSP1DDKEULA.mspx

Re: Re: writing PV block drivers for Windows

[Alan Cox]

> Then pay very close attention to paragraph (c) in section 3, because if you
> then get WQHL certification on the driver, and such certification is a
> mandated in many situations for sales and support, then it doesn't matter
> where the source came from.

Kind of ironic that Microsoft calls the GPL viral really isn't it 8)

Re: writing PV block drivers for Windows

[Andy Grover]

James Smart wrote:
> James Harper wrote:
>> I can understand the situation with the samples, so I've been careful
>> not to use them in any way which could mean that my drivers could be
>> considered a 'derived work'.

> Then pay very close attention to paragraph (c) in section 3, because if you
> then get WQHL certification on the driver, and such certification is a
> mandated in many situations for sales and support, then it doesn't matter
> where the source came from.
> http://www.microsoft.com/whdc/devtools/ddk/ServerSP1DDKEULA.mspx

Not getting a driver WHQL-certified may not matter to a lot of people.
BTW in the Vista WDK build 6000 the license appears to be substantially
shorter than the link above, and makes no mention of WHQL.

See also this thread: http://www.osronline.com/ShowThread.cfm?link=101027
It also seems to agree that if you stay away from the samples, you're OK.

James (Harper), is what you have so far available somewhere?

-- Andy

Re: writing PV block drivers for Windows

[Pezza]

James,

I'd be pretty much interested in the evolution this thing had (1 month has
passed...).
Have you got anything functional? Do you need any help with it (I'd be
extremely interested in this)?




James Harper wrote:
> 
> I'm now at the stage where I can think about writing some PV block
> drivers for Windows. I have working event channel and xen store
> subsystems (but they'll probably need some more refinement once things
> progress), and the Windows XenPCI driver enumerates devices as they are
> added to xenstore.
> 
> This leaves me with a few questions...
> 
> 1. I assume that the qemu virtual BIOS uses the virtual ATA for
> communications. Once my Windows drivers are loaded at boot time (part of
> the bootstrap process I assume), I need to turn off the emulated ATA
> interface so that windows doesn't detect that (two access methods to the
> same block device can't be a good idea!)... how might I get xen/qemu to
> turn that off at a given point... by writing something into xenstore?
>  
> 2. I'm presently planning on writing the vbd driver as a Windows SCSI
> miniport driver, which means windows would see the vbd driver as a scsi
> disk. It appears that Xen has a fairly simple idea of single block
> devices, without the concept of buses and controllers. Windows, however,
> likes controller buses with devices hanging off them. So I can create
> one virtual scsi HBA, and just put all the virtual devices on that, or I
> can create one virtual HBA per virtual device... any suggestions? I'm
> not sure that it really matters either way, although the first way seems
> like it would be tidier...
> 
> 3. Would the xen list admins consider a new mailing list for a gpl'd
> windows pv driver development? Would you consider providing a place to
> host it under the source control you use (I forget which one :)? Failing
> that I'll just put it up on SourceForge.
> 
> Thanks
> 
> James
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 
> 

-- 
View this message in context: http://www.nabble.com/writing-PV-block-drivers-for-Windows-tf4618069.html#a13305487
Sent from the Xen - Dev mailing list archive at Nabble.com.

RE: writing PV block drivers for Windows

[James Harper]

> James,
> 
> I'd be pretty much interested in the evolution this thing had (1 month
has
> passed...).
> Have you got anything functional? Do you need any help with it (I'd be
> extremely interested in this)?

Haven't had as much time as I'd like but things are progressing. I'm
still not sure that the windows side of the block device implementation
is really the correct way to do things...

I need to (yet again) rehash the code that enumerates block devices, and
once I'm happy with that I'll actually have to write some grant table
code, which is probably the main thing missing.

What is implemented:
. A Windows driver for the XenPCI device (eg loads and attaches to it,
and provides interfaces for the other drivers to talk to)
. Hypervisor calls (well... some of them... I'm just adding new ones as
I need them)
. A very basic event channel infrastructure
. A very basic xen bus infrastructure (list, read, watch, unwatch, etc)
. Creation of PDO's for everything returned by 'ls device' (xbd, xif,
etc) - windows then goes looking for drivers to attach to these
. The start of a disk class driver for xbd, which in turn enumerates
what is under device/xbd (eg 768, 5632, etc)

What is not implemented
. Grant table code
. The rest of the disk class driver
. An interface for usermode stuff to be able to talk to the kernel
driver
. A usermode service to monitor shutdown events (no documented way to do
a clean shutdown from kernel mode)
. drivers for network, console, vfb, etc - even if they're just dummy
drivers for now to stop windows asking for them

The pci driver contains the xenbus, event channel, and hypervisor stuff.
Ideally it would provide a ring buffer abstraction too, so the lower
drivers could just send and receive ringbuffer level events... I'll have
to look at a better way of doing that.

If I get time I'll put all the GPL stuff in each source file and put it
up somewhere, but probably not this week.

Thanks

James