lkml.org 
[lkml]   [2017]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run
From
Date
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[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-11-14 19:08    [W:0.065 / U:1.132 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site