[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/CPUID: fill all fields in x86_cpuid_policy_fill_native()


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Mon, 22 Jun 2020 14:59:28 +0100
  • Authentication-results: esa5.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Paul Durrant <paul@xxxxxxx>, Wei Liu <wl@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Delivery-date: Mon, 22 Jun 2020 13:59:34 +0000
  • Ironport-sdr: 7X9gmyIAKOlQL8nvF1udnwKS4JBWh3MorgVme+hYznieiE5DEWK3pAhQlytfVS3c+dgZ96e4N8 eSfj/FsfUlFahmGdFJlPquz7PeEyimAOetHx2xjTsFbb45IlRYa7qMuA5w6DnE5Hz0IQvEXNJp Kx0RttgZ5u3yqAKGrA9X6Lh3jRg0iLtkTAHk7Fa5PusrhQZjWEgLambRYX3zl8LuEhhdkWF6sd nd4Ld+4Lzw5RPQ98Zoy/YU3CYfsvB0LC47QOQp6/q2liT+jcMfpaWYtXhWc/TVi1pBCxgremps 8KM=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22/06/2020 14:37, Jan Beulich wrote:
> On 22.06.2020 14:39, Andrew Cooper wrote:
>> On 22/06/2020 13:09, Jan Beulich wrote:
>>> Coverity validly complains that the new call from
>>> tools/tests/cpu-policy/test-cpu-policy.c:test_cpuid_current() leaves
>>> two fields uninitialized, yet they get then consumed by
>>> x86_cpuid_copy_to_buffer(). (All other present callers of the function
>>> pass a pointer to a static - and hence initialized - buffer.)
>>>
>>> Coverity-ID: 1464809
>>> Fixes: c22ced93e167 ("tests/cpu-policy: Confirm that CPUID serialisation is 
>>> sorted")
>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>
>>> --- a/xen/lib/x86/cpuid.c
>>> +++ b/xen/lib/x86/cpuid.c
>>> @@ -176,6 +176,10 @@ void x86_cpuid_policy_fill_native(struct
>>>                            ARRAY_SIZE(p->extd.raw) - 1); ++i )
>>>          cpuid_leaf(0x80000000 + i, &p->extd.raw[i]);
>>>  
>>> +    /* Don't report leaves from possible lower level hypervisor. */
>> ", for now."
>>
>> This will change in the future.
> I was pondering at that moment whether to add it, but then I didn't
> think we'd want to let shine through lower level hypervisor info.
> But yes, I've added it, because it won't be wrong to say "for now",
> even if it end up being for much longer.

It won't be very much longer.

I don't intend to let it "shine though", but the outer hypervisors data
should be in the raw/host policy, just as the Xen Xen/Viridian leaves
need to be in the guest policies.

This is the longterm plan to handle Viridian features, because the
existing HVMPARAM simply isn't expressive enough.

~Andrew



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.