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 <scottw...@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.
>
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.
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
