Suggestion - trap window-close of VM

Quoted 4 lines

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.)

On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote

Quoted 11 lines · Richard Neill

Quoted 5 lines

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).

Quoted 19 lines · Ryan Rempel

On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote

Quoted 11 lines · Richard Neill

Quoted 5 lines

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).

Quoted 7 lines

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
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

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
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

vl.c +14 -0

@@ -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;

vl.c +7 -0

@@ -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();

vl.c +0 -0

@@ -2783,6 +2804,11 @@
            "-std-vga        simulate a standard VGA card with VESA 

Bochs Extensions\n"
" (default is CL-GD5446 PCI VGA)\n"
#endif

vl.c +3 -0

+#ifdef TARGET_I386
+	   "-on-quit [ignore-unless-halted|suspend-unless-halted]\n"
+	   "                select the behaviour when the emulator window is 

asked to quit\n"

vl.c +2 -0

+	   "                (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"

vl.c +37 -0

@@ -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
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

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?

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.

This isn't working quite right for me with a Windows 98 guest -- it traps the attempt to close the window all right, but it doesn't let the window close even when Window 98 has in fact shut down.

I wonder
whether this is related to the "Windows 98 doesn't use the HLT instruction" problem that is noted elsewhere (since that apparently doesn't affect Windows 2000).

Quoted 3 lines

This isn't working quite right for me with a Windows 98 guest -- it traps the attempt to close the window all right, but it doesn't let the window close even when Window 98 has in fact shut down.

As far as qemu is concerned there's nothing special about windows being "shut down". ie. it's not possible to tell if windows is doing something useful, or just sitting there waiting for you to turn it off.

Quoted 4 lines

I wonder
whether this is related to the "Windows 98 doesn't use the HLT instruction" problem that is noted elsewhere (since that apparently doesn't affect Windows 2000).

No. the HLT thing is just windows 9x being crap. It also happens on real hardware.

In theory windows should be able to "turn off" qemu using APM, like it does on real machines. However there seem to be bugs in the qemu implementation that stop this working.

Quoted 10 lines · Paul Brook

Quoted 5 lines

This isn't working quite right for me with a Windows 98 guest -- it traps the attempt to close the window all right, but it doesn't let the window close even when Window 98 has in fact shut down.

As far as qemu is concerned there's nothing special about windows being "shut down". ie. it's not possible to tell if windows is doing something useful, or just sitting there waiting for you to turn it off.

Just to clarify, I was commenting on Struan's patch, which does try to determine whether windows is "shut down" -- his patch seems to work with a Windows 2000 guest, but not a Windows 98 guest (he reported the former, I was reporting the latter).

Quoted 9 lines

Quoted 9 lines

I wonder
whether this is related to the "Windows 98 doesn't use the HLT instruction" problem that is noted elsewhere (since that apparently doesn't affect Windows 2000).

Quoted 4 lines

No. the HLT thing is just windows 9x being crap. It also happens on real hardware.

Quoted 5 lines

In theory windows should be able to "turn off" qemu using APM, like it does on real machines. However there seem to be bugs in the qemu implementation that stop this working.

Again to clarify, qemu does ordinarily quit as expected when I shut down a Windows 98 guest -- I was commenting specifically on Struan's patch, rather than qemu's normal behaviour. I was speculating that the HLT instruction might have an impact on Struan's method to detect whether windows had shut down (since it was a known difference between Windows 98 and 2000), but I may well be barking up the wrong tree there.

It subtracts one from the EIP (to find the address of
the previously-executed instruction) and examines the virtual memory location pointed to. If the memory location contains 0xF4 (HLT) then it examines the EFLAGS register. If the IF (Interrupt-enable) flag is cleared, then one might in fact assume that Windows 2000 is sitting there just waiting for you to turn it off. The assumption here is that if interrupts are disabled then there is no way the processor's halt state can be interrupted.

Quoted 3 lines · Struan Bartlett

It subtracts one from the EIP (to find the address of the previously-executed instruction) and examines the virtual memory location pointed to. If the memory location contains 0xF4 (HLT) then it examines the EFLAGS register. If the IF (Interrupt-enable) flag is cleared, then one might in fact assume that Windows 2000 is sitting there just waiting for you to turn it off. The assumption here is that if interrupts are disabled then there is no way the processor's halt state can be interrupted.

What happens if the previous instruction is a multi-byte instruction that happens to have 0xf4 as its last byte?

Quoted 9 lines

Quoted 8 lines

It subtracts one from the EIP (to find the address of
the previously-executed instruction) and examines the virtual memory location pointed to. If the memory location contains 0xF4 (HLT) then it examines the EFLAGS register. If the IF (Interrupt-enable) flag is cleared, then one might in fact assume that Windows 2000 is sitting there just waiting for you to turn it off. The assumption here is that if interrupts are disabled then there is no way the processor's halt state can be interrupted.

Quoted 2 lines

What happens if the previous instruction is a multi-byte instruction that happens to have 0xf4 as its last byte?

Before I did the IF check, that was a problem but now it should be ok. In your scenario, the IF flag would probably be found still to be set so it would be (correctly) assumed that Windows 2000 was not waiting to be turned off and qemu would continue normally.

So now you're implying that disabling interrupts is something that only very rarely happens, for example when shutting down the machine? I don't think that is a very realistic assumption.

--L

If I understand this correctly, it's specifically doing a halt with interrupts disabled. In theory that should just halt the processor indefinitely, since interrupts cannot be received. I can't imagine this being a common scenario for any software other than when it is completely shut down, unless of course you are explicitly expecting a non-maskable interrupt, which cannot be disabled, during a halt instruction. Again, I don't think it's all that common.

- Leo Reiter

Quoted 4 lines · Lennert Buytenhek

So now you're implying that disabling interrupts is something that only very rarely happens, for example when shutting down the machine? I don't think that is a very realistic assumption.

I suppose there's a reason, but why not trigger or set a flag on actual HLT instruction executed (while interrupts disabled)? That would avoid the kludge of peeking behind the instruction pointer.

If I understand this correctly, it's specifically doing a halt with interrupts disabled.

Quoted 5 lines

This isn't working quite right for me with a Windows 98 guest -- it traps the attempt to close the window all right, but it doesn't let the window close even when Window 98 has in fact shut down.

In theory windows should be able to "turn off" qemu using APM, like it does on real machines. However there seem to be bugs in the qemu implementation that stop this working.

Quoted 1 line · Paul Brook

In theory windows should be able to "turn off" qemu using APM, like it does on real machines. However there seem to be bugs in the qemu implementation that stop this working.

I thought I'd have a little look into why Windows 2000 doesn't turn off qemu using APM properly. I enabled DEBUG_BIOS in hw/pc.c then downloaded the latest Debian source for the Bochs bios v1.121 and defined DEBUG_ROMBIOS and DEBUG_APM both to be 1. I recompiled and installed the bios and ran qemu to load up Windows 2000. What we get seems interesting. By the time Qemu boots Windows 2000 to its first progress-bar, it has printed the following debug statements (with my explanation added in square brackets):

APM: EAX=00005300 [53 is the int 15h identifier for APM checked for in rombios.c. 00 is the APM installation check function]
APM: EAX=00005301 [01 is the APM real mode interface connect]
APM: EAX=0000530e [0e appears to request APM driver version]
APM: EAX=00005300 [00, again, is the APM installation check - why is this called twice?]
APM: EAX=00005304 [04 is APM interface disconnect]

Then, while Windows 2000 boots and until shutdown is complete, I get no more debug statements. My question is, why not? I'm no APM expert but, judging from the 'apmbios.S' comments I might expect to see APM: EAX=00005303 [03 is APM 32 bit protected mode interface connect]. I could speculate that the return code from APM function 0e does not satisfy Windows 2000 for some reason, so it does another installation check and then disconnects the APM interface entirely - hence no APM functionality in Windows 2000.

If I get more time I may research the APM functions more fully. In the meantime, if anyone can suggest any alternative theories or how to test them, I'd be curious.

Struan

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Having reviewed some of the APM1.2 specification, first impression is that the APM bios is required to provide not only a real-mode and protected 32-bit mode interface to its functions, but also a 16-bit protected mode interface, which the apmbios.S code apparently does not have.

I've tried adding one - although I'm not sure it's correct - and adjusting function 0x00 (APM installation check) to return 0x03 in cx (instead of 0x02 to signify the availability of this 16-bit interface) what's interesting is the debug statements immediately become slightly more promising:

APM: EAX=00005300
APM: EAX=00005301
APM: EAX=0000530e
APM: EAX=00005300
APM: EAX=00005304
APM: EAX=00005302 [16-bit protected mode interface connect]
APM: EAX=0000530e

As we can see, after having disconnected the real-mode interface the Windows APM driver seems to try to connect to the 16-bit protected mode interface (function 0x02). It then calls the APM driver version function (0x0e). But this isn't good enough. Windows 2000 still appears to call no further APM functions as it boots and shuts down. So, what's next?

If it's fair to assume that the Windows 2000 APM driver needs to interface with the APM bios using the 16-bit protected-mode interface (instead of the 32-bit interface) then the first thing that seems worth checking is my implementation of function 0x02, which I think it could well be returning the wrong code and data segment addresses. Here's the code:

;-----------------
; APM 16 bit protected mode interface connect
APMSYM(02):
cmp al, #0x02
jne APMSYM(03)

mov ax, #0xffff // 16 bit code segment base
mov bx, #_apm16_entry
mov cx, #0xf000 // data segment address
// 16 bit code segment size
mov si, #0xfff0
mov di, #0xfff0 // data segment length
jmp APMSYM(ok)

;-----------------
; APM 32 bit protected mode interface connect
APMSYM(03):
cmp al, #0x03
jne APMSYM(04)
mov ax, #0xf000 // 32 bit code segment base
mov ebx, #_apm32_entry
mov cx, #0xf000 // 16 bit code segment base
// 32 bit code segment size (low 16 bits)
// 16 bit code segment size (high 16 bits)
mov esi, #0xfff0fff0
mov dx, #0xf000 // data segment address
mov di, #0xfff0 // data segment length
jmp APMSYM(ok)

Can anyone advise?

Struan

Quoted 17 lines · Struan Bartlett

Quoted 1 line · Paul Brook

In theory windows should be able to "turn off" qemu using APM, like it does on real machines. However there seem to be bugs in the qemu implementation that stop this working.

I thought I'd have a little look into why Windows 2000 doesn't turn off qemu using APM properly. I enabled DEBUG_BIOS in hw/pc.c then downloaded the latest Debian source for the Bochs bios v1.121 and defined DEBUG_ROMBIOS and DEBUG_APM both to be 1. I recompiled and installed the bios and ran qemu to load up Windows 2000. What we get seems interesting. By the time Qemu boots Windows 2000 to its first progress-bar, it has printed the following debug statements (with my explanation added in square brackets):

APM: EAX=00005300 [53 is the int 15h identifier for APM checked for in rombios.c. 00 is the APM installation check function]
APM: EAX=00005301 [01 is the APM real mode interface connect]
APM: EAX=0000530e [0e appears to request APM driver version]
APM: EAX=00005300 [00, again, is the APM installation check - why is this called twice?]
APM: EAX=00005304 [04 is APM interface disconnect]

Then, while Windows 2000 boots and until shutdown is complete, I get no more debug statements. My question is, why not? I'm no APM expert but, judging from the 'apmbios.S' comments I might expect to see APM: EAX=00005303 [03 is APM 32 bit protected mode interface connect]. I could speculate that the return code from APM function 0e does not satisfy Windows 2000 for some reason, so it does another installation check and then disconnects the APM interface entirely - hence no APM functionality in Windows 2000.

If I get more time I may research the APM functions more fully. In the meantime, if anyone can suggest any alternative theories or how to test them, I'd be curious.

Quoted 8 lines

Struan

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Hi -

For anyone running Windows 2000 on Qemu, I've developed a fix that makes APM - and therefore Windows 2000 shutdown - correctly 'power off' (i.e. close) Qemu.

I needed to patch the BIOS - which didn't implement the APM 1.2 16-bit protected mode interface that Windows 2000 apparently requires.
...

What doesn't work yet is Standby and Suspend, although I've generalised

Quoted 5 lines

I needed to patch the BIOS - which didn't implement the APM 1.2 16-bit protected mode interface that Windows 2000 apparently requires.
...

What doesn't work yet is Standby and Suspend, although I've generalised

My network (using -user-net) stops working when I use your patched BIOS.

But it does close the window on shutdown!

Hi,

Quoted 9 lines

Quoted 5 lines

I needed to patch the BIOS - which didn't implement the APM 1.2 16-bit protected mode interface that Windows 2000 apparently requires.
...

What doesn't work yet is Standby and Suspend, although I've generalised

My network (using -user-net) stops working when I use your patched BIOS.

But it does close the window on shutdown!

I guess the patched rombios is based on a newer version from Bochs CVS. Qemu is still using the rombios of May 31, 2004 with some patches. In the meantime the PCI IRQ routing table has been modified and the PCI IRQ initialization has been added. Qemu needs a small patch to make it work again. I have already sent this patch to Fabrice Bellard and posted it here in the list, but nothing happened. I'd like to apply the APM patch to the official Bochs BIOS if you can confirm that it works. Here is the patch:

diff -urN /home/volker/qemu/hw/pci.c ./hw/pci.c

hw/pci.c renamed from home/volker/qemu/hw/pci.c +1 -2

@@ -494,7 +494,7 @@
 static inline int pci_slot_get_pirq(PCIDevice *pci_dev, int irq_num)
 {
     int slot_addend;
-    slot_addend = (pci_dev->devfn >> 3);
+    slot_addend = (pci_dev->devfn >> 3) - 1;
     return (irq_num + slot_addend) & 3;
 }
 
--

Bye

Volker

Hi Leonardo,

I have tried to install win2k from various CD's I have here around and I stumbled on one really weird thing..

Disk space issues. I have tried with 1GB, 2GB and 4GB virtual disks, and all of them seems to be quickly filled by the win2k installer and then the install fails..

Do you also have the same problem there at win4lin? or is it only happening with QEMU's internal IDE drive emulation? (since I recall that win4lin replaced the IDE driver with their own's one)..

Thanks,
Hetz

Yes, we did replace the IDE driver with our own implementation. But you can apply this patch that was posted long ago on the list that takes care of it on regular QEMU. It will slow things down a bit, so you may want to disable it, so you may want to optimize it or disable it after you get Windows 2000 installed, but it works. The issue seems to be the fact that the install-time Windows 2000 IDE driver doesn't like write operations generating an interrupt too quickly (i.e. before the "out" or DMA transfer returns). It doesn't seem to have this issue after the base OS is installed and booted however, but your experience may vary. Attached is the patch that we found on the list. It applies both to 0.6.1 and 0.6.2, albeit with some possible hunks.

Best regards,

Leo Reiter

Quoted 9 lines · Hetz Ben Hamo

Hi Leonardo,

I have tried to install win2k from various CD's I have here around and I stumbled on one really weird thing..

Disk space issues. I have tried with 1GB, 2GB and 4GB virtual disks, and all of them seems to be quickly filled by the win2k installer and then the install fails..

Quoted 6 lines

Do you also have the same problem there at win4lin? or is it only happening with QEMU's internal IDE drive emulation? (since I recall that win4lin replaced the IDE driver with their own's one)..

Thanks,
Hetz

--
Leonardo E. Reiter
Vice President of Engineering

Win4Lin, Inc.
Virtual Computing from Desktop to Data Center
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Thanks for the patch Leonardo...

Indeed, the patch seems to apply with some hunks (I suck at C programming :), and fails to buid with qemu with a compile error on the SPARC part of the emulation (Blue swirl, did you see the error?)

Does anyone else have a better solution other then patching and unpatching QEMU to install and use Windows 2000?

Thanks,
Hetz

Thanks for the patch Leonardo...

Indeed, the patch seems to apply with some hunks (I suck at C programming :), and fails to buid with qemu with a compile error on the SPARC part of the emulation (Blue swirl, did you see the error?)

Does anyone else have a better solution other then patching and unpatching QEMU to install and use Windows 2000?

Thanks,
Hetz

Yes, we did replace the IDE driver with our own implementation. But you can apply this patch that was posted long ago on the list that takes care of it on regular QEMU. It will slow things down a bit, so you may want to disable it, so you may want to optimize it or disable it after you get Windows 2000 installed, but it works. The issue seems to be the fact that the install-time Windows 2000 IDE driver doesn't like write operations generating an interrupt too quickly (i.e. before the "out" or DMA transfer returns). It doesn't seem to have this issue after the base OS is installed and booted however, but your experience may vary. Attached is the patch that we found on the list. It applies both to 0.6.1 and 0.6.2, albeit with some possible hunks.

Best regards,

Leo Reiter

Quoted 9 lines · Hetz Ben Hamo

Hi Leonardo,

I have tried to install win2k from various CD's I have here around and I stumbled on one really weird thing..

Disk space issues. I have tried with 1GB, 2GB and 4GB virtual disks, and all of them seems to be quickly filled by the win2k installer and then the install fails..

Quoted 6 lines

Do you also have the same problem there at win4lin? or is it only happening with QEMU's internal IDE drive emulation? (since I recall that win4lin replaced the IDE driver with their own's one)..

