[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8392fdc4-a6b2-a3aa-dca6-0a0ad7a411be@suse.com>
Date: Wed, 12 Jun 2019 12:36:49 +0200
From: Juergen Gross <jgross@...e.com>
To: Jan Beulich <JBeulich@...e.com>
Cc: Borislav Petkov <bp@...en8.de>,
Stefano Stabellini <sstabellini@...nel.org>,
the arch/x86 maintainers <x86@...nel.org>,
tglx@...utronix.de, xen-devel <xen-devel@...ts.xenproject.org>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>, mingo@...hat.com,
linux-kernel@...r.kernel.org, hpa@...or.com
Subject: Re: [Xen-devel] [PATCH] x86/xen: disable nosmt in Xen guests
On 12.06.19 12:19, Jan Beulich wrote:
>>>> On 12.06.19 at 12:12, <jgross@...e.com> wrote:
>> When running as a Xen guest selecting "nosmt" either via command line
>> or implicitly via default settings makes no sense, as the guest has no
>> clue about the real system topology it is running on. With Xen it is
>> the hypervisor's job to ensure the proper bug mitigations are active
>> regarding smt settings.
>
> I don't agree with the second sentence: It is in principle fine for the
> hypervisor to expose HT (i.e. not disable it as bug mitigation), and
> leave it to the guest kernels to protect themselves. We're just not
> at the point yet where Xen offers sufficient / reliable data to guest
> kernels to do so, so _for the time being_ what you say is correct.
Okay, I'll add something like:
This is true as long Xen doesn't support core scheduling together with
exposing the (then) correct sibling information to the guest and
indicating that case via a sutable interface.
Juergen
Powered by blists - more mailing lists