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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
