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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Roger Pau Monné [mailto:roger.pau@xxxxxxxxxx]
> Sent: 23 March 2016 14:54
> To: Bob Liu
> Cc: Roger Pau Monne; xen-devel@xxxxxxxxxxxxx; Paul Durrant; Ian Jackson;
> konrad.wilk@xxxxxxxxxx; jgross@xxxxxxxx; annie.li@xxxxxxxxxx; David
> Vrabel
> Subject: Re: [PATCH] blkif.h: document scsi/0x12/0x<NN> node
> 
> 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?
>

No, why do you think that? The info is in xenstore so why does the blkif 
protocol need to be involved at all?

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