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

[Bob Liu <bob.liu@oracle.com>]

On 03/16/2016 08:36 PM, Ian Jackson wrote:
> 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.
> 

That's much more clear, thank you very much!

> 
> 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

If backends are not encouraged to use this node, then we must have the toolstack write this node with the right VPD information.
Paul mentioned there should be corresponding code in the xapi project, but I haven't found out where.


> 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.
> 

But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.

That's because our underlying storage device has some vendor-specific features which can be recognized through informations in VPD pages.
And Our applications in guest want to aware of these vendor-specific features.

Regards,
Bob



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