On 11.07.2010, at 10:27, Nadav Har'El wrote: > On Fri, Jul 09, 2010, Dong, Eddie wrote about "RE: [PATCH 0/24] Nested VMX, > v5": >> Thnaks for the posting and in general the patches are well written. >> I like the concept of VMCSxy and I feel it is pretty clear (better than my >> previous naming as well), but there are some confusing inside, especially >> for the term "shadow" which I feel quit hard. > > Hi, and thanks for the excellent ideas. As you saw, I indeed started to > convert and converge the old terminology (including that ambiguous term > "shadow") into the new names vmcs01, vmcs02, vmcs12 - names which we > introduced in our technical report. > But I have not gone all the way with these changes. I should have, and I'll > do it now. > >> 1: Basically there are 2 diferent type in VMCS, one is defined by hardware, >> whose layout is unknown to VMM. Another one is defined by VMM (this patch) >> and used for vmcs12. >> The former one is using "struct vmcs" to describe its data instance, but the >> later one doesn't have a clear definition (or struct vmcs12?). I suggest we >> can have a distinguish struct for this, for example "struct sw_vmcs" >> (software vmcs), or "struct vvmcs" (virtual vmcs). > > I decided (but let me know if you have reservations) to use the name > "struct vmcs_fields" for the memory structure that contains the long list of > vmcs fields. I think this name describes the structure's content well. > > As in the last version of the patches, this list of vmcs fields will not on > its own be vmcs12's structure, because vmcs12, as a spec-compliant vmcs, also > needs to contain a couple of additional fields in its beginning, and we also > need a few more runtime fields.
Thinking about this - it would be perfectly legal to split the VMCS into two separate structs, right? You could have one struct that you map directly into the guest, so modifications to that struct don't trap. Of course the l1 guest shouldn't be able to modify all fields of the VMCS, so you'd still keep a second struct around with shadow fields. While at it, also add a bitmap to store the dirtyness status of your fields in, if you need that. That way a nesting aware guest could use a PV memory write instead of the (slow) instruction emulation. That should dramatically speed up nesting vmx. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
