[Qemu-devel] qemu/target-ppc cpu.h helper.c translate.c tran...
CVSROOT:/sources/qemu Module name:qemu Changes by: Jocelyn Mayer j_mayer 07/03/23 09:40:22 Modified files: target-ppc : cpu.h helper.c translate.c translate_init.c Log message: Fix debug printf: we need different macros for target_ulong prints and GPR ones, as the lengths can be different. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/cpu.h?cvsroot=qemur1=1.29r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/helper.c?cvsroot=qemur1=1.33r2=1.34 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.50r2=1.51 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate_init.c?cvsroot=qemur1=1.5r2=1.6 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)
Am Thu, 22 Mar 2007 21:13:00 +0100 schrieb Sunil Amitkumar Janki [EMAIL PROTECTED]: I have seen this error as well when building with i686/pentium3/athlon optimisations. As I am doing a course on x86 assembly programming at the moment I can tell you that it suffers from register starvation and the message tells you that there aren't enough registers left. Yeah, that's the message... what I wonder is this is to be expected. Does SSE steal or add registers? -march=pentium-mmx -m3dnow seems to work, though. Is it just a coincidence that gcc optimizattion uses some registers with high march (and SSE) that it didn't use with lower march? I'm wondering if it's the code that is just lucky to compile with some march settings and not so lucky with others or if it's a gcc bug or whatever... Thomas. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Guest mouse cursor drawing in SDL
Hi, sorry for late reply. On 21/03/07, Anthony Liguori [EMAIL PROTECTED] wrote: andrzej zaborowski wrote: (the pixel format of the cursor was the same as the pixel format of DisplayState). I'm not sure if we want to always use the same pixel format - for example with VMware SVGA and SDL in 16 bit mode, the cursor pixel format reported by guest Xorg was 8 bpp. This would mean two conversions instead of one: first VMware SVGA would have to convert 8 - 16 bpp then SDL 16 - 1 bpp. VNC expects the cursor data to be in the current pixel format. The nice thing about this approach is you don't need to pass a bunch of pixel info (for instance, you don't need to pass the depth, endianness, etc.). True. Maybe it's worth doing the double conversion (in the VGA and another one in SDL). The Cirrus hardware cursor also has to be copied anyway and doing the conversion is really straight forward. One question in my mind is what the alpha mask should look like. All that VNC (and SDL) can use is a 1-bit alpha depth. That's all Cirrus supports too. VMware SVGA supports an 8-bit alpha channel though so it may make sense to design the interface now to support that. VMware SVGA without CAP_ALPHA_CURSOR also does only 1-bit alpha. Maybe we should keep two masks - if the frontend (e.g SDL) supports only 1-bit alpha it would use only this basic mask - if the emulated VGA supports only 1-bit alpha it would leave the other mask opaque. I thought about that. Right now with my patch, the cursor mask is always 1-bit deep. I was thinking that perhaps the right thing to do is to make it always 8-bits deep and then convert in VNC. Do you think using the SDL cursor is all that useful? As soon as gtk widgets get involved, the cursor becomes ARGB so in practice, I'm not sure that it's all that helpful. It's pretty cool that you have only one cursor and that it's either in the VM or outside, and it's full hardware drawn. In addition without it, I think you can't get cursor refreshes between the SDL refresh callbacks. So with the patch the cursor movement is really smooth and responsive, eliminating the SDL latency. I find it amazing that it works :p I think VNC support is not a reason to drop this couple of lines in sdl.c (cause there's no API changes related). BTW, I've got the ALPHA_CURSOR working with VNC.. it's very sweet :-) Awesome! Are there screenshots? Regards, Andrew ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)
Am Fri, 23 Mar 2007 15:45:49 + schrieb Paul Brook [EMAIL PROTECTED]: I do not understand enough of QEMU yet, but I have checked out CVS and am reading through its source. When I understand more I hope we can fix this long-standing annoyance. This is GCC PR16185 http://gcc.gnu.org/PR16185. Hm, I think I stumbled over this before... so it is still valid. There's no fundamental reason why some options trigger it, and others don't. It trigerrs fairly randomly depending on the code generation choices gcc happens to make. So it is indeed the case that nothing particular in qemu triggers it, just the general grab on the registers. And it is something that won't be fixed anytime soon (in gcc), apart from ia32 going out of use... Personally, I started using qemu with my Pentium-M 1.4GHz laptop... so 32bit is the way there for a few years. So I'll check for every new qemu release and gcc version if it perhaps builds with normal optimization settings... or one identifies a spot to release a register for x86 where it doesn't hurt qemu (since it's always softmmu_template.h with helper.c). Anyway, this sounds more and more like a FAQ entry. Perhaps it should be mentioned in qemu docs. The problem is that x86 is chronically short of registers. qemu makes this significantly worse by telling gcc it can't use most of them. gcc simply isn't designed to work in these extreme situations. Yep, x86 is chronically short of many things and loaded with others. At work I secured two good old XP1000 alphas for myself... they're not really as fast as my laptop, but register starvation is nothing I expect to happen there. They got .. hm, what's the correct term... a shitload of registers! ;-) x86 really was the worst arch to become market leader for home computing. On the other hand that leadership was what made the arch mutate in the ways it did. Thomas. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] generating EFAULT in linux-user
Here is an updated patch that show more of the changes that are needed
to detect EFAULT situations in linux-user. The areas I focused on are
the socket, semaphore, and message queue family of syscalls as they all
make interesting use of pointers to structures. This patch does sit on
top of the other patches I sent to this list this week for semaphores
and message queues, so it can't be 'test driven' without them.
With this patch, more of the Linux Test Project test suite is able to
PASS, and qemu SEGVs less frequently.
Still to be done is to actually fold this into lock_user(), and finish
applying it in the other applicable syscalls.
Comments would be appreciated.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Network Software Engineering http://www.netsweng.com/
1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F
BD03 0A62 E534 37A7 9149Index: qemu/exec.c
===
--- qemu.orig/exec.c 2007-03-23 09:05:45.0 -0400
+++ qemu/exec.c 2007-03-23 09:06:23.0 -0400
@@ -1785,6 +1785,29 @@
spin_unlock(tb_lock);
}
+int page_check_range(target_ulong start, target_ulong len, int flags)
+{
+PageDesc *p;
+target_ulong end;
+target_ulong addr;
+
+end = TARGET_PAGE_ALIGN(start+len); /* must do before we loose bits in the next step */
+start = start TARGET_PAGE_MASK;
+
+if( end start ) return EFAULT; /* we've wrapped around */
+for(addr = start; addr end; addr += TARGET_PAGE_SIZE) {
+p = page_find(addr TARGET_PAGE_BITS);
+ if( !p ) return EFAULT;
+ if( !(p-flags PAGE_VALID) ) return EFAULT;
+
+if (!(p-flags PAGE_READ)
+(flags PAGE_READ) ) return EFAULT;
+if (!(p-flags PAGE_WRITE)
+(flags PAGE_WRITE) ) return EFAULT;
+}
+return 0;
+}
+
/* called from signal handler: invalidate the code and unprotect the
page. Return TRUE if the fault was succesfully handled. */
int page_unprotect(target_ulong address, unsigned long pc, void *puc)
Index: qemu/cpu-all.h
===
--- qemu.orig/cpu-all.h 2007-03-23 09:05:45.0 -0400
+++ qemu/cpu-all.h 2007-03-23 10:52:16.0 -0400
@@ -689,6 +689,7 @@
int page_get_flags(target_ulong address);
void page_set_flags(target_ulong start, target_ulong end, int flags);
void page_unprotect_range(target_ulong data, target_ulong data_size);
+int page_check_range(target_ulong start, target_ulong len, int flags);
#define SINGLE_CPU_DEFINES
#ifdef SINGLE_CPU_DEFINES
Index: qemu/linux-user/syscall.c
===
--- qemu.orig/linux-user/syscall.c 2007-03-23 09:06:16.0 -0400
+++ qemu/linux-user/syscall.c 2007-03-23 10:55:01.0 -0400
@@ -406,28 +406,36 @@
return ret;
}
-static inline void target_to_host_sockaddr(struct sockaddr *addr,
+static inline long target_to_host_sockaddr(struct sockaddr *addr,
target_ulong target_addr,
- socklen_t len)
+ socklen_t len,
+ int pg_access)
{
+long ret = 0;
struct target_sockaddr *target_saddr;
target_saddr = lock_user(target_addr, len, 1);
+if( ret=page_check_range(target_saddr,len,pg_access) ) return ret;
memcpy(addr, target_saddr, len);
addr-sa_family = tswap16(target_saddr-sa_family);
unlock_user(target_saddr, target_addr, 0);
+return ret;
}
-static inline void host_to_target_sockaddr(target_ulong target_addr,
+static inline long host_to_target_sockaddr(target_ulong target_addr,
struct sockaddr *addr,
- socklen_t len)
+ socklen_t len,
+ int pg_access)
{
+long ret = 0;
struct target_sockaddr *target_saddr;
target_saddr = lock_user(target_addr, len, 0);
+if( ret=page_check_range(target_saddr,len,pg_access) ) return ret;
memcpy(target_saddr, addr, len);
target_saddr-sa_family = tswap16(addr-sa_family);
unlock_user(target_saddr, target_addr, len);
+return ret;
}
/* ??? Should this also swap msgh-name? */
@@ -788,18 +796,20 @@
static long do_bind(int sockfd, target_ulong target_addr,
socklen_t addrlen)
{
+long ret = 0;
void *addr = alloca(addrlen);
-target_to_host_sockaddr(addr, target_addr, addrlen);
+if( ret=target_to_host_sockaddr(addr, target_addr, addrlen,PAGE_READ) ) return -ret;
return get_errno(bind(sockfd, addr, addrlen));
}
static long do_connect(int sockfd, target_ulong target_addr,
