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

["Roger Pau Monné" <roger.pau@citrix.com>]

[-- Attachment #1: Type: text/plain, Size: 4451 bytes --]

On Wed, 23 Mar 2016, Paul Durrant wrote:
> > -----Original Message-----
> > From: Roger Pau Monné [mailto:roger.pau@citrix.com]
> > Sent: 23 March 2016 14:54
> > To: Bob Liu
> > Cc: Roger Pau Monne; xen-devel@lists.xen.org; Paul Durrant; Ian Jackson;
> > konrad.wilk@oracle.com; jgross@suse.com; annie.li@oracle.com; 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@oracle.com>
> > > >> ---
> > > >>  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?

Sorry, I'm just trying to figure out how is this going to be used.

Isn't this information going to have some impact on how the user uses 
the block device? If not, why are we exporting it then?

Roger.

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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