From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: emulator: Only allow VMCALL/VMMCALL trapped by #UD Date: Wed, 09 Jan 2008 17:20:46 +0200 Message-ID: <4784E64E.30205@qumranet.com> References: <200801040936.08670.sheng.yang@intel.com> <477D9610.4010605@codemonkey.ws> <10EA09EFD8728347A513008B6B0DA77A029B54D6@pdsmsx411.ccr.corp.intel.com> <47803CEF.7000303@codemonkey.ws> <10EA09EFD8728347A513008B6B0DA77A029B5DC3@pdsmsx411.ccr.corp.intel.com> <4781FA68.7040604@qumranet.com> <10EA09EFD8728347A513008B6B0DA77A029B5E20@pdsmsx411.ccr.corp.intel.com> <478264B5.8030503@qumranet.com> <10EA09EFD8728347A513008B6B0DA77A029F5259@pdsmsx411.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, "Liu, Eric E" To: "Dong, Eddie" Return-path: In-Reply-To: <10EA09EFD8728347A513008B6B0DA77A029F5259-wq7ZOvIWXbNpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org Dong, Eddie wrote: >>>> If migration happens while rip is in the hypercall page, and if the >>>> >>>> >>> I didn't quit catch here. The source VM vCPU is in Qemu migration >>> part, The target VM VCPU is always waiting for migration >>> data/command. If you mean SMP case, all target VCPUs are in waiting >>> for data/cmd, and I assume source VCPUs are all in Qemu known state, >>> not? >>> >>> >>> >>> >> I'm talking about the guest rip. The guest is not aware of the >> migration. >> >> Suppose that on the last copy that the guest rip is >> (hypercall_page_virt + 3). This address might be in the middle of >> some instruction on the >> hypercall page on the target machine. You need to fix up rip and >> > > This depends on how the hypercall page instruction is generated. > In Xen's construction, the code in hypercall page is exactly same > between SVM & VMX except the VMCALL/VMMCALL instruction itself. > > If you make the assumption that the hypercall is a single 3-byte instruction, then you might as well patch it directly. Of course it depends on Intel and AMD not reusing each other's opcodes. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace