xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Bob Liu <bob.liu@oracle.com>
Cc: "jgross@suse.com" <jgross@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Ian Jackson <Ian.Jackson@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH] blkif.h: document scsi/0x12/0x<NN> node
Date: Wed, 23 Mar 2016 14:55:05 +0000	[thread overview]
Message-ID: <61abb834b62148e4af393070b0651782@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <alpine.OSX.2.20.1603231544240.753@mac>

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

  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@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-03-23 14:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-23 11:47 [PATCH] blkif.h: document scsi/0x12/0x<NN> node Bob Liu
2016-03-23 12:23 ` Paul Durrant
2016-03-23 14:22   ` Ian Jackson
2016-03-23 12:33 ` Roger Pau Monné
2016-03-23 13:37   ` Bob Liu
2016-03-23 14:53     ` Roger Pau Monné
2016-03-23 14:55       ` Paul Durrant [this message]
2016-03-23 15:43         ` Roger Pau Monné
2016-03-23 15:45           ` Paul Durrant
2016-03-23 16:00             ` Roger Pau Monné

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=61abb834b62148e4af393070b0651782@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=annie.li@oracle.com \
    --cc=bob.liu@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=jgross@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).