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

Re: [Xen-devel] Intermittent fatal page fault with XEN 4.3.1 (Centos 6.3 DOM0 with linux kernel 3.10.16.)



On 06/11/13 16:48, Jeff_Zimmerman@xxxxxxxxxx wrote:
> On Nov 6, 2013, at 8:18 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx>
>  wrote:
>
>> On Wed, 2013-11-06 at 16:05 +0000, Jeff_Zimmerman@xxxxxxxxxx wrote:
>>> Jan,
>>>
>>> I will give your patch a try.
>>> I have to recant my previous statement regarding not using nested-virt.
>>> It seems some of the code that is being executed on the vm contains vmx 
>>> instructions.
>>> Since by virtue of running this code in an hvm subject make it nested-virt.
>>>
>>> This raises a question, if this functionality is undesired can we just 
>>> disable nested virt by adding
>>> nestedhvm=false to the configuration file?  Should the cpuid and
>>> cupid_check settings be changed as well?
>> I'm reasonably certain that nestedhvm=false will clear the relevant
>> flags in the guest visible cpuid. I'd say it was a bug if this doesn't
>> happen.
>>
>> nestedhvm should be disabled by default, did you explicitly enable it?
>> Removing the line altogether ought to disable it too. Please let us know
>> if not.
>>
>> Ian.
>>
> I did not enable nestedvm and when I run xl list -l the output shows 
> nestedhvm=<default>
> I was not sure what the default was supposed to be. I will try setting it and 
> re-run our test.
> Jeff

nested-virt is strictly experimental, and still has known bugs (and
clearly some unknown ones).

I looked over the xl code and thought that nestedhvm should default to
false, but I would prefer someone more familar with libxl and the idl to
confirm what the default should be.

~Andrew

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


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