[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



On 08.07.13 11:13, 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...

You can translate GPA->PA with the hostp2m.

> 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 _pa suffix over the latter.

Christoph


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