From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: SVM: Fix fault-rip on vmsave/vmload emulation Date: Wed, 06 Apr 2011 15:43:47 +0300 Message-ID: <4D9C6003.5040209@redhat.com> References: <1302085803-25399-1-git-send-email-joerg.roedel@amd.com> <4D9C4C9C.6060401@redhat.com> <4D9C4E58.7020002@redhat.com> <20110406122753.GM23633@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , "stable@kernel.org" To: "Roedel, Joerg" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10730 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752496Ab1DFMny (ORCPT ); Wed, 6 Apr 2011 08:43:54 -0400 In-Reply-To: <20110406122753.GM23633@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/06/2011 03:27 PM, Roedel, Joerg wrote: > On Wed, Apr 06, 2011 at 07:28:24AM -0400, Avi Kivity wrote: > > On 04/06/2011 02:21 PM, Avi Kivity wrote: > > > On 04/06/2011 01:30 PM, Joerg Roedel wrote: > > >> When the emulation of vmload or vmsave fails because the > > >> guest passed an unsupported physical address it gets an #GP > > >> with rip pointing to the instruction after vmsave/vmload. > > >> This is a bug and fixed by this patch. > > >> > > > > > > Applied, thanks. > > > > > > > btw, I think the actual address check is incorrect, need to check > > MAXPHYADDR and not hardcoded 0xffff000000000000. > > There is a difference. MAX_PHYSADDR_BITS is the maximum Linux can > support while the mask above is the current limit the hardware > supports. I'm talking about MAXPHYADDR, the result of cpuid(0x80000008).eax[0:7]. (IIRC with the current page table format the absolute limit is 53 bits while the current limit is 48 bits). > It is the same on real hardware, when rax is>= (1<<48) there is a #GP > (and no intercept if in guest-mode). Here is btw. a difference between > nested-svm and hardware-svm, if rax contains a physical address which is > supported but not backed by RAM the machine will just freeze on real > hardware where as in nested-svm it causes a #GP (should be fine because > the behavior in this case is undefined). > In this case the behaviour before the patch was correct too :) -- error compiling committee.c: too many arguments to function