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:
> On 03/23/2016 08:33 PM, Roger Pau Monné wrote:
> > 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.
> > 
> 
> For this part, there is ioctl() interface for all block device.
> Looking at virtio-blk in KVM world, it can accept almost all SCSI commands 
> also in ioctl() even they already have virtio-scsi.
> But that's another story.
> 

So this means that you would then need to add a bunch of new request types 
to the PV block protocol in order to make use of this new exported 
information?

What are those commands going to be? How are they going to be passed to 
the underlying storage?

Roger.

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