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

[Jan Kiszka]

On 2012-08-14 09:52, Peter Maydell wrote:
> On 14 August 2012 08:42, Jan Kiszka <address@hidden> wrote:
>> On 2012-08-14 09:40, Peter Maydell wrote:
>>> On 14 August 2012 08:33, Jan Kiszka <address@hidden> wrote:
>>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
>>>> injection with feedback to allow lost-tick compensation) is the current
>>>> standard that other archs should pick up.
>>>
>>> Can it be documented in the kernel api.txt then, please? Nobody
>>> is going to use it otherwise... (If I'd been paying attention at the
>>> time I'd have nak'd the qemu patches that added it on the grounds
>>> they were using an undocumented kernel API :-))
>>
>> The kernel API's documentation has in fact a much younger history than
>> KVM support in QEMU. I think we still need to add quite a few standard
>> IOCTLs to make it complete. Patches always welcome.
> 
> 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.

For that reason, we allow userspace to find out if a (potentially) tick
driving IRQ was actually received by the guest or if it coalesced with
an ongoing event. In the latter case, userspace can reinject those
events once the guest is able to receive them again. All we need from
the kernel API is that feedback KVM_IRQ_LINE_STATUS provides. The return
values are "nicely" hidden in kvm_set_irq:

/*
 * Return value:
 *  < 0   Interrupt was ignored (masked or not delivered for other reasons)
 *  = 0   Interrupt was coalesced (previous irq is still pending)
 *  > 0   Number of CPUs interrupt was delivered to
 */

QEMU doesn't make use of that number of receiving CPUs and I'm mot sure
why we even report it. Maybe the kernel API should just state that >0
means delivered.

Jan

signature.asc
Description: OpenPGP digital signature