From: Bob Liu <bob.liu@oracle.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: jgross@suse.com, xen-devel@lists.xen.org, annie.li@oracle.com,
Paul.Durrant@citrix.com, david.vrabel@citrix.com,
Ian.Jackson@citrix.com
Subject: Re: [PATCH] blkif.h: document scsi/0x12/0x<NN> node
Date: Wed, 23 Mar 2016 21:37:10 +0800 [thread overview]
Message-ID: <56F29C06.7080602@oracle.com> (raw)
In-Reply-To: <alpine.OSX.2.20.1603231317560.753@mac>
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.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-23 13:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 11:47 [PATCH] blkif.h: document scsi/0x12/0x<NN> node Bob Liu
2016-03-23 12:23 ` Paul Durrant
2016-03-23 14:22 ` Ian Jackson
2016-03-23 12:33 ` Roger Pau Monné
2016-03-23 13:37 ` Bob Liu [this message]
2016-03-23 14:53 ` Roger Pau Monné
2016-03-23 14:55 ` Paul Durrant
2016-03-23 15:43 ` Roger Pau Monné
2016-03-23 15:45 ` Paul Durrant
2016-03-23 16:00 ` Roger Pau Monné
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F29C06.7080602@oracle.com \
--to=bob.liu@oracle.com \
--cc=Ian.Jackson@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=annie.li@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=jgross@suse.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).