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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > > > 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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> 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. Butif> 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 ''Findnew> hardware'' dialog to install drivers for it even there is a deviceobject> represents for it. When installing driver for new storage classdevice,> 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@lists.xensource.com http://lists.xensource.com/xen-devel