[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <04978d6d-8e1a-404d-b30d-402a7569c1f0@redhat.com>
Date: Tue, 16 Nov 2021 20:49:08 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Sean Christopherson <seanjc@...gle.com>
Cc: "Liu, Jing2" <jing2.liu@...el.com>,
LKML <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"Nakajima, Jun" <jun.nakajima@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Arjan van de Ven <arjan@...ux.intel.com>,
Jing Liu <jing2.liu@...ux.intel.com>,
"Cooper, Andrew" <andrew.cooper3@...rix.com>,
"Bae, Chang Seok" <chang.seok.bae@...el.com>
Subject: Re: Thoughts of AMX KVM support based on latest kernel
On 11/16/21 19:55, Thomas Gleixner wrote:
> We can do that, but I'm unhappy about this conditional in schedule(). So
> I was asking for doing a simple KVM only solution first:
>
> vcpu_run()
> kvm_load_guest_fpu()
> wrmsrl(XFD, guest_fpstate->xfd);
> XRSTORS
>
> do {
>
> local_irq_disable();
>
> if (test_thread_flag(TIF_NEED_FPU_LOAD))
> switch_fpu_return()
> wrmsrl(XFD, guest_fpstate->xfd);
>
> do {
> vmenter(); // Guest modifies XFD
> } while (reenter);
>
> update_xfd_state(); // Restore consistency
>
> local_irq_enable();
>
> and check how bad that is for KVM in terms of overhead on AMX systems.
I agree, this is how we handle SPEC_CTRL for example and it can be
extended to XFD. We should first do that, then switch to the MSR lists.
Hacking into schedule() should really be the last resort.
> local_irq_enable(); <- Problem starts here
>
> preempt_enable(); <- Becomes wider here
It doesn't become that much wider because there's always preempt
notifiers. So if it's okay to save XFD in the XSAVES wrapper and in
kvm_arch_vcpu_put(), that might be already remove the need to do it
schedule().
Paolo
Powered by blists - more mailing lists