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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
