qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control


From: Avi Kivity
Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode
Date: Tue, 23 Jun 2009 15:46:55 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Lightning/1.0pre Thunderbird/3.0b2

On 06/23/2009 03:39 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 06/23/2009 02:53 PM, Jan Kiszka wrote:
I'm talking about, just as one example, sitting in front of my gdb
[frontend], doing guest kernel [driver] debugging and issuing "monitor
whatever" commands from one place, ie. not having to switch between
management app and debugging interface back and forth.


Can gdb issue monitor commands?

Yes.

How does one do that?  seems a very useful feature.

By spawning an additional monitor terminal, but switching off its
readline support (as that is handled by gdb).

In case there is still someone out there not being aware of this ;) : we
_do_ have support for multiple monitors in qemu already. Just try
"-monitor X -serial mon:Y" with X!=Y.

I could say that management can proxy the gdb packets and thus support
its own cli (in fact, it must if it wants to support live migration),
but that's really an edge case and I doubt anyone will do that, so you
have a good point.

Proxying would mean interpreting all "classic" monitor commands to catch
those that may interfere with the mgmt app state. I also don't think
that is worth the effort.

No, you would use the management system's cli which naturally enforces all of a user's permissions and is integrated with the GUI:

gui ----\
cli ----+---[ management server ] ---- [ libvirt ] ---- qemu
gdb ----/

That's the only setup that can support migration without dropping sessions. That doesn't change the "I don't think it's worth the effort" state though.

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]