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

[Wayne Gong <wayne.gong@oracle.com>]

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