Re: [Qemu-devel] Page protection and i386 cmpxchg8b
On 23 févr. 07, at 23:56, Ilya Shar wrote: Sure. At first I was hitting unsupported mach syscalls, so I modified darwin-user/syscall.h according to /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/mach/syscall_sw.h : $ diff syscall.c syscall.c.orig 458,465d457 case -33: DPRINTF(semaphore_signal_trap(0x%x)\n, arg1); ret = semaphore_signal_trap(arg1); break; case -34: DPRINTF(semaphore_signal_all_trap(0x%x)\n, arg1); ret = semaphore_signal_all_trap(arg1); break; 471,474d462 case -37: DPRINTF(semaphore_wait_signal_trap(0x%x, 0x%x)\n, arg1, arg2); ret = semaphore_wait_signal_trap(arg1,arg2); break; cvs diff -u would be easier to read for me. (or diff -u). You could send this patch to the qemu-devel, that would be cool. With this Sfari went past the unsupported call -33 and now stops in call -61 (syscall_thread_switch). Can I just modify syscalls.c in a similar way to fix it? Yes you can! But a really alarming thing happens before it gets there. If my ethernet cable is not plugged in, cmpxchg8b write to a nonwritable page brings my system down. I suppose it happens in somewhere in the drivers. Ouch! I have noticed the same: qemu can trigger bugs really easily at the kernel level :( Could you explain how you know that cmpxchg8b is the key to our problem? Also qemu signal handlers might be overridden by some mach calls, that could explain the problem you are encountering. We need to work on this. Pierre. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Make removing IOHandlers safe from within an IOHandler
I was getting random SEGVs when disconnecting from the VNC server. I
tracked it down to the fact that if you remove a IOHandler from another
IOHandler, all sorts of badness may result as you're removing entries
from a linked list while transversing it.
My solution is to simply add a deleted flag to each entry and walk the
list a second time. During the second transversal, we'll remove nodes
that need removing.
Haven't seen the SEGV since I started using this patch.
Regards,
Anthony Liguori
diff -r 5f92961f382b vl.c
--- a/vl.c Thu Feb 22 01:48:01 2007 +
+++ b/vl.c Sat Feb 24 11:51:00 2007 -0600
@@ -4462,6 +4462,7 @@ typedef struct IOHandlerRecord {
IOCanRWHandler *fd_read_poll;
IOHandler *fd_read;
IOHandler *fd_write;
+int deleted;
void *opaque;
/* temporary data */
struct pollfd *ufd;
@@ -4487,8 +4488,7 @@ int qemu_set_fd_handler2(int fd,
if (ioh == NULL)
break;
if (ioh-fd == fd) {
-*pioh = ioh-next;
-qemu_free(ioh);
+ ioh-deleted = 1;
break;
}
pioh = ioh-next;
@@ -6157,7 +6157,7 @@ void qemu_system_powerdown_request(void)
void main_loop_wait(int timeout)
{
-IOHandlerRecord *ioh, *ioh_next;
+IOHandlerRecord *ioh;
fd_set rfds, wfds, xfds;
int ret, nfds;
struct timeval tv;
@@ -6192,6 +6192,8 @@ void main_loop_wait(int timeout)
FD_ZERO(wfds);
FD_ZERO(xfds);
for(ioh = first_io_handler; ioh != NULL; ioh = ioh-next) {
+ if (ioh-deleted)
+ continue;
if (ioh-fd_read
(!ioh-fd_read_poll ||
ioh-fd_read_poll(ioh-opaque) != 0)) {
@@ -6219,9 +6221,11 @@ void main_loop_wait(int timeout)
#endif
ret = select(nfds + 1, rfds, wfds, xfds, tv);
if (ret 0) {
-/* XXX: better handling of removal */
-for(ioh = first_io_handler; ioh != NULL; ioh = ioh_next) {
-ioh_next = ioh-next;
+ IOHandlerRecord **pioh;
+
+for(ioh = first_io_handler; ioh != NULL; ioh = ioh-next) {
+ if (ioh-deleted)
+ continue;
if (FD_ISSET(ioh-fd, rfds)) {
ioh-fd_read(ioh-opaque);
}
@@ -6229,6 +6233,17 @@ void main_loop_wait(int timeout)
ioh-fd_write(ioh-opaque);
}
}
+
+ /* remove deleted IO handlers */
+ pioh = first_io_handler;
+ while (*pioh) {
+ ioh = *pioh;
+ if (ioh-deleted) {
+ *pioh = ioh-next;
+ qemu_free(ioh);
+ } else
+ pioh = ioh-next;
+ }
}
#if defined(CONFIG_SLIRP)
if (slirp_inited) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Make removing IOHandlers safe from within an IOHandler
On Sat, Feb 24, 2007 at 11:54:17AM -0600, Anthony Liguori wrote: I was getting random SEGVs when disconnecting from the VNC server. I tracked it down to the fact that if you remove a IOHandler from another IOHandler, all sorts of badness may result as you're removing entries from a linked list while transversing it. My solution is to simply add a deleted flag to each entry and walk the list a second time. During the second transversal, we'll remove nodes that need removing. Haven't seen the SEGV since I started using this patch. That's pretty much identical solution to the one I just posted along with the patches for VNC TLS support, so I can also confirm this approach works solves the SEGV issue. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: Secure TLS encrypted authentication for VNC
On Sat, Feb 24, 2007 at 06:57:16PM +, Luke-Jr wrote: On Saturday 24 February 2007 04:54:44 pm Daniel P. Berrange wrote: Having repeatedly said that we should be doing TLS encryption for VNC, I figured I ought to get down implement it. So, in the spirit of 'release early, release often', here is the very first cut of my patch for QEMU. This isn't suitable for inclusion in CVS yet - I just want to put it out for people to see / experiment with. Do any Java applets support this? Preferably with an applet 'param' for a private key authentication? I've not tested it, but the VeNCrypt project have also patched the RealVNC java client to support the TLS auth extensions. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH][UPDATE] Make removing IOHandlers safe from within an IOHandler
Daniel P. Berrange wrote:
On Sat, Feb 24, 2007 at 11:54:17AM -0600, Anthony Liguori wrote:
I was getting random SEGVs when disconnecting from the VNC server. I
tracked it down to the fact that if you remove a IOHandler from another
IOHandler, all sorts of badness may result as you're removing entries
from a linked list while transversing it.
My solution is to simply add a deleted flag to each entry and walk the
list a second time. During the second transversal, we'll remove nodes
that need removing.
Haven't seen the SEGV since I started using this patch.
That's pretty much identical solution to the one I just posted along with
the patches for VNC TLS support, so I can also confirm this approach works
solves the SEGV issue.
Except I was missing one thing that you're patch had. I didn't reset
deleted when a new handler was deleted and added again from the same
callback. Attached patch addresses that.
Regards,
Anthony Liguori
Regards,
Dan.
diff -r 5f92961f382b vl.c
--- a/vl.c Thu Feb 22 01:48:01 2007 +
+++ b/vl.c Sat Feb 24 13:05:14 2007 -0600
@@ -4462,6 +4462,7 @@ typedef struct IOHandlerRecord {
IOCanRWHandler *fd_read_poll;
IOHandler *fd_read;
IOHandler *fd_write;
+int deleted;
void *opaque;
/* temporary data */
struct pollfd *ufd;
@@ -4487,8 +4488,7 @@ int qemu_set_fd_handler2(int fd,
if (ioh == NULL)
break;
if (ioh-fd == fd) {
-*pioh = ioh-next;
-qemu_free(ioh);
+ ioh-deleted = 1;
break;
}
pioh = ioh-next;
@@ -4509,6 +4509,7 @@ int qemu_set_fd_handler2(int fd,
ioh-fd_read = fd_read;
ioh-fd_write = fd_write;
ioh-opaque = opaque;
+ ioh-deleted = 0;
}
return 0;
}
@@ -6157,7 +6158,7 @@ void qemu_system_powerdown_request(void)
void main_loop_wait(int timeout)
{
-IOHandlerRecord *ioh, *ioh_next;
+IOHandlerRecord *ioh;
fd_set rfds, wfds, xfds;
int ret, nfds;
struct timeval tv;
@@ -6192,6 +6193,8 @@ void main_loop_wait(int timeout)
FD_ZERO(wfds);
FD_ZERO(xfds);
for(ioh = first_io_handler; ioh != NULL; ioh = ioh-next) {
+ if (ioh-deleted)
+ continue;
if (ioh-fd_read
(!ioh-fd_read_poll ||
ioh-fd_read_poll(ioh-opaque) != 0)) {
@@ -6219,9 +6222,11 @@ void main_loop_wait(int timeout)
#endif
ret = select(nfds + 1, rfds, wfds, xfds, tv);
if (ret 0) {
-/* XXX: better handling of removal */
-for(ioh = first_io_handler; ioh != NULL; ioh = ioh_next) {
-ioh_next = ioh-next;
+ IOHandlerRecord **pioh;
+
+for(ioh = first_io_handler; ioh != NULL; ioh = ioh-next) {
+ if (ioh-deleted)
+ continue;
if (FD_ISSET(ioh-fd, rfds)) {
ioh-fd_read(ioh-opaque);
}
@@ -6229,6 +6234,17 @@ void main_loop_wait(int timeout)
ioh-fd_write(ioh-opaque);
}
}
+
+ /* remove deleted IO handlers */
+ pioh = first_io_handler;
+ while (*pioh) {
+ ioh = *pioh;
+ if (ioh-deleted) {
+ *pioh = ioh-next;
+ qemu_free(ioh);
+ } else
+ pioh = ioh-next;
+ }
}
#if defined(CONFIG_SLIRP)
if (slirp_inited) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Hotplugging
Does anyone have plans to add more hotplugging support to qemu? For example, PCI hotplug (for video and network) and/or memory hotplug? Perhaps even disk hotplugging for more than just CD-ROMs? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] FreeBSD Support
MAP_PRIVATE|MAP_ANON also works on Solaris. In fact, Linux is the
only platform where it doesn't work due to a bug in the Linux kernel
as Fabrice mentions:
http://www.qemu.org/kqemu-tech.html#SEC7
Technically on Solaris, /tmp is probably the same thing as
MAP_PRIVATE|MAP_ANON since the filesystem is actually mapped to
virtual memory... however, it's much cleaner to not use a file if not
necessary. I can post a reworked patch that makes the file mapping
for the Linux case only if anyone's interested, but it's a pretty
simple change.
- Leo Reiter
On 2/24/07, Juergen Lock [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED] you write:
-=-=-=-=-=-
Ok FreeBSD Support round one..
Be gentle this is my first attempt at working with the rest of this
community..
Files it modifies and the reasons are as follows
configure - Adds HOST_FREEBSD type to alter included libraries FreeBSD does
not need -ltr
Makefile.target - Once again uses HOST_FREEBSD to avoid including -ltr
osdeps.c - FreeBSD does not have /dev/shm so it uses /tmp for kqemu_valloc
also sys/vfs.h is not part of freebsd stat information is part of
mount.h/param.h
...
Actually the port simply uses mmap MAP_PRIVATE|MAP_ANON, so no
tempfile is used at all (this is files/patch-osdep.c in the port):
Index: qemu/osdep.c
@@ -79,7 +79,9 @@
#if defined(USE_KQEMU)
+#ifndef __FreeBSD__
#include sys/vfs.h
+#endif
#include sys/mman.h
#include fcntl.h
@@ -90,6 +92,7 @@
const char *tmpdir;
char phys_ram_file[1024];
void *ptr;
+#ifndef __FreeBSD__
#ifdef HOST_SOLARIS
struct statvfs stfs;
#else
@@ -151,12 +154,20 @@
}
unlink(phys_ram_file);
}
+#endif
size = (size + 4095) ~4095;
+#ifndef __FreeBSD__
ftruncate(phys_ram_fd, phys_ram_size + size);
ptr = mmap(NULL,
size,
PROT_WRITE | PROT_READ, MAP_SHARED,
phys_ram_fd, phys_ram_size);
+#else
+ptr = mmap(NULL,
+ size,
+ PROT_WRITE | PROT_READ, MAP_PRIVATE|MAP_ANON,
+ -1, 0);
+#endif
if (ptr == MAP_FAILED) {
fprintf(stderr, Could not map physical memory\n);
exit(1);
___
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
Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: After shutting down the guest, I inspected its image files with qemu-info, which reported for hda image: nisaba.hda.qcow file format: raw virtual size: 4.3G (4596273152 bytes) disk size: 4.3G but hda was supposed to have a virtual size of approximately 20 GB, QCOW2 format and a saved snapshot... And now I got another corrupted image: This time, after installing some packages in a similar Debian guest, the system froze while shutting down (using 100% CPU on host). I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk, in a by then more than 4GB file) was no longer considered to be a QCOW2 image, as above. Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... Fortunately this time I have a backup copy of the virtual disk state just before it was corrupted. I'll try to see what happens if I convert it from qcow2 to qcow before proceeding. Any suggestions? Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... I have a copy of the disk image file as it was just before starting the qemu run which damaged it, and now I noticed that, during that qemu run, the image file size did not change: 4543348736 bytes. However, comparing both images with cmp -l shows extensive changes. Just an example, from the first bytes (byte number, original value, corrupted value): 1 121 0 2 106 0 3 111 0 4 373 0 8 2 0 24 14 0 28 5 0 39 50 0 47 20 0 52 1 0 55 20 0 60 2 0 1881 0 200 1887 0 40 1889 0 200 1895 0 100 9049 200 0 9054 1 0 9055 220 0 9057 200 0 9061 60 0 9062 115 0 9063 100 0 ... many more zeroed out... 49487 220 0 49569 200 0 49573 325 0 49574 357 0 49575 300 0 49665 0 147 49666 0 145 49667 0 55 49668 0 62 49669 0 56 49670 0 66 49671 0 56 49672 0 61 49673 0 70 49674 0 55 49675 0 63 49676 0 55 49677 0 153 ... many more un-zeroed ... 49853 0 40 49854 0 151 49855 0 163 49856 0 40 49857 200 141 49858 0 166 49859 0 141 49860 0 151 49861 46 154 49862 174 141 49863 140 142 49864 0 154 49865 0 145 ... many more un-zeroed ... 49983 0 142 49984 0 157 49985 200 157 49986 0 164 49987 0 40 49988 0 171 49989 15 157 49990 354 165 49991 200 162 49992 0 40 49993 200 155 49994 0 141 49995 0 143 49996 0 150 49997 16 151 49998 1 156 4 260 145 5 0 56 50001 0 12 50002 0 12 ... Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW image corruption under QEMU 0.9.0
J M Cerqueira Esteves wrote: This time, after installing some packages in a similar Debian guest, the [guest] system froze while shutting down (using 100% CPU on host). I then noticed that its supposed QCOW2 image file (a 20 GB virtual disk, in a by then more than 4GB file) was no longer considered to be a QCOW2 image, as above. Curiously this damaged image file has 4543348736 bytes. I wonder if there some new bug triggered by the image file size, for some size around 45 bytes... I took a copy of that qcow2 image file (made just before the 'fatal' qemu session), converted it to qcow, restarted qemu using this qcow version, reinstalled the additional Debian packages I had installed during the corrupting session (and more), even rebooted with a Debian pre-built 2.6.18 k7 kernel (the previous one there was the '686' variant). The resulting image file now has 4555382784 bytes (a bit larger than the previously damaged image) and it is still recognized as a qcow image. It seems there is some qcow2-specifig bug... Best regards J Esteves ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
