From: Konrad Rzeszutek Wilk <firstname.lastname@example.org> To: Ian Jackson <Ian.Jackson@eu.citrix.com> Cc: "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Paul Durrant <Paul.Durrant@citrix.com>, David Vrabel <email@example.com>, Roger Pau Monne <firstname.lastname@example.org> Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node Date: Tue, 22 Mar 2016 12:50:00 -0400 [thread overview] Message-ID: <20160322165000.GD18504@char.us.oracle.com> (raw) In-Reply-To: <email@example.com> 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 Xenfirstname.lastname@example.org http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-22 16:50 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 2016-03-22 16:14 ` Ian Jackson 2016-03-22 16:50 ` Konrad Rzeszutek Wilk [this message] 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=20160322165000.GD18504@char.us.oracle.com \ --email@example.com \ --cc=Ian.Jackson@eu.citrix.com \ --cc=Paul.Durrant@citrix.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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).