[Qemu-devel] [PATCH] Fix a race condition and non-leaf images growing in VMDK chains.
Hi,
In this patch I fixed two issues:
1. A race condition during write operations on snapshots.
Now we write the grain of data first and the L2 metadata after.
So, the snapshot will stay correct if the VM will be destroyed in the
middle of the write.
2. Non-leaf images growing during writes.
Assume we have snapshots chain (Base-Snap1-Snap2-...-Leaf) and we
run a VM with the latest image of this chain (leaf image).
We have a problem with non-leaf images growing in the snapshot-chain
(most noticeable when the VM performs aggressive writes).
It's an incorrect behavior according to VMDK spec.
For every write operation into an unknown offset, the active image
must query its ancestors for this offset, and if exists in any of them perform
a read-from-ancestor/modify/write-to-active the whole grain of that offset.
The problem happened upon read-from-ancestor/modify/write-to-active
where the ancestor was 2 or more generations above the active (leaf)image
(not a direct parent), as its direct child was modified.
Fixed by always write to the 'active' (leaf) image.
Regards,
Igor Lvovsky
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Fabrice Bellard
Sent: Tuesday, January 16, 2007 9:36 PM
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Race condition in VMDK (QCOW*) formats.
Well, it was never said that the QCOW* code was safe if you interrupted
QEMU at some point.
But I agree that it could be safer to write the sector first and update
the links after. It could be interesting to analyze the QCOW2 snapshots
handling too (what if QEMU is stopped during the creation of a snapshot ?).
Regards,
Fabrice.
Igor Lvovsky wrote:
Hi all,
I have doubt about the race condition during the *write operation on
snapshot*.
I think the problem exists in VMDK and QCOW* formats (I didn't checked
the others).
The example from the block_vmdk.c.
static int vmdk_write(BlockDriverState *bs, int64_t sector_num,
const uint8_t *buf, int nb_sectors)
{
BDRVVmdkState *s = bs-opaque;
int ret, index_in_cluster, n;
uint64_t cluster_offset;
while (nb_sectors 0) {
index_in_cluster = sector_num (s-cluster_sectors - 1);
n = s-cluster_sectors - index_in_cluster;
if (n nb_sectors)
n = nb_sectors;
cluster_offset = get_cluster_offset(bs, sector_num 9, 1);
if (!cluster_offset)
return -1;
lseek(s-fd, cluster_offset + index_in_cluster * 512, SEEK_SET);
ret = write(s-fd, buf, n * 512);
if (ret != n * 512)
return -1;
nb_sectors -= n;
sector_num += n;
buf += n * 512;
}
return 0;
}
The /get_cluster_offset(…)/ routine update the L2 table of the metadata
and return the /cluster_offset. /
After that the /vmdk_write(…)/ routine/ /actually write the grain at
right place.
So, we have timing hole here.
Assume, VM that perform write operation will be destroyed at this moment.
So, we have corrupted image (with updated L2 table, but without the
grain itself).
Regards,
Igor Lvovsky
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
block-vmdk.diff
Description: block-vmdk.diff
[Qemu-devel] qemu/target-mips cpu.h exec.h helper.c mips-def...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 13:49:44 Modified files: target-mips: cpu.h exec.h helper.c mips-defs.h op.c op_helper.c translate.c translate_init.c Log message: MIPS TLB style selection at runtime, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.31r2=1.32 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/exec.h?cvsroot=qemur1=1.25r2=1.26 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.37r2=1.38 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/mips-defs.h?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.49r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.42r2=1.43 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.75r2=1.76 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemur1=1.8r2=1.9
[Qemu-devel] qemu/hw vga.c vga_int.h vmware_vga.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Andrzej Zaborowski balrog 07/05/13 13:26:49 Modified files: hw : vga.c vga_int.h vmware_vga.c Log message: Allow VMware-SVGA operation enable before command FIFO is configured. Implement screendump for 32 bit colour depth. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vga.c?cvsroot=qemur1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vga_int.h?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/vmware_vga.c?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] qemu linux-user/elfload.c linux-user/main.c lin...
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 13:58:00 Modified files: linux-user : elfload.c main.c signal.c syscall.c linux-user/mips: syscall_nr.h target-mips: cpu.h Log message: MIPS linux-user update. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.40r2=1.41 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.108r2=1.109 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.36r2=1.37 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.101r2=1.102 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mips/syscall_nr.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/cpu.h?cvsroot=qemur1=1.32r2=1.33
Re: [Qemu-devel] [PATCH] MIPS: support MMU selection at runtime
Hervé Poussineau wrote: Hi, The attached patch removes the MIPS_USES_R4K_TLB define, and replaces it by some function pointers in the env structure. The model can be extended to support another TLB types quite easily (see translate_init.c) I expanded it to handle the fixed mapping MMU properly, and to keep the userland emulation working. Thiemo
Re: [Qemu-devel] [PATCH] VMware SVGA II emulation
Hi, On 03/05/07, James Pellow [EMAIL PROTECTED] wrote: Hi Andrew and others working on vmware hardware, I noticed the small patch made recently to the vmwarevga hardware in qemu, so I decided to test it again. Here is what I am getting on my tests: Host:Kubuntu 7.04 Qemu: CVS from May third. Guest: Windows 2000 Driver: From VMware 5.5.3 build 34685 CPU: Opteron 165 dual core. Guest Memory: 256M Host Memory: 1G KQemu: No [EMAIL PROTECTED]:~/qemu$ qemu -hda win2k.raw -cdrom windows.iso -boot c -m 256 -vmwarevga Could not open '/dev/kqemu' - QEMU acceleration layer not activated: No such file or directory vmsvga_value_write: guest runs Windows 2000. vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e vmmouse: unknown command 1e The initial portion of the boot (text mode bars advancing at the bottom of the screen) works perfectly, then when it switches to graphics mode (Win2k splash screen with small progress bar below) I actually see the progress bar, but only the blue channel and it is disproportionately large. Once the progress bar completes and windows 2k kernel is fully booted, I get small vertical blue bars covering the entire screen (see screenshot). It appears like qemu is no longer responding to paint messages from the window manager because it will not repaint, again as you can see from the screenshot. I'm happy to gather any additional information that may be helpful, and to look at the code if you point me in the right direction. I imagine the best documentation is the source code for the vmware X drivers. I digged out an old Windows Server 2003 (Enterprise Edition) install and played with it a bit. As soon as I booted it with -vmwarevga it autodetected the VMware SVGA II graphics adapter and installed a microsoft-certified-signed-blessed driver which (surprisingly) came with Windows - so I haven't tested with VMware Tools and their driver at all. It turned out the windows driver initialises the card in kindof the opposite order to Xorg driver, which I thought was illegal by my reading of the specs but apparently I misinterpreted this part. After de-illegalising it, Windows immediately started displaying correctly and I didn't see any other breakage except red and green components being exchanged in 24/32 bit modes (I only test 16bpp before). I was especially surprised that this driver didn't use any undocumented commands - only the same subset that the Xorg driver used. In the display properties dialog it reports only the colour depth that the host is using and all the standard screen resolutions plus the maximum resolution allowed by the hardware - so if you needed to use a non-standard resolution, like 2560x1770 that you mentioned, you'll have to edit the lines #define SVGA_MAX_WIDTH 2360 #define SVGA_MAX_HEIGHT 1770 in hw/vmware_vga.c because we don't have SDL window resizing at the moment (I'm wondering if the windows video driver manages that part - if so we could easily add it with Anthony Liguori's sdl.c hacks and the web page that had all of the VMware special io ports reverse engineered). Also make sure the video ram size (vl.h line 903) is enough to hold the framebuffer in given bit depth - if you don't do that, windows will go blue screen when you change the resolution. Windows didn't use the hardware mouse cursor but it did use hardware rectangle filling and copying. It seems the svga driver also probed for vmmouse for some reason (but using an undocumented command) - would be nice to get this working too. Here's a screenshot of Microsoft Windows 2003 running at 6400x4800x32bits with all of the bling enabled: http://www.numenor.art.pl/balrog/screen-qemu-vmsvga-windows.jpeg (hard to see the bling because of compression) I couldn't get it to display non-tiled desktop background - apparently it was running out of memory during the scaling and displayed all black background. It worked at 4000x3000 though. Cheers, Andrzej
[Qemu-devel] qemu/target-mips helper.c op.c op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 14:07:26 Modified files: target-mips: helper.c op.c op_helper.c Log message: MMU code improvements, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.38r2=1.39 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.43r2=1.44
Re: [Qemu-devel] [MIPS][PATCH] Fix mfc0 and dmtc0 instructions on MIPS64
Aurelien Jarno wrote: Hi all, The patch below fixes the mfc0 and dmtc0 instructions for the MIPS64 target: - The mfc0 instruction should return the 32 lowest bits of the coprocessor 0 register sign extended to 64-bit. Agreed, and I think it doess already. (The places where you added casts read fron 32bit wide registers anyway.) - The mtc0 instruction should do the same as the dmtc0 instruction for 64-bit coprocessor registers instead of copying only the low 32 bits. I'm not entirely sure about this, but it feels wrong, as mtc0 should have the same behaviour as on 32bit CPUs. What prompted the change here? - The XContest register does not exists on MIPS32 CPU. Indeed, but simply not wiring up the instruction decoding for 32bit should be good enough, no need to #ifdef everything. Thiemo
[Qemu-devel] qemu/target-mips translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 14:42:19 Modified files: target-mips: translate.c Log message: Don't decode CP0 XContext on 32bit MIPS. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.76r2=1.77
[Qemu-devel] qemu vl.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 14:54:54 Modified files: . : vl.c Log message: Windows: redirect serial port to console, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.294r2=1.295
Re: [Qemu-devel] [MIPS][PATCH] Fix mfc0 and dmtc0 instructions on MIPS64
Thiemo Seufer a écrit : Aurelien Jarno wrote: Hi all, The patch below fixes the mfc0 and dmtc0 instructions for the MIPS64 target: - The mfc0 instruction should return the 32 lowest bits of the coprocessor 0 register sign extended to 64-bit. Agreed, and I think it doess already. (The places where you added casts read fron 32bit wide registers anyway.) Oops, I haven't seen before that those registers were declared as int32_t, so that the sign extension is already done. Forget that part. - The mtc0 instruction should do the same as the dmtc0 instruction for 64-bit coprocessor registers instead of copying only the low 32 bits. I'm not entirely sure about this, but it feels wrong, as mtc0 should have the same behaviour as on 32bit CPUs. What prompted the change here? The MIPS64 ISA manual: Operation: data GPR[rt] if (Width(CPR[0,rd,sel]) = 64) then CPR[0,rd,sel] data else CPR[0,rd,sel] data31..0 endif But it is also need if you need to run a 32-bit kernel on MIPS64. For example the EntryHi register is a 64-bit register, and the higher 32 bits (and most notably the R part of this register) has to be filled. This part is initialised when an exception occurs, so even if a 32-bit kernel don't know about it, it already holds the correct values. - The XContest register does not exists on MIPS32 CPU. Indeed, but simply not wiring up the instruction decoding for 32bit should be good enough, no need to #ifdef everything. Ok. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] qemu/target-mips op.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 15:29:26 Modified files: target-mips: op.c Log message: Delete misleading comment. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.51r2=1.52
Re: [Qemu-devel] I2C/SMBus framework
Paul Brook wrote: The attached patch implements an I2C/SMBus framework for qemu. It provides an API for connecting emulated I2C devices, and implements SMBus as a layer on top of that. Currently the only i2c device in CVS is the piix eeprom. I've tested this as much as I can - linux successfully reads the eeprom contents. I've also used the same framework for several different boards. I will apply in a day or so if there are no serious objections. Minor niggle, a new compiler warning: /home/ths/qemu/qemu-work/hw/acpi.c: In function smb_ioport_writeb': /home/ths/qemu/qemu-work/hw/acpi.c:283: warning: 'val' might be used uninitialized in this function aside from that it works well for me. Thiemo
[Qemu-devel] qemu/target-sh4 translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 16:33:44 Modified files: target-sh4 : translate.c Log message: Fix XHACK() macro and use FREG if possible, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemur1=1.8r2=1.9
[Qemu-devel] qemu/target-sh4 op.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 16:35:36 Modified files: target-sh4 : op.c Log message: Remove unnecessary pointer magic in shift operations, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemur1=1.4r2=1.5
[Qemu-devel] qemu gdbstub.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 16:36:25 Modified files: . : gdbstub.c Log message: Add fpu register support to the gdb code, by Magnus Damm. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/gdbstub.c?cvsroot=qemur1=1.54r2=1.55
Re: [Qemu-devel] sh4: further updates
Magnus Damm wrote: Hi everyone, Here comes the second batch of patches for the user space emulator. Below is a one line summary of each patch, please have a look in the patch header for details: - Fix XHACK() macro and use FREG if possible - Emulate more fpu opcodes - Document FPSCR usage - Use DREG() over XREG() if possible - Remove unnecessary pointer magic in shift operations - Add fpu register support to the gdb code If you have any questions or comments, please don't hesitate to contact me! The sh4-fpu-new patch fails to build (on ppc/Linux) with: gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/home/ths/qemu/qemu-write/target-sh4 -I/home/ths/qemu/qemu-write -D__powerpc__ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/home/ths/qemu/qemu-write/fpu -I/home/ths/qemu/qemu-write/slirp-c -o translate-op.o /home/ths/qemu/qemu-write/translate-op.c In file included from /home/ths/qemu/qemu-write/translate-op.c:36: ./op.h: In function `dyngen_code': ./op.h:1220: error: syntax error before ')' token ./op.h:1221: error: syntax error before ')' token make[1]: *** [translate-op.o] Error 1 make[1]: Leaving directory `/home/ths/qemu/qemu-write/sh4-softmmu' make: *** [subdir-sh4-softmmu] Error 2 Thiemo
Re: [Qemu-devel] [MIPS][PATCH] Fix mfc0 and dmtc0 instructions on MIPS64
On Sun, May 13, 2007 at 04:57:42PM +0200, Aurelien Jarno wrote:
Thiemo Seufer a écrit :
Aurelien Jarno wrote:
Hi all,
The patch below fixes the mfc0 and dmtc0 instructions for the
MIPS64 target:
- The mfc0 instruction should return the 32 lowest bits of the
coprocessor 0 register sign extended to 64-bit.
Agreed, and I think it doess already. (The places where you added
casts read fron 32bit wide registers anyway.)
Oops, I haven't seen before that those registers were declared as
int32_t, so that the sign extension is already done.
Forget that part.
- The mtc0 instruction should do the same as the dmtc0 instruction for
64-bit coprocessor registers instead of copying only the low 32 bits.
I'm not entirely sure about this, but it feels wrong, as mtc0 should
have the same behaviour as on 32bit CPUs. What prompted the change here?
The MIPS64 ISA manual:
Operation:
data GPR[rt]
if (Width(CPR[0,rd,sel]) = 64) then
CPR[0,rd,sel] data
else
CPR[0,rd,sel] data31..0
endif
But it is also need if you need to run a 32-bit kernel on MIPS64. For
example the EntryHi register is a 64-bit register, and the higher 32
bits (and most notably the R part of this register) has to be filled.
This part is initialised when an exception occurs, so even if a 32-bit
kernel don't know about it, it already holds the correct values.
- The XContest register does not exists on MIPS32 CPU.
Indeed, but simply not wiring up the instruction decoding for 32bit
should be good enough, no need to #ifdef everything.
Please find below an updated patch against the current CVS that take
into account the remarks you made.
Bye,
Aurelien
Index: op.c
===
RCS file: /sources/qemu/qemu/target-mips/op.c,v
retrieving revision 1.51
diff -u -d -p -r1.51 op.c
--- op.c13 May 2007 14:07:26 - 1.51
+++ op.c13 May 2007 16:44:43 -
@@ -1262,7 +1262,7 @@ void op_mtc0_entrylo0 (void)
{
/* Large physaddr not implemented */
/* 1k pages not implemented */
-env-CP0_EntryLo0 = (int32_t)T0 0x3FFF;
+env-CP0_EntryLo0 = T0 0x3FFF;
RETURN();
}
@@ -1270,7 +1270,7 @@ void op_mtc0_entrylo1 (void)
{
/* Large physaddr not implemented */
/* 1k pages not implemented */
-env-CP0_EntryLo1 = (int32_t)T0 0x3FFF;
+env-CP0_EntryLo1 = T0 0x3FFF;
RETURN();
}
@@ -1340,9 +1340,9 @@ void op_mtc0_status (void)
uint32_t val, old;
uint32_t mask = env-Status_rw_bitmask;
-/* No reverse endianness, no MDMX/DSP, no 64bit ops,
- no 64bit addressing implemented. */
-val = (int32_t)T0 mask;
+/* No reverse endianness, no MDMX/DSP, no 64bit ops
+ implemented. */
+val = T0 mask;
old = env-CP0_Status;
if (!(val (1 CP0St_EXL))
!(val (1 CP0St_ERL))
@@ -1397,7 +1397,7 @@ void op_mtc0_cause (void)
void op_mtc0_epc (void)
{
-env-CP0_EPC = (int32_t)T0;
+env-CP0_EPC = T0;
RETURN();
}
@@ -1426,7 +1426,7 @@ void op_mtc0_watchlo0 (void)
{
/* Watch exceptions for instructions, data loads, data stores
not implemented. */
-env-CP0_WatchLo = (int32_t)(T0 ~0x7);
+env-CP0_WatchLo = (T0 ~0x7);
RETURN();
}
@@ -1455,7 +1455,7 @@ void op_mtc0_debug (void)
void op_mtc0_depc (void)
{
-env-CP0_DEPC = (int32_t)T0;
+env-CP0_DEPC = T0;
RETURN();
}
@@ -1491,7 +1491,7 @@ void op_mtc0_datahi (void)
void op_mtc0_errorepc (void)
{
-env-CP0_ErrorEPC = (int32_t)T0;
+env-CP0_ErrorEPC = T0;
RETURN();
}
@@ -1502,6 +1502,12 @@ void op_mtc0_desave (void)
}
#ifdef TARGET_MIPS64
+void op_mtc0_xcontext (void)
+{
+env-CP0_XContext = (env-CP0_XContext 0x1) | (T0
~0x1);
+RETURN();
+}
+
void op_dmfc0_entrylo0 (void)
{
T0 = env-CP0_EntryLo0;
@@ -1567,60 +1573,6 @@ void op_dmfc0_errorepc (void)
T0 = env-CP0_ErrorEPC;
RETURN();
}
-
-void op_dmtc0_entrylo0 (void)
-{
-/* Large physaddr not implemented */
-/* 1k pages not implemented */
-env-CP0_EntryLo0 = T0 0x3FFF;
-RETURN();
-}
-
-void op_dmtc0_entrylo1 (void)
-{
-/* Large physaddr not implemented */
-/* 1k pages not implemented */
-env-CP0_EntryLo1 = T0 0x3FFF;
-RETURN();
-}
-
-void op_dmtc0_context (void)
-{
-env-CP0_Context = (env-CP0_Context 0x007F) | (T0 ~0x007F);
-RETURN();
-}
-
-void op_dmtc0_epc (void)
-{
-env-CP0_EPC = T0;
-RETURN();
-}
-
-void op_dmtc0_watchlo0 (void)
-{
-/* Watch exceptions for instructions, data loads, data stores
- not implemented. */
-env-CP0_WatchLo = T0 ~0x7;
-RETURN();
-}
-
-void op_dmtc0_xcontext (void)
-{
-env-CP0_XContext = (env-CP0_XContext 0x) | (T0 ~0x);
-RETURN();
-}
-
-void op_dmtc0_depc (void)
-{
-env-CP0_DEPC = T0;
-RETURN();
-}
-
-void op_dmtc0_errorepc (void)
[Qemu-devel] qemu configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 18:02:43 Modified files: . : configure Log message: Support OSS on solaris, by Ben Taylor. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.142r2=1.143
[Qemu-devel] qemu/target-mips op.c translate.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 18:39:10 Modified files: target-mips: op.c translate.c Log message: Fix mfc0 and dmtc0 instructions on MIPS64, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.52r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.77r2=1.78
[Qemu-devel] qemu/target-mips helper.c op.c op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/05/13 19:22:13 Modified files: target-mips: helper.c op.c op_helper.c Log message: Full MIPS64 MMU implementation, by Aurelien Jarno. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/helper.c?cvsroot=qemur1=1.39r2=1.40 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.53r2=1.54 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op_helper.c?cvsroot=qemur1=1.44r2=1.45
Re: [Qemu-devel] Triple-fault causes abort(), which doesn't end pointer grabs
On 5/8/07, Paul Brook [EMAIL PROTECTED] wrote: On Monday 07 May 2007, Samuel Bronson wrote: So, if the guest system has a triple-fault, and I had had my mouse grabbed, it stays grabbed, so that X has to be restarted (as far as I know). This happens because abort() doesn't run functions registered with atexit(). Suggest use of exit() instead. Sounds like an X server bug to me. Possibly. Certainly it is not a desirable behaviour. But atexit() handlers are there for a reason... It might also be an SDL bug. actually. Sorry I took so long to reply.
