xm block-attach DomID tap:aio:/...

xm block-attach DomID tap:aio:/...

[Wayne Gong]

Hi folks,

I meet a problem when developing windows PV drivers for Xen. Now my 
drivers can support adding a 'file' type backend media as a VBD device 
using 'xm block-attach' command. With the same code, 'xm block-attach' a 
'tap:aio' type backend media cannot works fine on my PV drivers. But if 
I add a 'file' type backend media to windows VM and set set it to 
'tap:aio' type, it works fine. Since my driver didn't get WHQL digital 
signature, when adding a new device VM, windows will pops up a 'Find new 
hardware' dialog to install drivers for it even there is a device object 
represents for it. When installing driver for new storage class device, 
windows PnP manager will remove the device object and add a new one 
represents for the new device. In this progress, I will set device 
backend state to XenbusStateClosing->XenbusStateClosed 
->XenbusStateInitWait and then reinitialize the device. If it's a 'file' 
type, all these progress works fine, but it's a 'type:aio' type, my 
drivers cannot get any response from ring buffer for Read/Write scsi 
command.

So does anybody can give me some brief guide on difference between 
'file' type and 'tap:aio' type as a backend media for a frontend PV 
drivers? And I want to confirm that a 'tap:aio' type backend can work 
well when backend state changed as 
XenbusStateInitWait->XenbusStateConnected-> 
XenbusStateClosing->XenbusStateClosed 
->XenbusStateInitWait->XenbusStateConnected. I know that a 'file' type 
backend is Yes, I think 'tap:aio' type is Yes either, just want to conform.

James, any suggestion?

BTW, I use OVM 2.1.2 based on Xen 3.1 series.

Merry Christmas and Happy New Year!

Thanks
Wayne

Re: xm block-attach DomID tap:aio:/...

[Andrew Lyon]

On Fri, Dec 26, 2008 at 11:03 AM, Wayne Gong <wayne.gong@oracle.com> wrote:
> Hi folks,
>
> I meet a problem when developing windows PV drivers for Xen. Now my drivers
> can support adding a 'file' type backend media as a VBD device using 'xm
> block-attach' command. With the same code, 'xm block-attach' a 'tap:aio'
> type backend media cannot works fine on my PV drivers. But if I add a 'file'
> type backend media to windows VM and set set it to 'tap:aio' type, it works
> fine. Since my driver didn't get WHQL digital signature, when adding a new
> device VM, windows will pops up a 'Find new hardware' dialog to install
> drivers for it even there is a device object represents for it. When
> installing driver for new storage class device, windows PnP manager will
> remove the device object and add a new one represents for the new device. In
> this progress, I will set device backend state to
> XenbusStateClosing->XenbusStateClosed ->XenbusStateInitWait and then
> reinitialize the device. If it's a 'file' type, all these progress works
> fine, but it's a 'type:aio' type, my drivers cannot get any response from
> ring buffer for Read/Write scsi command.
>
> So does anybody can give me some brief guide on difference between 'file'
> type and 'tap:aio' type as a backend media for a frontend PV drivers? And I
> want to confirm that a 'tap:aio' type backend can work well when backend
> state changed as XenbusStateInitWait->XenbusStateConnected->
> XenbusStateClosing->XenbusStateClosed
> ->XenbusStateInitWait->XenbusStateConnected. I know that a 'file' type
> backend is Yes, I think 'tap:aio' type is Yes either, just want to conform.
>
> James, any suggestion?

Why don't you help James to improve his drivers instead of writing yet
another closed source set of drivers? it seems a bit rude to ask for
help with your closed source drivers from the only developer of gpl
drivers.

Closed source drivers are available from xensource, novell/suse,
halsign, and now oracle as well?

It seems like such a waste of effort, especially as James's gplpv
drivers are already very good and in time will probably outperform all
of the closed source drivers.

Andy

>
> BTW, I use OVM 2.1.2 based on Xen 3.1 series.
>
> Merry Christmas and Happy New Year!
>
> Thanks
> Wayne
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

RE: xm block-attach DomID tap:aio:/...

[James Harper]

> >
> > James, any suggestion?
> 
> Why don't you help James to improve his drivers instead of writing yet
> another closed source set of drivers? it seems a bit rude to ask for
> help with your closed source drivers from the only developer of gpl
> drivers.
> 
> Closed source drivers are available from xensource, novell/suse,
> halsign, and now oracle as well?
> 
> It seems like such a waste of effort, especially as James's gplpv
> drivers are already very good and in time will probably outperform all
> of the closed source drivers.
> 

Andy,

Wayne's version of the drivers are forked from an earlier version of
mine, and are therefore GPL. I believe Wayne has slightly different
objectives but the info sharing and assistance goes both ways.

James

RE: xm block-attach DomID tap:aio:/...

[James Harper]

> Hi folks,
> 
> I meet a problem when developing windows PV drivers for Xen. Now my
> drivers can support adding a 'file' type backend media as a VBD device
> using 'xm block-attach' command. With the same code, 'xm block-attach'
a
> 'tap:aio' type backend media cannot works fine on my PV drivers. But
if
> I add a 'file' type backend media to windows VM and set set it to
> 'tap:aio' type, it works fine. Since my driver didn't get WHQL digital
> signature, when adding a new device VM, windows will pops up a 'Find
new
> hardware' dialog to install drivers for it even there is a device
object
> represents for it. When installing driver for new storage class
device,
> windows PnP manager will remove the device object and add a new one
> represents for the new device. In this progress, I will set device
> backend state to XenbusStateClosing->XenbusStateClosed
> ->XenbusStateInitWait and then reinitialize the device. If it's a
'file'
> type, all these progress works fine, but it's a 'type:aio' type, my
> drivers cannot get any response from ring buffer for Read/Write scsi
> command.
> 
> So does anybody can give me some brief guide on difference between
> 'file' type and 'tap:aio' type as a backend media for a frontend PV
> drivers? And I want to confirm that a 'tap:aio' type backend can work
> well when backend state changed as
> XenbusStateInitWait->XenbusStateConnected->
> XenbusStateClosing->XenbusStateClosed
> ->XenbusStateInitWait->XenbusStateConnected. I know that a 'file' type
> backend is Yes, I think 'tap:aio' type is Yes either, just want to
> conform.
> 
> James, any suggestion?
> 
> BTW, I use OVM 2.1.2 based on Xen 3.1 series.
> 

I have tried tap:aio before and also had no success, but I haven't
looked into why. If you do find out then please let me know.

Thanks

James