From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch 1/5] KVM: add basic paravirt support (v2) Date: Thu, 21 Feb 2008 17:38:30 +0200 Message-ID: <47BD9AF6.7020206@qumranet.com> References: <20080220194720.750258362@harmony.lab.boston.redhat.com> <20080220195019.552114916@harmony.lab.boston.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel@lists.sourceforge.net To: Marcelo Tosatti Return-path: In-Reply-To: <20080220195019.552114916@harmony.lab.boston.redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Marcelo Tosatti wrote: > Add basic KVM paravirt support. Avoid vm-exits on IO delays. > > Add KVM_GET_PARA_FEATURES ioctl so paravirt features can be reported in a > single bitmask. This allows the host to disable features on runtime if > appropriate, which would require one ioctl per feature otherwise. > > The limit of 32 features can be extended to 64 if needed, beyond that a new > MSR is required. > > v1->v2: > - replace KVM_CAP_CLOCKSOURCE with KVM_CAP_PARA_FEATURES > - cover FEATURE_CLOCKSOURCE > > > I don't understand the motivation for this. A handful of ioctl()s at init time are hardly time consuming. There is the advantage that paravirt kernel advances are reflected automatically without changes in userspace, but sometimes this is a disadvantage (it means there is no way to disable it, for instance). -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/