This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] RE: [Xen-users] Release 0.9.2 of GPL PV Drivers for Wind

Hi James-san and all,

I'm planning to post the latest pvSCSI driver tomorrow evening.
Following are brief explanation of current design and implementation 

# I will describe same contents on tomorrow's mail. :-)

As you know, after the post of pvSCSI driver to Xen community on Feb.
18th, we have gotten a lot of requests for improvements. We recognize
that the primary improvements, which affects the basic design of the
pvSCSI driver archtecture, are as follows.

1. Create a "virtual (SCSI) host" on Dom0, and attach it to 
   appropriate guest domain.
2. Hot-plug a LUN to the virtual host on the Dom0 created by above 1.
   The LUN appears and becomes usable immediately on the guest domain. 
   (By repeating this procedure, you can attach multiple LUNs to the
   guest domain.)
3. Support arbitrary SCSI ID mapping between physical host(s) on the 
   Dom0 and the virtual host. (Physical ID "host:channel:target:lun" 
   on the Dom0 can be mapped to arbitrary virtual ID 
4. The above 1. to 3. causes needs for "munging" of request and reply
   packet on Dom0. (e.g. The LUN list in reply packet for REPORT_LUN
   command should be appropriately altered in order to report correct
   LUNs actually attached to the virtual host.)
5. Support the Netchannel2, new communication mechanism between Dom0 
   and guest domain, in order to improve performance.

We have implemented mainly above 1. to 3.

As for 4., we are trying to develop a framework, which can support
various "munging" functions according to user requirements, device
specific functions and so on. (Ideally, the munging function can be
dynamically plugged in, and such like a bitmap table, which controls
invocation of the munging functions, can be specifiable by user.)
How ever, this is a very heavy work, so design and implementation are
still in progress.

And also above 5., we recognize that the source code is not yet 
available, therefore current pvSCSI driver does not support it. If it
became available, we would like to replace current communication 
mechanism with it.

Jun Kamada

On Wed, 28 May 2008 19:31:58 +1000
"James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:

> > 
> > James, if you can find some free time, could you please explain us how
> > this vscsi thing works and how to enable it? Would it also gain us
> some
> > performance, or is for serving other purpose?
> > 
> pvSCSI was a series of patches posted by Jun Kamada on or around 18th
> Feb 2008 (look for subject "[Patch x/7] pvSCSI driver]. Jun was given a
> heap of feedback in response to those patches and went away to dwell on
> it. A recent post indicated that he would be releasing an updated
> version soon.
> xenscsi is a windows frontend driver to the pvSCSI backend driver, and
> allows (via the sg interface) raw scsi devices to be exported from Linux
> to Windows. I am now using it to do test restores of Symantec's Backup
> Exec backups using Symantec's IDR CD. Because the PV drivers are all WDM
> instead of WDF, it's easy enough to make a windows text mode setup
> floppy so you can activate the drivers via F6 when installing Windows.
> As for performance, I'm getting between 1-2GB/minute from the tape
> drive, this performance is probably limited by other factors, eg I'm
> still using the qemu harddisk drivers at that stage.
> If you had a scsi device (or sas/sata possibly) that you were willing to
> dedicate solely to one domain, xenscsi would allow you to do it. I've
> only tested it on tape drives at the moment. YMMV :)
> James
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list