Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <df3af1c2-fe93-ea21-56e5-4d70d08e55f2@redhat.com>
Date:   Wed, 13 Oct 2021 14:26:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.1.0
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core
Content-Language: en-US
To:     Andy Lutomirski <luto@kernel.org>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc:     the arch/x86 maintainers <x86@kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Arjan van de Ven <arjan@linux.intel.com>,
        kvm list <kvm@vger.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@intel.com>,
        Jing Liu <jing2.liu@linux.intel.com>,
        Sean Christopherson <seanjc@google.com>
References: <20211011215813.558681373@linutronix.de>
 <20211011223611.069324121@linutronix.de>
 <8a5762ab-18d5-56f8-78a6-c722a2f387c5@redhat.com>
 <BYAPR11MB3256B39E2A34A09FF64ECC5BA9B79@BYAPR11MB3256.namprd11.prod.outlook.com>
 <0962c143-2ff9-f157-d258-d16659818e80@redhat.com>
 <BYAPR11MB325676AAA8A0785AF992A2B9A9B79@BYAPR11MB3256.namprd11.prod.outlook.com>
 <da47ba42-b61e-d236-2c1c-9c5504e48091@redhat.com>
 <d673e736-0a72-4549-816d-b755227ea797@www.fastmail.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <d673e736-0a72-4549-816d-b755227ea797@www.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 13/10/21 12:14, Andy Lutomirski wrote:
>> I think it's simpler to always wait for #NM, it will only happen
>> once per vCPU.  In other words, even if the guest clears XFD before
>> it generates #NM, the guest_fpu's XFD remains nonzero and an #NM
>> vmexit is possible.  After #NM the guest_fpu's XFD is zero; then
>> passthrough can happen and the #NM vmexit trap can be disabled.
>
> This will stop being at all optimal when Intel inevitably adds
> another feature that uses XFD.  In the potentially infinite window in
> which the guest manages XFD and #NM on behalf of its userspace and
> when the guest allocates the other hypothetical feature, all the #NMs
> will have to be trapped by KVM.

The reason is that it's quite common to simply let the guest see all 
CPUID bits that KVM knows about.  But it's not unlikely that most guests 
will not ever use any XFD feature, and therefore will not ever see an 
#NM.  I wouldn't have any problem with allocating _all_ of the dynamic 
state space on the first #NM.

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.

Paolo

> Is it really worthwhile for KVM to use XFD at all instead of
> preallocating the state and being done with it?  KVM would still have
> to avoid data loss if the guest sets XFD with non-init state, but #NM
> could always pass through.
>