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: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH] kvm: Move kvm_allows_irq0_override() to target-i386
Date: Sat, 21 Jul 2012 12:22:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2012-07-21 11:56, Peter Maydell wrote:
> 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)?

It describes this requirement primarily.

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

It depends on the feature set of the in-kernel irqchips and if this can
possibly vary on real hw.

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

Let's look at this again when we redefined the KVM test functions. Maybe
then the infrastructure is available to move it cleanly. Maybe it will
continue to not matter and we can leave it alone.

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

Could you inject IRQs from an in-kernel helper that (partially or fully)
emulates some device sitting on peripheral buses as well (like PCI)? If
not, you aren't done with the in-kernel irqchip model yet.

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

Once the prerequisites for peripheral interrupt injections are there,
enabling irqfd for your arch should be straightforward. I'm picking on
those prerequisites here, not irqfd.

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

linux/Documentation/virtual/kvm/api.txt is a good start, though not
really a high-level summary.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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