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

RE: [Xen-devel] [PATCH 00/17][RFC] Nested virtualization for VMX



On Thu, 2010-04-22 at 18:16 +0800, Christoph Egger wrote:
>On Thursday 22 April 2010 11:41:12 Qing He wrote:
>>   - On 21190, even without nested patchset, Xen as L1
>>     suffers a considerable booting lag, this phenomenon
>>     was not observed on my previous base, around cs.
>>     20200
>
>I can reproduce this bug as well. Last known working c/s is 20382
>and known broken c/s is 20390.
>Potential candidates are c/s 20384, 20386, 20389 and 20390
>which introduced the bug.
>I wasn't able to verify c/s 20384, 20386 and 20389 due to
>build or boot problems.

That's a pretty narrower range, and easier to root cause. I ever tried to do a 
bisect when I met the problem, but didn't get much out of it because of 
ioemu/xen dependencies.

>
>Do you also have a paper how your patchset works ?

While I don't have a long description about details, there was a Xensummit talk 
to explain the basic ideas, the foil can be found below
        http://www.xen.org/files/xensummit_intel09/xensummit-nested-virt.pdf

Basically, it's build on homogeneity to gain better performance. A ``shadow 
VMCS'' is constructed from host VMCS and virtual VMCS, and then gets loaded to 
physical VMCS to control the L2 guest behavior. The policy of shadow VMCS 
construction and VMExits handling is a result of inspecting individual fields 
and VMExit types. There are some comments in the code to address the policy 
used, which you can have a look if interested.

Thanks,
Qing


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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