Re: [RFC PATCH v3 5/6] kvm/ppc/mpic: in-kernel MPIC emulation

[Scott Wood <scottwood@freescale.com>]

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 <scottwood@freescale.com>
> > ---
> [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