On Wed, 07 Dec 2011, Avi Kivity wrote:

On 12/05/2011 10:18 PM, Eric B Munson wrote:

quoted

Changes from V4:
Rename KVM_GUEST_PAUSED to KVMCLOCK_GUEST_PAUSED
Add description of KVMCLOCK_GUEST_PAUSED ioctl to api.txt

Changes from V3:
Include CC's on patch 3
Drop clear flag ioctl and have the watchdog clear the flag when it is reset

Changes from V2:
A new kvm functions defined in kvm_para.h, the only change to pvclock is the
initial flag definition

Changes from V1:
(Thanks Marcelo)
Host code has all been moved to arch/x86/kvm/x86.c
KVM_PAUSE_GUEST was renamed to KVM_GUEST_PAUSED

When a guest kernel is stopped by the host hypervisor it can look like a soft
lockup to the guest kernel.  This false warning can mask later soft lockup
warnings which may be real.  This patch series adds a method for a host
hypervisor to communicate to a guest kernel that it is being stopped.  The
final patch in the series has the watchdog check this flag when it goes to
issue a soft lockup warning and skip the warning if the guest knows it was
stopped.

It was attempted to solve this in Qemu, but the side effects of saving and
restoring the clock and tsc for each vcpu put the wall clock of the guest behind
by the amount of time of the pause.  This forces a guest to have ntp running
in order to keep the wall clock accurate.

Having this controlled from userspace means it doesn't work for SIGSTOP
or for long scheduling delays.  What about doing this automatically
based on preempt notifiers?


-- 
error compiling committee.c: too many arguments to function

My concern for preempt notifiers is masking real soft lockup warnings.  If the
flag is set every time the vm is preempted, it becomes more likely that we will
mask real warnings.  The ioctl was choosen because it sets the flag only when
the guest is being paused deliberately.

AFAIK, SIGSTOP is not a supported way to stop a qemu vm so a soft lockup
warning would be working as designed there.  If that isn't the case, or if it
ever changes, we could always install a signal handler for SIGCONT that set the
flag before resuming the vm.

Scheduling delays are also beyond the scope of this problem and I see the soft
lockup warning as appropriate in that case.

Eric