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

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 4988 bytes --]

On 2012-07-21 12:53, Peter Maydell wrote:
> On 21 July 2012 11:22, Jan Kiszka <jan.kiszka@web.de> wrote:
>> On 2012-07-21 11:56, Peter Maydell wrote:
>>> 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.
> 
> If the interrupt route is on-CPU then its routing is fixed (for
> that CPU), and you don't need to care about irqfds because the
> kernel knows what CPU it's providing to the guest, has both ends
> of the connection and can just do the right thing however is most
> convenient for the internal implementation. If the interrupt route
> is off-CPU then all bets are off because the routing is machine
> specific and could go through any kind of logic between the peripheral
> and the CPU's irqchip.
> 
> I don't see how you can do this with QEMU's current IRQ infrastructure,
> which basically just hardwires everything with qemu_irq lines and
> doesn't provide any way to query the routing and logic from an
> irq source to its destination.

Routing from arbitrary sources to the in-kernel sink, skipping
intermediate steps in the hotpath is in fact an unsolved issue in QEMU.
We are just introducing band-aid for PCI on x86 (to introduce PCI device
assignment). Long-term, this requires a generic solution which allows
path discovery etc. But this is a userspace problem, nothing related to
the KVM kernel features.

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

>>> 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.
> 
> I looked for 'irqfd' in that and found a straightforward ioctl for
> "wire this eventfd up to this irqchip input". That doesn't say anything
> about remapping of IRQs, and it's not clear to me either why a
> straightforward "use an ioctl to deliver incoming interrupts" design
> would be broken by adding that later: it's just a different source
> for the interrupt...

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

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]