Thanks,
Hetz

------------------------------------------------------------------------

diff -rbu qemu.orig/hw/ide.c qemu/hw/ide.c

hw/ide.c +26 -0

@@ -332,8 +332,12 @@
     uint8_t *data_ptr;
     uint8_t *data_end;
     uint8_t io_buffer[MAX_MULT_SECTORS*512 + 4];
+    int ide_set_irq_from_timer;
 } IDEState;
 
+volatile int ide_set_irq_from_timer;
+static IDEState *IDEStates[4];
+
 #define BM_STATUS_DMAING 0x01
 #define BM_STATUS_ERROR  0x02
 #define BM_STATUS_INT    0x04

@@ -512,6 +516,21 @@
     }
 }
 
+void make_ide_set_irq(void)
+{
+	int i;
+	IDEState *s;
+
+	ide_set_irq_from_timer--;
+	for(i = 0; (s=IDEStates[i]) != NULL; i++) {
+		if(s->ide_set_irq_from_timer) {
+			s->ide_set_irq_from_timer--;
+			ide_set_irq(s);
+			break;
+		}
+	}
+}
+
 /* prepare data transfer and tell what to do after */
 static void ide_transfer_start(IDEState *s, uint8_t *buf, int size, 
                                EndTransferFunc *end_transfer_func)

