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

From: "Jürgen Groß" <jgross@suse.com>
To: George Dunlap <george.dunlap@citrix.com>,
	Steven Haigh <netwiz@crc.id.au>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Andreas Kinzler <hfp@posteo.de>, Jan Beulich <jbeulich@suse.com>,
	Ian Jackson <ian.jackson@citrix.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [Xen-devel] [PATCH RFC] x86: Add hack to disable "Fake HT" mode
Date: Fri, 15 Nov 2019 16:10:33 +0100	[thread overview]
Message-ID: <98e13c5d-fdc9-3805-3081-9a001d69898a@suse.com> (raw)
In-Reply-To: <c8ee22b9-5823-a362-4ca3-e7bcec105b99@citrix.com>

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.

Juergen

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