On Thu, 20 Dec 2018, Gerd Hoffmann wrote:
On Wed, Dec 19, 2018 at 07:11:34PM +0100, BALATON Zoltan wrote:
On Wed, 19 Dec 2018, Daniel P. Berrangé wrote:
On Tue, Dec 18, 2018 at 08:05:59PM +0100, BALATON Zoltan wrote:
On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
I don't see any difference de
On Wed, Dec 19, 2018 at 07:11:34PM +0100, BALATON Zoltan wrote:
> On Wed, 19 Dec 2018, Daniel P. Berrangé wrote:
> > On Tue, Dec 18, 2018 at 08:05:59PM +0100, BALATON Zoltan wrote:
> > > On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
> > > > I don't see any difference depending on whether I use Ctr
On Wed, 19 Dec 2018, Daniel P. Berrangé wrote:
On Tue, Dec 18, 2018 at 08:05:59PM +0100, BALATON Zoltan wrote:
On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
I don't see any difference depending on whether I use Ctrl-Alt-3 before
or after the yellow screen - both work as expected. The fact that
On Tue, Dec 18, 2018 at 08:05:59PM +0100, BALATON Zoltan wrote:
> On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
> > I don't see any difference depending on whether I use Ctrl-Alt-3 before
> > or after the yellow screen - both work as expected. The fact that you
> > see a difference though does sug
On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
I don't see any difference depending on whether I use Ctrl-Alt-3 before
or after the yellow screen - both work as expected. The fact that you
see a difference though does suggest that there's something odd being
done in the ppc emulation that is in t
On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
On Tue, Dec 18, 2018 at 10:54:06AM +, Mark Cave-Ayland wrote:
On 17/12/2018 14:56, BALATON Zoltan wrote:
I still have this problem after updating everything on my machine, latest QEMU
and
SDL 2.0.9 so it's not likely to be a bug in some exter
On Tue, Dec 18, 2018 at 02:11:35PM +0100, BALATON Zoltan wrote:
> On Tue, 18 Dec 2018, Daniel P. Berrangé wrote:
> > On Tue, Dec 18, 2018 at 10:54:06AM +, Mark Cave-Ayland wrote:
> > > On 17/12/2018 14:56, BALATON Zoltan wrote:
> > >
> > > > I still have this problem after updating everything
On Tue, Dec 18, 2018 at 10:54:06AM +, Mark Cave-Ayland wrote:
> On 17/12/2018 14:56, BALATON Zoltan wrote:
>
> > I still have this problem after updating everything on my machine, latest
> > QEMU and
> > SDL 2.0.9 so it's not likely to be a bug in some external component. If I
> > just start
On Mon, Dec 17, 2018 at 10:57:14PM +0100, BALATON Zoltan wrote:
> On Mon, 17 Dec 2018, Daniel P. Berrangé wrote:
> > On Mon, Dec 17, 2018 at 03:56:49PM +0100, BALATON Zoltan wrote:
> > > On Wed, 21 Mar 2018, BALATON Zoltan wrote:
> > > > On Wed, 21 Mar 2018, Gerd Hoffmann wrote:
> > > > > > while t
On 17/12/2018 14:56, BALATON Zoltan wrote:
> I still have this problem after updating everything on my machine, latest
> QEMU and
> SDL 2.0.9 so it's not likely to be a bug in some external component. If I
> just start
> qemu-system-ppc (compiled with --disable-gtk) and try to open monitor conso
Hi,
> > > > > Doesn't reproduce too. It's also not clear why x86_64 should behave
> > > > > different that ppc. There is no arch-specific code ui/, so there
> > > > > should
> > > > > be no difference, exept for hardware like paralle ports which are not
> > > > > supported by all machine type
On Mon, 17 Dec 2018, Daniel P. Berrangé wrote:
On Mon, Dec 17, 2018 at 03:56:49PM +0100, BALATON Zoltan wrote:
On Wed, 21 Mar 2018, BALATON Zoltan wrote:
On Wed, 21 Mar 2018, Gerd Hoffmann wrote:
while the serial output seems to be behind the monitor output in the window
opening with Ctrl+Alt+
On Mon, Dec 17, 2018 at 03:56:49PM +0100, BALATON Zoltan wrote:
> On Wed, 21 Mar 2018, BALATON Zoltan wrote:
> > On Wed, 21 Mar 2018, Gerd Hoffmann wrote:
> > > > while the serial output seems to be behind the monitor output in the
> > > > window
> > > > opening with Ctrl+Alt+2 and flashes when I
On Wed, 21 Mar 2018, BALATON Zoltan wrote:
On Wed, 21 Mar 2018, Gerd Hoffmann wrote:
while the serial output seems to be behind the monitor output in the window
opening with Ctrl+Alt+2 and flashes when I type in this window. (This
doesn't seem to happen with qemu-system-x86_64, maybe that's why
On Wed, Jul 18, 2018 at 05:08:21PM +0200, Markus Armbruster wrote:
> Marc-André, one question for you inline. Search for your name.
>
> Peter Xu writes:
>
> > On Thu, Jun 28, 2018 at 03:20:41PM +0200, Markus Armbruster wrote:
> >> Peter Xu writes:
> >>
> >> > On Wed, Jun 27, 2018 at 03:13:57P
Marc-André, one question for you inline. Search for your name.
Peter Xu writes:
> On Thu, Jun 28, 2018 at 03:20:41PM +0200, Markus Armbruster wrote:
>> Peter Xu writes:
>>
>> > On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
>> >> Monitor behavior changes even when the clie
Peter Xu writes:
> On Mon, Jul 02, 2018 at 07:43:06AM +0200, Markus Armbruster wrote:
>> More lose ends:
>>
>> * scripts/qmp/ doesn't support OOB, yet. qmp-shell.py in particular
>>
>> * test-qmp-cmds neglects to cover the OOB additions to qmp-dispatch.c
>
> Would you mind I put these aside fo
On Mon, Jul 02, 2018 at 07:43:06AM +0200, Markus Armbruster wrote:
> More lose ends:
>
> * scripts/qmp/ doesn't support OOB, yet. qmp-shell.py in particular
>
> * test-qmp-cmds neglects to cover the OOB additions to qmp-dispatch.c
Would you mind I put these aside for now?
I'm afraid things gro
More lose ends:
* scripts/qmp/ doesn't support OOB, yet. qmp-shell.py in particular
* test-qmp-cmds neglects to cover the OOB additions to qmp-dispatch.c
On Thu, Jun 28, 2018 at 11:29:30AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Jun 27, 2018 at 10:35:15AM +0200, Markus Armbruster wrote:
> >> Markus Armbruster writes:
> >>
> >> > Another lose end: event COMMAND_DROPPED seems to lack test coverage.
> >>
> >> Hmm, dropping
On Thu, Jun 28, 2018 at 03:20:41PM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
> >> Monitor behavior changes even when the client rejects capability "oob".
> >>
> >> Traditionally, the monitor reads, executes and res
On Thu, Jun 28, 2018 at 08:55:48AM +0200, Markus Armbruster wrote:
> Peter Xu writes:
>
> > On Wed, Jun 27, 2018 at 01:23:07PM +0200, Markus Armbruster wrote:
> >> Daniel P. Berrangé writes:
> >>
> >> > On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
> >> >> Markus Armbruster
On Thu, Jun 28, 2018 at 09:04:19AM +0200, Markus Armbruster wrote:
> Eric Blake writes:
>
> > On 06/27/2018 07:07 AM, Peter Xu wrote:
> >
> Worse than that - broadcasting to all monitors is categorically broken.
> Different monitors make use the same "id" formatting scheme, so if you
>
Peter Xu writes:
> On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
>> Monitor behavior changes even when the client rejects capability "oob".
>>
>> Traditionally, the monitor reads, executes and responds to one command
>> after the other. If the client sends in-band commands
Daniel P. Berrangé writes:
> On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
>> Monitor behavior changes even when the client rejects capability "oob".
>>
>> Traditionally, the monitor reads, executes and responds to one command
>> after the other. If the client sends in-band
On 06/28/2018 01:55 AM, Markus Armbruster wrote:
Changing an existing event from broadcast to unicast is an observable
change in existing behavior. Compatibility break unless we can show
nobody can use / uses the observation.
And no one could have been relying on the broadcast COMMAND_DROPPED
Peter Xu writes:
> On Wed, Jun 27, 2018 at 10:35:15AM +0200, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>> > Another lose end: event COMMAND_DROPPED seems to lack test coverage.
>>
>> Hmm, dropping commands serves to limit the request queue. What limits
>> the response queue?
>
Eric Blake writes:
> On 06/27/2018 07:07 AM, Peter Xu wrote:
>
Worse than that - broadcasting to all monitors is categorically broken.
Different monitors make use the same "id" formatting scheme, so if you
broadcast COMMAND_DROPPED to a different monitor you might have clashing
>>>
Peter Xu writes:
> On Wed, Jun 27, 2018 at 01:23:07PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé writes:
>>
>> > On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
>> >> Markus Armbruster writes:
>> >>
>> >> > Markus Armbruster writes:
>> >> >
>> >> >> I fooled aro
On Wed, Jun 27, 2018 at 09:40:40AM +0200, Markus Armbruster wrote:
> Another lose end: event COMMAND_DROPPED seems to lack test coverage.
This one I can do. Since I'll try to prepare some patches to fix the
event issue, I can try to add the test alongside.
Thanks for mentioning!
--
Peter Xu
On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
> Monitor behavior changes even when the client rejects capability "oob".
>
> Traditionally, the monitor reads, executes and responds to one command
> after the other. If the client sends in-band commands faster than the
> server
On Wed, Jun 27, 2018 at 03:13:57PM +0200, Markus Armbruster wrote:
> Monitor behavior changes even when the client rejects capability "oob".
>
> Traditionally, the monitor reads, executes and responds to one command
> after the other. If the client sends in-band commands faster than the
> server
Monitor behavior changes even when the client rejects capability "oob".
Traditionally, the monitor reads, executes and responds to one command
after the other. If the client sends in-band commands faster than the
server can execute them, the kernel will eventually refuse to buffer
more, and sendi
On 06/27/2018 07:07 AM, Peter Xu wrote:
Worse than that - broadcasting to all monitors is categorically broken.
Different monitors make use the same "id" formatting scheme, so if you
broadcast COMMAND_DROPPED to a different monitor you might have clashing
"id" and thus incorrectly tell a client
On Wed, Jun 27, 2018 at 10:35:15AM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Another lose end: event COMMAND_DROPPED seems to lack test coverage.
>
> Hmm, dropping commands serves to limit the request queue. What limits
> the response queue?
As long as we have a request
On Wed, Jun 27, 2018 at 01:23:07PM +0200, Markus Armbruster wrote:
> Daniel P. Berrangé writes:
>
> > On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
> >> Markus Armbruster writes:
> >>
> >> > Markus Armbruster writes:
> >> >
> >> >> I fooled around a bit, and I think there
Daniel P. Berrangé writes:
> On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
>> Markus Armbruster writes:
>>
>> > Markus Armbruster writes:
>> >
>> >> I fooled around a bit, and I think there are a few lose ends.
>> > [...]
>> >> Talking to a QMP monitor that supports OOB:
>
On Wed, Jun 27, 2018 at 10:41:38AM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
>
> > Markus Armbruster writes:
> >
> >> I fooled around a bit, and I think there are a few lose ends.
> > [...]
> >> Talking to a QMP monitor that supports OOB:
> >>
> >> $ socat UNIX:test-qmp REA
Markus Armbruster writes:
> Markus Armbruster writes:
>
>> I fooled around a bit, and I think there are a few lose ends.
> [...]
>> Talking to a QMP monitor that supports OOB:
>>
>> $ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
>> {"QMP": {"version": {"qemu": {
Markus Armbruster writes:
> Another lose end: event COMMAND_DROPPED seems to lack test coverage.
Hmm, dropping commands serves to limit the request queue. What limits
the response queue?
Before OOB, the monitor read at most one command, and wrote its response
with monitor_puts().
For input, t
Markus Armbruster writes:
> I fooled around a bit, and I think there are a few lose ends.
[...]
> Talking to a QMP monitor that supports OOB:
>
> $ socat UNIX:test-qmp READLINE,history=$HOME/.qmp_history,prompt='QMP> '
> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 12, "major": 2},
Another lose end: event COMMAND_DROPPED seems to lack test coverage.
Hello,
On Wed, 21 Mar 2018, Gerd Hoffmann wrote:
On Tue, Mar 20, 2018 at 11:43:08PM +0100, BALATON Zoltan wrote:
1. Scrollback does not work. With SDL1.2 it is possible to scroll the
monitor (and maybe other output windows as well, I'm not sure about that)
with Ctrl+PgUp/PgDn but this does not
On Tue, Mar 20, 2018 at 11:43:08PM +0100, BALATON Zoltan wrote:
> Hello,
>
> With SDL2 the monitor and serial output windows behave differently than they
> used to with SDL1.2 in that they are opening in separate windows. This is an
> unexpected change we've discussed before but other than this th
Hello,
With SDL2 the monitor and serial output windows behave differently than
they used to with SDL1.2 in that they are opening in separate windows.
This is an unexpected change we've discussed before but other than this
there are actual bugs with SDL2:
1. Scrollback does not work. With SDL
* Sam (batmanu...@gmail.com) wrote:
> [gangyewei-3@yf-mos-test-net07 tests]$ telnet 127.0.0.1 55919
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> QEMU 2.6.2 monitor - type 'help' for more information
> (qemu) chardev-add
> socket,id=char-test_intf1,path=/usr/local/va
[gangyewei-3@yf-mos-test-net07 tests]$ telnet 127.0.0.1 55919
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
QEMU 2.6.2 monitor - type 'help' for more information
(qemu) chardev-add
socket,id=char-test_intf1,path=/usr/local/var/run/openvswitch/test_intf1,server=on
chardev-add
BTW, same result while using `telnet 127.0.0.1 55919`, which means also
have the two problem in the email before.
2017-09-08 11:23 GMT+08:00 Sam :
> Hi all,
>
> I'm using HMP socket to send command to add netdev, my command like this:
>
> [gangyewei-3@yf-mos-test-net07 tests]$ sudo python monito
Hi all,
I'm using HMP socket to send command to add netdev, my command like this:
[gangyewei-3@yf-mos-test-net07 tests]$ sudo python monitor.py 55919
> (qemu):
> Connected to qemu monitor ...
> on_monitor_open
> ds
> (qemu):
> {'return': ["unknown command: 'ds'"]}
> chardev-add
> socket,id=char
On Wed, May 24, 2017 at 10:26:58AM -0500, Eric Blake wrote:
> On 05/24/2017 10:16 AM, Simon wrote:
> > Hello,
> >
> > It seems that the monitor file path length is limited to about 100
> > characters (107 to be precise).
>
> Welcome to the joy of Unix socket (AF_UNIX) files. The kernel imposes a
Thank you for your answer Eric, I've learned a new thing today :) !
On 05/24/2017 10:16 AM, Simon wrote:
> Hello,
>
> It seems that the monitor file path length is limited to about 100
> characters (107 to be precise).
Welcome to the joy of Unix socket (AF_UNIX) files. The kernel imposes a
hard length limit on sockaddr_un.sun_path[] (see 'man 7 unix') - and it
i
Hello,
It seems that the monitor file path length is limited to about 100
characters (107 to be precise).
Currently I'm using the '-monitor' parameter to create the monitor file
in a directory which gather all the files related to a given VM (monitor
file, PID file, disk image, etc.):
-mon
Am 06.10.2016 um 13:07 hat Paolo Bonzini geschrieben:
> On 05/10/2016 19:43, Dr. David Alan Gilbert wrote:
> > > Speaking of the pocket calculator: my recommendation would be "nuke from
> > > orbit". It adds surprising corner cases to the HMP language, and
> > > provides next to no value.
> >
> >
"Dr. David Alan Gilbert" writes:
> * Markus Armbruster (arm...@redhat.com) wrote:
>
> Thanks for this.
>
>> In the beginning, there was only monitor.c, and it provided what we
>> today call HMP, at just under 500 SLOC.
>>
>> Since then, most (but not all) HMP commands have moved elsewhere, eithe
Hi
On Thu, Oct 6, 2016 at 3:14 PM Paolo Bonzini wrote:
>
>
> On 06/10/2016 13:10, Peter Maydell wrote:
> > On 6 October 2016 at 12:07, Paolo Bonzini wrote:
> >> My hunch is that it would be a drop in the sea if monitor.c were
> >> refactored properly.
> >
> > Speaking of refactoring, is there s
On 06/10/2016 13:10, Peter Maydell wrote:
> On 6 October 2016 at 12:07, Paolo Bonzini wrote:
>> My hunch is that it would be a drop in the sea if monitor.c were
>> refactored properly.
>
> Speaking of refactoring, is there scope for splitting things
> up so that if the foo subsystem needs to im
On 6 October 2016 at 12:07, Paolo Bonzini wrote:
> My hunch is that it would be a drop in the sea if monitor.c were
> refactored properly.
Speaking of refactoring, is there scope for splitting things
up so that if the foo subsystem needs to implement a monitor
command it can just call a function
On 05/10/2016 19:43, Dr. David Alan Gilbert wrote:
> > Speaking of the pocket calculator: my recommendation would be "nuke from
> > orbit". It adds surprising corner cases to the HMP language, and
> > provides next to no value.
>
> Huh, didn't realise that existed - I assume you mean get_expr a
* Laszlo Ersek (ler...@redhat.com) wrote:
> On 10/05/16 19:43, Dr. David Alan Gilbert wrote:
> > I guess the other thing that should be nuked is util/readline.c if we
> > can find a good, suitably licensed alternative.
>
> http://thrysoee.dk/editline/
> https://github.com/antirez/linenoise
>
>
On 10/05/16 19:43, Dr. David Alan Gilbert wrote:
> * Markus Armbruster (arm...@redhat.com) wrote:
>
> Thanks for this.
>
>> In the beginning, there was only monitor.c, and it provided what we
>> today call HMP, at just under 500 SLOC.
>>
>> Since then, most (but not all) HMP commands have moved e
* Markus Armbruster (arm...@redhat.com) wrote:
Thanks for this.
> In the beginning, there was only monitor.c, and it provided what we
> today call HMP, at just under 500 SLOC.
>
> Since then, most (but not all) HMP commands have moved elsewhere, either
> to the applicable subsystem, or to hmp.c.
On Wed, 05 Oct 2016 18:22:28 +0200
Markus Armbruster wrote:
> In the beginning, there was only monitor.c, and it provided what we
> today call HMP, at just under 500 SLOC.
>
> Since then, most (but not all) HMP commands have moved elsewhere, either
> to the applicable subsystem, or to hmp.c. Co
In the beginning, there was only monitor.c, and it provided what we
today call HMP, at just under 500 SLOC.
Since then, most (but not all) HMP commands have moved elsewhere, either
to the applicable subsystem, or to hmp.c. Command declaration moved to
hmp-commands.hx and hmp-commands-info.hx.
Pl
Il 19/06/2014 03:46, yan cui ha scritto:
We want to use QEMU to test some OS features on x86_64 systems. This
feature requires the monitor and mwait instructions on x86, but we do
not know whether QEMU currently support this. I got a QEMU copy from
http://git.qemu.org/qemu.git, and grep "mon
Hi all,
We want to use QEMU to test some OS features on x86_64 systems. This
feature requires the monitor and mwait instructions on x86, but we do not
know whether QEMU currently support this. I got a QEMU copy from
http://git.qemu.org/qemu.git, and grep "monitor" in the source code tree,
only
A set of patches adding completion support for various hmp commands. Following
other series that were merged earlier.
Hani Benhabiles (7):
monitor: Add ringbuf_write and ringbuf_read argument completion.
monitor: Add watchdog_action argument completion.
monitor: Add migrate_set_capability co
On Tue, May 20, 2014 at 12:01:01AM +0100, Hani Benhabiles wrote:
> A set of patches adding completion support for various hmp commands. Following
> other series that were merged earlier.
>
Resent the complete series. Please ignore this incomplete one.
Sorry for the flood.
> Hani Benhabiles (7):
A set of patches adding completion support for various hmp commands. Following
other series that were merged earlier.
Hani Benhabiles (7):
monitor: Add ringbuf_write and ringbuf_read argument completion.
monitor: Add watchdog_action argument completion.
monitor: Add migrate_set_capability co
Hi,
> -nographic without -nodefaults sets up a default serial line and a
> monitor, multiplexed onto stdio. Another way to get that is -serial
> mon:stdio.
>
> Maybe the multiplexing has regressed. I'm not sure, as I don't use it
> myself. Gerd (cc'ed) might know more.
Works for me. Serial
Mike Day writes:
> On Thu, Apr 24, 2014 at 3:31 AM, Markus Armbruster wrote:
>>> I believe someone on the list mentioned they are seeing a couple
>>> problems entering and exiting the Monitor. I'd like to look at this more
>>> closely, starting with my most pending issue: losing the terminal ech
On Thu, Apr 24, 2014 at 3:31 AM, Markus Armbruster wrote:
>> I believe someone on the list mentioned they are seeing a couple
>> problems entering and exiting the Monitor. I'd like to look at this more
>> closely, starting with my most pending issue: losing the terminal echo
>> after exiting the M
Mike Day writes:
> I believe someone on the list mentioned they are seeing a couple
> problems entering and exiting the Monitor. I'd like to look at this more
> closely, starting with my most pending issue: losing the terminal echo
> after exiting the Monitor.
Reproducer?
> Does anyone have a q
I believe someone on the list mentioned they are seeing a couple
problems entering and exiting the Monitor. I'd like to look at this more
closely, starting with my most pending issue: losing the terminal echo
after exiting the Monitor.
Does anyone have a quick pointer as to where I should look fo
Jan,
After my most recent pull from qemu git master, I realized I can no
longer use '-monitor stdio' together with '-enable-kvm'. They each
work separately, but when used together, qemu dies with the following
error:
$ bin/qemu-system-x86_64 -enable-kvm -monitor stdio
failed to initialize KVM: In
> How can I monitor the execution of some specific instructions (for
> example calls) of an application executing in linux-user mode? My
> first idea was inserting an interrupt (creating its proper handler)
> before all target instructions but I couldn`t get the it working. Any
> ideas on this?
Hello there,
How can I monitor the execution of some specific instructions (for
example calls) of an application executing in linux-user mode? My
first idea was inserting an interrupt (creating its proper handler)
before all target instructions but I couldn`t get the it working. Any
ideas on this?
Hello there,
How can I monitor the execution of some specific instructions (for
example calls) of an application executing in linux-user mode? My
first idea was inserting an interrupt (creating its proper handler)
before all target instructions but I couldn`t get the it working. Any
ideas on this?
Hello there,
Consider I`ve an apllication A executing in "linux-user" mode. How can
I monitor the execution of some instructions from A? For example, all
calls. I thought inserting an interrupt before all calls and creating
a new interrupt handler could do the job, but I can´t get it working.
Any
I would like to submit the monitor multiplexing patch again. It is
ported against the latest CVS.
It allows adding monitor capabilities like stdio but with tcp for
instance, and the escape character can be changed from the default.
signed-off-by: [EMAIL PROTECTED]
Index: monitor.c
Anyone think that the monitor help screen ought to implement some kind of paging
(think more) or something? I did a help, and half of the help is off the
screen before
I can figure out what I'm looking for (and apparently what I'm looking for is
already
scrolled off).
THoughts?
Ben
__
On Sat, 15 Jul 2006 23:51:39 +0200, Michael Fisher <[EMAIL PROTECTED]>
wrote:
1. Can the commands (i.e. sendkeys, savevm, loadvm) be initiated from
within the guest OS? If so, can you give me an example?
Of course, by its nature, not. A good emulator cannot allow that.
However, - if you confi
1. Can the commands (i.e. sendkeys, savevm, loadvm) be initiated from
within the guest OS? If so, can you give me an example?
2. When executing 'savevm' can it be saved to a virtual disk?
Thanks,
desNotes
___
Qemu-devel mailing list
Qemu-devel@nongn
I have a couple of questions regarding commands as part of the Qemu monitor:
1. Can the commands (i.e. sendkeys, savevm, loadvm) be initiated from
within the guest OS? If so, can you give me an example?
2. When executing 'savevm' can it be saved to a virtual disk?
Thanks,
desNotes
__
Ok, I forgot about external kernel modules or patches, as I don't use
any. But in plain Linux 2.6.17 mwait is only used in the function
mwait_idle()
R. Armiento wrote:
But I just don't see how you can postulate that mwait is not used
anywhere else in the Linux kernel? There are many kernel
85 matches
Mail list logo
