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. 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). > 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. 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. > I guess it's fine to start with the kmap() based implementation and > change it later. Great, thanks. > Note: you need to kunmap() and kvm_release_page_dirty() not only on > vmxoff and vmptrld/vmclear, but also when ioctl(KVM_VCPU_RUN) exits to > userspace. That ensures that live migration sees the page dirtied and > is able to copy it. Thanks. I'll look into this and fix this. -- Nadav Har'El | Wednesday, Jun 23 2010, 11 Tammuz 5770 nyh@xxxxxxxxxxxxxxxxxxx |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |The space between my ears was http://nadav.harel.org.il |intentionally left blank. -- 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
