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
|
Home