[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 1/1 V5] x86/AMD: Fix nested svm crash due to assertion in __virt_to_maddr



At 14:17 +0100 on 07 Aug (1375885025), Jan Beulich wrote:
> >>> On 05.08.13 at 10:31, <suravee.suthikulpanit@xxxxxxx> wrote:
> > From: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
> > 
> > Fix assertion in __virt_to_maddr when starting nested SVM guest
> > in debug mode. Investigation has shown that svm_vmsave/svm_vmload
> > make use of __pa() with invalid address.
> > 
> > Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@xxxxxxx>
> 
> Tim - have all your earlier comments been addressed in this version?

Yes, I'm happy with this one.

Reviewed-by: Tim Deegan <tim@xxxxxxx>

> > -    if (!nestedhvm_enabled(v->domain)) {
> > +    if ( !nestedhvm_enabled(v->domain) || !hvm_svm_enabled(v) ) {
> 
> Suravee, why is this change needed (here and further down)?
> Can we really get here when hvm_svm_enabled(v) returns false?
> I don't recall this having been there in earlier versions.

This came from discussion of what fault to inject -- we always intercept
VM{RUN,LOAD,SAVE} so I think we can get here.  The AMD docs for those say:
 "Checks exceptions (#GP) before the intercept."
but nothing about checking guest_efer.SVME so AFAICT we have to do that
in Xen.

Arguably this fix could could be a separate patch.  Certainly the same
check ought to go into svm_exit_do_vmrun().

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.