Re: [Xen-devel] [PATCH] blkif.h: document scsi/0x12/0x<NN> node

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, 23 Mar 2016, Bob Liu wrote:

> This patch documents a xenstore node which is used by XENVBD Windows PV
> driver.
> 
> The use case is that XenServer may have OEM specific storage backends and
> there is requirement to run OEM software in guest which relied on VPD
> information supplied by the storages.
> Adding a node to xenstore is the easiest way to get this VPD information from
> the backend into guest where XENVBD Windows PV driver can get INQUIRY VPD data
> from this node and return to OEM software.
> 
> Signed-off-by: Bob Liu <bob.liu@xxxxxxxxxx>
> ---
>  xen/include/public/io/blkif.h |   24 ++++++++++++++++++++++++
>  1 file changed, 24 insertions(+)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 99f0326..afbcbff 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -182,6 +182,30 @@
>   *      backend driver paired with a LIFO queue in the frontend will
>   *      allow us to have better performance in this scenario.
>   *
> + * scsi/0x12/0x<NN>
> + *   Values: base64 encoded string
> + *
> + *   This optional node contains SCSI INQUIRY VPD information.
> + *   <NN> is the hexadecimal representation of the VPD page code.
> + *   Currently only XENVBD Windows PV driver is using this node.
> + *
> + *   A frontend e.g XENVBD Windows PV driver 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 just disregard these
> + *   xenstore nodes.
> + *
> + *   The data of this string node is base64 encoded. Base64 is a group of
> + *   similar binary-to-text encoding schemes that represent binary data in an
> + *   ASCII string format by translating it into a radix-64 representation.
> + *

I'm sorry, but I need to raise similar concerns as the ones expressed by 
other people.

I understand that those pages that you plan to export to the guest contain 
some kind of hardware specific information, but how is the guest going to 
make use of this?

It can only interact with a Xen virtual block device, and there you can 
only send read, write, flush and discard requests. Even the block size is 
hardcoded to 512b by the protocol, so I'm not sure how are you going to 
use this information.

Also, the fact that's implemented in some drivers in some OS isn't an 
argument in order to have them added. FreeBSD had for a very long time a 
set of custom extensions, that where never added to blkif.h simply because 
they were broken and unneeded, so the solution was to remove them from the 
implementation, and the same could happen here IMHO.

Roger.

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