Patchwork [6/6] Initialize in-kernel irqchip

login
register
mail settings
Submitter Glauber Costa
Date Sept. 28, 2009, 9:15 p.m.
Message ID <1254172517-28216-7-git-send-email-glommer@redhat.com>
Download mbox | patch
Permalink /patch/34400/
State Superseded
Headers show

Comments

Glauber Costa - Sept. 28, 2009, 9:15 p.m.
Now that we have all devices set up, this patch initializes the irqchip.
This is dependant on the io-thread, since we need someone to pull ourselves
out of the halted state.

I believe this should be the default when we are running over the io-thread.
Later on, I plan to post a patch that makes it optional.

Signed-off-by: Glauber Costa <glommer@redhat.com>
---
 kvm-all.c |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)
Jan Kiszka - Oct. 2, 2009, 8:33 p.m.
Glauber Costa wrote:
> Now that we have all devices set up, this patch initializes the irqchip.
> This is dependant on the io-thread, since we need someone to pull ourselves
> out of the halted state.
> 
> I believe this should be the default when we are running over the io-thread.
> Later on, I plan to post a patch that makes it optional.

I agree that in-kernel chips should be default if possible, but I would
keep the possibility to disable them like in qemu-kvm. This helps
specifically to track down issues in their implementations or their
potential side effects.

I have no good suggestion yet how the user interface should look like
(likely not as in qemu-kvm). Maybe some qdev property of the related
devices? But it seems like those are not yet user visible nor configurable.

Jan
Jamie Lokier - Oct. 2, 2009, 9:59 p.m.
Jan Kiszka wrote:
> I agree that in-kernel chips should be default if possible, but I would
> keep the possibility to disable them like in qemu-kvm. This helps
> specifically to track down issues in their implementations or their
> potential side effects.

As one of the side effects is to prevent migration to non-KVM hosts
(according to an earlier answer), I'd say the option to disable it is
essential.

Won't that option come for free when we have machine configuration
files - by simply specifying one irqchip or the other?

-- Jamie
Glauber Costa - Oct. 2, 2009, 10:22 p.m.
On Fri, Oct 2, 2009 at 6:59 PM, Jamie Lokier <jamie@shareable.org> wrote:
> Jan Kiszka wrote:
>> I agree that in-kernel chips should be default if possible, but I would
>> keep the possibility to disable them like in qemu-kvm. This helps
>> specifically to track down issues in their implementations or their
>> potential side effects.
>
> As one of the side effects is to prevent migration to non-KVM hosts
> (according to an earlier answer), I'd say the option to disable it is
> essential.
>
> Won't that option come for free when we have machine configuration
> files - by simply specifying one irqchip or the other?

Even if it does, I have code for that already.

I will post when I repost that series.

> -- Jamie
>
>
>

Patch

diff --git a/kvm-all.c b/kvm-all.c
index 50616d1..30df418 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -453,6 +453,22 @@  int kvm_set_irq(int irq, int level, int *status)
 
     return 1;
 }
+
+static int kvm_create_irqchip(KVMState *s)
+{
+    int ret;
+
+    if (!kvm_check_extension(s, KVM_CAP_IRQCHIP))
+        return -1;
+
+    ret = kvm_vm_ioctl(s, KVM_CREATE_IRQCHIP);
+    if (ret < 0)
+        return ret;
+
+    s->irqchip_in_kernel = 1;
+
+    return 0;
+}
 #endif
 
 int kvm_init(int smp_cpus)
@@ -536,6 +552,11 @@  int kvm_init(int smp_cpus)
     }
 #endif
 
+#if defined(CONFIG_IOTHREAD) && defined(KVM_CAP_IRQCHIP)
+    ret = kvm_create_irqchip(s);
+    if (ret < 0)
+        goto err;
+#endif
     ret = kvm_arch_init(s, smp_cpus);
     if (ret < 0)
         goto err;