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

Re: [Xen-devel] x86/AMD: Nested hvm crashes in 4.3



On 28/06/13 15:20, Suravee Suthikulanit wrote:
> On 6/28/2013 2:58 AM, Jan Beulich wrote:
>>>>> On 28.06.13 at 02:44, Suravee Suthikulanit
>>>>> <suravee.suthikulpanit@xxxxxxx> wrote:
>>> So, I have finally able to get the crash dump (see below). The crash
>>> is due
>>> to an assert
>>>
>>>       (XEN) Assertion 'va >= XEN_VIRT_START' failed at
>>> /sandbox/xen/xen.git/xen/include/asm/x86_64/page.h:86
>>>
>>> * Debugging show the va=ffff82c40002d000,
>>> XEN_VIRT_START=ffff82c4c0000000,
>>> DIRECTMAP_VIRT_END=ffffff8000000000.
>>> * Backtrace symbol showing the crash is in "svm_vmexit_handler()",
>>> which is
>>> inlined from "svm_vmexit_do_vmsave()" and "svm_vmsave()".
>> Which helps in no way identifying where the problem is -
>> svm_vmexit_handler() is just too large to spot this without either
>> the matching xen-syms at hand, or you adding further
>> instrumentation.
>>
>> Jan
>
> What I am trying to say is, the assertion is in the __virt_to_maddr
> which is called from
> svm_vmexit_do_vmsave().  However, this is a bit complicate due to
> macros and inlines.
> Here is the callchain supposed to look like:
>
>     ASSERT(va >= XEN_VIRT_START )
>     __virt_to_maddr        <---- inlined
>     virt_to_mfn ()         <---- macro
>     __pa ()                <---- macro
>     smv_vmasave()          <---- inlined
>     svm_vmexit_do_vmsave() <---- inlined
>     svm_vmexit_handler()   <---- symbol
>
> Suravee

The code is assuming that the virtual address is mapped into the Xen
pagetables when in fact it is not.

The code needs to be corrected to use map_domain_page() to correctly
access a domheap page.

~Andrew

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