From: Ian Jackson <Ian.Jackson@eu.citrix.com> To: Bob Liu <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, Paul.Durrant@citrix.com, firstname.lastname@example.org Subject: Re: [RFC PATCH] blkif.h: document scsi/0x12/0x83 node Date: Wed, 16 Mar 2016 12:36:01 +0000 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Bob Liu writes ("[RFC PATCH] blkif.h: document scsi/0x12/0x83 node"): > Sometimes, we need to query VPD page=0x83 data from underlying > storage so that vendor supplied software can run inside the VM and > believe it's talking to the vendor's own storage. But different > vendors may have different special features, so it's not suitable to > export through "feature-xxxx". > > One solution is query the whole VPD page through Xenstore node, which has > already been used by windows pv driver. > http://xenbits.xen.org/gitweb/?p=pvdrivers/win/xenvbd.git;a=blob;f=src/xenvbd/pdoinquiry.c Thanks for your contribution. Thanks also to Konrad for decoding the numbers, which really helps me understand what is going on here and helped me find the relevant references. (For background: I have just double-checked the SCSI spec and: INQUIRY lets you query either the standard page, or one of a number of `vital product data' pages, each identified by an 8-bit page number. The VPD pages are mostly full of vendor-specific data in vendor-specific format.) I have some qualms about the approach you have adopted. It is difficult to see how this feature could be used safely without knowledge specific to the storage vendor. But I think it is probably OK to define a specification along these lines provided that it is very clear that if you aren't the storage vendor and you use this and something breaks, you get to keep all the pieces. > + * scsi/0x12/0x83 > + * Values: string > + * A base64 formatted string providing VPD pages read out from backend > + * device. I think this probably isn't the prettiest name for this node or necessarily the best format but given that this protocol is already deployed, and this syntax will do, I don't want to quibble. I would like the base64 encoding to specified much more explicitly. Just `base64 formatted' is too vague. > + * The backend driver or the toolstack should write this node with VPD > + * informations when attaching devices. I think this is the wrong semantics. I certainly don't want to encourage backends to use this feature. Rather, I would prefer something like this: * scsi/0x12/0x<NN> This optional node contains SCSI INQUIRY VPD information. <NN> is the hexadecimal representation of the VPD page code. A frontend 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 (ie, which does not use these xenstore nodes), and which presents as a SCSI target to its containing OS, should support and provide whatever VPD information it considers appropriate, and should disregard these xenstore nodes. A frontend need not - and often will not - present to its containing OS as a device addressable with SCSI CDBs. Such a frontend has no use for SCSI INQUIRY VPD information. A backend should set this information with caution. Pages containing device-vendor-specific information should not be specified without the appropriate device-vendor-specific knowledge. Also I have two other observations: Firstly, AFAICT you have not provided any way to set the standard INQUIRY response. Is it not necessary in your application to provide synthetic vendorid and productid, at the very least ? Secondly, I think your hope that > blkfront in Linux ... can use the same mechanism. is I think misguided. blkfront does not present the disk (to the rest of the Linux storage system) as a SCSI device. Rather, Linux allows blkfront to present as a block device, directly, and this is what blkfront does. So blkfront would not consume this data. Ian. _______________________________________________ Xen-devel mailing list Xenemail@example.com http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-03-16 12:36 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 [this message] 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 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 \ --firstname.lastname@example.org \ --email@example.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).