On 11/23/2010 08:41 AM, Avi Kivity wrote:
On 11/23/2010 01:00 AM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
teaching
them to respond to these signals, introduce monitor commands that stop
and start
individual vcpus.
The purpose of these commands
On 11/23/2010 12:41 AM, Avi Kivity wrote:
On 11/23/2010 01:00 AM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
teaching
them to respond to these signals, introduce monitor commands that
stop and start
individual vcpus.
The purpose of these
On 11/23/2010 02:16 AM, Dor Laor wrote:
On 11/23/2010 08:41 AM, Avi Kivity wrote:
On 11/23/2010 01:00 AM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
teaching
them to respond to these signals, introduce monitor commands that stop
and start
On 11/23/2010 03:51 PM, Anthony Liguori wrote:
On 11/23/2010 12:41 AM, Avi Kivity wrote:
On 11/23/2010 01:00 AM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of
teaching
them to respond to these signals, introduce monitor commands that
stop and
On 11/23/2010 08:00 AM, Avi Kivity wrote:
If we could catch SIGSTOP, then it would be easy to unblock it only
while running in guest context. It would then stop on exit to
userspace.
Yeah, that's not a bad idea.
Except we can't.
Yeah, I s:SIGSTOP:SIGUSR1:g.
Using monitor commands is
On 11/23/2010 04:24 PM, Anthony Liguori wrote:
Using monitor commands is fairly heavyweight for something as high
frequency as this. What control period do you see people using?
Maybe we should define USR1 for vcpu start/stop.
What happens if one vcpu is stopped while another is
On 11/23/2010 01:00 AM, Anthony Liguori wrote:
qemu-kvm vcpu threads don't response to SIGSTOP/SIGCONT. Instead of teaching
them to respond to these signals, introduce monitor commands that stop and start
individual vcpus.
The purpose of these commands are to implement CPU hard limits using an
