qemu-devel
[Top][All Lists]
Advanced

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

[patch] Re: [patch] on-quit-v0.21 with resume/suspend/power-off dialog R


From: Struan Bartlett
Subject: [patch] Re: [patch] on-quit-v0.21 with resume/suspend/power-off dialog Re: [patch] Re: [Qemu-devel] Suggestion - trap window-close of VM
Date: Fri, 29 Jul 2005 01:07:29 +0100 (BST)

If anyone cares, I've updated my on-quit-0.21 patch to cleanly apply to
qemu 0.7.1 (to be precise the 2005-07-23 nightly snapshot of 0.7.1).

Instructions and history below. Feedback still welcome.

Struan

On Sat, 7 May 2005, Struan Bartlett wrote:

> Having had the APM bios fixed in the 0.7 Qemu release, which allows
> Windows 2000 to correctly signal Qemu when it wants to shutdown the VM,
> I've updated my '-on-quit' patch - which prevented the VM from being
> crudely shut down by accidentally pressing Ctrl-C or closing the VM
> window - to remove the nasty i386-specific "halt-instruction-detection"
> code and provide what I hope you will agree is a cleaner replacement.
>
> The new patch instead relies on APM/SDL/Cocoa/Cuda each specifying
> whether the shutdown request originated from the hardware or from the
> user. In the case of user request, Qemu's behaviour will depend on the
> command line option specified: 1. '-on-quit ignore' means ignore the
> Ctrl-C; 2. '-on-quit suspend' means suspend the VM. In the case of a
> hardware shutdown, the VM will shut down normally (but if '-on-quit
> suspend' was selected it will delete the named suspend file first).
>
> The patch features extra options '-on-quit ask' and '-on-quit
> <filepath>' which both cause Qemu to run a script to ask the user
> whether they want to resume, suspend or power off the VM. For non-WIN32
> platforms, this is easily implemented it using a script that the
> xmessage command i.e.:
>
> #!/bin/sh
>
> exec /usr/bin/X11/xmessage -center -timeout 10 -buttons
> 'Resume:0,Suspend:1,Power Off:2' 'Do you want to resume, suspend, or
> power off this virtual machine?'
>
> The '-on-quit ask' option assumes a default script filename
> "on_quit_ask", assumed to be in the CONFIG_QEMU_SHAREDIR directory (i.e.
> usually /usr/local/share/qemu).
>
> Example command (Linux) which should correctly buffer naive users from
> accidental VM shutdown and suspend file overwriting: it resumes from
> suspended.qemu file if it exists; asks user whether to resume, power off
> or suspend on CTRL-C or window close; suspend saves to the same file;
> power off deleted the suspend file.
>
> qemu -hda win2k.raw -m 64 -monitor null -loadvm suspended.qemu -on-quit ask
>
> Feedback welcome!
>
> Struan
>
> Struan Bartlett wrote:
>
> > 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.
> >>

Attachment: on-quit-v0.21.patch-to-0.7.1
Description: Text document


reply via email to

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