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: <ec9c761d-4b5c-71e2-c1fc-d256b6b78c04@redhat.com>
Date:   Thu, 14 Oct 2021 08:50:38 +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:     Thomas Gleixner <tglx@linutronix.de>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        LKML <linux-kernel@vger.kernel.org>
Cc:     "x86@kernel.org" <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@vger.kernel.org" <kvm@vger.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@intel.com>,
        Jing Liu <jing2.liu@linux.intel.com>,
        "seanjc@google.com" <seanjc@google.com>,
        Andrew Cooper <andrew.cooper3@citrix.com>
References: <871r4p9fyh.ffs@tglx>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <871r4p9fyh.ffs@tglx>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 13/10/21 16:06, Thomas Gleixner wrote:
>> - the guest value stored in vcpu->arch.
>>
>> - the "QEMU" value attached to host_fpu.  This one only becomes zero if
>> QEMU requires AMX (which shouldn't happen).
> 
> I don't think that makes sense.
> 
> First of all, if QEMU wants to expose AMX to guests, then it has to ask
> for permission to do so as any other user space process. We're not going
> to make that special just because.

Hmm, I would have preferred if there was no need to enable AMX for the 
QEMU FPU.  But you're saying that guest_fpu needs to swap out to 
current->thread.fpu if the guest is preempted, which would require 
XFD=0; and affect QEMU operation as well.

In principle I don't like it very much; it would be nicer to say "you 
enable it for QEMU itself via arch_prctl(ARCH_SET_STATE_ENABLE), and for 
the guests via ioctl(KVM_SET_CPUID2)".  But I can see why you want to 
keep things simple, so it's not a strong objection at all.

> Anything else will just create more problems than it solves. Especially
> #NM handling (think nested guest) and the XFD_ERR additive behaviour
> will be a nasty playground and easy to get wrong.
> 
> Not having that at all makes life way simpler, right?

It is simpler indeed, and it makes sense to start simple.  I am not sure 
if it will hold, but I agree it's better for the first implementation.

Paolo