* [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 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 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 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 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: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 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
* 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: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 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 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-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
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).