From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Date: Thu, 4 Apr 2013 08:59:02 +0300 Message-ID: <20130404055902.GL3889@redhat.com> References: <20130403155527.GJ3889@redhat.com> <1365022684.25627.11@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, paulus@samba.org To: Scott Wood Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37446 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756099Ab3DDF7z (ORCPT ); Thu, 4 Apr 2013 01:59:55 -0400 Content-Disposition: inline In-Reply-To: <1365022684.25627.11@snotra> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Apr 03, 2013 at 03:58:04PM -0500, Scott Wood wrote: > On 04/03/2013 10:55:27 AM, Gleb Natapov wrote: > >On Tue, Apr 02, 2013 at 08:57:52PM -0500, Scott Wood wrote: > >> Hook the MPIC code up to the KVM interfaces, add locking, etc. > >> > >> TODO: irqfd support, split up into multiple patches, KVM_IRQ_LINE > >> support > >> > >> Signed-off-by: Scott Wood > >> --- > >[skip] > > > >> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h > >> index 20ce2d2..d8f44ef 100644 > >> --- a/include/uapi/linux/kvm.h > >> +++ b/include/uapi/linux/kvm.h > >> @@ -927,6 +927,15 @@ struct kvm_device_attr { > >> __u64 addr; /* userspace address of attr data */ > >> }; > >> > >> +#define KVM_DEV_TYPE_FSL_MPIC_20 1 > >> +#define KVM_DEV_TYPE_FSL_MPIC_42 2 > >> + > >> +#define KVM_DEV_MPIC_GRP_MISC 1 > >> +#define KVM_DEV_MPIC_BASE_ADDR 0 /* 64-bit */ > >> + > >> +#define KVM_DEV_MPIC_GRP_REGISTER 2 /* 32-bit */ > >> +#define KVM_DEV_MPIC_GRP_IRQ_ACTIVE 3 /* 32-bit */ > >Why not put them in arch specific header? > > KVM_DEV_TYPE_* is not an arch-specific enumeration -- this was > discussed last time around. > Yes, I am talking about KVM_DEV_MPIC_* only. KVM_DEV_TYPE_ are used by common code so should stay here. > KVM_DEV_MPIC_* could go elsewhere if you want to avoid cluttering > the main kvm.h. The arch header would be OK, since the non-arch > header includes the arch header, and thus it wouldn't be visible to > userspace where it is -- if there later is a need for MPIC (or > whatever other device follows MPIC's example) on another > architecture, it could be moved without breaking anything. Or, we > could just have a header for each device type. > If device will be used by more then one arch it will move into virt/kvm and will have its own header, like ioapic. -- Gleb.