On 07/11/2010 06:39 PM, Nadav Har'El wrote:
On Sun, Jul 11, 2010, Avi Kivity wrote about "Re: [PATCH 0/24] Nested VMX, v5":
nesting-
aware L1 guest hypervisors to actually use that internal structure to
modify
vmcs12 directly, without vmread/vmwrite and exits.
No, they can't, since (for writes) L0 might cache the information and
not read it again. For reads, L0 might choose to update vmcs12 on demand.
Well, in the current version of the nested code, all L0 does on a L1 vmwrite
is to update the in-memory vmcs12 structure. It doesn't not update vmcs02,
nor cache anything, nor remember what has changed and what hasn't. So replacing
it with a direct write to the memory structure should be fine...
Note you said "current version". What if this later changes?
So, we cannot allow a guest to access vmcs12 directly. There has to be
a protocol that allows the guest to know what it can touch and what it
can't (or, tell the host what the guest touched and what it hasn't).
Otherwise, we lose the ability to optimize.
Of course, this situation isn't optimal, and we *should* optimize the number of
unnecessary vmwrites L2 entry and exit (and we actually tried some of this
in our tech report), but it's not in the current patch set. When we do these
kind of optimizations, you're right that:
A pvvmread/write needs to communicate with L0 about what fields are
valid (likely using available and dirty bitmaps).
It's right even before we do these optimizations, so a pv guest written
before the optimizations can run on an optimized host.
--
error compiling committee.c: too many arguments to function
--
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
