xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
@ 2016-03-16  3:09 Bob Liu
  2016-03-16  7:16 ` Konrad Rzeszutek Wilk
  2016-03-16 12:36 ` Ian Jackson
  0 siblings, 2 replies; 27+ messages in thread
From: Bob Liu @ 2016-03-16  3:09 UTC (permalink / raw)
  To: xen-devel; +Cc: jgross, Bob Liu, annie.li, Paul.Durrant, Ian.Jackson, roger.pau

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

This patch documents the Xenstore node to blkif.h, so that blkfront in Linux and
other frontends can use the same mechanism.

Signed-off-by: Bob Liu <bob.liu@oracle.com>
---
 xen/include/public/io/blkif.h |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 99f0326..30a6e46 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -182,6 +182,14 @@
  *      backend driver paired with a LIFO queue in the frontend will
  *      allow us to have better performance in this scenario.
  *
+ * scsi/0x12/0x83
+ * 	Values:	string
+ *
+ * 	A base64 formatted string providing VPD pages read out from backend
+ * 	device.
+ * 	The backend driver or the toolstack should write this node with VPD
+ * 	informations when attaching devices.
+ *
  *----------------------- Request Transport Parameters ------------------------
  *
  * max-ring-page-order
-- 
1.7.10.4


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

^ permalink raw reply related	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16  3:09 [RFC PATCH] blkif.h: document scsi/0x12/0x83 node Bob Liu
@ 2016-03-16  7:16 ` Konrad Rzeszutek Wilk
  2016-03-16 12:36 ` Ian Jackson
  1 sibling, 0 replies; 27+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-16  7:16 UTC (permalink / raw)
  To: Bob Liu; +Cc: jgross, xen-devel, annie.li, Paul.Durrant, Ian.Jackson, roger.pau

On Wed, Mar 16, 2016 at 11:09:05AM +0800, Bob Liu wrote:
> 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
> 
> This patch documents the Xenstore node to blkif.h, so that blkfront in Linux and
> other frontends can use the same mechanism.
> 
> Signed-off-by: Bob Liu <bob.liu@oracle.com>
> ---
>  xen/include/public/io/blkif.h |    8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 99f0326..30a6e46 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -182,6 +182,14 @@
>   *      backend driver paired with a LIFO queue in the frontend will
>   *      allow us to have better performance in this scenario.
>   *
> + * scsi/0x12/0x83

Could you mention that 0x12 is the SCSI opcode for INQUIRY and
0x83 is for device identity.

There is also the 0x80 with serial number (useful?)
> + * 	Values:	string
> + *
> + * 	A base64 formatted string providing VPD pages read out from backend
> + * 	device.
> + * 	The backend driver or the toolstack should write this node with VPD
> + * 	informations when attaching devices.
> + *
>   *----------------------- Request Transport Parameters ------------------------
>   *
>   * max-ring-page-order
> -- 
> 1.7.10.4
> 

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16  3:09 [RFC PATCH] blkif.h: document scsi/0x12/0x83 node Bob Liu
  2016-03-16  7:16 ` Konrad Rzeszutek Wilk
@ 2016-03-16 12:36 ` Ian Jackson
  2016-03-16 13:59   ` Bob Liu
  1 sibling, 1 reply; 27+ messages in thread
From: Ian Jackson @ 2016-03-16 12:36 UTC (permalink / raw)
  To: Bob Liu; +Cc: jgross, xen-devel, annie.li, Paul.Durrant, roger.pau

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16 12:36 ` Ian Jackson
@ 2016-03-16 13:59   ` Bob Liu
  2016-03-16 14:07     ` Paul Durrant
                       ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Bob Liu @ 2016-03-16 13:59 UTC (permalink / raw)
  To: Ian Jackson; +Cc: jgross, xen-devel, annie.li, Paul.Durrant, roger.pau


On 03/16/2016 08:36 PM, Ian Jackson wrote:
> 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.
> 

That's much more clear, thank you very much!

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

If backends are not encouraged to use this node, then we must have the toolstack write this node with the right VPD information.
Paul mentioned there should be corresponding code in the xapi project, but I haven't found out where.


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

But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.

That's because our underlying storage device has some vendor-specific features which can be recognized through informations in VPD pages.
And Our applications in guest want to aware of these vendor-specific features.

