From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH RFC 01/31] xen/public: Export featureset information in the public API Date: Wed, 23 Dec 2015 03:24:59 -0700 Message-ID: <567A767B02000078000DFA35@prv-mh.provo.novell.com> References: <1450301073-28191-1-git-send-email-andrew.cooper3@citrix.com> <1450301073-28191-2-git-send-email-andrew.cooper3@citrix.com> <5679885102000078000C25AD@prv-mh.provo.novell.com> <56797D8E.3080408@citrix.com> <56798F7502000078000C2627@prv-mh.provo.novell.com> <567A71DF.2070109@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <567A71DF.2070109@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: andrew.cooper3@citrix.com Cc: tim@xen.org, Ian.Campbell@citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org >>> Andrew Cooper 12/23/15 11:05 AM >>> >On 22/12/2015 16:59, Jan Beulich wrote: >>>>> On 22.12.15 at 17:42, wrote: >>> On 22/12/15 16:28, Jan Beulich wrote: >>>>>>> On 16.12.15 at 22:24, wrote: >>>>> +#define XEN_FEATURESET_1d 0 /* 0x00000001.edx */ >>>>> +#define XEN_FEATURESET_1c 1 /* 0x00000001.ecx */ >>>>> +#define XEN_FEATURESET_e1d 2 /* 0x80000001.edx */ >>>>> +#define XEN_FEATURESET_e1c 3 /* 0x80000001.ecx */ >>>>> +#define XEN_FEATURESET_Da1 4 /* 0x0000000d:1.eax */ >>>>> +#define XEN_FEATURESET_7b0 5 /* 0x00000007:0.ebx */ >>>> This ends up being pretty cryptic. >>> Perhaps at a first glance, but there are so many uses that a shorthand >>> really is needed. See especially the MSR masking patches towards the >>> end of the series. >> I understand that something short is needed. But as the main >> identifier in the ABI? > >It really comes down to whom is intended to do what with a featureset. > >These values are derivable as functions of the feature values >themselves, but that requires an assumption that the featureset bitmap >mirrors hardware precisely. Providing this (names not withstanding) as >a part of the ABI is intended to provide that assurance. > >I fully intend higher levels of the toolstack to deal with a featureset >as an arbitrary bitmap, but lower levels like libxc do need a greater >level of understanding of its layout. All understood. The question just is whether the main identifiers in the public header should be this cryptic, or whether consumers should instead introduce shortcuts of their liking (even more so that, just like noted elsewhere, these identifiers also lack "CPU" and perhaps "x86" in their names - in the end feature leveling isn't something that's needed on x86 only). Jan