From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH RFC 0/4] Paravirt-spinlock implementation for KVM guests (Version 0) Date: Wed, 28 Jul 2010 18:10:59 -0400 Message-ID: <20100728221059.GA32739@phenom.dumpdata.com> References: <20100726061150.GB21699@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: avi@redhat.com, Marcelo Tosatti , Gleb Natapov , linux-kernel@vger.kernel.org, npiggin@suse.de, Jeremy Fitzhardinge , kvm@vger.kernel.org, bharata@in.ibm.com, Balbir Singh , Jan Beulich To: Srivatsa Vaddagiri Return-path: Received: from rcsinet10.oracle.com ([148.87.113.121]:20452 "EHLO rcsinet10.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755715Ab0G1WNZ (ORCPT >); Wed, 28 Jul 2010 18:13:25 -0400 Content-Disposition: inline In-Reply-To: <20100726061150.GB21699@linux.vnet.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Jul 26, 2010 at 11:41:50AM +0530, Srivatsa Vaddagiri wrote: > This patch-series implements paravirt-spinlock implementation for KVM guests, > based heavily on Xen's implementation. I tried to refactor Xen's spinlock > implementation to make it common for both Xen and KVM - but found that > few differences between Xen and KVM (Xen has the ability to block on a > particular event/irq for example) _and_ the fact that the guest kernel > can be compiled to support both Xen and KVM hypervisors (CONFIG_XEN and > CONFIG_KVM_GUEST can both be turned on) makes the "common" code a eye-sore. > There will have to be: > > if (xen) { > ... > } else if (kvm) { > .. > } > > or possibly: > > alternative(NOP, some_xen_specific_call, ....) Why not utilize the pvops path?