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:18:46 +0200 Message-ID: <4926ED76.9060606@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> <4926EAB9.7060102@redhat.com> <8E9A93AB-6EEF-4582-A23A-BC B491A9307A@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]:35727 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754301AbYKURSz (ORCPT ); Fri, 21 Nov 2008 12:18:55 -0500 In-Reply-To: <8E9A93AB-6EEF-4582-A23A-BCB491A9307A@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: Alexander Graf wrote: >> >> Yeah. We could move some of these out, and emulate the rest (ltr I >> think is needed). > > Then older versions of kvm would still break If emulation fails, go back to virtualization. Or am I missing something? >> >> That's what kvm_x86_ops is for. We already emulate vendor specific >> instructions (vmcall and vmmcall). > > From what I can tell kvm_x86_ops tries to multiplex calls that happen > to be different on svm/vmx, but existent on both. SVM instructions > usually don't appear on VMX ;-). Right. But so what? I don't want to lose any future improvements the emulator may have (like traps on debug register, etc). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.