Regards,
Bob



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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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-16 14:33     ` Ian Jackson
  2 siblings, 1 reply; 27+ messages in thread
From: Paul Durrant @ 2016-03-16 14:07 UTC (permalink / raw)
  To: Bob Liu, Ian Jackson; +Cc: jgross, annie.li, Roger Pau Monne, xen-devel

> -----Original Message-----
> From: Bob Liu [mailto:bob.liu@oracle.com]
> Sent: 16 March 2016 13:59
> To: Ian Jackson
> Cc: xen-devel@lists.xen.org; Paul Durrant; konrad.wilk@oracle.com;
> jgross@suse.com; Roger Pau Monne; annie.li@oracle.com
> Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
> 
> 
> On 03/16/2016 08:36 PM, Ian Jackson wrote:
> > 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/x
> envbd/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.
> >
> 
> That's much more clear, thank you very much!
> 
> >
> > 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
> 
> If backends are not encouraged to use this node, then we must have the
> toolstack write this node with the right VPD information.
> Paul mentioned there should be corresponding code in the xapi project, but I
> haven't found out where.
> 
> 
> > 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.
> >
> 
> But we'd like to get the VPD information(of underlying storage device) also in
> Linux blkfront, even blkfront is not a SCSI device.
> 
> That's because our underlying storage device has some vendor-specific
> features which can be recognized through informations in VPD pages.
> And Our applications in guest want to aware of these vendor-specific
> features.

I think the missing piece of the puzzle is how the applications get this information. In Windows, since everything is a SCSI LUN (or has to emulate one) applications just send down 'scsi pass-through' IOCTLs and get the raw INQUIRY data back. In Linux there would need to be some alternative scheme that presumably blkfront would have to support.

  Paul

> 
> Regards,
> Bob
> 


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16 13:59   ` Bob Liu
  2016-03-16 14:07     ` Paul Durrant
@ 2016-03-16 14:32     ` David Vrabel
  2016-03-17  5:07       ` Bob Liu
  2016-03-17 11:12       ` Ian Jackson
  2016-03-16 14:33     ` Ian Jackson
  2 siblings, 2 replies; 27+ messages in thread
From: David Vrabel @ 2016-03-16 14:32 UTC (permalink / raw)
  To: Bob Liu, Ian Jackson; +Cc: jgross, annie.li, Paul.Durrant, roger.pau, xen-devel

On 16/03/16 13:59, Bob Liu wrote:
> 
> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.

Why does blkback/blkfront need to involved here?  This is just some
xenstore keys that can be written by the toolstack and directly read by
the relevant application in the guest.

David

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16 13:59   ` Bob Liu
  2016-03-16 14:07     ` Paul Durrant
  2016-03-16 14:32     ` David Vrabel
@ 2016-03-16 14:33     ` Ian Jackson
  2 siblings, 0 replies; 27+ messages in thread
From: Ian Jackson @ 2016-03-16 14:33 UTC (permalink / raw)
  To: Bob Liu; +Cc: jgross, xen-devel, annie.li, Paul.Durrant, roger.pau

Bob Liu writes ("Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> That's because our underlying storage device has some vendor-specific features which can be recognized through informations in VPD pages.
> And Our applications in guest want to aware of these vendor-specific features.

What kind of vendor-specific features ?  How would the application in
the guest make use of them ?

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16 14:07     ` Paul Durrant
@ 2016-03-17  5:04       ` Bob Liu
  0 siblings, 0 replies; 27+ messages in thread
From: Bob Liu @ 2016-03-17  5:04 UTC (permalink / raw)
  To: Paul Durrant; +Cc: jgross, xen-devel, annie.li, Ian Jackson, Roger Pau Monne


On 03/16/2016 10:07 PM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Bob Liu [mailto:bob.liu@oracle.com]
..snip..
>>>
>>
>> But we'd like to get the VPD information(of underlying storage device) also in
>> Linux blkfront, even blkfront is not a SCSI device.
>>
>> That's because our underlying storage device has some vendor-specific
>> features which can be recognized through informations in VPD pages.
>> And Our applications in guest want to aware of these vendor-specific
>> features.
> 
> I think the missing piece of the puzzle is how the applications get this information. 
> In Windows, since everything is a SCSI LUN (or has to emulate one) applications just send down 'scsi pass-through' IOCTLs and get the raw INQUIRY data back. 
> In Linux there would need to be some alternative scheme that presumably blkfront would have to support.
> 

They plan to send a REQ_TYPE_BLOCK_PC request down to blkfront, and hoping blkfront can handle this request and return the VPD informations.
I'll confirm weather they can read the xenstore node directly.

-- 
Regards,
-Bob

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-16 14:32     ` David Vrabel
@ 2016-03-17  5:07       ` Bob Liu
  2016-03-17 11:12       ` Ian Jackson
  1 sibling, 0 replies; 27+ messages in thread
From: Bob Liu @ 2016-03-17  5:07 UTC (permalink / raw)
  To: David Vrabel
  Cc: jgross, Ian Jackson, xen-devel, annie.li, Paul.Durrant, roger.pau


On 03/16/2016 10:32 PM, David Vrabel wrote:
> On 16/03/16 13:59, Bob Liu wrote:
>>
>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
> 
> Why does blkback/blkfront need to involved here?  This is just some
> xenstore keys that can be written by the toolstack and directly read by
> the relevant application in the guest.
> 

Exactly, let me check if they can direct read this xenstore node.

