Re: [Xen-devel] [PATCH RFC] x86: Add hack to disable "Fake HT" mode

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 11/15/19 3:10 PM, Jürgen Groß wrote:
> On 15.11.19 16:05, George Dunlap wrote:
>> FTR, please avoid top-posting. :-)
>>
>> On 11/15/19 2:31 PM, Steven Haigh wrote:
>>> Just regarding the use of a system environment variable to turn this
>>> feature / bugfix / hack on and off - this would probably break starting
>>> the VM via the xendomains script.
>>>
>>> If the VM definition is in /etc/xen/auto/, then there would be nothing
>>> to set the environment variable before the VM is launched - hence it
>>> would not be applied and a guest crash would occur...
>>>
>>> Depending on the VM's settings, this would either continue to start &
>>> crash - or just stop again until it could be started with the ENV
>>> variable.
>>
>> Right.  So a couple of options:
>>
>> 1. Users of xendomains could set the environment variable in their
>> xendomains script
>>
>> 2. We could add a xl.cfg option.  Unknown xl.cfg entries are ignored
>> (for better or for worse); in the future, when the "fake ht" thing is
>> replaced, we can either continue ignoring it, or give a useful error
>> message saying how it should be changed.
>>
>> 2a.  We could have the config option *replace* the environment variable;
>> in which case we'd leave libvirt users high and dry
>>
>> 2b. We could have the config option cause xl to *set* the environment
>> variable, which should continue to allow other toolstacks (even those
>> not using libxl) to potentially work around the issue.
>>
>> Right now I'm leaning towards 2b, and having it be in a separate patch.
> 
> In which case we should consider having a way to set arbitrary
> environment variables from the config file in order to avoid this kind
> of discussion in future similar cases.

Right, I was thinking about a good / useful interface; e.g.:

workarounds = [
    AMD_RYZEN_TOPOLOGY_FIX=ignore
]

And then have 'ignore' mean, "Ignore this if you haven't heard of it, or
if the option has gone away; 'auto' mean, "Do the most reasonable
thing", 'strict' to mean, "Fail domain build if this workaround is
obsolete", or something like that.  Then users can dial their own "just
make it work" vs "tell me it's gone" as they like.

 -George


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