From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 12/12] Accelerate nested SVM by emulating parts of GIF=0 v6 Date: Fri, 21 Nov 2008 19:07:05 +0200 Message-ID: <4926EAB9.7060102@redhat.com> References: <1227280482-25361-1-git-send-email-agraf@suse.de> <1227280482-25361-2-git-send-email-agraf@suse.de> <1227280482-25361-3-git-send-email-agraf@suse.de> <1227280482-25361-4-git-send-email-agraf@suse.de> <1227280482-25361-5-git-send-email-agraf@suse.de> <1227280482-25361-6-git-send-email-agraf@suse.de> <1227280482-25361-7-git-send-email-agraf@suse.de> <1227280482-25361-8-git-send-email-agraf@suse.de> <1227280482-25361-9-git-send-email-agraf@suse.de> <1227280482-25361-10-git-send-email-agraf@suse.de> <1227280482-25361-11-git-send-email-agraf@suse.de> <1227280482-25361-12-git-send-email-agraf@suse.de> <1227280482-25361-13-git-send-email-agraf@suse.de> <4926E771.9000704@redhat.com> <3D59C2E9-27A0-4492-88E2-0A01C1A1A334@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, joro@8bytes.org, anthony@codemonkey.ws To: Alexander Graf Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36313 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755119AbYKURHE (ORCPT ); Fri, 21 Nov 2008 12:07:04 -0500 In-Reply-To: <3D59C2E9-27A0-4492-88E2-0A01C1A1A334@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: >> >> Neat trick. Have you looked at svm.c to see if we can cut out >> extraneous instructions (or move them out of the gif=0 area)? Could >> mean big savings. > > Well for now I only emulate pre-vmrun and vmsave, because the emulator > breaks on lldt and set dr6 and ltr and ... > Yeah. We could move some of these out, and emulate the rest (ltr I think is needed). >> >> Move to the regular x86 emulator, so if we extend it with debug flag >> support, privilege checking, etc, we get that for svm as well. > > Do you seriously want to have a callback to svm specific code in the > x86 emulator? That's what kvm_x86_ops is for. We already emulate vendor specific instructions (vmcall and vmmcall). > I was thinking of doing that, but this way looked way cleaner to me. I > would actually rather use prefixes as hint on pattern matching. > So e.g. if we find a clgi instruction with some random prefix (or > somehow marked in other ways) we could just run a pattern that does > what the entry code would do. This way no emulation would be needed. Smells like dynamic translation to me. I don't see how you could do that generically -- it might work for one version of kvm, but not for other hypervisors. >>> static int nested_svm_vmexit_real(struct vcpu_svm *svm, void *arg1, >>> void *arg2, void *opaque) >>> { >>> @@ -1551,6 +1600,9 @@ static int nested_svm_vmexit(struct vcpu_svm >>> *svm) >>> kvm_mmu_reset_context(&svm->vcpu); >>> kvm_mmu_load(&svm->vcpu); >>> + /* KVM calls vmsave after vmrun, so let's run it now if we can */ >>> + nested_svm_emulate(svm, NULL); >>> + >>> >> >> Will also call stgi eventually, so it may make sense to loop here too. > > See above - I did that, it broke, I tried to debug it for ~2 days and > just figured I'll leave it as is for now. Certainly, we can leave it for later. > The current version gives _huge_ savings already. Can you quantify? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.