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

2013-04-08 Thread Paul Mackerras 
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.

[snip]

 @@ -2164,6 +2164,15 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
   bool test = cd-flags  KVM_CREATE_DEVICE_TEST;
  
   switch (cd-type) {
 +#ifdef CONFIG_KVM_MPIC
 + case KVM_DEV_TYPE_FSL_MPIC_20:
 + case KVM_DEV_TYPE_FSL_MPIC_42: {
 + if (test)
 + return 0;
 +
 + return kvm_create_mpic(kvm, cd-type);
 + }
 +#endif

I think this needs to be more like:

#ifdef CONFIG_KVM_MPIC
case KVM_DEV_TYPE_FSL_MPIC_20:
case KVM_DEV_TYPE_FSL_MPIC_42: {
int fd;

if (test)
return 0;

fd = kvm_create_mpic(kvm, cd-type);
if (fd  0)
return fd;
cd-fd = fd;
return 0;
}
#endif

Paul.
--
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

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

2013-04-08 Thread Gleb Natapov 
On Thu, Apr 04, 2013 at 06:33:38PM -0500, Scott Wood wrote:
 On 04/04/2013 12:59:02 AM, Gleb Natapov wrote:
 On Wed, Apr 03, 2013 at 03:58:04PM -0500, Scott Wood wrote:
  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.
 
 virt/kvm/ioapic.h is not uapi.  The ioapic uapi component (e.g.
 struct kvm_ioapic_state) is duplicated between x86 and ia64, which
 is the sort of thing I'd like to avoid.  I'm OK with putting it in
 the PPC header if, upon a later need for multi-architecture support,
 it could move into either the main uapi header or a separate uapi
 header that the main uapi header includes (i.e. no userspace-visible
 change in which header needs to be included).
 
Agree, it make sense to have separate uapi header for a device that is
used by more then one arch.

--
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

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

2013-04-08 Thread Scott Wood 

On 04/08/2013 01:30:42 AM, Paul Mackerras 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.

[snip]

 @@ -2164,6 +2164,15 @@ static int kvm_ioctl_create_device(struct  
kvm *kvm,

bool test = cd-flags  KVM_CREATE_DEVICE_TEST;

switch (cd-type) {
 +#ifdef CONFIG_KVM_MPIC
 +  case KVM_DEV_TYPE_FSL_MPIC_20:
 +  case KVM_DEV_TYPE_FSL_MPIC_42: {
 +  if (test)
 +  return 0;
 +
 +  return kvm_create_mpic(kvm, cd-type);
 +  }
 +#endif

I think this needs to be more like:

#ifdef CONFIG_KVM_MPIC
case KVM_DEV_TYPE_FSL_MPIC_20:
case KVM_DEV_TYPE_FSL_MPIC_42: {
int fd;

if (test)
return 0;

fd = kvm_create_mpic(kvm, cd-type);
if (fd  0)
return fd;
cd-fd = fd;
return 0;
}
#endif


Right, thanks for spotting.  It didn't show up in my testing because I  
did the same thing on the QEMU side.


-Scott
--
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

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

2013-04-04 Thread Alexander Graf 

On 04.04.2013, at 00:54, Scott Wood wrote:

 On 04/03/2013 05:12:06 PM, Alexander Graf wrote:
 Am 04.04.2013 um 00:07 schrieb Scott Wood scottw...@freescale.com:
  On 04/03/2013 04:58:56 PM, Alexander Graf wrote:
  Am 03.04.2013 um 23:38 schrieb Scott Wood scottw...@freescale.com:
   On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
   On 03.04.2013, at 03:57, 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
---
v3: mpic_put - kvmppc_mpic_put
   
   
   [...]
+void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
+
int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
 struct kvm_config_tlb *cfg);
int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 63c67ec..a87139b 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -151,6 +151,11 @@ config KVM_E500MC
   
 If unsure, say N.
   
+config KVM_MPIC
+bool KVM in-kernel MPIC emulation
+depends on KVM
   This should probably depend on FSL KVM for now, until someone adds 
   support for other MPIC revisions.
  
   I don't see a symbol specifically for FSL KVM.  What part of the MPIC 
   code depends on booke or any FSL-specific code?
  You support only FSL mpic device IDs :). So if someone on book3s goes 
  along and sees this, he'd think yes, I want an in-kernel MPIC, enables 
  the option and wastes space.
 
  Would this waste space is not generally the criteria for kconfig 
  dependencies.  Who is the kernel to get in the way of someone that wants 
  an FSL MPIC on a 4xx VM? :-)
 
  And again, there's no symbol for FSL KVM -- I'd have to use a list that 
  could get out of date.  And it would reduce build testing in 
  allyesconfig-type configs.
 Ok, please indicate compatibility limitations in the Kconfig description at 
 least then.
 
 OK -- not really a compatibility limitation so much as what models are 
 supported.
 
 Note that mpc86xx has a 74xx-derived core, but also has an FSL MPIC...
 
 Is 74xx/e600 supported by book3s_pr?  Can't tell from the kconfig text. :-)

On book3s_pr we don't have a good compatibility check mechanism in place. 
That's really suboptimal.

