| Message ID | 1254172517-28216-7-git-send-email-glommer@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
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
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
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 > > >
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;
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(-)