linux-kernel - Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1510682877.30057.1.camel@redhat.com>
Date:   Tue, 14 Nov 2017 13:07:57 -0500
From:   Rik van Riel <riel@...hat.com>
To:     David Hildenbrand <david@...hat.com>, pbonzini@...hat.com
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        tglx@...utronix.de, rkrcmar@...hat.com, borntraeger@...ibm.com
Subject: Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run

On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote:
> 
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index c73e493adf07..92e66685249e 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> 
> We should also get rid of guest_fpu_loaded now, right?

Indeed, we no longer need that member. I'll get rid of it.

> emulator_get_fpu() does a kvm_load_guest_fpu(). Doesn't that mean
> that
> this is now not needed anymore? (at least when emulator code is
> called
> from inside the loop?)

Now that is a very good question!

When called from inside the loop, it is indeed not
needed.

My question is, can the in-kernel emulator code ever
be called from OUTSIDE the KVM_RUN ioctl loop?

If so, we need to restore the user FPU context before
returning from the emulator code. Given that the current
emulator code does not do that, I suspect this is not
the case. I also see no path from the kvm ioctl into
the emulator code, other than via KVM_RUN.

The FPU and XSAVE ioctls all work on the saved
vcpu->arch.guest_fpu data, and never directly on the
registers.

Looks like we can completely get rid of .get_fpu and
.put_fpu...

Unless Paolo has any objection, I'll go do that :)

> Also, what about preempt_diable() at that point, still needed?

If the guest FPU context is the only FPU context loaded
for the task at that point in time, we should not need
to run with preemption disabled.

After all, if we were to get preempted, the context switch
code would automatically save and restore the guest FPU
context for us.

-- 
All rights reversed
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)