xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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

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