Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c
On 17/06/07 17:30 +0100, Thiemo Seufer wrote: Lauri Leukkunen wrote: Attached patch fixes the linux-user path mangling code for use with real target root filesystems that have nasty symlinks and lots of files. The old code is terribly slow and can easily end up going through the entire host system /usr hierarchy in a recursive loop. Compared to the previous version of this patch, fixes an issue with attempting to free() a pointer returned by GNU basename(). I gave it a try, and found: - It loses the path caching (which should be done incrementally to avoid the slowness you observe) Current path mangling is not just slow, it gets stuck in a loop for 15 minutes on my box and eats all my RAM until it exhausts all virtual memory: 3976 lleukkun 18 0 2641m 1.5g 188 R 68 77.4 1:26.36 qemu-arm So I don't know if losing a bit of caching is that bad in comparison. I've implemented a kinda similar path mangling system for scratchbox2, there I'm caching the translations in a cache dir as symlinks, cuts down the mangling overhead quite a bit, but on the other hand sb2 needs to do a lot more work to determine how to mangle the path. Not sure it's worth the trouble for qemu. It seems on a current debian/testing it no longer works at all, it used to hog all memory and then (maybe after getting a NULL from malloc()?) continued, now it just eats all swap and keeps going as long as the kernel permits. If you want to see the effect get a maemo rootfs from here: http://repository.maemo.org/stable/3.1/armel/maemo-sdk-rootstrap_3.1_armel.tgz and try giving the extracted dir to qemu-arm -L /path/to/the/rootfs It gets tripped up by the /usr/X11R6/bin/X11 - . symlink, don't ask me why such a link is needed ;) - It misses to do error handling on malloc() returns - It is broken, an emulated /bin/ls /.. shows it ascends above the root. I'll try to provide an updated patch with these addressed tomorrow. /lauri
Re: [Qemu-devel] mipsel support for graphic mode
Yuval Mintz wrote: Yuval Mintz wrote: Hello, Can anyone tell me if there exist support for a graphical (e.g., when no ?nographic is used) when using qemu to emulate a mips little-endian machine (malta)? I'm trying using both windows XP and linux as host machines, but I couldn't even use the most basic X usages. If it is not currently supported, what in what state of development does it stand? What is lacking to allow usage of a graphic mode? I guess your Malta kernel lacks framebuffer support. http://people.debian.org/~ths/qemu/malta/ works for me. Thiemo Let me give some more information: my kernel was constructed to support framebuffers. I wrote a small program that opens the framebuffer, memcpy it and tries to write to it. I manage to pass the opening part, but I recieve the message that no device is found and so it is not a legal command. The use of the described above vmlinux doesn't change that error messge. Then your program does something differently than the standard fb tools which come with Debian. Thiemo well, if someone has a working environment for mipsel with a fb support and working graphic mode, and he coould point me to his files/send them to me (e.g. kernel, filesystem, anything else...) it would be much appreciated. Thanks, yuval _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
[Qemu-devel] Re: 2.6.21 kernel on emulated/real Malta board
On Sun, Jun 17, 2007 at 10:06:55AM +0200, Geert Uytterhoeven wrote: I guess it's just the printk buffer that's being output again to the new console, when the console subsystem switches from early console to real console. Correct. Ralf
[Qemu-devel] qemu block-vmdk.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/18 15:01:31 Modified files: . : block-vmdk.c Log message: Fix a race condition and non-leaf imagesgrowing in VMDK chains, by Igor Lvovsky. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemur1=1.10r2=1.11
[Qemu-devel] kqemu-1.3.0pre11 hangs system
Hi, I am running Debian Sid and installed its qemu (0.9.0-2) package. Debian Sid has a problem: it's kqemu package is outdated, since it depends upon its 2.6.18 kernel, which is no longer available. So I compiled/installed kqemu-1.3.0pre11 instead on Debian's 2.6.21-1-k7. That all went uneventful. But booting XP completely hangs the system: it stops every clock/applet and needs the red button. W/o kqemu I can boot XP fine and get the message that kqemu is not available. Regards, Hugo Vanwoerkom Yahoo! Mail has very limited reply options. You can top-post or bottom-post and that's it! Hugo Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469
[Qemu-devel] qemu vl.h hw/mips_pica61.c hw/parallel.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/06/18 18:55:46 Modified files: . : vl.h hw : mips_pica61.c parallel.c Log message: Add parallel memory mapped interface, by Herve Poussineau. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.251r2=1.252 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/parallel.c?cvsroot=qemur1=1.7r2=1.8
Re: [Qemu-devel] qemu + Windows NT (2000, XP, etc)
Michael Mohr wrote: QEMU developers: I have been using QEMU off and on for some time. Recently I had a need for a Windows XP VM to be joined to a domain. I discovered a rather annoying issue in the form of the key-grab: NT-based Microsoft operating systems make heavy use of Ctrl-Alt-Delete, i.e. to sign on, open the task manager, change your password, lock your screen, etc. I've started using the tablet USB device specifically because I don't like this grabby behaviour, and it started becoming a real problem for everyday use. I wrote a patch that adds a command-line switch to qemu (-alt-grab). It allows you to remap the keygrab combination to Ctrl-Alt-Shift when using SDL-based displays. It has only been tested on Linux / AMD64. Please reply to me off-list, as I am not subscribed. Comments are appreciated, and I would like to see this make it into the mainline QEMU branch. - Patches below are against kvm-26. I forward-ported this patch to qemu CVS, but see below... The included patches were written by Michael Mohr. They are licensed to you under the GNU GPL version 2 or (at your discretion) any later version. I would like to keep the license the same on a per-file basis, could you grant an (additional) BSD-style license as declared at the top of the respective files? Thiemo
Re: [Qemu-devel] [PATCH] Fix TLS support on x86
Alexander Graf wrote: Hi, this patch is based on the NPTL/TLS patch, David Woodhouse sent to the list some months ago, which unfortulately did not work for me, so these are the fixes needed to get it working. After all there is a certain chance, that I got something wrong but basically it does the following: 1. Implement the tg_kill syscall 2. Set the GS shadow register according to the information set_thread_area receives. I'm not sure about that part, but using the qemu internal functions (cpu_x86_load_seg) did not work for me. 3. Implement the new (2.5.xx) TID setting features of clone() 4. Use clone() for forking, since fork() did not always work for me (especially when using TLS) Please split the patch per-feature, and make sure it applies to CVS head. (It fails to apply because it appears to depend on another patch which adds fadvise64 support.) Also, keep the code formatting style the same as the surrounding code (line length, space vs. tabs, whitespace around parentheses, ... ). Thiemo
[Qemu-devel] [PATCH, arm] Segmentation fault when run with -nographic
Hi all, The patch below fixes a segmentation fault when using the arm emulation with -nographic. Bye Aurelien Index: hw/versatilepb.c === RCS file: /sources/qemu/qemu/hw/versatilepb.c,v retrieving revision 1.15 diff -u -d -p -r1.15 versatilepb.c --- hw/versatilepb.c3 Jun 2007 15:19:33 - 1.15 +++ hw/versatilepb.c18 Jun 2007 20:04:22 - @@ -10,6 +10,8 @@ #include vl.h #include arm_pic.h +extern int nographic; + /* Primary interrupt controller. */ typedef struct vpb_sic_state @@ -215,7 +217,8 @@ static void versatile_init(int ram_size, /* The versatile/PB actually has a modified Color LCD controller that includes hardware cursor support from the PL111. */ -pl110_init(ds, 0x1012, pic[16], 1); +if (!nographic) +pl110_init(ds, 0x1012, pic[16], 1); pl181_init(0x10005000, sd_bdrv, sic[22], sic[1]); #if 0 -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
Re: [Qemu-devel] [PATCH, arm] Segmentation fault when run with -nographic
Aurelien Jarno wrote: Hi all, The patch below fixes a segmentation fault when using the arm emulation with -nographic. The sparc emulation in CVS also currently segaults with -nographic. Will this patch fix that as well? Bye Aurelien -Nigel
Re: [Qemu-devel] [PATCH, arm] Segmentation fault when run with -nographic
On Monday 18 June 2007, Aurelien Jarno wrote: Hi all, The patch below fixes a segmentation fault when using the arm emulation with -nographic. No. This is the wrong way to fix this. Fix the segfault, don't disable the device emulation. Paul
Re: [Qemu-devel] [PATCH][UPDATED] Fix path mangling in linux-user/path.c
On 18/06/07 09:02 +0300, Lauri Leukkunen wrote:
On 17/06/07 17:30 +0100, Thiemo Seufer wrote:
Lauri Leukkunen wrote:
- It misses to do error handling on malloc() returns
- It is broken, an emulated /bin/ls /.. shows it ascends above
the root.
I'll try to provide an updated patch with these addressed tomorrow.
Attached is the latest version of this patch. I've tried to test it with
various interesting paths and it works for me.
/lauri
Index: linux-user/path.c
===
RCS file: /sources/qemu/qemu/linux-user/path.c,v
retrieving revision 1.3
diff -u -r1.3 path.c
--- linux-user/path.c 17 Jun 2007 15:32:30 - 1.3
+++ linux-user/path.c 18 Jun 2007 20:30:27 -
@@ -3,157 +3,249 @@
The assumption is that this area does not change.
*/
+
#include sys/types.h
#include dirent.h
#include unistd.h
#include stdlib.h
+
+#ifdef _GNU_SOURCE
+#undef _GNU_SOURCE
#include string.h
+#include libgen.h
+#define _GNU_SOURCE
+#else
+#include string.h
+#include libgen.h
+#endif
+
#include errno.h
#include stdio.h
#include qemu.h
-struct pathelem
-{
-/* Name of this, eg. lib */
-char *name;
-/* Full path name, eg. /usr/gnemul/x86-linux/lib. */
-char *pathname;
-struct pathelem *parent;
-/* Children */
-unsigned int num_entries;
-struct pathelem *entries[0];
-};
-
-static struct pathelem *base;
+char *base = NULL;
-/* First N chars of S1 match S2, and S2 is N chars long. */
-static int strneq(const char *s1, unsigned int n, const char *s2)
-{
-unsigned int i;
-
-for (i = 0; i n; i++)
- if (s1[i] != s2[i])
- return 0;
-return s2[i] == 0;
-}
-
-static struct pathelem *add_entry(struct pathelem *root, const char *name);
-
-static struct pathelem *new_entry(const char *root,
- struct pathelem *parent,
- const char *name)
-{
-struct pathelem *new = malloc(sizeof(*new));
-new-name = strdup(name);
-asprintf(new-pathname, %s/%s, root, name);
-new-num_entries = 0;
-return new;
-}
-
-#define streq(a,b) (strcmp((a), (b)) == 0)
+struct path_entry {
+struct path_entry *prev;
+struct path_entry *next;
+char name[PATH_MAX];
+};
-static struct pathelem *add_dir_maybe(struct pathelem *path)
+char *decolonize_path(const char *path)
{
-DIR *dir;
+char *cpath, *index, *start;
+char cwd[PATH_MAX];
+struct path_entry list;
+struct path_entry *work;
+struct path_entry *new;
+char *buf = NULL;
-if ((dir = opendir(path-pathname)) != NULL) {
- struct dirent *dirent;
-
- while ((dirent = readdir(dir)) != NULL) {
- if (!streq(dirent-d_name,.) !streq(dirent-d_name,..)){
- path = add_entry(path, dirent-d_name);
- }
- }
-closedir(dir);
+if (!path) {
+return NULL;
}
-return path;
-}
-static struct pathelem *add_entry(struct pathelem *root, const char *name)
-{
-root-num_entries++;
+buf = malloc((PATH_MAX + 1) * sizeof(char));
+memset(buf, '\0', PATH_MAX + 1);
-root = realloc(root, sizeof(*root)
- + sizeof(root-entries[0])*root-num_entries);
+list.next = NULL;
+list.prev = NULL;
+work = list;
+
+if (path[0] != '/') {
+/* not an absolute path */
+memset(cwd, '\0', PATH_MAX);
+if (getcwd(cwd, PATH_MAX) 0) {
+perror(error getting current work dir\n);
+return NULL;
+}
+unsigned int l = (strlen(cwd) + 1 + strlen(path) + 1);
+cpath = malloc((strlen(cwd) + 1
++ strlen(path) + 1) * sizeof(char));
+if (!cpath)
+abort();
-root-entries[root-num_entries-1] = new_entry(root-pathname, root, name);
-root-entries[root-num_entries-1]
- = add_dir_maybe(root-entries[root-num_entries-1]);
-return root;
-}
+memset(cpath, '\0', l);
+strcpy(cpath, cwd);
+strcat(cpath, /);
+strcat(cpath, path);
+} else {
+if (!(cpath = strdup(path)))
+abort();
+}
-/* This needs to be done after tree is stabalized (ie. no more reallocs!). */
-static void set_parents(struct pathelem *child, struct pathelem *parent)
-{
-unsigned int i;
+start = cpath + 1; /* ignore leading '/' */
+while (1) {
+unsigned int last = 0;
+
+index = strstr(start, /);
+if (!index) {
+last = 1;
+} else {
+*index = '\0';
+}
+
+if (index == start) {
+goto proceed; /* skip over empty strings
+ resulting from // */
+}
+
+if (strcmp(start, ..) == 0) {
+/* travel up one */
+if (!work-prev)
+goto proceed;
+work = work-prev;
+free(work-next);
+work-next = NULL;
+} else if (strcmp(start, .) == 0) {
+/* ignore */
+goto proceed;
+} else {
+/* add an entry
Re: [Qemu-devel] [PATCH] Segmentation fault when run with -nographic
I already sent a patch for this to the list: http://lists.gnu.org/archive/html/qemu-devel/2007-06/msg00185.html Stefan Nigel Horne schrieb: Aurelien Jarno wrote: Hi all, The patch below fixes a segmentation fault when using the arm emulation with -nographic. The sparc emulation in CVS also currently segaults with -nographic. Will this patch fix that as well? Bye Aurelien -Nigel