@@ -667,7 +686,11 @@
         ide_transfer_start(s, s->io_buffer, 512 * n1, ide_sector_write);
     }
     ide_set_sector(s, sector_num + n);
+    if(s->ide_set_irq_from_timer) {
+	ide_set_irq_from_timer++;
+    } else {
     ide_set_irq(s);
+    }
 }
 
 static int ide_write_dma_cb(IDEState *s, 

@@ -1511,6 +1534,7 @@
             s->error = 0;
             s->status = SEEK_STAT | READY_STAT;
             s->req_nb_sectors = 1;
+	    s->ide_set_irq_from_timer = 1;
             ide_transfer_start(s, s->io_buffer, 512, ide_sector_write);
             break;
         case WIN_MULTREAD:

@@ -1528,6 +1552,7 @@
             n = s->nsector;
             if (n > s->req_nb_sectors)
                 n = s->req_nb_sectors;
+	    s->ide_set_irq_from_timer = 1;
             ide_transfer_start(s, s->io_buffer, 512 * n, ide_sector_write);
             break;
         case WIN_READDMA:

@@ -1883,6 +1908,7 @@
 
     for(i = 0; i < 2; i++) {
         s = ide_state + i;
+	IDEStates[drive_serial-1] = s;
         if (i == 0)
             s->bs = hd0;
         else

diff -rbu qemu.orig/vl.c qemu/vl.c

vl.c +6 -4

@@ -911,7 +911,7 @@
 
         /* timer signal */
         sigfillset(&act.sa_mask);
-        act.sa_flags = 0;
+	act.sa_flags = SA_RESTART;
 #if defined (TARGET_I386) && defined(USE_CODE_COPY)
         act.sa_flags |= SA_ONSTACK;
 #endif

@@ -2403,7 +2403,12 @@
     int n, max_size;
 #endif
     int ret;
+    /* ide.c hack */
+    extern volatile int ide_set_irq_from_timer;
+    extern void make_ide_set_irq(void);
 
+	if(ide_set_irq_from_timer)
+		make_ide_set_irq();
 #ifdef _WIN32
         if (timeout > 0)
             Sleep(timeout);

@@ -2449,8 +2454,6 @@
                             n = read(ioh->fd, buf, ioh->max_size);
                             if (n >= 0) {
                                 ioh->fd_read(ioh->opaque, buf, n);
-                            } else if (errno != EAGAIN) {
-                                ioh->fd_read(ioh->opaque, NULL, -errno);
                             }
                         }
                     }
 
 
