Re: [kvm-devel] [PATCH 10/13] KVM: Wire up hypercall handlers toa central arch-independent location

From: Avi Kivity
Date: Thu Feb 22 2007 - 08:30:17 EST

Arjan van de Ven wrote:
Somthing else that came up in a conversation with Dor: the need for a clean way to raise a guest interrupt. The guest may be sleeping in userspace, scheduled out, or running on another cpu (and requiring an ipi to get it out of guest mode).

yeah it'd be nice if I could just call a function for it rather than
poking into kvm internals ;)

Sure. Please report all inconveniences (they're really bugs) so we can fix them.

Poking at kvm internals means you waste your time learning them, and later we can't change them.

Right now I'm thinking about using the signal machinery since it appears to do exactly the right thing.

signals are *expensive* though.

I think the expensive part of signals is userspace delivery. If they are always blocked in userspace, they become just another IPC channel.

I plan to add a signal mask to KVM_RUN a la pselect() so that userspace can dequeue signals instead of using a signal handler.

If you design an interrupt interface, it'd rock if you could make it
such that it is "raise <this> interrupt within <x> miliseconds from
now", rather than making it mostly synchronous. That way irq mitigation
becomes part of the interface rather than having to duplicate it all
over the virtual drivers...

Can't it be done by a helper function using a timer and a signal (or whatever mechanism we use to wake up vcpus)?

error compiling committee.c: too many arguments to function

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at