| Message ID | 1458733679-20245-1-git-send-email-bob.liu@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> -----Original Message----- > From: Bob Liu [mailto:bob.liu@oracle.com] > Sent: 23 March 2016 11:48 > To: xen-devel@lists.xen.org > Cc: Paul Durrant; Ian Jackson; konrad.wilk@oracle.com; jgross@suse.com; > Roger Pau Monne; annie.li@oracle.com; David Vrabel; Bob Liu > Subject: [PATCH] blkif.h: document scsi/0x12/0x<NN> node > > This patch documents a xenstore node which is used by XENVBD Windows > PV > driver. > > The use case is that XenServer may have OEM specific storage backends and > there is requirement to run OEM software in guest which relied on VPD > information supplied by the storages. > Adding a node to xenstore is the easiest way to get this VPD information > from > the backend into guest where XENVBD Windows PV driver can get INQUIRY > VPD data > from this node and return to OEM software. > > Signed-off-by: Bob Liu <bob.liu@oracle.com> > --- > xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h > index 99f0326..afbcbff 100644 > --- a/xen/include/public/io/blkif.h > +++ b/xen/include/public/io/blkif.h > @@ -182,6 +182,30 @@ > * backend driver paired with a LIFO queue in the frontend will > * allow us to have better performance in this scenario. > * > + * scsi/0x12/0x<NN> > + * Values: base64 encoded string > + * > + * This optional node contains SCSI INQUIRY VPD information. > + * <NN> is the hexadecimal representation of the VPD page code. > + * Currently only XENVBD Windows PV driver is using this node. > + * > + * A frontend e.g XENVBD Windows PV driver which represents a Xen > VBD to > + * its containing operating system as a (virtual) SCSI target may return > the s/target/LUN > + * specified data in response to INQUIRY commands from its containing > OS. I think we can safely say "containing OS" is Windows. > + * > + * 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. Not necessarily. Page 0x80 is compulsory in the T10 SPC spec so it has to be synthesized in the absence of data in xenstore. > + * > + * A frontend which does not support this feature just disregard these > + * xenstore nodes. > + * > + * The data of this string node is base64 encoded. Base64 is a group of > + * similar binary-to-text encoding schemes that represent binary data in > an > + * ASCII string format by translating it into a radix-64 representation. Do we need to explain what base64 is? Paul > + * > *----------------------- Request Transport Parameters ------------------------ > * > * max-ring-page-order > -- > 1.7.10.4
On Wed, 23 Mar 2016, Bob Liu wrote: > This patch documents a xenstore node which is used by XENVBD Windows PV > driver. > > The use case is that XenServer may have OEM specific storage backends and > there is requirement to run OEM software in guest which relied on VPD > information supplied by the storages. > Adding a node to xenstore is the easiest way to get this VPD information from > the backend into guest where XENVBD Windows PV driver can get INQUIRY VPD data > from this node and return to OEM software. > > Signed-off-by: Bob Liu <bob.liu@oracle.com> > --- > xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h > index 99f0326..afbcbff 100644 > --- a/xen/include/public/io/blkif.h > +++ b/xen/include/public/io/blkif.h > @@ -182,6 +182,30 @@ > * backend driver paired with a LIFO queue in the frontend will > * allow us to have better performance in this scenario. > * > + * scsi/0x12/0x<NN> > + * Values: base64 encoded string > + * > + * This optional node contains SCSI INQUIRY VPD information. > + * <NN> is the hexadecimal representation of the VPD page code. > + * Currently only XENVBD Windows PV driver is using this node. > + * > + * A frontend e.g XENVBD Windows PV driver which represents a Xen VBD to > + * its containing operating system as a (virtual) SCSI target may return the > + * specified data in response to INQUIRY commands from its containing OS. > + * > + * A frontend which supports this feature must return the backend-specified > + * data for every INQUIRY command with the EVPD bit set. > + * For EVPD=1 INQUIRY commands where the corresponding xenstore node > + * does not exist, the frontend must report (to its containing OS) an > + * appropriate failure condition. > + * > + * A frontend which does not support this feature just disregard these > + * xenstore nodes. > + * > + * The data of this string node is base64 encoded. Base64 is a group of > + * similar binary-to-text encoding schemes that represent binary data in an > + * ASCII string format by translating it into a radix-64 representation. > + * I'm sorry, but I need to raise similar concerns as the ones expressed by other people. I understand that those pages that you plan to export to the guest contain some kind of hardware specific information, but how is the guest going to make use of this? It can only interact with a Xen virtual block device, and there you can only send read, write, flush and discard requests. Even the block size is hardcoded to 512b by the protocol, so I'm not sure how are you going to use this information. Also, the fact that's implemented in some drivers in some OS isn't an argument in order to have them added. FreeBSD had for a very long time a set of custom extensions, that where never added to blkif.h simply because they were broken and unneeded, so the solution was to remove them from the implementation, and the same could happen here IMHO. Roger.
On 03/23/2016 08:33 PM, Roger Pau Monné wrote: > On Wed, 23 Mar 2016, Bob Liu wrote: > >> This patch documents a xenstore node which is used by XENVBD Windows PV >> driver. >> >> The use case is that XenServer may have OEM specific storage backends and >> there is requirement to run OEM software in guest which relied on VPD >> information supplied by the storages. >> Adding a node to xenstore is the easiest way to get this VPD information from >> the backend into guest where XENVBD Windows PV driver can get INQUIRY VPD data >> from this node and return to OEM software. >> >> Signed-off-by: Bob Liu <bob.liu@oracle.com> >> --- >> xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ >> 1 file changed, 24 insertions(+) >> >> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h >> index 99f0326..afbcbff 100644 >> --- a/xen/include/public/io/blkif.h >> +++ b/xen/include/public/io/blkif.h >> @@ -182,6 +182,30 @@ >> * backend driver paired with a LIFO queue in the frontend will >> * allow us to have better performance in this scenario. >> * >> + * scsi/0x12/0x<NN> >> + * Values: base64 encoded string >> + * >> + * This optional node contains SCSI INQUIRY VPD information. >> + * <NN> is the hexadecimal representation of the VPD page code. >> + * Currently only XENVBD Windows PV driver is using this node. >> + * >> + * A frontend e.g XENVBD Windows PV driver which represents a Xen VBD to >> + * its containing operating system as a (virtual) SCSI target may return the >> + * specified data in response to INQUIRY commands from its containing OS. >> + * >> + * A frontend which supports this feature must return the backend-specified >> + * data for every INQUIRY command with the EVPD bit set. >> + * For EVPD=1 INQUIRY commands where the corresponding xenstore node >> + * does not exist, the frontend must report (to its containing OS) an >> + * appropriate failure condition. >> + * >> + * A frontend which does not support this feature just disregard these >> + * xenstore nodes. >> + * >> + * The data of this string node is base64 encoded. Base64 is a group of >> + * similar binary-to-text encoding schemes that represent binary data in an >> + * ASCII string format by translating it into a radix-64 representation. >> + * > > I'm sorry, but I need to raise similar concerns as the ones expressed by > other people. > > I understand that those pages that you plan to export to the guest contain > some kind of hardware specific information, but how is the guest going to > make use of this? > > It can only interact with a Xen virtual block device, and there you can > only send read, write, flush and discard requests. Even the block size is > hardcoded to 512b by the protocol, so I'm not sure how are you going to > use this information. > For this part, there is ioctl() interface for all block device. Looking at virtio-blk in KVM world, it can accept almost all SCSI commands also in ioctl() even they already have virtio-scsi. But that's another story. Thanks, Bob > Also, the fact that's implemented in some drivers in some OS isn't an > argument in order to have them added. FreeBSD had for a very long time a > set of custom extensions, that where never added to blkif.h simply because > they were broken and unneeded, so the solution was to remove them from the > implementation, and the same could happen here IMHO. > > Roger. >
Paul Durrant writes ("RE: [PATCH] blkif.h: document scsi/0x12/0x<NN> node"):
> > From: Bob Liu [mailto:bob.liu@oracle.com]
> > Sent: 23 March 2016 11:48
> > To: xen-devel@lists.xen.org
> > Cc: Paul Durrant; Ian Jackson; konrad.wilk@oracle.com; jgross@suse.com;
> > Roger Pau Monne; annie.li@oracle.com; David Vrabel; Bob Liu
> > Subject: [PATCH] blkif.h: document scsi/0x12/0x<NN> node
Nacked-by: Ian Jackson <ian.jackson@eu.citrix.com>
I'm sorry to say that the need for this protocol extension, and its
proper semantics, have yet to be established.
I don't think it was appropriate to repost the patch in this form
while the conversation on those topics is ongoing. It would have been
appropriate if the patch contained answers, or at least forward
movement, in that conversation. But regret to say that this version
of this patch does not do that.
> > + * The data of this string node is base64 encoded. Base64 is a group of
> > + * similar binary-to-text encoding schemes that represent binary data in
> > an
> > + * ASCII string format by translating it into a radix-64 representation.
>
> Do we need to explain what base64 is?
This seems to be a response to my complaint
I would like the base64 encoding to specified much more explicitly.
Just `base64 formatted' is too vague.
By that I meant that the specific exact base64 format (of which there
are of course several dialects each with various variants) has to be
specified, probably by an reference to a suitable external
specification.
I did not mean that a general dictionary definition of base64 should
be cut-and-pasted from Wikipedia into this specification document.
Thanks,
Ian.
On Wed, 23 Mar 2016, Bob Liu wrote: > On 03/23/2016 08:33 PM, Roger Pau Monné wrote: > > On Wed, 23 Mar 2016, Bob Liu wrote: > > > >> This patch documents a xenstore node which is used by XENVBD Windows PV > >> driver. > >> > >> The use case is that XenServer may have OEM specific storage backends and > >> there is requirement to run OEM software in guest which relied on VPD > >> information supplied by the storages. > >> Adding a node to xenstore is the easiest way to get this VPD information from > >> the backend into guest where XENVBD Windows PV driver can get INQUIRY VPD data > >> from this node and return to OEM software. > >> > >> Signed-off-by: Bob Liu <bob.liu@oracle.com> > >> --- > >> xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ > >> 1 file changed, 24 insertions(+) > >> > >> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h > >> index 99f0326..afbcbff 100644 > >> --- a/xen/include/public/io/blkif.h > >> +++ b/xen/include/public/io/blkif.h > >> @@ -182,6 +182,30 @@ > >> * backend driver paired with a LIFO queue in the frontend will > >> * allow us to have better performance in this scenario. > >> * > >> + * scsi/0x12/0x<NN> > >> + * Values: base64 encoded string > >> + * > >> + * This optional node contains SCSI INQUIRY VPD information. > >> + * <NN> is the hexadecimal representation of the VPD page code. > >> + * Currently only XENVBD Windows PV driver is using this node. > >> + * > >> + * A frontend e.g XENVBD Windows PV driver which represents a Xen VBD to > >> + * its containing operating system as a (virtual) SCSI target may return the > >> + * specified data in response to INQUIRY commands from its containing OS. > >> + * > >> + * A frontend which supports this feature must return the backend-specified > >> + * data for every INQUIRY command with the EVPD bit set. > >> + * For EVPD=1 INQUIRY commands where the corresponding xenstore node > >> + * does not exist, the frontend must report (to its containing OS) an > >> + * appropriate failure condition. > >> + * > >> + * A frontend which does not support this feature just disregard these > >> + * xenstore nodes. > >> + * > >> + * The data of this string node is base64 encoded. Base64 is a group of > >> + * similar binary-to-text encoding schemes that represent binary data in an > >> + * ASCII string format by translating it into a radix-64 representation. > >> + * > > > > I'm sorry, but I need to raise similar concerns as the ones expressed by > > other people. > > > > I understand that those pages that you plan to export to the guest contain > > some kind of hardware specific information, but how is the guest going to > > make use of this? > > > > It can only interact with a Xen virtual block device, and there you can > > only send read, write, flush and discard requests. Even the block size is > > hardcoded to 512b by the protocol, so I'm not sure how are you going to > > use this information. > > > > For this part, there is ioctl() interface for all block device. > Looking at virtio-blk in KVM world, it can accept almost all SCSI commands also in ioctl() even they already have virtio-scsi. > But that's another story. > So this means that you would then need to add a bunch of new request types to the PV block protocol in order to make use of this new exported information? What are those commands going to be? How are they going to be passed to the underlying storage? Roger.
> -----Original Message----- > From: Roger Pau Monné [mailto:roger.pau@citrix.com] > Sent: 23 March 2016 14:54 > To: Bob Liu > Cc: Roger Pau Monne; xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; > konrad.wilk@oracle.com; jgross@suse.com; annie.li@oracle.com; David > Vrabel > Subject: Re: [PATCH] blkif.h: document scsi/0x12/0x<NN> node > > On Wed, 23 Mar 2016, Bob Liu wrote: > > On 03/23/2016 08:33 PM, Roger Pau Monné wrote: > > > On Wed, 23 Mar 2016, Bob Liu wrote: > > > > > >> This patch documents a xenstore node which is used by XENVBD > Windows PV > > >> driver. > > >> > > >> The use case is that XenServer may have OEM specific storage backends > and > > >> there is requirement to run OEM software in guest which relied on VPD > > >> information supplied by the storages. > > >> Adding a node to xenstore is the easiest way to get this VPD information > from > > >> the backend into guest where XENVBD Windows PV driver can get > INQUIRY VPD data > > >> from this node and return to OEM software. > > >> > > >> Signed-off-by: Bob Liu <bob.liu@oracle.com> > > >> --- > > >> xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ > > >> 1 file changed, 24 insertions(+) > > >> > > >> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h > > >> index 99f0326..afbcbff 100644 > > >> --- a/xen/include/public/io/blkif.h > > >> +++ b/xen/include/public/io/blkif.h > > >> @@ -182,6 +182,30 @@ > > >> * backend driver paired with a LIFO queue in the frontend will > > >> * allow us to have better performance in this scenario. > > >> * > > >> + * scsi/0x12/0x<NN> > > >> + * Values: base64 encoded string > > >> + * > > >> + * This optional node contains SCSI INQUIRY VPD information. > > >> + * <NN> is the hexadecimal representation of the VPD page > code. > > >> + * Currently only XENVBD Windows PV driver is using this node. > > >> + * > > >> + * A frontend e.g XENVBD Windows PV driver which represents > a Xen VBD to > > >> + * its containing operating system as a (virtual) SCSI target may > return the > > >> + * specified data in response to INQUIRY commands from its > containing OS. > > >> + * > > >> + * A frontend which supports this feature must return the > backend-specified > > >> + * data for every INQUIRY command with the EVPD bit set. > > >> + * For EVPD=1 INQUIRY commands where the corresponding > xenstore node > > >> + * does not exist, the frontend must report (to its containing > OS) an > > >> + * appropriate failure condition. > > >> + * > > >> + * A frontend which does not support this feature just disregard > these > > >> + * xenstore nodes. > > >> + * > > >> + * The data of this string node is base64 encoded. Base64 is a > group of > > >> + * similar binary-to-text encoding schemes that represent > binary data in an > > >> + * ASCII string format by translating it into a radix-64 > representation. > > >> + * > > > > > > I'm sorry, but I need to raise similar concerns as the ones expressed by > > > other people. > > > > > > I understand that those pages that you plan to export to the guest > contain > > > some kind of hardware specific information, but how is the guest going to > > > make use of this? > > > > > > It can only interact with a Xen virtual block device, and there you can > > > only send read, write, flush and discard requests. Even the block size is > > > hardcoded to 512b by the protocol, so I'm not sure how are you going to > > > use this information. > > > > > > > For this part, there is ioctl() interface for all block device. > > Looking at virtio-blk in KVM world, it can accept almost all SCSI commands > also in ioctl() even they already have virtio-scsi. > > But that's another story. > > > > So this means that you would then need to add a bunch of new request > types > to the PV block protocol in order to make use of this new exported > information? > No, why do you think that? The info is in xenstore so why does the blkif protocol need to be involved at all? Paul > What are those commands going to be? How are they going to be passed to > the underlying storage? > > Roger.
On Wed, 23 Mar 2016, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monné [mailto:roger.pau@citrix.com] > > Sent: 23 March 2016 14:54 > > To: Bob Liu > > Cc: Roger Pau Monne; xen-devel@lists.xen.org; Paul Durrant; Ian Jackson; > > konrad.wilk@oracle.com; jgross@suse.com; annie.li@oracle.com; David > > Vrabel > > Subject: Re: [PATCH] blkif.h: document scsi/0x12/0x<NN> node > > > > On Wed, 23 Mar 2016, Bob Liu wrote: > > > On 03/23/2016 08:33 PM, Roger Pau Monné wrote: > > > > On Wed, 23 Mar 2016, Bob Liu wrote: > > > > > > > >> This patch documents a xenstore node which is used by XENVBD > > Windows PV > > > >> driver. > > > >> > > > >> The use case is that XenServer may have OEM specific storage backends > > and > > > >> there is requirement to run OEM software in guest which relied on VPD > > > >> information supplied by the storages. > > > >> Adding a node to xenstore is the easiest way to get this VPD information > > from > > > >> the backend into guest where XENVBD Windows PV driver can get > > INQUIRY VPD data > > > >> from this node and return to OEM software. > > > >> > > > >> Signed-off-by: Bob Liu <bob.liu@oracle.com> > > > >> --- > > > >> xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ > > > >> 1 file changed, 24 insertions(+) > > > >> > > > >> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h > > > >> index 99f0326..afbcbff 100644 > > > >> --- a/xen/include/public/io/blkif.h > > > >> +++ b/xen/include/public/io/blkif.h > > > >> @@ -182,6 +182,30 @@ > > > >> * backend driver paired with a LIFO queue in the frontend will > > > >> * allow us to have better performance in this scenario. > > > >> * > > > >> + * scsi/0x12/0x<NN> > > > >> + * Values: base64 encoded string > > > >> + * > > > >> + * This optional node contains SCSI INQUIRY VPD information. > > > >> + * <NN> is the hexadecimal representation of the VPD page > > code. > > > >> + * Currently only XENVBD Windows PV driver is using this node. > > > >> + * > > > >> + * A frontend e.g XENVBD Windows PV driver which represents > > a Xen VBD to > > > >> + * its containing operating system as a (virtual) SCSI target may > > return the > > > >> + * specified data in response to INQUIRY commands from its > > containing OS. > > > >> + * > > > >> + * A frontend which supports this feature must return the > > backend-specified > > > >> + * data for every INQUIRY command with the EVPD bit set. > > > >> + * For EVPD=1 INQUIRY commands where the corresponding > > xenstore node > > > >> + * does not exist, the frontend must report (to its containing > > OS) an > > > >> + * appropriate failure condition. > > > >> + * > > > >> + * A frontend which does not support this feature just disregard > > these > > > >> + * xenstore nodes. > > > >> + * > > > >> + * The data of this string node is base64 encoded. Base64 is a > > group of > > > >> + * similar binary-to-text encoding schemes that represent > > binary data in an > > > >> + * ASCII string format by translating it into a radix-64 > > representation. > > > >> + * > > > > > > > > I'm sorry, but I need to raise similar concerns as the ones expressed by > > > > other people. > > > > > > > > I understand that those pages that you plan to export to the guest > > contain > > > > some kind of hardware specific information, but how is the guest going to > > > > make use of this? > > > > > > > > It can only interact with a Xen virtual block device, and there you can > > > > only send read, write, flush and discard requests. Even the block size is > > > > hardcoded to 512b by the protocol, so I'm not sure how are you going to > > > > use this information. > > > > > > > > > > For this part, there is ioctl() interface for all block device. > > > Looking at virtio-blk in KVM world, it can accept almost all SCSI commands > > also in ioctl() even they already have virtio-scsi. > > > But that's another story. > > > > > > > So this means that you would then need to add a bunch of new request > > types > > to the PV block protocol in order to make use of this new exported > > information? > > > > No, why do you think that? The info is in xenstore so why does the blkif protocol need to be involved at all? Sorry, I'm just trying to figure out how is this going to be used. Isn't this information going to have some impact on how the user uses the block device? If not, why are we exporting it then? Roger.
> -----Original Message----- [snip] > > > > > > > > For this part, there is ioctl() interface for all block device. > > > > Looking at virtio-blk in KVM world, it can accept almost all SCSI > commands > > > also in ioctl() even they already have virtio-scsi. > > > > But that's another story. > > > > > > > > > > So this means that you would then need to add a bunch of new request > > > types > > > to the PV block protocol in order to make use of this new exported > > > information? > > > > > > > No, why do you think that? The info is in xenstore so why does the blkif > protocol need to be involved at all? > > Sorry, I'm just trying to figure out how is this going to be used. > > Isn't this information going to have some impact on how the user uses > the block device? If not, why are we exporting it then? > I assume that the user will want to get this information from blkfront via ioctl (as Bob suggests), but blkfront can just pull it straight from xenstore. No need for any communication with blkback. Paul > Roger.
On Wed, 23 Mar 2016, Paul Durrant wrote: > > -----Original Message----- > [snip] > > > > > > > > > > For this part, there is ioctl() interface for all block device. > > > > > Looking at virtio-blk in KVM world, it can accept almost all SCSI > > commands > > > > also in ioctl() even they already have virtio-scsi. > > > > > But that's another story. > > > > > > > > > > > > > So this means that you would then need to add a bunch of new request > > > > types > > > > to the PV block protocol in order to make use of this new exported > > > > information? > > > > > > > > > > No, why do you think that? The info is in xenstore so why does the blkif > > protocol need to be involved at all? > > > > Sorry, I'm just trying to figure out how is this going to be used. > > > > Isn't this information going to have some impact on how the user uses > > the block device? If not, why are we exporting it then? > > > > I assume that the user will want to get this information from blkfront via ioctl (as Bob suggests), but blkfront can just pull it straight from xenstore. No need for any communication with blkback. Yes, I understand this. What I want to know is what impact is this information going to have on how the user uses the PV block device. Is the information found in this magic page going to be used to try to send requests of specfic size in order to take advantge of some hw features? And then my other question is, in order to take advantadge of this information, will we need to add new PV block request types that encapsulate SCSI commands? TBH, ATM I don't see why this is useful at all. Roger.
diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h index 99f0326..afbcbff 100644 --- a/xen/include/public/io/blkif.h +++ b/xen/include/public/io/blkif.h @@ -182,6 +182,30 @@ * backend driver paired with a LIFO queue in the frontend will * allow us to have better performance in this scenario. * + * scsi/0x12/0x<NN> + * Values: base64 encoded string + * + * This optional node contains SCSI INQUIRY VPD information. + * <NN> is the hexadecimal representation of the VPD page code. + * Currently only XENVBD Windows PV driver is using this node. + * + * A frontend e.g XENVBD Windows PV driver which represents a Xen VBD to + * its containing operating system as a (virtual) SCSI target may return the + * specified data in response to INQUIRY commands from its containing OS. + * + * A frontend which supports this feature must return the backend-specified + * data for every INQUIRY command with the EVPD bit set. + * For EVPD=1 INQUIRY commands where the corresponding xenstore node + * does not exist, the frontend must report (to its containing OS) an + * appropriate failure condition. + * + * A frontend which does not support this feature just disregard these + * xenstore nodes. + * + * The data of this string node is base64 encoded. Base64 is a group of + * similar binary-to-text encoding schemes that represent binary data in an + * ASCII string format by translating it into a radix-64 representation. + * *----------------------- Request Transport Parameters ------------------------ * * max-ring-page-order
This patch documents a xenstore node which is used by XENVBD Windows PV driver. The use case is that XenServer may have OEM specific storage backends and there is requirement to run OEM software in guest which relied on VPD information supplied by the storages. Adding a node to xenstore is the easiest way to get this VPD information from the backend into guest where XENVBD Windows PV driver can get INQUIRY VPD data from this node and return to OEM software. Signed-off-by: Bob Liu <bob.liu@oracle.com> --- xen/include/public/io/blkif.h | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)