Re: [Qemu-devel] [PATCH] kvm-all.c: Move init of irqchip_inject_ioctl out of kvm_irqchip_create()

[Peter Maydell <peter.maydell@linaro.org>]

On 14 August 2012 09:09, Jan Kiszka <jan.kiszka@web.de> wrote:
> On 2012-08-14 09:52, Peter Maydell wrote:
>> Well, you appear to know what this variant ioctl does and why it's
>> better than KVM_IRQ_LINE, whereas I don't. I just want to deliver
>> an interrupt, KVM_IRQ_LINE lets me deliver an interrupt, why
>> do I need anything more? (What would I do with the status return, for
>> instance? I have to assert the incoming irq line, there's nothing for
>> me to do if the kernel says "sorry, can't do that" except abort qemu.)
>
> Not sure how timekeeping of all your guests will work, but a classic
> scenario on x86 is that some timer is programmed to deliver periodic
> ticks (or one-shot ticks that also generates a virtual periodic timer)
> and that those ticks will then be used to derive the system time of the
> guest. Now, if the guest was unable to process the past tick completely
> (due to host load) and we inject already another tick event, that one
> will get lost. Some guests (older Linuxes but also many proprietary
> OSes) are not prepared for such tick loss and will suffer from drifting
> wall clocks.

So, for ARM the overwhelmingly common case will be that we use the in
kernel architectural timer for doing periodic / one-shot ticks. That's
all in the kernel anyway (both timer and VGIC interrupt controller).

The less plausible case uses the in-kernel interrupt controller but an
out of kernel timer device. The only link between the two is a qemu_irq line,
so we have (a) no way to tell if this interrupt line into the GIC is a timer
or not and (b) no back-channel to the timer device to report things anyway.

The really unlikely case (in that there is theoretically code to handle it
but in practice QEMU will refuse to configure itself this way) has an out
of kernel GIC. In this case the interrupts we deliver to the kernel are
pre-coalesced into a single IRQ line, and there's definitely not a lot
we could do with the status report.

Marc Z tells me we could make the kernel return the 'did this coalesce?'
status without too much difficulty, but unless it's actually possible
to do something useful with it in userspace I'm not sure I see the point.

-- PMM