-- 
Regards,
-Bob

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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-22 12:55         ` Bob Liu
  1 sibling, 2 replies; 27+ messages in thread
From: Ian Jackson @ 2016-03-17 11:12 UTC (permalink / raw)
  To: David Vrabel; +Cc: jgross, annie.li, xen-devel, Paul.Durrant, roger.pau

David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> On 16/03/16 13:59, Bob Liu wrote:
> > But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
> 
> Why does blkback/blkfront need to involved here?  This is just some
> xenstore keys that can be written by the toolstack and directly read by
> the relevant application in the guest.

I'm getting rather a different picture here than at first.  Previously
I thought you had some 3rd-party application, not under your control,
which expected to see this VPD data.

But now I think that you're saying the application is under your own
control.  I don't understand why synthetic VPD data is the best way to
give your application the information it needs.

What is the application doing with this VPD data ?  I mean,
which specific application functions, and how do they depend on the
VPD data ?

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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
  1 sibling, 1 reply; 27+ messages in thread
From: David Vrabel @ 2016-03-17 11:18 UTC (permalink / raw)
  To: Ian Jackson; +Cc: jgross, annie.li, xen-devel, Paul.Durrant, roger.pau

On 17/03/16 11:12, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
>> On 16/03/16 13:59, Bob Liu wrote:
>>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
>>
>> Why does blkback/blkfront need to involved here?  This is just some
>> xenstore keys that can be written by the toolstack and directly read by
>> the relevant application in the guest.
> 
> I'm getting rather a different picture here than at first.  Previously
> I thought you had some 3rd-party application, not under your control,
> which expected to see this VPD data.

Bob != David?

> But now I think that you're saying the application is under your own
> control.  I don't understand why synthetic VPD data is the best way to
> give your application the information it needs.
> 
> What is the application doing with this VPD data ?  I mean,
> which specific application functions, and how do they depend on the
> VPD data ?

David


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-17 11:18         ` David Vrabel
@ 2016-03-17 11:20           ` Ian Jackson
  0 siblings, 0 replies; 27+ messages in thread
From: Ian Jackson @ 2016-03-17 11:20 UTC (permalink / raw)
  To: David Vrabel; +Cc: jgross, annie.li, xen-devel, Paul.Durrant, roger.pau

David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> On 17/03/16 11:12, Ian Jackson wrote:
> > David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> >> On 16/03/16 13:59, Bob Liu wrote:
> >>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
> >>
> >> Why does blkback/blkfront need to involved here?  This is just some
> >> xenstore keys that can be written by the toolstack and directly read by
> >> the relevant application in the guest.
> > 
> > I'm getting rather a different picture here than at first.  Previously
> > I thought you had some 3rd-party application, not under your control,
> > which expected to see this VPD data.
> 
> Bob != David?

Sorry, yes, the "you" I refer to above is Bob, not David.  I replied
to David's message because it seemd to give the best context.

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-17 11:12       ` Ian Jackson
  2016-03-17 11:18         ` David Vrabel
@ 2016-03-22 12:55         ` Bob Liu
  2016-03-22 13:41           ` David Vrabel
  1 sibling, 1 reply; 27+ messages in thread
From: Bob Liu @ 2016-03-22 12:55 UTC (permalink / raw)
  To: Ian Jackson
  Cc: jgross, xen-devel, annie.li, Paul.Durrant, David Vrabel, roger.pau


On 03/17/2016 07:12 PM, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
>> On 16/03/16 13:59, Bob Liu wrote:
>>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
>>
>> Why does blkback/blkfront need to involved here?  This is just some
>> xenstore keys that can be written by the toolstack and directly read by
>> the relevant application in the guest.
> 

They want a more generic way because the application may run on all kinds of environment including baremetal.
So they prefers to just call ioctl(SG_IO) against a storage device.

> I'm getting rather a different picture here than at first.  Previously
> I thought you had some 3rd-party application, not under your control,
> which expected to see this VPD data.
> 
> But now I think that you're saying the application is under your own
> control.  I don't understand why synthetic VPD data is the best way to
> give your application the information it needs.
> 
> What is the application doing with this VPD data ?  I mean,
> which specific application functions, and how do they depend on the
> VPD data ?
> 

From the feedbacks I just got, they do *not* want the details to be in public.

Anyway, I think this is not a block of this patch.
In Windows PV block driver, we already use the same way to get the raw INQUIRY data.
 * The Windows PV block driver accepts ioctl(SG_IO).
 * Then it reads this /scsi/0x12/0x83 node.
 * Then return the raw INQURIY data back to ioctl.

Since Linux guest also wants to do the same thing, let's making this mechanism to be a generic interface!
I'll post a patch adding ioctl(SG_IO) support to xen-blkfront together with a updated version of this patch soon.

Thanks,
Bob

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 12:55         ` Bob Liu
@ 2016-03-22 13:41           ` David Vrabel
  2016-03-22 14:10             ` Konrad Rzeszutek Wilk
  0 siblings, 1 reply; 27+ messages in thread
From: David Vrabel @ 2016-03-22 13:41 UTC (permalink / raw)
  To: Bob Liu, Ian Jackson
  Cc: jgross, xen-devel, annie.li, Paul.Durrant, David Vrabel, roger.pau

On 22/03/16 12:55, Bob Liu wrote:
> 
> On 03/17/2016 07:12 PM, Ian Jackson wrote:
>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
>>> On 16/03/16 13:59, Bob Liu wrote:
>>>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
>>>
>>> Why does blkback/blkfront need to involved here?  This is just some
>>> xenstore keys that can be written by the toolstack and directly read by
>>> the relevant application in the guest.
>>
> 
> They want a more generic way because the application may run on all kinds of environment including baremetal.
> So they prefers to just call ioctl(SG_IO) against a storage device.
> 
>> I'm getting rather a different picture here than at first.  Previously
>> I thought you had some 3rd-party application, not under your control,
>> which expected to see this VPD data.
>>
>> But now I think that you're saying the application is under your own
>> control.  I don't understand why synthetic VPD data is the best way to
>> give your application the information it needs.
>>
>> What is the application doing with this VPD data ?  I mean,
>> which specific application functions, and how do they depend on the
>> VPD data ?
>>
> 
> From the feedbacks I just got, they do *not* want the details to be in public.

It is difficult to suggest how it should be done correctly without this
information.

I also find it difficult to see a use case where running the storage
software in the guest (instead of in the backend) is sensible or desirable.

