Re: [Xen-devel] Status of 4.13

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Nov 21, 2019, at 3:34 PM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 21.11.2019 16:20, George Dunlap wrote:
>> 
>> 
>>> On Nov 21, 2019, at 8:41 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> 
>>> On 21.11.2019 08:36, Jürgen Groß wrote:
>>>> On 21.11.19 08:30, Steven Haigh wrote:
>>>>> On 2019-11-21 17:05, Jürgen Groß wrote:
>>>>>> Where do we stand with Xen 4.13 regarding blockers and related patches?
>>>>>> 
>>>>>> 2. Ryzen/Rome failures with Windows guests:
>>>>>>   What is the currently planned way to address the problem? Who is
>>>>>>   working on that?
>>>>> 
>>>>> A workaround was found by specifying cpuid values in the Windows VM 
>>>>> config file.
>>>>> 
>>>>> The workaround line is:
>>>>> cpuid = [ "0x80000008:ecx=xxxxxxxxxxxxxxxx0100xxxxxxxxxxxx" ]
>>>>> 
>>>>> It was suggested that this be documented - but no immediate action 
>>>>> should be taken - with a view to correct this properly in 4.14.
>>>> 
>>>> I'm aware of the suggestion, but not of any decision. :-)
>>> 
>>> It was my understanding that we'd cap the 4-bit value to 7 for
>>> the time being. I think George was planning to send a patch.
>> 
>> On that also, I’m aware of the suggestion, but not of any decision.
>> I don’t think I got much feedback, positive or negative, about the idea.
>> 
>> Suppose we implement the limit for 4.13. If someone runs Linux VMs
>> on 4.12 a system with a hardware value of 7 for apic_id_size, the
>> guests will see 8.  If they then migrate to 4.13, the value will
>> magically change under their feet to 7.  Is that OK?
> 
> Let's look at the prereqs for running a Linux (or actually any) VM
> on such hardware: At least on dual socket systems with such CPUs
> Xen 4.12 wouldn't even boot. I don't know how wide a range of
> single socket systems with these 64-code CPUs would exist or
> appear down the road.
> 
> The workaround before our enabling of x2APIC mode for these boxes
> was to disable SMT, which has the side effect of changing said
> value to 6.

Can you expand on this a bit?  Are you saying that Xen 4.12 couldn’t boot on 
such a system, and so as long as we limit this in the first Xen release which 
*can*, we won’t have a backwards compatibility problem?

But I thought Steven had already encountered and fixed this issue on such a 
system running 4.12 (or something earlier).

> As to your actual question - as far as Linux goes, I don't think
> they re-evaluate this CPUID leaf post boot. But I could be wrong
> with this, and of course other OSes might behave differently.

What I’m not getting here is a recommendation. :-)  I don’t really know what 
the chances of all these things happening are.

If you think there’s at least a 25% chance of it being approved, I can send a 
patch to limit the value to 7, and we can discuss it more there (where the 
patch name will make it more clear what’s being discussed).

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