From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 03/15] KVM: PPC: Allow userspace to unset the IRQ line Date: Mon, 08 Mar 2010 16:09:33 +0200 Message-ID: <4B95051D.9030803@redhat.com> References: <1267807842-3751-1-git-send-email-agraf@suse.de> <1267807842-3751-4-git-send-email-agraf@suse.de> <4B94FF27.5010800@redhat.com> <4B950017.9010805@suse.de> <4B950104.3030107@redhat.com> <4B9501D3.80406@suse.de> <4B95029C.6000800@redhat.com> <4B950328.90005@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Alexander Graf Return-path: Received: from mx1.redhat.com ([209.132.183.28]:11421 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754468Ab0CHOJh (ORCPT ); Mon, 8 Mar 2010 09:09:37 -0500 In-Reply-To: <4B950328.90005@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: On 03/08/2010 04:01 PM, Alexander Graf wrote: > Avi Kivity wrote: > >> On 03/08/2010 03:55 PM, Alexander Graf wrote: >> >>> Avi Kivity wrote: >>> >>> >>>> On 03/08/2010 03:48 PM, Alexander Graf wrote: >>>> >>>> >>>>> >>>>> >>>>>> How does userspace know they exist? >>>>>> >>>>>> >>>>>> >>>>> #ifdef KVM_INTERRUPT_SET? MOL is the only user of this so far. And >>>>> that >>>>> won't work without the hypervisor call anyways. >>>>> >>>>> >>>>> >>>> We generally compile on one machine, and run on another. >>>> >>>> >>> So? Then IRQ unsetting doesn't work. Without this series you won't get >>> much further than booting the kernel anyways because XER is broken, TLB >>> flushes are broken and FPU loading is broken. So not being able to unset >>> an IRQ line is the least of your problems :). >>> >>> >> There's a difference between an error message telling you to upgrade >> to a kernel with KVM_CAP_BLAH and a failure. It's the difference >> between a bug report and silence. >> > I see. So we can check for KVM_CAP_PPC_OSI and know that it's in the > same patch series, also making KVM_INTERRUPT_XXX work, right? Or do you > really want to have 500 capabilities for every single patch? > Having individual capabilities makes backporting a lot easier (otherwise you have to backport the whole thing). If the changes are logically separate, I prefer 500 separate capabilities. However, for a platform bringup, it's okay to have just one capability, assuming none of the changes are applicable to other platforms. -- error compiling committee.c: too many arguments to function