> Anyway, I think this is not a block of this patch.
> In Windows PV block driver, we already use the same way to get the raw INQUIRY data.
>  * The Windows PV block driver accepts ioctl(SG_IO).
>  * Then it reads this /scsi/0x12/0x83 node.
>  * Then return the raw INQURIY data back to ioctl.
> 
> Since Linux guest also wants to do the same thing, let's making this mechanism to be a generic interface!
> I'll post a patch adding ioctl(SG_IO) support to xen-blkfront together with a updated version of this patch soon.

I do not think this feature is generally useful outside of this
unspecified use case.  I do not think that supplying details about
underlying storage device (beyond generic properties) to guests is
sensible (e.g., what if the guest snapshot is restored on different
storage?).

And thus I do not not think we should either: a) make this part of the
blkif ABI; or b) add support to xen-blkfront or xen-blkback.

David

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 13:41           ` David Vrabel
@ 2016-03-22 14:10             ` Konrad Rzeszutek Wilk
  2016-03-22 14:38               ` David Vrabel
  0 siblings, 1 reply; 27+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-22 14:10 UTC (permalink / raw)
  To: David Vrabel
  Cc: jgross, Ian Jackson, annie.li, xen-devel, Paul.Durrant, roger.pau

On Tue, Mar 22, 2016 at 01:41:43PM +0000, David Vrabel wrote:
> On 22/03/16 12:55, Bob Liu wrote:
> > 
> > On 03/17/2016 07:12 PM, Ian Jackson wrote:
> >> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> >>> On 16/03/16 13:59, Bob Liu wrote:
> >>>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
> >>>
> >>> Why does blkback/blkfront need to involved here?  This is just some
> >>> xenstore keys that can be written by the toolstack and directly read by
> >>> the relevant application in the guest.
> >>
> > 
> > They want a more generic way because the application may run on all kinds of environment including baremetal.
> > So they prefers to just call ioctl(SG_IO) against a storage device.
> > 
> >> I'm getting rather a different picture here than at first.  Previously
> >> I thought you had some 3rd-party application, not under your control,
> >> which expected to see this VPD data.
> >>
> >> But now I think that you're saying the application is under your own
> >> control.  I don't understand why synthetic VPD data is the best way to
> >> give your application the information it needs.
> >>
> >> What is the application doing with this VPD data ?  I mean,
> >> which specific application functions, and how do they depend on the
> >> VPD data ?
> >>
> > 
> > From the feedbacks I just got, they do *not* want the details to be in public.
> 
> It is difficult to suggest how it should be done correctly without this
> information.

Just think of it as a black box.
> 
> I also find it difficult to see a use case where running the storage
> software in the guest (instead of in the backend) is sensible or desirable.

Are you suggesting that doing backend drivers is not sensible?
> 
> > Anyway, I think this is not a block of this patch.
> > In Windows PV block driver, we already use the same way to get the raw INQUIRY data.
> >  * The Windows PV block driver accepts ioctl(SG_IO).
> >  * Then it reads this /scsi/0x12/0x83 node.
> >  * Then return the raw INQURIY data back to ioctl.
> > 
> > Since Linux guest also wants to do the same thing, let's making this mechanism to be a generic interface!
> > I'll post a patch adding ioctl(SG_IO) support to xen-blkfront together with a updated version of this patch soon.
> 
> I do not think this feature is generally useful outside of this
> unspecified use case.  I do not think that supplying details about
> underlying storage device (beyond generic properties) to guests is
> sensible (e.g., what if the guest snapshot is restored on different
> storage?).

The restore process (xl) can update the XenStore key with the new storage.
> 
> And thus I do not not think we should either: a) make this part of the
> blkif ABI; or b) add support to xen-blkfront or xen-blkback.

It is already coded in Windows PV drivers so I am not following why
codyfing this in the blkif.h is harmful?


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

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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:12                 ` Ian Jackson
  0 siblings, 2 replies; 27+ messages in thread
From: David Vrabel @ 2016-03-22 14:38 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: jgross, Ian Jackson, annie.li, xen-devel, Paul.Durrant, roger.pau

On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 22, 2016 at 01:41:43PM +0000, David Vrabel wrote:
>> On 22/03/16 12:55, Bob Liu wrote:
>>>
>>> On 03/17/2016 07:12 PM, Ian Jackson wrote:
>>>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
>>>>> On 16/03/16 13:59, Bob Liu wrote:
>>>>>> But we'd like to get the VPD information(of underlying storage device) also in Linux blkfront, even blkfront is not a SCSI device.
>>>>>
>>>>> Why does blkback/blkfront need to involved here?  This is just some
>>>>> xenstore keys that can be written by the toolstack and directly read by
>>>>> the relevant application in the guest.
>>>>
>>>
>>> They want a more generic way because the application may run on all kinds of environment including baremetal.
>>> So they prefers to just call ioctl(SG_IO) against a storage device.
>>>
>>>> I'm getting rather a different picture here than at first.  Previously
>>>> I thought you had some 3rd-party application, not under your control,
>>>> which expected to see this VPD data.
>>>>
>>>> But now I think that you're saying the application is under your own
>>>> control.  I don't understand why synthetic VPD data is the best way to
>>>> give your application the information it needs.
>>>>
>>>> What is the application doing with this VPD data ?  I mean,
>>>> which specific application functions, and how do they depend on the
>>>> VPD data ?
>>>>
>>>
>>> From the feedbacks I just got, they do *not* want the details to be in public.
>>
>> It is difficult to suggest how it should be done correctly without this
>> information.
> 
> Just think of it as a black box.

This isn't sufficient.