------------------------------------------------------------------------

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

If other people confirm that this patch is solving the issue, I can try to improve it so that it is commitable.

Fabrice.

Please see this before committing:
http://lists.gnu.org/archive/html/qemu-devel/2004-12/msg00167.html
It specifically mentions that this hack is only good for installing win2k,

but it degrades performance, so after installing, the patch need to be removed..

d. Once you exit SP3 installation, copy the saved msgina.dll
from step b into both the c:\winnt\system32 and
c:\winnt\system32\dllcache directories. First you will have
to rename the existing msgina.dll's in those directories to
something else since they are in use. But be quick, because the System File Checker which is not easy to disable will restore them before you know it (after you rename them but
before you restore the saved version)

APM: EAX=00005300
APM: EAX=00005301
APM: EAX=0000530e
APM: EAX=00005300
APM: EAX=00005304
APM: EAX=00005302 [16-bit protected mode interface connect]
APM: EAX=0000530e

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Struan Bartlett
Sent: Wednesday, March 30, 2005 3:22 PM
To: [email protected]
Subject: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM

*This message was transferred with a trial version of CommuniGate(tm) Pro*

Quoted 1 line · Paul Brook

Quoted 1 line

This isn't working quite right for me with a Windows 98 guest --

Quoted 1 line

Quoted 1 line