What I'm saying is that Kconfig should say In-kernel emulation of FSL MPIC 2.0 
and FSL MPIC 4.2 interrupt controllers. Say Y here if you plan to run KVM on an 
FSL system. That'd be in line with what you can actually enable using the 
ioctls and leaves the decision whether that's a good thing to the user.

Code-wise there shouldn't be any dependency on host or guest architecture of 
course.


Alex

--
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

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

2013-04-04 Thread Scott Wood 

On 04/04/2013 12:59:02 AM, Gleb Natapov wrote:

On Wed, Apr 03, 2013 at 03:58:04PM -0500, Scott Wood wrote:
 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.


virt/kvm/ioapic.h is not uapi.  The ioapic uapi component (e.g. struct  
kvm_ioapic_state) is duplicated between x86 and ia64, which is the sort  
of thing I'd like to avoid.  I'm OK with putting it in the PPC header  
if, upon a later need for multi-architecture support, it could move  
into either the main uapi header or a separate uapi header that the  
main uapi header includes (i.e. no userspace-visible change in which  
header needs to be included).


-Scott
--
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

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

2013-04-03 Thread Gleb Natapov 
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_MISC1
 +#define   KVM_DEV_MPIC_BASE_ADDR 0   /* 64-bit */
 +
 +#define KVM_DEV_MPIC_GRP_REGISTER2   /* 32-bit */
 +#define KVM_DEV_MPIC_GRP_IRQ_ACTIVE  3   /* 32-bit */
Why not put them in arch specific header?

 +
  /* ioctl for vm fd */
  #define KVM_CREATE_DEVICE  _IOWR(KVMIO,  0xe0, struct kvm_create_device)
  
 diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
 index ed033c0..e325f5d 100644
 --- a/virt/kvm/kvm_main.c
 +++ b/virt/kvm/kvm_main.c
 @@ -2164,6 +2164,15 @@ static int kvm_ioctl_create_device(struct kvm *kvm,
   bool test = cd-flags  KVM_CREATE_DEVICE_TEST;
  
   switch (cd-type) {
 +#ifdef CONFIG_KVM_MPIC
 + case KVM_DEV_TYPE_FSL_MPIC_20:
 + case KVM_DEV_TYPE_FSL_MPIC_42: {
 + if (test)
 + return 0;
 +
 + return kvm_create_mpic(kvm, cd-type);
 + }
 +#endif
   default:
   return -ENODEV;
   }
 -- 
 1.7.9.5
 
 
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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

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

2013-04-03 Thread Alexander Graf 

On 03.04.2013, at 03:57, 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
 ---
 v3: mpic_put - kvmppc_mpic_put
 
 

[...]

 +void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
 +
 int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
 struct kvm_config_tlb *cfg);
 int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
 diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
 index 63c67ec..a87139b 100644
 --- a/arch/powerpc/kvm/Kconfig
 +++ b/arch/powerpc/kvm/Kconfig
 @@ -151,6 +151,11 @@ config KVM_E500MC
 
 If unsure, say N.
 
 +config KVM_MPIC
 + bool KVM in-kernel MPIC emulation
 + depends on KVM

This should probably depend on FSL KVM for now, until someone adds support for 
other MPIC revisions.

 +
 +
 source drivers/vhost/Kconfig
 
 endif # VIRTUALIZATION
 diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
 index b772ede..4a2277a 100644
 --- a/arch/powerpc/kvm/Makefile
 +++ b/arch/powerpc/kvm/Makefile
 @@ -103,6 +103,8 @@ kvm-book3s_32-objs := \
   book3s_32_mmu.o
 kvm-objs-$(CONFIG_KVM_BOOK3S_32) := $(kvm-book3s_32-objs)
 
 +kvm-objs-$(CONFIG_KVM_MPIC) += mpic.o
 +
 kvm-objs := $(kvm-objs-m) $(kvm-objs-y)
 
 obj-$(CONFIG_KVM_440) += kvm.o
 

[...]

 struct irq_dest {
 + struct kvm_vcpu *vcpu;
 +
   int32_t ctpr;   /* CPU current task priority */
   struct irq_queue raised;
   struct irq_queue servicing;
 - qemu_irq *irqs;
 
   /* Count of IRQ sources asserting on non-INT outputs */
 - uint32_t outputs_active[OPENPIC_OUTPUT_NB];
 + uint32_t outputs_active[NUM_OUTPUTS];
 };
 
 +struct openpic;