You are presenting a solution but have not properly described the
problem so no one can evaluate whether the solution is appropriate.

>> I also find it difficult to see a use case where running the storage
>> software in the guest (instead of in the backend) is sensible or desirable.
> 
> Are you suggesting that doing backend drivers is not sensible?

I do not understand your question.

>>> Anyway, I think this is not a block of this patch.
>>> In Windows PV block driver, we already use the same way to get the raw INQUIRY data.
>>>  * The Windows PV block driver accepts ioctl(SG_IO).
>>>  * Then it reads this /scsi/0x12/0x83 node.
>>>  * Then return the raw INQURIY data back to ioctl.
>>>
>>> Since Linux guest also wants to do the same thing, let's making this mechanism to be a generic interface!
>>> I'll post a patch adding ioctl(SG_IO) support to xen-blkfront together with a updated version of this patch soon.
>>
>> I do not think this feature is generally useful outside of this
>> unspecified use case.  I do not think that supplying details about
>> underlying storage device (beyond generic properties) to guests is
>> sensible (e.g., what if the guest snapshot is restored on different
>> storage?).
> 
> The restore process (xl) can update the XenStore key with the new storage.

And how is this going to be communicated to the application using the data?

>> And thus I do not not think we should either: a) make this part of the
>> blkif ABI; or b) add support to xen-blkfront or xen-blkback.
> 
> It is already coded in Windows PV drivers so I am not following why
> codyfing this in the blkif.h is harmful?

My understanding was that this was a legacy hack that should be removed
(we do not currently make use of it).

David

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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:12                 ` Ian Jackson
  1 sibling, 1 reply; 27+ messages in thread
From: Paul Durrant @ 2016-03-22 14:43 UTC (permalink / raw)
  To: David Vrabel, Konrad Rzeszutek Wilk
  Cc: jgross, annie.li, xen-devel, Ian Jackson, Roger Pau Monne

> -----Original Message-----
> From: David Vrabel [mailto:david.vrabel@citrix.com]
> Sent: 22 March 2016 14:38
> To: Konrad Rzeszutek Wilk
> Cc: Bob Liu; Ian Jackson; jgross@suse.com; xen-devel@lists.xen.org;
> annie.li@oracle.com; Paul Durrant; Roger Pau Monne
> Subject: Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
> 
> On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 22, 2016 at 01:41:43PM +0000, David Vrabel wrote:
> >> On 22/03/16 12:55, Bob Liu wrote:
> >>>
> >>> On 03/17/2016 07:12 PM, Ian Jackson wrote:
> >>>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> >>>>> On 16/03/16 13:59, Bob Liu wrote:
> >>>>>> But we'd like to get the VPD information(of underlying storage
> device) also in Linux blkfront, even blkfront is not a SCSI device.
> >>>>>
> >>>>> Why does blkback/blkfront need to involved here?  This is just some
> >>>>> xenstore keys that can be written by the toolstack and directly read
> by
> >>>>> the relevant application in the guest.
> >>>>
> >>>
> >>> They want a more generic way because the application may run on all
> kinds of environment including baremetal.
> >>> So they prefers to just call ioctl(SG_IO) against a storage device.
> >>>
> >>>> I'm getting rather a different picture here than at first.  Previously
> >>>> I thought you had some 3rd-party application, not under your control,
> >>>> which expected to see this VPD data.
> >>>>
> >>>> But now I think that you're saying the application is under your own
> >>>> control.  I don't understand why synthetic VPD data is the best way to
> >>>> give your application the information it needs.
> >>>>
> >>>> What is the application doing with this VPD data ?  I mean,
> >>>> which specific application functions, and how do they depend on the
> >>>> VPD data ?
> >>>>
> >>>
> >>> From the feedbacks I just got, they do *not* want the details to be in
> public.
> >>
> >> It is difficult to suggest how it should be done correctly without this
> >> information.
> >
> > Just think of it as a black box.
> 
> This isn't sufficient.
> 
> You are presenting a solution but have not properly described the
> problem so no one can evaluate whether the solution is appropriate.
> 
> >> I also find it difficult to see a use case where running the storage
> >> software in the guest (instead of in the backend) is sensible or desirable.
> >
> > Are you suggesting that doing backend drivers is not sensible?
> 
> I do not understand your question.
> 
> >>> Anyway, I think this is not a block of this patch.
> >>> In Windows PV block driver, we already use the same way to get the raw
> INQUIRY data.
> >>>  * The Windows PV block driver accepts ioctl(SG_IO).
> >>>  * Then it reads this /scsi/0x12/0x83 node.
> >>>  * Then return the raw INQURIY data back to ioctl.
> >>>
> >>> Since Linux guest also wants to do the same thing, let's making this
> mechanism to be a generic interface!
> >>> I'll post a patch adding ioctl(SG_IO) support to xen-blkfront together
> with a updated version of this patch soon.
> >>
> >> I do not think this feature is generally useful outside of this
> >> unspecified use case.  I do not think that supplying details about
> >> underlying storage device (beyond generic properties) to guests is
> >> sensible (e.g., what if the guest snapshot is restored on different
> >> storage?).
> >
> > The restore process (xl) can update the XenStore key with the new
> storage.
> 
> And how is this going to be communicated to the application using the data?
> 
> >> And thus I do not not think we should either: a) make this part of the
> >> blkif ABI; or b) add support to xen-blkfront or xen-blkback.
> >
> > It is already coded in Windows PV drivers so I am not following why
> > codyfing this in the blkif.h is harmful?
> 
> My understanding was that this was a legacy hack that should be removed
> (we do not currently make use of it).
>

AFAIK XenServer still very much makes use of it.

  Paul
 
> David

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 14:43                 ` Paul Durrant
@ 2016-03-22 15:09                   ` Ian Jackson
  2016-03-22 15:25                     ` Paul Durrant
  0 siblings, 1 reply; 27+ messages in thread
