linux-kernel - Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <875ytz7q2u.ffs@tglx>
Date:   Thu, 14 Oct 2021 14:23:21 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paolo Bonzini <pbonzini@...hat.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     "x86@...nel.org" <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@...r.kernel.org" <kvm@...r.kernel.org>,
        "Nakajima, Jun" <jun.nakajima@...el.com>,
        Jing Liu <jing2.liu@...ux.intel.com>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core

Paolo,

On Thu, Oct 14 2021 at 08:50, Paolo Bonzini wrote:
> 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.

Exactly. If we don't enable it for QEMY itself, then this is creating
just a horrible inconsistency which requires nasty hacks. I'm not at
all interested in those as I just got rid of quite some and made the
code consistent.

> 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.

Errm.

   qemu()
     read_config()
     if (dynamic_features_passthrough())
	request_permission(feature)             <- prctl(ARCH_SET_STATE_ENABLE)

     create_vcpu_threads()
       ....

       vcpu_thread()
	 kvm_ioctl(ENABLE_DYN_FEATURE, feature) <- KVM ioctl

That's what I lined out, right?

>> 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.

KISS is a very reasonable engineering principle :)

If there is a real world use case and a proper technical justification
for doing the dynamic buffer allocation then I'm happy to discuss that.

Thanks,

        tglx