[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59c1dbc5-95f6-c592-d85c-c13a64bbee55@redhat.com>
Date: Wed, 13 Oct 2021 17:05:44 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Andy Lutomirski <luto@...nel.org>,
"Liu, Jing2" <jing2.liu@...el.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc: the arch/x86 maintainers <x86@...nel.org>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
kvm list <kvm@...r.kernel.org>,
"Nakajima, Jun" <jun.nakajima@...el.com>,
Jing Liu <jing2.liu@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core
On 13/10/21 16:59, Andy Lutomirski wrote:
>>
>> Thinking more about it, #NM only has to be trapped if XCR0 enables
>> a dynamic feature. In other words, the guest value of XFD can be
>> limited to (host_XFD|guest_XFD) & guest_XCR0. This avoids that
>> KVM unnecessarily traps for old guests that use CR0.TS.
>>
> You could simplify this by allocating the state the first time XCR0
> enables the feature in question.
>
> (This is how regular non-virt userspace*should* work too, but it
> looks like I’ve probably been outvoted on that front…)
Good point, you could do that too and do the work on the XCR0 vmexit
instead of #NM.
Paolo
Powered by blists - more mailing lists