Re: [Xen-devel] [PATCH v2 04/13] libx86: Share struct cpuid_policy with userspace

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.07.18 at 11:51, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/07/18 10:38, Jan Beulich wrote:
>>>>> On 13.07.18 at 22:03, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> +static inline void cpuid_featureset_to_policy(
>>> +    const uint32_t fs[FEATURESET_NR_ENTRIES], struct cpuid_policy *p)
>>> +{
>>> +    p->basic._1d  = fs[FEATURESET_1d];
>>> +    p->basic._1c  = fs[FEATURESET_1c];
>>> +    p->extd.e1d   = fs[FEATURESET_e1d];
>>> +    p->extd.e1c   = fs[FEATURESET_e1c];
>>> +    p->xstate.Da1 = fs[FEATURESET_Da1];
>>> +    p->feat._7b0  = fs[FEATURESET_7b0];
>>> +    p->feat._7c0  = fs[FEATURESET_7c0];
>>> +    p->extd.e7d   = fs[FEATURESET_e7d];
>>> +    p->extd.e8b   = fs[FEATURESET_e8b];
>>> +    p->feat._7d0  = fs[FEATURESET_7d0];
>>> +}
>> I realize this is only code movement, but since you didn't answer the
>> question raised on the Intel Process Trace thread (v2 03/10) yet, I'll
>> raise it here again: Shouldn't other fields of p be set to zero here?
> 
> No - why should it?
> 
> (In fact, it very deliberately does not, and changing this will break
> all of the policy derivation logic.)

Did you look at the context in which I've raised the question originally?
I did in particular ask about this effectively still being a form of black
listing (I said "white listing" there by mistake), just taking leaf 6 (and
Intel hardware) as example. guest_cpuid() takes whatever is there in
the policy, and update_domain_cpuid_info() does nothing either. It
was my understanding that with the switch to the new model we're
now strictly while listing features. Luwei's patch would extend the
un-audited handing through to RDT and SGX leaves.

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel