xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Ian Jackson <Ian.Jackson@eu.citrix.com>
To: Bob Liu <bob.liu@oracle.com>
Cc: jgross@suse.com, xen-devel@lists.xen.org, annie.li@oracle.com,
	Paul.Durrant@citrix.com, roger.pau@citrix.com
Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
Date: Wed, 16 Mar 2016 12:36:01 +0000	[thread overview]
Message-ID: <22249.21297.924145.426969@mariner.uk.xensource.com> (raw)
In-Reply-To: <1458097745-554-1-git-send-email-bob.liu@oracle.com>

Bob Liu writes ("[RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> Sometimes, we need to query VPD page=0x83 data from underlying
> storage so that vendor supplied software can run inside the VM and
> believe it's talking to the vendor's own storage.  But different
> vendors may have different special features, so it's not suitable to
> export through "feature-xxxx".
> 
> One solution is query the whole VPD page through Xenstore node, which has
> already been used by windows pv driver.
> http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvbd.git;a=blob;f=src/xenvbd/pdoinquiry.c

Thanks for your contribution.

Thanks also to Konrad for decoding the numbers, which really helps me
understand what is going on here and helped me find the relevant
references.

(For background: I have just double-checked the SCSI spec and: INQUIRY
lets you query either the standard page, or one of a number of `vital
product data' pages, each identified by an 8-bit page number.  The VPD
pages are mostly full of vendor-specific data in vendor-specific
format.)

I have some qualms about the approach you have adopted.  It is
difficult to see how this feature could be used safely without
knowledge specific to the storage vendor.

But I think it is probably OK to define a specification along these
lines provided that it is very clear that if you aren't the storage
vendor and you use this and something breaks, you get to keep all the
pieces.

> + * scsi/0x12/0x83
> + * 	Values:	string
> + * 	A base64 formatted string providing VPD pages read out from backend
> + * 	device.

I think this probably isn't the prettiest name for this node or
necessarily the best format but given that this protocol is already
deployed, and this syntax will do, I don't want to quibble.

I would like the base64 encoding to specified much more explicitly.
Just `base64 formatted' is too vague.


> + * 	The backend driver or the toolstack should write this node with VPD
> + * 	informations when attaching devices.

I think this is the wrong semantics.  I certainly don't want to
encourage backends to use this feature.

Rather, I would prefer something like this:

 * scsi/0x12/0x<NN>

   This optional node contains SCSI INQUIRY VPD information.
   <NN> is the hexadecimal representation of the VPD page code.

   A frontend 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 (ie, which does not
   use these xenstore nodes), and which presents as a SCSI target to
   its containing OS, should support and provide whatever VPD
   information it considers appropriate, and should disregard these
   xenstore nodes.

   A frontend need not - and often will not - present to its
   containing OS as a device addressable with SCSI CDBs.  Such a
   frontend has no use for SCSI INQUIRY VPD information.

   A backend should set this information with caution.  Pages
   containing device-vendor-specific information should not be
   specified without the appropriate device-vendor-specific knowledge.


Also I have two other observations:

Firstly, AFAICT you have not provided any way to set the standard
INQUIRY response.  Is it not necessary in your application to provide
synthetic vendorid and productid, at the very least ?

Secondly, I think your hope that

> blkfront in Linux ... can use the same mechanism.

is I think misguided.  blkfront does not present the disk (to the rest
of the Linux storage system) as a SCSI device.  Rather, Linux allows
blkfront to present as a block device, directly, and this is what
blkfront does.

So blkfront would not consume this data.


Ian.

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

  parent reply	other threads:[~2016-03-16 12:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16  3:09 Bob Liu
2016-03-16  7:16 ` Konrad Rzeszutek Wilk
2016-03-16 12:36 ` Ian Jackson [this message]
2016-03-16 13:59   ` Bob Liu
2016-03-16 14:07     ` Paul Durrant
2016-03-17  5:04       ` Bob Liu
2016-03-16 14:32     ` David Vrabel
2016-03-17  5:07       ` Bob Liu
2016-03-17 11:12       ` Ian Jackson
2016-03-17 11:18         ` David Vrabel
2016-03-17 11:20           ` Ian Jackson
2016-03-22 12:55         ` Bob Liu
2016-03-22 13:41           ` David Vrabel
2016-03-22 14:10             ` Konrad Rzeszutek Wilk
2016-03-22 14:38               ` David Vrabel
2016-03-22 14:43                 ` Paul Durrant
2016-03-22 15:09                   ` Ian Jackson
2016-03-22 15:25                     ` Paul Durrant
2016-03-22 16:14                       ` Ian Jackson
2016-03-22 16:50                         ` Konrad Rzeszutek Wilk
2016-03-22 17:39                         ` Paul Durrant
2016-03-22 15:12                 ` Ian Jackson
2016-03-22 15:27                   ` Konrad Rzeszutek Wilk
2016-03-22 16:11                     ` Ian Jackson
2016-03-22 16:38                       ` Konrad Rzeszutek Wilk
2016-03-22 16:25                     ` Jan Beulich
2016-03-16 14:33     ` Ian Jackson

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=22249.21297.924145.426969@mariner.uk.xensource.com \
    --to=ian.jackson@eu.citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=annie.li@oracle.com \
    --cc=bob.liu@oracle.com \
    --cc=jgross@suse.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    --subject='Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node' \
    /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

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).