Re: [PATCH] KVM: SVM: Fix fault-rip on vmsave/vmload emulation

[Avi Kivity <avi@redhat.com>]

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