From: Ian Jackson @ 2016-03-22 15:09 UTC (permalink / raw)
  To: Paul Durrant; +Cc: jgross, xen-devel, annie.li, David Vrabel, Roger Pau Monne

Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> AFAIK XenServer still very much makes use of it.

Can you answer, for XenServer's use case, some of the questions that
David and I have asked ?

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 14:38               ` David Vrabel
  2016-03-22 14:43                 ` Paul Durrant
@ 2016-03-22 15:12                 ` Ian Jackson
  2016-03-22 15:27                   ` Konrad Rzeszutek Wilk
  1 sibling, 1 reply; 27+ messages in thread
From: Ian Jackson @ 2016-03-22 15:12 UTC (permalink / raw)
  To: David Vrabel; +Cc: jgross, annie.li, xen-devel, Paul.Durrant, roger.pau

David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> > Just think of it as a black box.
> 
> This isn't sufficient.
> 
> You are presenting a solution but have not properly described the
> problem so no one can evaluate whether the solution is appropriate.

I'm sorry to be awkward, but I'm afraid I do agree with David Vrabel's
messages in this thread.

I don't think this is a sterile academic conversation which would (if
satisfactorily answered) have no real implications.  Rather, if we
understood the use case properly, there would probably be implications
for whether how this functionality ought to be exposed via the libxl
API; whether blkfront should consume this information by default; and
so on.

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 15:09                   ` Ian Jackson
@ 2016-03-22 15:25                     ` Paul Durrant
  2016-03-22 16:14                       ` Ian Jackson
  0 siblings, 1 reply; 27+ messages in thread
From: Paul Durrant @ 2016-03-22 15:25 UTC (permalink / raw)
  To: Ian Jackson; +Cc: jgross, xen-devel, annie.li, David Vrabel, Roger Pau Monne

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 22 March 2016 15:09
> To: Paul Durrant
> Cc: David Vrabel; Konrad Rzeszutek Wilk; Bob Liu; jgross@suse.com; xen-
> devel@lists.xen.org; annie.li@oracle.com; Roger Pau Monne
> Subject: RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
> 
> Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > AFAIK XenServer still very much makes use of it.
> 
> Can you answer, for XenServer's use case, some of the questions that
> David and I have asked ?
> 

It's getting hard to parse the thread at this point but, as I've mentioned in a previous response in the thread, Windows basically assumes disks are SCSI and it's up to the controller driver to make it look that way.
To that end the XENVBD Windows PV driver synthesizes VPD pages 80 and 83 but also have the ability pull base64 encoded VPD data from xenstore. The synthesis is required to make Windows work properly but the reason for overriding it with data from xenstore is not apparent. In XenServer the storage backend code does populate the VPD information (with UUID information for the storage volume created by XAPI) but I don't believe that this is necessary behaviour in the normal case. My *assumption* is that, at some point in the past, XenServer had OEM specific storage backends and the requirement to run OEM s/w in guest which relied on VPD supplied by the storage, and as is commonly the case xenstore was the easiest way to get this information from the backend and into the guest.

  Paul

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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:25                     ` Jan Beulich
  0 siblings, 2 replies; 27+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-22 15:27 UTC (permalink / raw)
  To: Ian Jackson
  Cc: jgross, xen-devel, annie.li, Paul.Durrant, David Vrabel, roger.pau

On Tue, Mar 22, 2016 at 03:12:02PM +0000, Ian Jackson wrote:
> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> > On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
> > > Just think of it as a black box.
> > 
> > This isn't sufficient.
> > 
> > You are presenting a solution but have not properly described the
> > problem so no one can evaluate whether the solution is appropriate.
> 
> I'm sorry to be awkward, but I'm afraid I do agree with David Vrabel's
> messages in this thread.
> 
> I don't think this is a sterile academic conversation which would (if
> satisfactorily answered) have no real implications.  Rather, if we
> understood the use case properly, there would probably be implications
> for whether how this functionality ought to be exposed via the libxl
> API; whether blkfront should consume this information by default; and
> so on.

Lets take one step back.

What is the problem with documenting an existing use-case in blkif.h?

Regardless of whether it is viewed "legacy" by some folks and by others
drivers it is still in use?

> 
> Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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
  1 sibling, 1 reply; 27+ messages in thread
From: Ian Jackson @ 2016-03-22 16:11 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: jgross, xen-devel, annie.li, Paul.Durrant, David Vrabel, roger.pau

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> > I don't think this is a sterile academic conversation which would (if
> > satisfactorily answered) have no real implications.  Rather, if we
> > understood the use case properly, there would probably be implications
> > for whether how this functionality ought to be exposed via the libxl
> > API; whether blkfront should consume this information by default; and
> > so on.
> 
> Lets take one step back.
> 
> What is the problem with documenting an existing use-case in blkif.h?
> 
> Regardless of whether it is viewed "legacy" by some folks and by others
> drivers it is still in use?

Firstly, if you want to document it then the documentation needs to
explain what the semantics are supposed to be.  At the moment I'm not
sure I see a correct and useful set of semantics.  I had a go at
writing something but several of the things I wrote in it seem to have
been contradicted by comments from Bob Liu and others.

