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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).