> From: Nadav Har'El [mailto:nyh@xxxxxxxxxxxxxxxxxxx] > Sent: Saturday, May 21, 2011 4:32 AM > > On Fri, May 20, 2011, Tian, Kevin wrote about "RE: [PATCH 07/31] nVMX: > Introduce vmcs02: VMCS used to run L2": > > btw, shouldn't you clear recycled VMCS and reset 'cpu' and 'launched' fields? > > Well, I believe the answer is "no": As far as I understood, a host is allowed > to take a VMCS that has been used once to launch a certain guest, and then > modify all the VMCS's fields to define a completely different guest, and then > VMRESUME it, without doing the regular VMCLEAR/VMLAUNCH, even though > it's > "a different guest". Is there something wrong in my assumption? Does VMX > keep > anything constant between successive VMRESUMEs? Yes, you can reuse a VMCS with a completely different state if the VMCS is used on the same processor, and you must ensure that VMCS not having a dirty state on other processors. The SDM 3B (21.10.1) explicitly requires: ---- No VMCS should ever be active on more than one logical processor. If a VMCS is to be "migrated" from one logical processor to another, the first logical processor should execute VMCLEAR for the VMCS (to make it inactive on that logical processor and to ensure that all VMCS data are in memory) before the other logical processor executes VMPTRLD for the VMCS (to make it active on the second logical processor). A VMCS that is made active on more than one logical processor may become corrupted ---- Here the vmcs02 being overridden may have been run on another processor before but is not vmclear-ed yet. When you resume this vmcs02 with new content on a separate processor, the risk of corruption exists. > > > Have you tried SMP L2 guest? > > It "sort of" works, but it *does* appear to still have a bug which I didn't > yet have the time to hunt... In one case, for example, an 8-vcpu L2 on an > 8-vcpu L1 seemed to work well (e.g., doing parallel make) for about a minute, > and then hung with some sort of page fault in the kernel. > See whether cleaning up above can help here. Thanks Kevin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
