From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 5/24] Introduce vmcs12: a VMCS structure for L1 Date: Wed, 23 Jun 2010 15:13:39 +0300 Message-ID: <4C21FA73.8030502@redhat.com> References: <1276431753-nyh@il.ibm.com> <201006131225.o5DCP79H012922@rice.haifa.ibm.com> <4C15E95D.9000300@redhat.com> <20100622145441.GA23496@fermat.math.technion.ac.il> <4C21BE6C.1060404@redhat.com> <20100623120740.GA4078@fermat.math.technion.ac.il> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Alexander Graf , Joerg Roedel To: "Nadav Har'El" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:27184 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750999Ab0FWMNs (ORCPT ); Wed, 23 Jun 2010 08:13:48 -0400 In-Reply-To: <20100623120740.GA4078@fermat.math.technion.ac.il> Sender: kvm-owner@vger.kernel.org List-ID: 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