On 04/09/2019 10:26, Jan Beulich wrote:
> On 03.09.2019 14:34, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpuid.c
>>> +++ b/xen/arch/x86/cpuid.c
>>> @@ -545,6 +545,11 @@ void recalculate_cpuid_policy(struct dom
>>>
>>> p->extd.maxlinaddr = p->extd.lm ? 48 : 32;
>>>
>>> + if ( p->extd.rdpru )
>>> + p->extd.rdpru_max = min(p->extd.rdpru_max, max->extd.rdpru_max);
>>> + else
>>> + p->extd.rdpru_max = 0;
>>> +
>>> recalculate_xstate(p);
>>> recalculate_misc(p);
>> The CPUID logic needs quite a bit more than this, and to be safe on
>> migrate. For one, recalculate_xstate() unilaterally clobbers this to 0.
> I've looked again - recalculate_misc() clobbers .a, .b, and .c,
> but not .d afaics.
It is clobbered in the common section at the top.
...
/* Most of Power/RAS hidden from guests. */
p->extd.raw[0x7].a = p->extd.raw[0x7].b = p->extd.raw[0x7].c = 0;
p->extd.raw[0x8].d = 0;
switch ( p->x86_vendor )
{
...
> Anyway, just as a note, as you've said you'd
> take care of this anyway, and I'll re-base afterwards.
I looked at this a bit yesterday, and it very ugly opencoding bits of
the policy work without that work.
I've got an idea for just enough skeleton policy work to avoid the
duplicated effort, which I think will be a more sensible way of making
progress. It will certainly reduce the latency on being able to start
MSR_SPEC_CTRL work.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