It is difficult to write a suitable document.  Ideally the document
would give an example use case.  But it appears that the only use case
is super secret!

Secondly, apparently this is not regarded as deprecated.  Bob Liu
says he plans to add support for it to blkfront.

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  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
  0 siblings, 2 replies; 27+ messages in thread
From: Ian Jackson @ 2016-03-22 16:14 UTC (permalink / raw)
  To: Paul Durrant; +Cc: jgross, xen-devel, annie.li, David Vrabel, Roger Pau Monne

Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> It's getting hard to parse the thread at this point but, as I've
> mentioned in a previous response in the thread, Windows basically
> assumes disks are SCSI and it's up to the controller driver to make
> it look that way.

Right.  That makes perfect sense.

> To that end the XENVBD Windows PV driver synthesizes VPD pages 80
> and 83 but also have the ability pull base64 encoded VPD data from
> xenstore. The synthesis is required to make Windows work properly

Right.

> but the reason for overriding it with data from xenstore is not
> apparent.

Thanks, this is the part that we are struggling with and which it is
proposed to now document.

> In XenServer the storage backend code does populate the
> VPD information (with UUID information for the storage volume
> created by XAPI) but I don't believe that this is necessary
> behaviour in the normal case.

So the VPD here is a UUID from Xapi ?  Not anything do with the
underlying storage ?

I think that is a plausible thing for Xapi to do.  Although I don't
fully understand why it would be necessary, it doesn't seem
implausible that there are guest OS's which look for and do something
useful with such data (because they could use it, for example, to
reliably identify a storage volume other than by reading its
contents).

> My *assumption* is that, at some point
> in the past, XenServer had OEM specific storage backends and the
> requirement to run OEM s/w in guest which relied on VPD supplied by
> the storage, and as is commonly the case xenstore was the easiest
> way to get this information from the backend and into the guest.

Right, but the VPD information would be Xapi-generated and generic,
rather than containing OEM information from the disk ?

Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 15:27                   ` Konrad Rzeszutek Wilk
  2016-03-22 16:11                     ` Ian Jackson
@ 2016-03-22 16:25                     ` Jan Beulich
  1 sibling, 0 replies; 27+ messages in thread
From: Jan Beulich @ 2016-03-22 16:25 UTC (permalink / raw)
  To: Konrad Rzeszutek Wilk
  Cc: Juergen Gross, Ian Jackson, xen-devel, annie.li, Paul.Durrant,
	David Vrabel, roger.pau

>>> On 22.03.16 at 16:27, <konrad.wilk@oracle.com> wrote:
> On Tue, Mar 22, 2016 at 03:12:02PM +0000, Ian Jackson wrote:
>> David Vrabel writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document 
> scsi/0x12/0x83 node"):
>> > On 22/03/16 14:10, Konrad Rzeszutek Wilk wrote:
>> > > Just think of it as a black box.
>> > 
>> > This isn't sufficient.
>> > 
>> > You are presenting a solution but have not properly described the
>> > problem so no one can evaluate whether the solution is appropriate.
>> 
>> I'm sorry to be awkward, but I'm afraid I do agree with David Vrabel's
>> messages in this thread.
>> 
>> I don't think this is a sterile academic conversation which would (if
>> satisfactorily answered) have no real implications.  Rather, if we
>> understood the use case properly, there would probably be implications
>> for whether how this functionality ought to be exposed via the libxl
>> API; whether blkfront should consume this information by default; and
>> so on.
> 
> Lets take one step back.
> 
> What is the problem with documenting an existing use-case in blkif.h?

Namely taking into account Paul's almost simultaneous reply I'm
in doubt whether this is a use case or an abuse of some readily
available mechanism.

Jan


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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 16:11                     ` Ian Jackson
@ 2016-03-22 16:38                       ` Konrad Rzeszutek Wilk
  0 siblings, 0 replies; 27+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-22 16:38 UTC (permalink / raw)
  To: Ian Jackson
  Cc: jgross, xen-devel, annie.li, Paul.Durrant, David Vrabel, roger.pau

On Tue, Mar 22, 2016 at 04:11:35PM +0000, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> > > I don't think this is a sterile academic conversation which would (if
> > > satisfactorily answered) have no real implications.  Rather, if we
> > > understood the use case properly, there would probably be implications
> > > for whether how this functionality ought to be exposed via the libxl
> > > API; whether blkfront should consume this information by default; and
> > > so on.
> > 
> > Lets take one step back.
> > 
> > What is the problem with documenting an existing use-case in blkif.h?
> > 
> > Regardless of whether it is viewed "legacy" by some folks and by others
> > drivers it is still in use?
> 
> Firstly, if you want to document it then the documentation needs to
> explain what the semantics are supposed to be.  At the moment I'm not
> sure I see a correct and useful set of semantics.  I had a go at
> writing something but several of the things I wrote in it seem to have
> been contradicted by comments from Bob Liu and others.
> 
> It is difficult to write a suitable document.  Ideally the document
> would give an example use case.  But it appears that the only use case
> is super secret!

:-)

> 
> Secondly, apparently this is not regarded as deprecated.  Bob Liu
> says he plans to add support for it to blkfront.

One step at a time. First lets document this XenStore key in blkif.h
so it is know what it does and the semantics of it.

> 
> Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 16:14                       ` Ian Jackson
@ 2016-03-22 16:50                         ` Konrad Rzeszutek Wilk
  2016-03-22 17:39                         ` Paul Durrant
  1 sibling, 0 replies; 27+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-22 16:50 UTC (permalink / raw)
  To: Ian Jackson
  Cc: jgross, xen-devel, annie.li, Paul Durrant, David Vrabel, Roger Pau Monne

