| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] xm block-attach DomID tap:aio:/...
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home