On 06/23/2010 03:07 PM, Nadav Har'El wrote:
On Wed, Jun 23, 2010, Avi Kivity wrote about "Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1":
kmap() really should be avoided when possible. It is for when we don't
have a pte pointing to the page (for example, accessing a user page from
outside its process context).
I'm afraid I do not follow. kmap() is needed for when you have 32-bit
pointers but more than 4GB of RAM.
No, it's needed when you don't have a pte to a page. You always have
ptes to userspace pages when in process context, even if those pages are
above the 900MB normally addressable by the kernel on i386.
Why do we need to avoid using it?
I understand why one would like to avoid leaving many kmaped pages for
long durations, but here we're talking about just one page (per vcpu).
It prevents neat stuff like ksm, transparent hugepages, page migration,
swapping. One page per vcpu is not a lot, but if it can be avoided, it
is better.
Really, the correct API is kvm_read_guest() and kvm_write_guest(). They
can easily be wrapped in with something that takes a vmcs12 field and
automatically references the vmptr:
kvm_set_cr0(vcpu, gvmcs_read64(vcpu, guest_cr0));
But as you also said, this doesn't solve the original problem which you found,
(which was what happens when the vmcs12 page is swapped out and it is needed
when sleeping is not allowed) unless we make changes to the injection logic,
as you analyzed. I agree that we should consider it for a future fix.
Is it only the injection logic that is involved? If so, we're in good
shape.
If I understand the nested-SVM code correctly, they took a similar approach to
mine - except they pin and unpin the page on every entry and exit, instead of
on VMPTRLD (SVM doesn't have a notion of one current vmcb). But they still
don't (if I understand correctly) call any special function on every access.
Right, it will be better if they use kvm_*_guest() as well.
--
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
