From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rik van Riel Subject: Re: [PATCH] x86,kvm: move qemu/guest FPU switching out to vcpu_run Date: Tue, 14 Nov 2017 13:07:57 -0500 Message-ID: <1510682877.30057.1.camel@redhat.com> References: <20171114001223.441ea2ca@annuminas.surriel.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-09DCwSgiYgl3vGfspZei" Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, rkrcmar@redhat.com, borntraeger@de.ibm.com To: David Hildenbrand , pbonzini@redhat.com Return-path: Received: from mx1.redhat.com ([209.132.183.28]:54724 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751213AbdKNSIC (ORCPT ); Tue, 14 Nov 2017 13:08:02 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: --=-09DCwSgiYgl3vGfspZei Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2017-11-14 at 17:57 +0100, David Hildenbrand wrote: >=20 > > 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 >=20 > 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. --=20 All rights reversed --=-09DCwSgiYgl3vGfspZei Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJaCzD9AAoJEM553pKExN6DyK8H/j9+qYqvsquddcqYj/C8jo+1 J+pOjNGODfvW9ZwgCFu9TOkUL1fNYrZ1+m5sMBMnAcPQEhXcP+p8TBWXIQZZXB6y D6Ay3ns+evE1OEVUPFRQ7/d/8m+lpSDB8cXv+SoguoWwj7ffWYh8Hw0GBkrF5ybs /+lRfB/jDoHML49QBIaLbBmsp8cLMqpkjQWhz/MyeDf3VkfLXWTPsn7IcoHO9GVQ 0Z6KNd371By/gYbI2E2M7KDjPgmMlWNS7uaLreofaB3pnznVE6src9hkmHmPbq/m EWNlIiEVGH+TwuiG6nnPOUYhkZZmm9HiI2tV/aEmSYFTPAbnJT+PWNdFFjVyDA4= =kU3M -----END PGP SIGNATURE----- --=-09DCwSgiYgl3vGfspZei--