On 11/23/2010 06:49 PM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching
them to respond to these signals (which cannot be trapped), use SIGUSR1 to
approximate the behavior of SIGSTOP/SIGCONT.
The purpose of this is to implement CPU hard limits using an external tool that
watches the CPU consumption and stops the VCPU as appropriate.
This provides a more elegant solution in that it allows the VCPU thread to
release qemu_mutex before going to sleep.
This current implementation uses a single signal. I think this is too racey
in the long term so I think we should introduce a second signal. If two signals
get coalesced into one, it could confuse the monitoring tool into giving the
VCPU the inverse of it's entitlement.
You can use sigqueue() to send an accompanying value.
It might be better to simply move this logic entirely into QEMU to make this
more robust--the question is whether we think this is a good long term feature
to carry in QEMU?
I'm more concerned about lock holder preemption, and interaction of this
mechanism with any kernel solution for LHP.
+static __thread int sigusr1_wfd;
+
+static void on_sigusr1(int signo)
+{
+ char ch = 0;
+ if (write(sigusr1_wfd,&ch, 1)< 0) {
+ /* who cares */
+ }
+}
We do have signalfd().
+
+static void sigusr1_read(void *opaque)
+{
+ CPUState *env = opaque;
+ ssize_t len;
+ int caught_signal = 0;
+
+ do {
+ char buffer[256];
+ len = read(env->sigusr1_fd, buffer, sizeof(buffer));
+ caught_signal = 1;
+ } while (len> 0);
+
+ if (caught_signal) {
+ if (env->stopped) {
env->stopped is multiplexed among multiple users, so this interferes
with vm_stop().
We need to make ->stopped a reference count instead.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
