Re: [Xen-devel] [RFC PATCH] blkif.h: document scsi/0x12/0x83 node

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx]
> Sent: 22 March 2016 15:09
> To: Paul Durrant
> Cc: David Vrabel; Konrad Rzeszutek Wilk; Bob Liu; jgross@xxxxxxxx; xen-
> devel@xxxxxxxxxxxxx; annie.li@xxxxxxxxxx; 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel