From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/3] Split up pv-ops Date: Thu, 19 Nov 2009 09:42:10 +0200 Message-ID: <4B04F6D2.8080805@redhat.com> References: <1258503192-14246-1-git-send-email-agraf@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm list , virtualization@lists.linux-foundation.org, Glauber Costa , Nick Piggin To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60454 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752862AbZKSHmO (ORCPT ); Thu, 19 Nov 2009 02:42:14 -0500 In-Reply-To: <1258503192-14246-1-git-send-email-agraf@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 11/18/2009 02:13 AM, Alexander Graf wrote: > Paravirt ops is currently only capable of either replacing a lot of Linux > internal code or none at all. The are users that don't need all of the > possibilities pv-ops delivers though. > > On KVM for example we're perfectly fine not using the PV MMU, thus not > touching any MMU code. That way we don't have to improve pv-ops to become > fast, we just don't compile the MMU parts in! > > This patchset splits pv-ops into several smaller config options split by > feature category and then converts the KVM pv-ops code to use only the > bits that are required, lowering overhead. > > Alexander Graf (3): > Split paravirt ops by functionality > Only export selected pv-ops feature structs > Split the KVM pv-ops support by feature > > The whole thing looks good to me. Let's wait for Jeremy to ack though. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.