From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation Date: Wed, 3 Apr 2013 15:58:04 -0500 Message-ID: <1365022684.25627.11@snotra> References: <20130403155527.GJ3889@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , , , To: Gleb Natapov Return-path: In-Reply-To: <20130403155527.GJ3889@redhat.com> (from gleb@redhat.com on Wed Apr 3 10:55:27 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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. 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. -Scott