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 <>
To:     Paolo Bonzini <>,
        "Liu, Jing2" <>,
        LKML <>
Cc:     "" <>,
        "Bae, Chang Seok" <>,
        Dave Hansen <>,
        Arjan van de Ven <>,
        "" <>,
        "Nakajima, Jun" <>,
        Jing Liu <>,
        "" <>,
        "Cooper, Andrew" <>
Subject: Re: [patch 13/31] x86/fpu: Move KVMs FPU swapping to FPU core


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:


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

        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)

        swap(current->thread.fpu.fpstate, current->thread.fpu.guest_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);

        swap(current->thread.fpu.fpstate, current->thread.fpu.guest_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:


     fpu_swap_kvm_fpu(); <- 1

     while (...)

     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)


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



Powered by blists - more mailing lists