traps the attempt to close the window all right, but it doesn't

Quoted 4 lines

Quoted 3 lines

the window close even when Window 98 has in fact shut down.

In theory windows should be able to "turn off" qemu using

APM, like it does on

Quoted 1 line

real machines. However there seem to be bugs in the qemu

implementation that

Quoted 3 lines

stop this working.

I thought I'd have a little look into why Windows 2000 doesn't turn off
qemu using APM properly. I enabled DEBUG_BIOS in hw/pc.c then downloaded
the latest Debian source for the Bochs bios v1.121 and defined DEBUG_ROMBIOS and DEBUG_APM both to be 1. I recompiled and installed the
bios and ran qemu to load up Windows 2000. What we get seems interesting. By the time Qemu boots Windows 2000 to its first progress-bar, it has printed the following debug statements (with my

explanation added in square brackets):

APM: EAX=00005300 [53 is the int 15h identifier for APM checked for in
rombios.c. 00 is the APM installation check function]
APM: EAX=00005301 [01 is the APM real mode interface connect]
APM: EAX=0000530e [0e appears to request APM driver version]
APM: EAX=00005300 [00, again, is the APM installation check - why is

this called twice?]
APM: EAX=00005304 [04 is APM interface disconnect]

Then, while Windows 2000 boots and until shutdown is complete, I get no
more debug statements. My question is, why not? I'm no APM expert but,
judging from the 'apmbios.S' comments I might expect to see APM:
EAX=00005303 [03 is APM 32 bit protected mode interface connect]. I could speculate that the return code from APM function 0e does not satisfy Windows 2000 for some reason, so it does another

