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

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



At 10:13 +0100 on 08 Jul (1373278413), Jan Beulich wrote:
> >>> On 06.07.13 at 00:10, <suravee.suthikulpanit@xxxxxxx> wrote:
> > @@ -1816,7 +1816,7 @@ svm_vmexit_do_vmload(struct vmcb_struct *vmcb,
> >          goto inject;
> >      }
> >  
> > -    svm_vmload(nv->nv_vvmcx);
> > +    svm_vmload_by_paddr(nv->nv_vvmcxaddr);
> >      /* State in L1 VMCB is stale now */
> >      v->arch.hvm_svm.vmcb_in_sync = 0;
> >  
> > @@ -1852,7 +1852,7 @@ svm_vmexit_do_vmsave(struct vmcb_struct *vmcb,
> >          goto inject;
> >      }
> >  
> > -    svm_vmsave(nv->nv_vvmcx);
> > +    svm_vmsave_by_paddr(nv->nv_vvmcxaddr);
> >  
> >      __update_guest_eip(regs, inst_len);
> >      return;
> 
> As said on the previous version already - from all I can tell these
> are GPAs, not PAs, and hence can't be passed untranslated to
> VMLOAD/VMSAVE. If I'm right with this, I also can't see how this
> would have worked for you...
> 
> Apart from that I also dislike the _by_paddr suffix. I'd suggest
> either just _pa, or (slightly preferable) prefixing the names with
> a double underscore instead.

I prefer the _pa suffix; it carries a reminder of what this version does.

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®.