xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paul Durrant <Paul.Durrant@citrix.com>
To: Ian Jackson <Ian.Jackson@citrix.com>
Cc: "jgross@suse.com" <jgross@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"annie.li@oracle.com" <annie.li@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node
Date: Tue, 22 Mar 2016 15:25:33 +0000	[thread overview]
Message-ID: <f57d9c919c944ebcb317a34d208e08f5@AMSPEX02CL03.citrite.net> (raw)
In-Reply-To: <22257.24593.152679.907473@mariner.uk.xensource.com>

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

  reply	other threads:[~2016-03-22 15:25 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-16  3:09 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 [this message]
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

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=f57d9c919c944ebcb317a34d208e08f5@AMSPEX02CL03.citrite.net \
    --to=paul.durrant@citrix.com \
    --cc=Ian.Jackson@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 \
    --subject='Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node' \
    /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

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