check and then disconnects the APM interface entirely - hence no APM

functionality in Windows 2000.

If I get more time I may research the APM functions more fully. In the
meantime, if anyone can suggest any alternative theories or how to test
them, I'd be curious.

Struan

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

My Windows XP guests are also unable to power off QEMU. As I know, there is the posibillity to install W2K or XP without ACPI support. Has anyone tried that ? Could it be, that the default installation of Windows with ACPI disable the APM support ? My brain is remembering something... Win98 guest closes QEMU fine.

Andreas

Quoted 11 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Struan Bartlett
Sent: Wednesday, March 30, 2005 3:22 PM
To: [email protected]
Subject: APM bug Re: [Qemu-devel] Re: Suggestion - trap window-close of VM

Quoted 5 lines

*This message was transferred with a trial version of CommuniGate(tm) Pro*

Quoted 1 line · Paul Brook

Quoted 1 line

This isn't working quite right for me with a Windows 98 guest --

it

Quoted 1 line

Quoted 1 line

Quoted 1 line

traps the attempt to close the window all right, but it doesn't

let

Quoted 35 lines

Quoted 3 lines

Quoted 1 line

the window close even when Window 98 has in fact shut down.

In theory windows should be able to "turn off" qemu using

APM, like it does on

Quoted 1 line

