From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH RFC 0/4] Paravirt-spinlock implementation for KVM guests (Version 0) Date: Mon, 02 Aug 2010 11:50:52 +0300 Message-ID: <4C5686EC.4060703@redhat.com> References: <20100726061150.GB21699@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: vatsa@linux.vnet.ibm.com Return-path: In-Reply-To: <20100726061150.GB21699@linux.vnet.ibm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 07/26/2010 09:11 AM, 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, ....) > > type of code in the common implementation. I do think things are pretty common. If that is the only issue, you can use a plain function vector, no? -- error compiling committee.c: too many arguments to function