Isn't this superfluous?

 +
 struct openpic {
 + struct kvm *kvm;
 + struct kvm_io_device mmio;
 + struct list_head mmio_regions;
 + atomic_t users;
 + bool mmio_mapped;
 +
 + gpa_t reg_base;
 + spinlock_t lock;
 +
   /* Behavior control */
   struct fsl_mpic_info *fsl;
   uint32_t model;
 @@ -208,6 +231,47 @@ struct openpic {
   uint32_t irq_msi;
 };
 
 

[...]

 -static uint64_t openpic_gbl_read(void *opaque, gpa_t addr, unsigned len)
 +static int openpic_gbl_read(void *opaque, gpa_t addr, u32 *ptr)
 {
   struct openpic *opp = opaque;
 - uint32_t retval;
 + u32 retval;
 
 - pr_debug(%s: addr %# HWADDR_PRIx \n, __func__, addr);
 + pr_debug(%s: addr %#llx\n, __func__, addr);
   retval = 0x;
   if (addr  0xF)
 - return retval;
 + goto out;
 
   switch (addr) {
   case 0x1000:/* FRR */
   retval = opp-frr;
 + retval |= (opp-nb_cpus - 1)  FRR_NCPU_SHIFT;
   break;
   case 0x1020:/* GCR */
   retval = opp-gcr;
 @@ -731,8 +771,8 @@ static uint64_t openpic_gbl_read(void *opaque, gpa_t 
 addr, unsigned len)
   case 0x90:
   case 0xA0:
   case 0xB0:
 - retval =
 - openpic_cpu_read_internal(opp, addr, get_current_cpu());
 + retval = openpic_cpu_read_internal(opp, addr,
 + retval, get_current_cpu());

This looks bogus. You're passing retval and overwrite it with the return value 
right after the function returns?

   break;
   case 0x10A0:/* IPI_IVPR */
   case 0x10B0:
 @@ -750,28 +790,28 @@ static uint64_t openpic_gbl_read(void *opaque, gpa_t 
 addr, unsigned len)
   default:
   break;
   }
 - pr_debug(%s: = 0x%08x\n, __func__, retval);
 
 - return retval;
 +out:
 + pr_debug(%s: = 0x%08x\n, __func__, retval);
 + *ptr = retval;
 + return 0;
 }
 

[...]

 
 +static int kvm_mpic_read(struct kvm_io_device *this, gpa_t addr,
 +  int len, void *ptr)
 +{
 + struct openpic *opp = container_of(this, struct openpic, mmio);
 + int ret;
 +
 + /*
 +  * Technically only 32-bit accesses are allowed, but be nice to
 +  * people dumping registers a byte at a time -- it works in real
 +  * hardware (reads only, not writes).

Do 16-bit accesses work in real hardware?

 +  */
 + if (len == 4) {
 + if (addr  3) {
 + pr_debug(%s: bad alignment %llx/%d\n,
 +  __func__, addr, len);
 + return -EINVAL;
 + }

if (addr  (len - 1))

Then the read_internal call can be shared between the different access sizes, 
no?

 +
 + spin_lock_irq(opp-lock);
 + ret = kvm_mpic_read_internal(opp, addr - opp-reg_base, ptr);
 + spin_unlock_irq(opp-lock);
 +
 + pr_debug(%s: addr %llx ret %d len 4 val %x\n,
 +  __func__, addr, ret, *(const u32 *)ptr);
 + } else if (len == 1) {
 + union {
 + u32 val;
 + u8

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

2013-04-03 Thread Scott Wood 

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.


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
--
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

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

2013-04-03 Thread Scott Wood 

On 04/03/2013 11:19:42 AM, Alexander Graf wrote:


On 03.04.2013, at 03:57, 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
 ---
 v3: mpic_put - kvmppc_mpic_put



[...]

 +void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
 +
 int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
  struct kvm_config_tlb *cfg);
 int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
 diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
 index 63c67ec..a87139b 100644
 --- a/arch/powerpc/kvm/Kconfig
 +++ b/arch/powerpc/kvm/Kconfig
 @@ -151,6 +151,11 @@ config KVM_E500MC

  If unsure, say N.

 +config KVM_MPIC
 +  bool KVM in-kernel MPIC emulation
 +  depends on KVM

This should probably depend on FSL KVM for now, until someone adds  
support for other MPIC revisions.


I don't see a symbol specifically for FSL KVM.  What part of the MPIC  
code depends on booke or any FSL-specific code?



 struct irq_dest {
 +  struct kvm_vcpu *vcpu;
 +
int32_t ctpr;   /* CPU current task priority */
struct irq_queue raised;
struct irq_queue servicing;
 -  qemu_irq *irqs;

/* Count of IRQ sources asserting on non-INT outputs */
 -  uint32_t outputs_active[OPENPIC_OUTPUT_NB];
 +  uint32_t outputs_active[NUM_OUTPUTS];
 };

 +struct openpic;

Isn't this superfluous?


Yes, will remove.  Probably a leftover from when there was other stuff  
in between that referenced it.


 @@ -731,8 +771,8 @@ static uint64_t openpic_gbl_read(void *opaque,  
gpa_t addr, unsigned len)

case 0x90:
case 0xA0:
case 0xB0:
 -  retval =
 -		openpic_cpu_read_internal(opp, addr,  
get_current_cpu());

 +  retval = openpic_cpu_read_internal(opp, addr,
 +  retval, get_current_cpu());

This looks bogus. You're passing retval and overwrite it with the  
return value right after the function returns?


Yeah, will fix.  Thanks for spotting it.


 +static int kvm_mpic_read(struct kvm_io_device *this, gpa_t addr,
 +   int len, void *ptr)
 +{
 +  struct openpic *opp = container_of(this, struct openpic, mmio);
 +  int ret;
 +
 +  /*
 +   * Technically only 32-bit accesses are allowed, but be nice to
 +   * people dumping registers a byte at a time -- it works in real
 +   * hardware (reads only, not writes).

Do 16-bit accesses work in real hardware?


Probably, though according to the documentation only 32-bit accesses  
should be used.  As the comment says, I'm just being nice to hexdumps  
and such, which are unlikely to use 16-bit accesses.



 +   */
 +  if (len == 4) {
 +  if (addr  3) {
 +  pr_debug(%s: bad alignment %llx/%d\n,
 +   __func__, addr, len);
 +  return -EINVAL;
 +  }

if (addr  (len - 1))

Then the read_internal call can be shared between the different  
access sizes, no?


Not as is, because the read_internal call passes a different pointer in  
the two different cases.  I originally tried to write this with more in  
common between the two cases, and it got a bit messy.  I'll give it  
another shot, though.



 +  spin_lock_irq(opp-lock);
 +		ret = kvm_mpic_read_internal(opp, addr - opp-reg_base,  
ptr);

 +  spin_unlock_irq(opp-lock);
 +
 +  pr_debug(%s: addr %llx ret %d len 4 val %x\n,
 +   __func__, addr, ret, *(const u32 *)ptr);
 +  } else if (len == 1) {
 +  union {
 +  u32 val;
 +  u8 bytes[4];
 +  } u;
 +
 +  spin_lock_irq(opp-lock);
 +		ret = kvm_mpic_read_internal(opp, addr - opp-reg_base,  
u.val);

 +  spin_unlock_irq(opp-lock);
 +
 +  *(u8 *)ptr = u.bytes[addr  3];
 +
 +  pr_debug(%s: addr %llx ret %d len 1 val %x\n,
 +   __func__, addr, ret, *(const u8 *)ptr);
 +  } else {
 +  pr_debug(%s: bad length %d\n, __func__, len);
 +  return -EINVAL;
 +  }
 +
 +  return ret;
 +}
 +

[...]


 +static int mpic_set_attr(struct openpic *opp, struct  
kvm_device_attr *attr)

 +{
 +  u32 attr32;
 +
 +  switch (attr-group) {
 +  case KVM_DEV_MPIC_GRP_MISC:
 +  switch (attr-attr) {
 +  case KVM_DEV_MPIC_BASE_ADDR:
 +  return set_base_addr(opp, attr);
 +  }
 +
 +  break;
 +
 +  case KVM_DEV_MPIC_GRP_REGISTER:
 +		if (copy_from_user(attr32, (u32 __user  
*)(long)attr-addr,

 + sizeof(u32)))

get_user?


OK.


 +  switch (attr-group) {
 +  case KVM_DEV_MPIC_GRP_MISC:
 +  switch (attr-attr) {
 +  case KVM_DEV_MPIC_BASE_ADDR:
 +  mutex_lock(opp-kvm-slots_lock);
 +  attr64 = opp-reg_base;
 +  mutex_unlock(opp-kvm-slots_lock);
 +
 +  if (copy_to_user((u64 __user *)(long)attr-addr,
 +

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

2013-04-03 Thread Alexander Graf 


Am 03.04.2013 um 23:38 schrieb Scott Wood scottw...@freescale.com:

 On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
 On 03.04.2013, at 03:57, 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
  ---
  v3: mpic_put - kvmppc_mpic_put
 
 
 [...]
  +void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
  +
  int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
   struct kvm_config_tlb *cfg);
  int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
  diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
  index 63c67ec..a87139b 100644
  --- a/arch/powerpc/kvm/Kconfig
  +++ b/arch/powerpc/kvm/Kconfig
  @@ -151,6 +151,11 @@ config KVM_E500MC
 
   If unsure, say N.
 
  +config KVM_MPIC
  +bool KVM in-kernel MPIC emulation
  +depends on KVM
 This should probably depend on FSL KVM for now, until someone adds support 
 for other MPIC revisions.
 
 I don't see a symbol specifically for FSL KVM.  What part of the MPIC code 
 depends on booke or any FSL-specific code?

You support only FSL mpic device IDs :). So if someone on book3s goes along and 
sees this, he'd think yes, I want an in-kernel MPIC, enables the option and 
wastes space.

 
  struct irq_dest {
  +struct kvm_vcpu *vcpu;
  +
 int32_t ctpr;/* CPU current task priority */
 struct irq_queue raised;
 struct irq_queue servicing;
  -qemu_irq *irqs;
 
 /* Count of IRQ sources asserting on non-INT outputs */
  -uint32_t outputs_active[OPENPIC_OUTPUT_NB];
  +uint32_t outputs_active[NUM_OUTPUTS];
  };
 
  +struct openpic;
 Isn't this superfluous?
 
 Yes, will remove.  Probably a leftover from when there was other stuff in 
 between that referenced it.
 
  @@ -731,8 +771,8 @@ static uint64_t openpic_gbl_read(void *opaque, gpa_t 
  addr, unsigned len)
 case 0x90:
 case 0xA0:
 case 0xB0:
  -retval =
  -openpic_cpu_read_internal(opp, addr, get_current_cpu());
  +retval = openpic_cpu_read_internal(opp, addr,
  +retval, get_current_cpu());
 This looks bogus. You're passing retval and overwrite it with the return 
 value right after the function returns?
 
 Yeah, will fix.  Thanks for spotting it.
 
  +static int kvm_mpic_read(struct kvm_io_device *this, gpa_t addr,
  + int len, void *ptr)
  +{
  +struct openpic *opp = container_of(this, struct openpic, mmio);
  +int ret;
  +
  +/*
  + * Technically only 32-bit accesses are allowed, but be nice to
  + * people dumping registers a byte at a time -- it works in real
  + * hardware (reads only, not writes).
 Do 16-bit accesses work in real hardware?
 
 Probably, though according to the documentation only 32-bit accesses should 
 be used.  As the comment says, I'm just being nice to hexdumps and such, 
 which are unlikely to use 16-bit accesses.
 
  + */
  +if (len == 4) {
  +if (addr  3) {
  +pr_debug(%s: bad alignment %llx/%d\n,
  + __func__, addr, len);
  +return -EINVAL;
  +}
 if (addr  (len - 1))
 Then the read_internal call can be shared between the different access 
 sizes, no?
 
 Not as is, because the read_internal call passes a different pointer in the 
 two different cases.  I originally tried to write this with more in common 
 between the two cases, and it got a bit messy.  I'll give it another shot, 
 though.

Yeah, but don't waste too much effort on it :). It's not that important.

 
  +spin_lock_irq(opp-lock);
  +ret = kvm_mpic_read_internal(opp, addr - opp-reg_base, ptr);
  +spin_unlock_irq(opp-lock);
  +
  +pr_debug(%s: addr %llx ret %d len 4 val %x\n,
  + __func__, addr, ret, *(const u32 *)ptr);
  +} else if (len == 1) {
  +union {
  +u32 val;
  +u8 bytes[4];
  +} u;
  +
  +spin_lock_irq(opp-lock);
  +ret = kvm_mpic_read_internal(opp, addr - opp-reg_base, u.val);
  +spin_unlock_irq(opp-lock);
  +
  +*(u8 *)ptr = u.bytes[addr  3];
  +
  +pr_debug(%s: addr %llx ret %d len 1 val %x\n,
  + __func__, addr, ret, *(const u8 *)ptr);
  +} else {
  +pr_debug(%s: bad length %d\n, __func__, len);
  +return -EINVAL;
  +}
  +
  +return ret;
  +}
  +
 [...]
 
  +static int mpic_set_attr(struct openpic *opp, struct kvm_device_attr 
  *attr)
  +{
  +u32 attr32;
  +
  +switch (attr-group) {
  +case KVM_DEV_MPIC_GRP_MISC:
  +switch (attr-attr) {
  +case KVM_DEV_MPIC_BASE_ADDR:
  +return set_base_addr(opp, attr);
  +}
  +
  +break;
  +
  +case KVM_DEV_MPIC_GRP_REGISTER:
  +if (copy_from_user(attr32, (u32 __user *)(long)attr-addr,
  +   sizeof(u32)))
 get_user?
 
 OK.
 
  +switch

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

2013-04-03 Thread Scott Wood 

On 04/03/2013 04:58:56 PM, Alexander Graf wrote:



Am 03.04.2013 um 23:38 schrieb Scott Wood scottw...@freescale.com:

 On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
 On 03.04.2013, at 03:57, 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
  ---
  v3: mpic_put - kvmppc_mpic_put
 
 
 [...]
  +void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
  +
  int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
   struct kvm_config_tlb *cfg);
  int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
  diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
  index 63c67ec..a87139b 100644
  --- a/arch/powerpc/kvm/Kconfig
  +++ b/arch/powerpc/kvm/Kconfig
  @@ -151,6 +151,11 @@ config KVM_E500MC
 
   If unsure, say N.
 
  +config KVM_MPIC
  +bool KVM in-kernel MPIC emulation
  +depends on KVM
 This should probably depend on FSL KVM for now, until someone adds  
support for other MPIC revisions.


 I don't see a symbol specifically for FSL KVM.  What part of the  
MPIC code depends on booke or any FSL-specific code?


You support only FSL mpic device IDs :). So if someone on book3s goes  
along and sees this, he'd think yes, I want an in-kernel MPIC,  
enables the option and wastes space.


Would this waste space is not generally the criteria for kconfig  
dependencies.  Who is the kernel to get in the way of someone that  
wants an FSL MPIC on a 4xx VM? :-)


And again, there's no symbol for FSL KVM -- I'd have to use a list that  
could get out of date.  And it would reduce build testing in  
allyesconfig-type configs.



  +switch (attr-group) {
  +case KVM_DEV_MPIC_GRP_MISC:
  +switch (attr-attr) {
  +case KVM_DEV_MPIC_BASE_ADDR:
  +mutex_lock(opp-kvm-slots_lock);
  +attr64 = opp-reg_base;
  +mutex_unlock(opp-kvm-slots_lock);
  +
  +if (copy_to_user((u64 __user *)(long)attr-addr,
  + attr64, sizeof(u64)))
 u64 is tricky with put_user on 32bit hosts, so here copy_to_user  
makes sense


 What are the issues with put_user?  It looks like it's supported  
with a pair of stw instructions.


Oh? Last time I tried to use get/put_user for one_reg it failed on  
ppc32. So maybe the u64 support is new?


Not new according to git -- though I haven't tried to use it yet; maybe  
it's broken.



  +case KVM_DEV_MPIC_GRP_IRQ_ACTIVE:
  +if (attr-attr  MAX_SRC)
  +return -EINVAL;
  +
  +attr32 = opp-src[attr-attr].pending;
 Isn't this missing a lock?

 I don't see why it needs one.  If the pending status changes during  
the ioctl, it's undefined which state you'll read back, and a lock  
wouldn't change that (you could end up taking the lock before or  
after the change gets made).


 reg_base above was a different situation -- it's 64-bit, so we  
can't read it atomically on 32-bit.


Ok, so this relies on 32bit read accesses being atomic and stale  
values ok.


Not just 32-bit, but only two possible values, with one bitflip between  
them...  Even if GCC does the read a byte at a time it'd be OK.



That works for me, but deserves a comment.


If I'm going to change it, might as well just put the lock in to be  
consistent.


-Scott
--
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

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

2013-04-03 Thread Alexander Graf 


Am 04.04.2013 um 00:07 schrieb Scott Wood scottw...@freescale.com:

 On 04/03/2013 04:58:56 PM, Alexander Graf wrote:
 Am 03.04.2013 um 23:38 schrieb Scott Wood scottw...@freescale.com:
  On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
  On 03.04.2013, at 03:57, 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
   ---
   v3: mpic_put - kvmppc_mpic_put
  
  
  [...]
   +void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
   +
   int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
struct kvm_config_tlb *cfg);
   int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
   diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
   index 63c67ec..a87139b 100644
   --- a/arch/powerpc/kvm/Kconfig
   +++ b/arch/powerpc/kvm/Kconfig
   @@ -151,6 +151,11 @@ config KVM_E500MC
  
If unsure, say N.
  
   +config KVM_MPIC
   +bool KVM in-kernel MPIC emulation
   +depends on KVM
  This should probably depend on FSL KVM for now, until someone adds 
  support for other MPIC revisions.
 
  I don't see a symbol specifically for FSL KVM.  What part of the MPIC 
  code depends on booke or any FSL-specific code?
 You support only FSL mpic device IDs :). So if someone on book3s goes along 
 and sees this, he'd think yes, I want an in-kernel MPIC, enables the 
 option and wastes space.
 
 Would this waste space is not generally the criteria for kconfig 
 dependencies.  Who is the kernel to get in the way of someone that wants an 
 FSL MPIC on a 4xx VM? :-)
 
 And again, there's no symbol for FSL KVM -- I'd have to use a list that could 
 get out of date.  And it would reduce build testing in allyesconfig-type 
 configs.

Ok, please indicate compatibility limitations in the Kconfig description at 
least then.

 
   +switch (attr-group) {
   +case KVM_DEV_MPIC_GRP_MISC:
   +switch (attr-attr) {
   +case KVM_DEV_MPIC_BASE_ADDR:
   +mutex_lock(opp-kvm-slots_lock);
   +attr64 = opp-reg_base;
   +mutex_unlock(opp-kvm-slots_lock);
   +
   +if (copy_to_user((u64 __user *)(long)attr-addr,
   + attr64, sizeof(u64)))
  u64 is tricky with put_user on 32bit hosts, so here copy_to_user makes 
  sense
 
  What are the issues with put_user?  It looks like it's supported with a 
  pair of stw instructions.
 Oh? Last time I tried to use get/put_user for one_reg it failed on ppc32. So 
 maybe the u64 support is new?
 
 Not new according to git -- though I haven't tried to use it yet; maybe it's 
 broken.
 
   +case KVM_DEV_MPIC_GRP_IRQ_ACTIVE:
   +if (attr-attr  MAX_SRC)
   +return -EINVAL;
   +
   +attr32 = opp-src[attr-attr].pending;
  Isn't this missing a lock?
 
  I don't see why it needs one.  If the pending status changes during the 
  ioctl, it's undefined which state you'll read back, and a lock wouldn't 
  change that (you could end up taking the lock before or after the change 
  gets made).
 
  reg_base above was a different situation -- it's 64-bit, so we can't read 
  it atomically on 32-bit.
 Ok, so this relies on 32bit read accesses being atomic and stale values ok.
 
 Not just 32-bit, but only two possible values, with one bitflip between 
 them...  Even if GCC does the read a byte at a time it'd be OK.
 
 That works for me, but deserves a comment.
 
 If I'm going to change it, might as well just put the lock in to be 
 consistent.

Either way works, just want to make sure whoever reads the code knows that 
things were done on purpose :)

Alex

 
 -Scott
--
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

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

2013-04-03 Thread Scott Wood 

On 04/03/2013 05:12:06 PM, Alexander Graf wrote:



Am 04.04.2013 um 00:07 schrieb Scott Wood scottw...@freescale.com:

 On 04/03/2013 04:58:56 PM, Alexander Graf wrote:
 Am 03.04.2013 um 23:38 schrieb Scott Wood  
scottw...@freescale.com:

  On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
  On 03.04.2013, at 03:57, 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
   ---
   v3: mpic_put - kvmppc_mpic_put
  
  
  [...]
   +void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
   +
   int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
struct kvm_config_tlb *cfg);
   int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
   diff --git a/arch/powerpc/kvm/Kconfig  
b/arch/powerpc/kvm/Kconfig

   index 63c67ec..a87139b 100644
   --- a/arch/powerpc/kvm/Kconfig
   +++ b/arch/powerpc/kvm/Kconfig
   @@ -151,6 +151,11 @@ config KVM_E500MC
  
If unsure, say N.
  
   +config KVM_MPIC
   +bool KVM in-kernel MPIC emulation
   +depends on KVM
  This should probably depend on FSL KVM for now, until someone  
adds support for other MPIC revisions.

 
  I don't see a symbol specifically for FSL KVM.  What part of  
the MPIC code depends on booke or any FSL-specific code?
 You support only FSL mpic device IDs :). So if someone on book3s  
goes along and sees this, he'd think yes, I want an in-kernel MPIC,  
enables the option and wastes space.


 Would this waste space is not generally the criteria for kconfig  
dependencies.  Who is the kernel to get in the way of someone that  
wants an FSL MPIC on a 4xx VM? :-)


 And again, there's no symbol for FSL KVM -- I'd have to use a list  
that could get out of date.  And it would reduce build testing in  
allyesconfig-type configs.


Ok, please indicate compatibility limitations in the Kconfig  
description at least then.


OK -- not really a compatibility limitation so much as what models  
are supported.


Note that mpc86xx has a 74xx-derived core, but also has an FSL MPIC...

Is 74xx/e600 supported by book3s_pr?  Can't tell from the kconfig text.  
:-)



   +case KVM_DEV_MPIC_GRP_IRQ_ACTIVE:
   +if (attr-attr  MAX_SRC)
   +return -EINVAL;
   +
   +attr32 = opp-src[attr-attr].pending;
  Isn't this missing a lock?
 
  I don't see why it needs one.  If the pending status changes  
during the ioctl, it's undefined which state you'll read back, and a  
lock wouldn't change that (you could end up taking the lock before or  
after the change gets made).

 
  reg_base above was a different situation -- it's 64-bit, so we  
can't read it atomically on 32-bit.
 Ok, so this relies on 32bit read accesses being atomic and stale  
values ok.


 Not just 32-bit, but only two possible values, with one bitflip  
between them...  Even if GCC does the read a byte at a time it'd be  
OK.


 That works for me, but deserves a comment.

 If I'm going to change it, might as well just put the lock in to be  
consistent.


Either way works, just want to make sure whoever reads the code knows  
that things were done on purpose :)


OTOH, it looks like access_reg() *was* missing a lock. :-P

-Scott
--
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

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

2013-04-03 Thread Scott Wood 

On 04/03/2013 05:07:30 PM, Scott Wood wrote:

On 04/03/2013 04:58:56 PM, Alexander Graf wrote:



Am 03.04.2013 um 23:38 schrieb Scott Wood scottw...@freescale.com:

 On 04/03/2013 11:19:42 AM, Alexander Graf wrote:
 On 03.04.2013, at 03:57, Scott Wood wrote:
  +switch (attr-group) {
  +case KVM_DEV_MPIC_GRP_MISC:
  +switch (attr-attr) {
  +case KVM_DEV_MPIC_BASE_ADDR:
  +mutex_lock(opp-kvm-slots_lock);
  +attr64 = opp-reg_base;
  +mutex_unlock(opp-kvm-slots_lock);
  +
  +if (copy_to_user((u64 __user *)(long)attr-addr,
  + attr64, sizeof(u64)))
 u64 is tricky with put_user on 32bit hosts, so here copy_to_user  
makes sense


 What are the issues with put_user?  It looks like it's supported  
with a pair of stw instructions.


Oh? Last time I tried to use get/put_user for one_reg it failed on  
ppc32. So maybe the u64 support is new?


Not new according to git -- though I haven't tried to use it yet;  
maybe it's broken.


Yeah, it's broken. :-P

__get_user_size() looks OK, but __get_user_check/nocheck() goes through  
an intermediary unsigned long __gu_val.


There's a separate __get_user64_nocheck() that uses long long, but no  
check variant, no put, and it's only available in 32-bit builds.   
And it's not used anywhere (barring ungreppable token-pasting magic).   
Sigh.


-Scott
--
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

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

2013-04-02 Thread Scott Wood 
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
---
v3: mpic_put - kvmppc_mpic_put

 Documentation/virtual/kvm/devices/mpic.txt |   37 ++
 arch/powerpc/include/asm/kvm_host.h|8 +-
 arch/powerpc/include/asm/kvm_ppc.h |7 +
 arch/powerpc/kvm/Kconfig   |5 +
 arch/powerpc/kvm/Makefile  |2 +
 arch/powerpc/kvm/booke.c   |   10 +-
 arch/powerpc/kvm/mpic.c|  814 +---
 arch/powerpc/kvm/powerpc.c |   12 +-
 include/linux/kvm_host.h   |2 +
 include/uapi/linux/kvm.h   |9 +
 virt/kvm/kvm_main.c|9 +
 11 files changed, 714 insertions(+), 201 deletions(-)
 create mode 100644 Documentation/virtual/kvm/devices/mpic.txt

diff --git a/Documentation/virtual/kvm/devices/mpic.txt 
b/Documentation/virtual/kvm/devices/mpic.txt
new file mode 100644
index 000..79e000a
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/mpic.txt
@@ -0,0 +1,37 @@
+MPIC interrupt controller
+=
+
+Device types supported:
+  KVM_DEV_TYPE_FSL_MPIC_20 Freescale MPIC v2.0
+  KVM_DEV_TYPE_FSL_MPIC_42 Freescale MPIC v4.2
+
+Only one MPIC instance, of any type, may be instantiated.  The created
+MPIC will act as the system interrupt controller, connecting to each
+vcpu's interrupt inputs.
+
+Groups:
+  KVM_DEV_MPIC_GRP_MISC
+  Attributes:
+KVM_DEV_MPIC_BASE_ADDR (rw, 64-bit)
+  Base address of the 256 KiB MPIC register space.  Must be
+  naturally aligned.  A value of zero disables the mapping.
+  Reset value is zero.
+
+  KVM_DEV_MPIC_GRP_REGISTER (rw, 32-bit)
+Access an MPIC register, as if the access were made from the guest. 
+attr is the byte offset into the MPIC register space.  Accesses
+must be 4-byte aligned.
+
+MSIs may be signaled by using this attribute group to write
+to the relevant MSIIR.
+
+  KVM_DEV_MPIC_GRP_IRQ_ACTIVE (rw, 32-bit)
+IRQ input line for each standard openpic source.  0 is inactive and 1
+is active, regardless of interrupt sense.
+
+For edge-triggered interrupts:  Writing 1 is considered an activating
+edge, and writing 0 is ignored.  Reading returns 1 if a previously
+signaled edge has not been acknowledged, and 0 otherwise.
+
+attr is the IRQ number.  IRQ numbers for standard sources are the
+byte offset of the relevant IVPR from EIVPR0, divided by 32.
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index e34f8fe..7e7aef9 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -359,6 +359,11 @@ struct kvmppc_slb {
 #define KVMPPC_BOOKE_MAX_IAC   4
 #define KVMPPC_BOOKE_MAX_DAC   2
 
+/* KVMPPC_EPR_USER takes precedence over KVMPPC_EPR_KERNEL */
+#define KVMPPC_EPR_NONE0 /* EPR not supported */
+#define KVMPPC_EPR_USER1 /* exit to userspace to fill EPR */
+#define KVMPPC_EPR_KERNEL  2 /* in-kernel irqchip */
+
 struct kvmppc_booke_debug_reg {
u32 dbcr0;
u32 dbcr1;
@@ -522,7 +527,7 @@ struct kvm_vcpu_arch {
u8 sane;
u8 cpu_type;
u8 hcall_needed;
-   u8 epr_enabled;
+   u8 epr_flags; /* KVMPPC_EPR_xxx */
u8 epr_needed;
 
u32 cpr0_cfgaddr; /* holds the last set cpr0_cfgaddr */
@@ -589,5 +594,6 @@ struct kvm_vcpu_arch {
 #define KVM_MMIO_REG_FQPR  0x0060
 
 #define __KVM_HAVE_ARCH_WQP
+#define __KVM_HAVE_CREATE_DEVICE
 
 #endif /* __POWERPC_KVM_HOST_H__ */
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index f589307..3b63b97 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -164,6 +164,8 @@ extern int kvmppc_prepare_to_enter(struct kvm_vcpu *vcpu);
 
 extern int kvm_vm_ioctl_get_htab_fd(struct kvm *kvm, struct kvm_get_htab_fd *);
 
+int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq);
+
 /*
  * Cuts out inst bits with ordering according to spec.
  * That means the leftmost bit is zero. All given bits are included.
@@ -245,6 +247,9 @@ int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id, union 
kvmppc_one_reg *);
 
 void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 pid);
 
+struct openpic;
+void kvmppc_mpic_put(struct openpic *opp);
+
 #ifdef CONFIG_KVM_BOOK3S_64_HV
 static inline void kvmppc_set_xics_phys(int cpu, unsigned long addr)
 {
@@ -270,6 +275,8 @@ static inline void kvmppc_set_epr(struct kvm_vcpu *vcpu, 
u32 epr)
 #endif
 }
 
+void kvmppc_mpic_set_epr(struct kvm_vcpu *vcpu);
+
 int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
  struct kvm_config_tlb *cfg);
 int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu *vcpu,
diff --git a/arch/powerpc/kvm/Kconfig