[Top][All Lists]

[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 10:56:37 +0100

On 21 July 2012 10:44, Jan Kiszka <address@hidden> wrote:
> On 2012-07-21 11:30, Peter Maydell wrote:
>> On 21 July 2012 10:14, Jan Kiszka <address@hidden> wrote:
>>> On 2012-07-21 10:54, Peter Maydell wrote:
>>>> On 21 July 2012 07:57, Jan Kiszka <address@hidden> wrote:
>>> Naming is x86 specific, semantic not. It means that KVM doesn't prevent
>>> remapping of IRQs. Granted, I really hope you don't make such mistakes
>>> in your arch.
>> What does "remapping of IRQs" mean here?
> It means that the QEMU model of the board can define interrupt routes in
> an unconfined way, which is obviously always true when the irqchips are
> all in userspace but not necessarily when KVM support is in the loop.

Er, surely it's only false if your KVM irqchip is obviously broken?
I mean, any sane in-kernel-irqchip model needs to support the same set
of incoming irq lines as the out-of-kernel irqchip model it's replacing.
There's no difference in flexibility there.

Or are you trying to talk about defining interrupt routes when the
source and destination are both kernel code but the route needs to
be set by userspace (ie is machine specific not cpu specific)?
Whether that's possible sounds to me like it would depend on all
the board model code between the source and destination rather
than being a single global boolean check.

>> not very generic to me, in that I really don't know what it would
>> mean in an ARM context. The fact that the only caller of this is
>> in hw/pc.c is also a big red flag that this isn't exactly generic.
> x86 is also still the only arch with full in-kernel irqchip support. And
> even if there is only one arch using it, that doesn't mean the test
> needs to be moved around - if the test itself is generic, just always
> true for other archs.

I just don't see why this check is anything other than "do I have
a broken x86 kernel irqchip?" In particular it doesn't have any
documented semantics defined in generic terms that you could usefully
use in general QEMU code to say "do I need to call this function
and what should I be doing based on the result?"

>>>>>  - in-kernel KVM helpers like vhost or VFIO can inject IRQs directly
>>>>> The latter point implies that irqfd is available and that interrupt
>>>>> routes from virtual IRQs (*) (like the one associated with an irqfd) to
>>>>> the in-kernel IRQ controller have to be established. That's pretty 
>>>>> generic.
>>>> But you can perfectly well have an in-kernel-irqchip that doesn't
>>>> support irqfd
>>> You could, thought this doesn't make much sense.
>> Why doesn't it make sense? On ARM, in-kernel-irqchip means you can take
>> advantage of the hardware support for a virtual GIC, and you can use
>> the virtual timer support too. These are both big performance advantages
>> even if QEMU never does anything with irqfds. (In fact the current
>> ARM KVM VGIC code doesn't support irqfds as far as I can see from
>> a quick scan of the kernel code.)
> It doesn't make sense as it means your in-kernel irqchip model is
> semi-finished. If you didn't consider how to support direct in-kernel
> IRQ injections, you risk designing something that requires userspace
> quirk handling later on when extending it to full-featured in-kernel
> irqchip support.

Well, the in-kernel virtual timer already does direct in-kernel IRQ
injection to the VGIC: it calls a function to say "inject IRQ X"...
(this works because the interrupt line used is fixed by the CPU,
it's not a board model property so there is no need for the routing
to be defined by userspace. (ie both ends of this irq injection are
in the CPU proper.))

As far as I can tell you seem to be saying "irqfds are an extra
feature you might want later", which is exactly "you can have
an irqchip without them".

(Is there some summary of the design of the irqfds stuff somewhere I
can go and read up?)

-- PMM

reply via email to

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