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]

Date:   Fri, 15 Oct 2021 11:36:25 +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>,
        "Cooper, Andrew" <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 21:14, Thomas Gleixner wrote:
> On Thu, Oct 14 2021 at 17:01, Paolo Bonzini wrote:
>>> vcpu_create()
>>> 
>>>    fpu_init_fpstate_user(guest_fpu, supported_xcr0)
>>> 
>>> That will (it does not today) do:
>>> 
>>>       guest_fpu::__state_perm = supported_xcr0 & xstate_get_group_perm();
>>> 
>>> The you have the information you need right in the guest FPU.
>>
>> Good, I wasn't aware of the APIs that will be there.
>
> Me neither, but that's a pretty obvious consequence of the work I'm
> doing for AMX. So I made it up for you. :)

let me make some more up for you!

If you carefully look at part 2 of the rework, then you might notice
that there is a fundamental change which allows to do a real
simplification for KVM FPU handling:

   current->thread.fpu.fpstate

is now a pointer. So you can spare one FPU allocation because we can now
do:

fpu_attach_guest_fpu(supported_xcr0)
{
        guest_fpstate = alloc_fpstate(supported_xcr0);
        fpu_init_fpstate_user(guest_fpstate, supported_xcr0);
        current->thread.fpu.guest_fpstate = guest_fpstate;
}

fpu_swap_kvm_fpu() becomes in the first step:

fpu_swap_kvm_fpu(bool enter_guest)
{
        safe_fpregs_to_fpstate(current->thread.fpu.fpstate);

        swap(current->thread.fpu.fpstate, current->thread.fpu.guest_fpstate);

        restore_fpregs_from_fpstate(current->thread.fpu.fpstate);
}

@enter guest will allow to do some sanity checks

In a second step:

fpu_swap_kvm_fpu(bool enter_guest, u64 guest_needs_features)
{
        possibly_reallocate(enter_guest, guest_needs_features);
        safe_fpregs_to_fpstate(current->thread.fpu.fpstate);

        swap(current->thread.fpu.fpstate, current->thread.fpu.guest_fpstate);

        restore_fpregs_from_fpstate(current->thread.fpu.fpstate);
        possibly_reallocate(enter_guest, guest_needs_features);
}

@guest_needs_features is the information which you gather via guest XCR0
and guest XFD.

So fpu_swap_kvm_fpu() is going to be the place where reallocation happens
and that's good enough for both cases:

vcpu_run()

     fpu_swap_kvm_fpu(); <- 1

     while (...)
           vmenter();

     fpu_swap_kvm_fpu(); <- 2

#1 QEMU user space used feature and has already large fpstate

#2 Guest requires feature but has not used it yet (XCR0/XFD trapping)

See?

It's not only correct, it's also simple and truly beautiful.

Thanks,

        tglx