real machines. However there seem to be bugs in the qemu

implementation that

Quoted 1 line

stop this working.

I thought I'd have a little look into why Windows 2000 doesn't turn off
qemu using APM properly. I enabled DEBUG_BIOS in hw/pc.c then downloaded
the latest Debian source for the Bochs bios v1.121 and defined DEBUG_ROMBIOS and DEBUG_APM both to be 1. I recompiled and installed the
bios and ran qemu to load up Windows 2000. What we get seems interesting. By the time Qemu boots Windows 2000 to its first progress-bar, it has printed the following debug statements (with my

explanation added in square brackets):

APM: EAX=00005300 [53 is the int 15h identifier for APM checked for in
rombios.c. 00 is the APM installation check function]
APM: EAX=00005301 [01 is the APM real mode interface connect]
APM: EAX=0000530e [0e appears to request APM driver version]
APM: EAX=00005300 [00, again, is the APM installation check - why is

this called twice?]
APM: EAX=00005304 [04 is APM interface disconnect]

Quoted 8 lines

Then, while Windows 2000 boots and until shutdown is complete, I get no
more debug statements. My question is, why not? I'm no APM expert but,
judging from the 'apmbios.S' comments I might expect to see APM:
EAX=00005303 [03 is APM 32 bit protected mode interface connect]. I could speculate that the return code from APM function 0e does not satisfy Windows 2000 for some reason, so it does another

installation

Quoted 10 lines

check and then disconnects the APM interface entirely - hence no APM

functionality in Windows 2000.

If I get more time I may research the APM functions more fully. In the
meantime, if anyone can suggest any alternative theories or how to test
them, I'd be curious.

Quoted 8 lines

Struan

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

Quoted 28 lines · Struan Bartlett

Quoted 19 lines · Ryan Rempel

On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote

Quoted 11 lines · Richard Neill

Quoted 5 lines

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).

Quoted 7 lines

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).

Quoted 10 lines

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
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

------------------------------------------------------------------------

vl.c +63 -1

@@ -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
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

This looks great -- thanks!

I suppose one other option that would be kind of neat is if closing Qemu could somehow signal the Windows 2000 guest to shut down. Someone had suggested that earlier in the thread, but it sounded like that would require ACPI support in Qemu? Or is it something that could be generated through APM? Since Qemu is (in effect) the hardware, I guess the question is whether it's possible for the hardware to tell Windows 2000 to shut down?

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

I guess
the question is whether it's possible for the hardware to tell Windows 2000 to shut down?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 5 lines

I guess
the question is whether it's possible for the hardware to tell Windows 2000 to shut down?

The answer is YES FOR SURE.
If you press the power button the system cleanly shut down.

The question is: which is the event generated by the power button that triggers the shut down?

- --
Flavio Visentin

|                     \|||/
|                    @/0.0\@
|                     \ - /
+------------------oOOo---oOOo------------------

There are only 10 types of people in this world:
those who understand binary, and those who don't.

GPG Key: http://www.zipman.it/gpgkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCf+/4usUmHkh1cnoRAoXBAJ4/9YhZXS1nwUUCek4LWi4DLnpGQACeJU1P rVz+muvcSXoVfHpUCm/e1L4=
=aYOu
-----END PGP SIGNATURE-----

_______________________________________________
Qemu-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

Quoted 93 lines · Struan Bartlett

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

Quoted 36 lines · Struan Bartlett

Quoted 21 lines · Ryan Rempel

On Mon, Nov 29, 2004 at 21:46:54 +0100, Lennert Buytenhek wrote

Quoted 13 lines · Richard Neill

Quoted 7 lines

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).

Quoted 7 lines

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.

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).

Quoted 6 lines

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).

Doesn't X allow a handler to be called for events like window closing? You could use this to pop up a "You've asked to close this VM. Kill, save or cancel?" message and allow the user to choose the appropriate option.