On Thu, May 24, 2007 at 4:29 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
Halting in userspace requires a relatively cumbersome mechanism to signal
the
halted VCPU. Implementing halt in kernel should be relatively straight
forward and it
Gregory Haskins wrote:
We have a specialized signal mask for the kernel, and it is already in
effect here. See KVM_SET_SIGNAL_MASK.
KVM_SET_SIGNAL_MASK is precisely what I was trying to counteract ;).
Basically I was thinking that userspace could have set some arbitrary
So as long as any appropriate signal will kick the HLT out of this wait-queue,
we are ok. It sounds like I can just get rid of the sigprocmask all together
and this will work? If so, I will pull that out for the v8 drop I am about
to make (rebased on git-head)
On Thu, May 24, 2007 at 8:17
Gregory Haskins wrote:
So as long as any appropriate signal will kick the HLT out of this
wait-queue, we are ok. It sounds like I can just get rid of the sigprocmask
all together and this will work?
Yes.
--
error compiling committee.c: too many arguments to function
Gregory Haskins wrote:
1) I think I really want *any* signal to kick the HLT, so I temporarily
unmask everything while halted.
Acutally that'll cause trouble if people have device drivers in user
space, which mask SIGIO for the CPU threads like our s390 prototype
does. Consider leaving the
On Thu, May 24, 2007 at 10:57 AM, in message [EMAIL PROTECTED],
Carsten Otte [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
1) I think I really want *any* signal to kick the HLT, so I temporarily
unmask everything while halted.
Acutally that'll cause trouble if people have device drivers
Halting in userspace requires a relatively cumbersome mechanism to signal the
halted VCPU. Implementing halt in kernel should be relatively straight
forward and it eliminates the need for the signaling
Signed-off-by: Gregory Haskins [EMAIL PROTECTED]
---
drivers/kvm/kvm.h |3 +
