Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Bob Liu writes ("[RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> Sometimes, we need to query VPD page=0x83 data from underlying
> storage so that vendor supplied software can run inside the VM and
> believe it's talking to the vendor's own storage.  But different
> vendors may have different special features, so it's not suitable to
> export through "feature-xxxx".
> 
> One solution is query the whole VPD page through Xenstore node, which has
> already been used by windows pv driver.
> http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvbd.git;a=blob;f=src/xenvbd/pdoinquiry.c

Thanks for your contribution.

Thanks also to Konrad for decoding the numbers, which really helps me
understand what is going on here and helped me find the relevant
references.

(For background: I have just double-checked the SCSI spec and: INQUIRY
lets you query either the standard page, or one of a number of `vital
product data' pages, each identified by an 8-bit page number.  The VPD
pages are mostly full of vendor-specific data in vendor-specific
format.)

I have some qualms about the approach you have adopted.  It is
difficult to see how this feature could be used safely without
knowledge specific to the storage vendor.

But I think it is probably OK to define a specification along these
lines provided that it is very clear that if you aren't the storage
vendor and you use this and something breaks, you get to keep all the
pieces.

> + * scsi/0x12/0x83
> + *   Values: string
> + *   A base64 formatted string providing VPD pages read out from backend
> + *   device.

I think this probably isn't the prettiest name for this node or
necessarily the best format but given that this protocol is already
deployed, and this syntax will do, I don't want to quibble.

I would like the base64 encoding to specified much more explicitly.
Just `base64 formatted' is too vague.


> + *   The backend driver or the toolstack should write this node with VPD
> + *   informations when attaching devices.

I think this is the wrong semantics.  I certainly don't want to
encourage backends to use this feature.

Rather, I would prefer something like this:

 * scsi/0x12/0x<NN>

   This optional node contains SCSI INQUIRY VPD information.
   <NN> is the hexadecimal representation of the VPD page code.

   A frontend which represents a Xen VBD to its containing operating
   system as a (virtual) SCSI target may return the specified data in
   response to INQUIRY commands from its containing OS.

   A frontend which supports this feature must return the backend-
   specified data for every INQUIRY command with the EVPD bit set.
   For EVPD=1 INQUIRY commands where the corresponding xenstore node
   does not exist, the frontend must report (to its containing OS) an
   appropriate failure condition.

   A frontend which does not support this feature (ie, which does not
   use these xenstore nodes), and which presents as a SCSI target to
   its containing OS, should support and provide whatever VPD
   information it considers appropriate, and should disregard these
   xenstore nodes.

   A frontend need not - and often will not - present to its
   containing OS as a device addressable with SCSI CDBs.  Such a
   frontend has no use for SCSI INQUIRY VPD information.

   A backend should set this information with caution.  Pages
   containing device-vendor-specific information should not be
   specified without the appropriate device-vendor-specific knowledge.


Also I have two other observations:

Firstly, AFAICT you have not provided any way to set the standard
INQUIRY response.  Is it not necessary in your application to provide
synthetic vendorid and productid, at the very least ?

Secondly, I think your hope that

> blkfront in Linux ... can use the same mechanism.

is I think misguided.  blkfront does not present the disk (to the rest
of the Linux storage system) as a SCSI device.  Rather, Linux allows
blkfront to present as a block device, directly, and this is what
blkfront does.

So blkfront would not consume this data.


Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel