qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386
Date: Sat, 21 Jul 2012 13:17:00 +0100

On 21 July 2012 12:08, Jan Kiszka <address@hidden> wrote:
> On 2012-07-21 12:53, Peter Maydell wrote:
>> This is still sounding like "there is an extra feature which you should
>> probably implement at some point and should certainly design with the
>> intention of supporting", not "you cannot have an irqchip without irqfds".
>>
>> Therefore QEMU code which cares about irqfds should be doing
>> checks for irqfd functionality, not "is there an in kernel
>> irqchip".
>
> Defining some kvm_irqfd_available() is one thing. Ignoring irqfd "for
> now" while introducing in-kernel irqchip is another, less wise decision.

You still haven't really explained why we can't just ignore irqfd
for now. I don't see how it would particularly affect the design
of the kernel implementation very much, and the userspace interface
seems to just be an extra ioctl.

> Once you support the backend (KVM_SET_GSI_ROUTING + KVM_IRQ_LINE),
> adding irqfd is in fact simple.

I don't really understand where KVM_SET_GSI_ROUTING comes into
this -- the documentation is a bit opaque. It says "Sets the GSI
routing table entries" but it doesn't define what a GSI is or
what we're routing to where. Googling suggests GSI is an APIC
specific term so it doesn't sound like it's relevant for non-x86.

I'm not sure what KVM_IRQ_LINE has to do with it either -- this
is just the standard interrupt injection ioctl. KVM ARM supports
this whether there's an in-kernel irqchip or not.

-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]