On Tue, Mar 22, 2016 at 04:14:40PM +0000, Ian Jackson wrote:
> Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node"):
> > It's getting hard to parse the thread at this point but, as I've
> > mentioned in a previous response in the thread, Windows basically
> > assumes disks are SCSI and it's up to the controller driver to make
> > it look that way.
> 
> Right.  That makes perfect sense.
> 
> > To that end the XENVBD Windows PV driver synthesizes VPD pages 80
> > and 83 but also have the ability pull base64 encoded VPD data from
> > xenstore. The synthesis is required to make Windows work properly
> 
> Right.
> 
> > but the reason for overriding it with data from xenstore is not
> > apparent.
> 
> Thanks, this is the part that we are struggling with and which it is
> proposed to now document.
> 
> > In XenServer the storage backend code does populate the
> > VPD information (with UUID information for the storage volume
> > created by XAPI) but I don't believe that this is necessary
> > behaviour in the normal case.
> 
> So the VPD here is a UUID from Xapi ?  Not anything do with the
> underlying storage ?

For this to be 'correct' the SCSI INQ binary result data (which is
what the base64 would encode) would need to follow the SCSI op codes.

There are bits in it that MUST be defined to make any sense.
The serial number can be an UUID or such.
> 
> I think that is a plausible thing for Xapi to do.  Although I don't
> fully understand why it would be necessary, it doesn't seem
> implausible that there are guest OS's which look for and do something
> useful with such data (because they could use it, for example, to
> reliably identify a storage volume other than by reading its
> contents).
> 
> > My *assumption* is that, at some point
> > in the past, XenServer had OEM specific storage backends and the
> > requirement to run OEM s/w in guest which relied on VPD supplied by
> > the storage, and as is commonly the case xenstore was the easiest
> > way to get this information from the backend and into the guest.
> 
> Right, but the VPD information would be Xapi-generated and generic,
> rather than containing OEM information from the disk ?
> 
> Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
  2016-03-22 16:14                       ` Ian Jackson
  2016-03-22 16:50                         ` Konrad Rzeszutek Wilk
@ 2016-03-22 17:39                         ` Paul Durrant
  1 sibling, 0 replies; 27+ messages in thread
From: Paul Durrant @ 2016-03-22 17:39 UTC (permalink / raw)
  To: Ian Jackson; +Cc: jgross, xen-devel, annie.li, David Vrabel, Roger Pau Monne

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Sent: 22 March 2016 16:15
> To: Paul Durrant
> Cc: David Vrabel; Konrad Rzeszutek Wilk; Bob Liu; jgross@suse.com; xen-
> devel@lists.xen.org; annie.li@oracle.com; Roger Pau Monne
> Subject: RE: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
> 
> Paul Durrant writes ("RE: [Xen-devel] [RFC PATCH] blkif.h: document
> scsi/0x12/0x83 node"):
> > It's getting hard to parse the thread at this point but, as I've
> > mentioned in a previous response in the thread, Windows basically
> > assumes disks are SCSI and it's up to the controller driver to make
> > it look that way.
> 
> Right.  That makes perfect sense.
> 
> > To that end the XENVBD Windows PV driver synthesizes VPD pages 80
> > and 83 but also have the ability pull base64 encoded VPD data from
> > xenstore. The synthesis is required to make Windows work properly
> 
> Right.
> 
> > but the reason for overriding it with data from xenstore is not
> > apparent.
> 
> Thanks, this is the part that we are struggling with and which it is
> proposed to now document.
> 
> > In XenServer the storage backend code does populate the
> > VPD information (with UUID information for the storage volume
> > created by XAPI) but I don't believe that this is necessary
> > behaviour in the normal case.
> 
> So the VPD here is a UUID from Xapi ?  Not anything do with the
> underlying storage ?
> 
> I think that is a plausible thing for Xapi to do.  Although I don't
> fully understand why it would be necessary, it doesn't seem
> implausible that there are guest OS's which look for and do something
> useful with such data (because they could use it, for example, to
> reliably identify a storage volume other than by reading its
> contents).
> 

I think that in the general case the VPD data is created by XAPI (or some element of the storage code) from the UUID. My belief is, though, there were cases where XAPI instead got the VPD data from the underlying storage.

> > My *assumption* is that, at some point
> > in the past, XenServer had OEM specific storage backends and the
> > requirement to run OEM s/w in guest which relied on VPD supplied by
> > the storage, and as is commonly the case xenstore was the easiest
> > way to get this information from the backend and into the guest.
> 
> Right, but the VPD information would be Xapi-generated and generic,
> rather than containing OEM information from the disk ?
> 

Not in the case of these (mythical) OEM backends.

I don't know whether it meets Oracle's use-case but I'm happy to add code in XENVBD to synthesize page 80 from a straightforward serial number in xenstore.

  Paul

> Ian.

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

^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2016-03-22 17:39 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-16  3:09 [RFC PATCH] blkif.h: document scsi/0x12/0x83 node Bob Liu
2016-03-16  7:16 ` Konrad Rzeszutek Wilk
2016-03-16 12:36 ` Ian Jackson
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

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