Re: [Xen-devel] Status of 4.13

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.11.2019 17:03, George Dunlap wrote:
> 
> 
>> 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).

Looks like I was mis-remembering - indeed Andreas posted such
CPUID output (despite this apparently only having been an 8-core
chip).

>> 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.

Nor do I. My _guess_ is it shouldn't upset any guest.

> 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).

Since we're looking for a preferably cheap and simple workaround
rather an actual solution, I think such a patch has higher than
25% probability of getting approved.

Jan

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