From: Asko Kauppi <asko.kauppi@sci.fi>
To: qemu-devel@nongnu.org
Subject: Re: [patch] Re: [Qemu-devel] Suggestion - trap window-close of VM
Date: Mon, 28 Mar 2005 15:51:30 +0300 [thread overview]
Message-ID: <9fdf1714f679008d8a524bade67f5492@sci.fi> (raw)
In-Reply-To: <4247EBB0.6090409@praguespringpeople.org>
Would it be too hard to implement a proper "state save" such as in
Virtual PC and others? In my experience, that single feature is the
most important of any emulation system; ability to work for a while,
then suspend the whole system for days, weeks, or years, and catching
up where you last left it.
Is there some practical reason why QEmu should not offer this?
-ak
28.3.2005 kello 14:34, Struan Bartlett kirjoitti:
Hi,
>
> I've attached a patch against the 2005-03-26 snapshot that implements
> two '-on-quit' options for the emulator window: ignore-unless-halted
> and suspend-unless-halted, that aim to make it safe to allow naive
> users to (try to) close the VM window by trapping requests to shutdown
> and either ignoring them or forcing a save of the VM state before
> obeying them.
>
> Caveat: I'll come clean straight away that the patch is implemented
> using a nasty TARGET_i386-specific hack that detects whether the guest
> operating system has permanently halted by looking to see if the last
> instruction executed was 0xF4 and, if so, whether the IF flag is
> cleared. Saying that, this system appears to work reasonably well on
> my Pentium host running a Windows 2000 guest, but I have not tested it
> on any other systems.
>
> Usage:
>
> 1. If you provide naive users with a variation on the following
> command line, then you can let your naive users (try to) close the VM
> window as much as they like. Unless the guest has permanently halted,
> attempts to close the VM window should save the VM state to
> 'suspended.qemu' in the current working directory before qemu exits.
> The same command line will restart the VM where it left off. Then,
> once the guest has permanently halted, qemu will delete the
> suspended.qemu file so that the next launch of qemu will boot afresh:
>
> qemu -hda win2k.raw -m 64 -monitor null -loadvm suspended.qemu
> -on-quit suspend-unless-halted
>
> 2. Alternatively, the following command will make qemu ignore the
> user's request to close the emulator window unless the guest has
> already permanently halted:
>
> qemu -hda win2k.raw -m 64 -monitor null -on-quit ignore-unless-halted
>
> 3. If you combine this with a test of whether qemu is already
> running, then it should be safe to let naive users try to both launch
> and to close qemu as much as they like. e.g.
>
> killall -0 qemu 2>/dev/null; if [ $? == 1 ]; then qemu -hda win2k.raw
> -m 64 -monitor null -loadvm suspended.qemu -on-quit
> suspend-unless-halted; fi &
>
> 4. Finally, if your leave out the -on-quit option altogether, then
> qemu's behaviour should remain completely unchanged.
>
> I hope this is useful for some i386/W2K users out there. Any
> constructive criticism appreciated. If you know how I could improve
> permanent halt detection (that doesn't require in-depth knowledge of
> APM or ACPI) then please let me know.
>
> Struan
>
> Struan Bartlett wrote:
> Ryan Rempel wrote:
> On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote
>
> On Mon, Nov 29, 2004 at 08:43:56PM +0000, Richard Neill wrote:
>
> A thought that occurred to me. If one is running a virtual machine (eg
> copy of WinXP), then simply closing the qemu window is a really bad
> idea, since it will effectively crash the guest.
>
> Related thought -- it would be way cool if we could make killing qemu
> do exactly happens when you press the power button on an ACPI-capable
> machine with any recent OS on it (auto shutdown.)
>
> I was wondering if anyone has followed up on this suggestion. I'm
> putting together a Qemu-based setup for some relatively naive users,
> and ideally I'd like to be able to deal with this in a reasonable
> elegant way (the ACPI hook sounds very elegant indeed).
>
> Alternatively, how do people deal with the problem of naive users who
> might just close the Qemu window without shutting down the guest
> properly? I'm working in a KDE environment -- perhaps there is a way
> in KDE to prevent the close button from appearing? But that wouldn't
> catch every case either (for instance, if the user were to shut down
> the host).
> This sounds like a good idea. An alternative solution, that might be
> more straightforward to implement if Qemu doesn't implement ACPI yet,
> would be for the kill signal to simply cause Qemu to do the equivalent
> of entering 'stop' and 'savevm <somefilepath>' into the monitor.
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
> --- qemu-snapshot-2005-03-26_23/vl.c Sun Mar 13 17:59:37 2005
> +++ qemu-snapshot-2005-03-26_23-on-quit/vl.c Mon Mar 28 02:06:52 2005
> @@ -139,6 +139,9 @@
> int graphic_height = 600;
> int graphic_depth = 15;
> int full_screen = 0;
> +#ifdef TARGET_I386
> +int on_quit = 0;
> +#endif
> TextConsole *vga_console;
> CharDriverState *serial_hds[MAX_SERIAL_PORTS];
> CharDriverState *parallel_hds[MAX_PARALLEL_PORTS];
> @@ -2675,6 +2678,17 @@
> qemu_get_clock(rt_clock));
> }
>
> +#ifdef TARGET_I386
> +int ishalted() {
> + uint8_t buf[16];
> + uint64_t v;
> +
> + cpu_memory_rw_debug(cpu_single_env, cpu_single_env->eip-1, buf,
> 16, 0);
> + v = ldub_raw(buf);
> + return (v == 0xf4) && ( !(cpu_single_env->eflags & 0x200) );
> +}
> +#endif
> +
> int main_loop(void)
> {
> int ret, timeout;
> @@ -2684,9 +2698,16 @@
> if (vm_running) {
> ret = cpu_exec(env);
> if (shutdown_requested) {
> +#ifdef TARGET_I386
> + if( on_quit == 0 || on_quit == 2 || ( on_quit == 1 &&
> ishalted() ) ) {
> +#endif
> ret = EXCP_INTERRUPT;
> break;
> }
> +#ifdef TARGET_I386
> + shutdown_requested = 0;
> + }
> +#endif
> if (reset_requested) {
> reset_requested = 0;
> qemu_system_reset();
> @@ -2783,6 +2804,11 @@
> "-std-vga simulate a standard VGA card with VESA
> Bochs Extensions\n"
> " (default is CL-GD5446 PCI VGA)\n"
> #endif
> +#ifdef TARGET_I386
> + "-on-quit [ignore-unless-halted|suspend-unless-halted]\n"
> + " select the behaviour when the emulator window is
> asked to quit\n"
> + " (default is none)\n"
> +#endif
> "-loadvm file start right away with a saved state
> (loadvm in monitor)\n"
> "\n"
> "During emulation, the following keys are useful:\n"
> @@ -2864,6 +2890,10 @@
> QEMU_OPTION_full_screen,
> QEMU_OPTION_pidfile,
> QEMU_OPTION_no_kqemu,
> +
> +#ifdef TARGET_I386
> + QEMU_OPTION_on_quit
> +#endif
> };
>
> typedef struct QEMUOption {
> @@ -2932,6 +2962,9 @@
> { "loadvm", HAS_ARG, QEMU_OPTION_loadvm },
> { "full-screen", 0, QEMU_OPTION_full_screen },
> { "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
> +#ifdef TARGET_I386
> + { "on-quit", HAS_ARG, QEMU_OPTION_on_quit },
> +#endif
>
> /* temporary options */
> { "pci", 0, QEMU_OPTION_pci },
> @@ -3383,6 +3416,19 @@
> case QEMU_OPTION_pidfile:
> create_pidfile(optarg);
> break;
> +#ifdef TARGET_I386
> + case QEMU_OPTION_on_quit:
> + if(!strcmp(optarg, "ignore-unless-halted")) {
> + fprintf(stderr, "%s enabled\n", optarg);
> + on_quit = 1;
> + }
> + else if(!strcmp(optarg, "suspend-unless-halted")) {
> + fprintf(stderr, "%s enabled\n", optarg);
> + on_quit = 2;
> + }
> + else on_quit = 0;
> + break;
> +#endif
> #ifdef USE_KQEMU
> case QEMU_OPTION_no_kqemu:
> kqemu_allowed = 0;
> @@ -3696,6 +3742,23 @@
> }
> }
> main_loop();
> +
> +#ifdef TARGET_I386
> + if( on_quit == 2 ) {
> + char *f = "suspended.qemu";
> + if( ishalted() ) {
> +
> + fprintf(stderr, "VM is halted: removing suspend file %s\n",f);
> + unlink(f);
> + /* qemu_savevm(f); */
> + }
> + else {
> + fprintf(stderr, "Autosaving VM to file %s\n",f);
> + qemu_savevm(f);
> + }
> + }
> +#endif
> +
> quit_timers();
> return 0;
> }
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
next prev parent reply other threads:[~2005-03-28 13:10 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-27 3:49 [Qemu-devel] Suggestion - trap window-close of VM Ryan Rempel
2005-03-27 18:30 ` Struan Bartlett
2005-03-28 11:34 ` [patch] " Struan Bartlett
2005-03-28 12:51 ` Asko Kauppi [this message]
2005-03-28 13:04 ` Paul Brook
2005-03-29 22:37 ` [Qemu-devel] " Ryan Rempel
2005-03-29 22:52 ` Paul Brook
2005-03-30 1:17 ` Ryan Rempel
2005-03-30 12:20 ` Struan Bartlett
2005-03-30 12:48 ` Lennert Buytenhek
2005-03-30 13:26 ` Struan Bartlett
2005-03-30 18:22 ` Lennert Buytenhek
2005-03-30 20:16 ` Leonardo E. Reiter
2005-03-30 21:22 ` Lennert Buytenhek
2005-03-30 21:43 ` Struan Bartlett
2005-03-31 9:32 ` John R. Hogerhuis
2005-03-31 12:31 ` Lennert Buytenhek
2005-03-30 13:21 ` APM bug " Struan Bartlett
2005-03-31 10:38 ` Struan Bartlett
2005-03-31 17:56 ` Struan Bartlett
2005-04-03 22:00 ` A Fix " Struan Bartlett
2005-04-04 9:53 ` Struan Bartlett
2005-04-04 17:12 ` Struan Bartlett
2005-04-04 22:26 ` Iain McFarlane
2005-04-05 16:34 ` Volker Ruppert
2005-04-05 21:05 ` Iain McFarlane
2005-04-05 21:33 ` [Qemu-devel] Re: Windows 2000 SP4 (was Re: APM bug) Leonardo E. Reiter
2005-04-05 22:57 ` Hetz Ben Hamo
2005-04-05 23:03 ` Leonardo E. Reiter
2005-04-05 23:48 ` Hetz Ben Hamo
2005-04-06 0:28 ` Leonardo E. Reiter
2005-04-06 0:52 ` [Qemu-devel] Re: Windows 2000 SP4 Leonardo E. Reiter
2005-04-06 20:25 ` [Qemu-devel] Re: Windows 2000 SP4 (was Re: APM bug) Fabrice Bellard
2005-04-06 22:47 ` Hetz Ben Hamo
2005-04-07 7:17 ` Jonas Maebe
2005-04-07 11:56 ` Flavio Visentin
2005-04-05 23:40 ` Derek Fawcus
2005-04-07 16:42 ` A Fix Re: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-closeof VM Andreas Bollhalder
2005-04-05 13:55 ` APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM Alex Beregszaszi
2005-03-31 16:38 ` Andreas Bollhalder
2005-03-31 17:32 ` Jason Gress
2005-05-07 16:30 ` [patch] on-quit-v0.21 with resume/suspend/power-off dialog Re: [patch] Re: [Qemu-devel] " Struan Bartlett
2005-05-09 15:43 ` Ryan Rempel
2005-05-09 22:25 ` Struan Bartlett
2005-05-09 23:19 ` Flavio Visentin
2005-05-10 8:40 ` Struan Bartlett
2005-07-29 0:07 ` [patch] " Struan Bartlett
2005-03-28 15:04 ` Mark Williamson
2005-03-28 19:13 ` Joshua Kugler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fdf1714f679008d8a524bade67f5492@sci.fi \
--to=asko.kauppi@sci.fi \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.