[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |