Looks like SELinux to me. Even - you should raise it with whoever
writes your policy.
On Mon, 01 May 2006 23:29:54 +0200
Fabrice Bellard [EMAIL PROTECTED] wrote:
Are you sure that the bug is really in kqemu ? It is possible that
your guest kernel implements a security system which prevents
I had a similar problem, but only when not using kqemu.
When using a stack overflow exploit, the shellcode provided only
executes when using kqemu. I can attribute this to either the
shellcode being in a different location (maybe someone can clarify
this, is qemu using a different memory layout
Hi!
The current CVS QEMU Makefile builds qemu-system-mips
binary which really emulates a little-endian system and should be
renamed to the qemu-system-mipsel
[EMAIL PROTECTED] qemu/bin]$ ls
qemuqemu-i386 qemu-mipsel qemu-sparcqemu-system-ppc
qemu-armqemu-img qemu-ppc
Leonardo E. Reiter [EMAIL PROTECTED] wrote:
Ben,
You can use the patch I posted here recently to get QEMU to fix the BGR
problem internally. It doesn't have to be done at the VNC level - and
in fact, this way, you can use it on the Solaris native X server (or
even SunRays) in 24-bit
Hi,
On Tue, 2 May 2006, Ben Taylor wrote:
Tried it, still didn't come up correctly, with or without the -bgr flag
and using the vnc option.
I guess the problem is that client format and pixel format are different.
The RFB protocol says that the server has to convert to the client format
Johannes Schindelin [EMAIL PROTECTED] wrote:
Hi,
On Tue, 2 May 2006, Ben Taylor wrote:
Tried it, still didn't come up correctly, with or without the -bgr flag
and using the vnc option.
I guess the problem is that client format and pixel format are different.
The RFB protocol
On Tue, 2 May 2006, Marius Groeger wrote:
again, a current version of my FPU patch for MIPS. Fabrice, I tried to
Sorry, hunk #1 of the target-mips/op_mem.c patch got out wrong. (I
wanted to remove other feature patches[1] first and seemed to have
messed up in doing so.) Just delete this
Hello Mark,
thanks a lot for your advice! This really solves the issue and now I'm
able to ping other instance and ssh to its openbsd.
Thanks!
Karel
On Tue, 2 May 2006, Mark Jonckheere wrote:
I did try to reply via the mailing-list, but after three days my
posting is still missing:
qemu
Fabrice Bellard wrote:
Why adding several labels ? qemu_free(NULL) is perfectly valid. I would
just add the missing qemu_free(phdr) ...
Okay. Wasn't sure about this ;)
Do you want a patch for qemu_free(phdr)?
Dirk
___
Qemu-devel mailing list
Alexander Voropay wrote:
The current CVS QEMU Makefile builds qemu-system-mips
binary which really emulates a little-endian system and should be
renamed to the qemu-system-mipsel
With configure --target-list you can select mips-softmmu or
mipsel-softmmu. So I think it's a good idea to extend
-usbdevice tablet emulates a absolute position USB HID device instead of
a PS/2 mouse, so there is no need for messy mouse calibration when using
VNC. It also allows you to get rid of the need to have the SDL version
'grab' the mouse.
On Sat, Apr 29, 2006 at 07:36:01PM +0200, Christian MICHON
After some significant debugging I found the problem with GDB on the
target side.
The instruction translation was not correctly executing undefined
instructions per section 3.13.1 of the ARM Architecture Reference
Manual. Using the attached patch, the target side GDB as well as kernel
side
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 20:54:12
Modified files:
. : elf_ops.h
Log message:
fixed memory leak
CVSWeb URLs:
To clarify the current behaviour of kqemu and QEMU with self-writing
code, the following table can be useful:
Supported feature QEMUkqemu
CS.limit no yes
NX bit yes (x86_64
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 21:09:02
Modified files:
slirp : ip.h
Log message:
32 KB packet handling (Ed Swierk)
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 22:18:28
Modified files:
hw : mips_r4k.c
Log message:
performance boost (on P4 hosts at least, rdtsc is a _very_ bad random
generator)
I just looked at the MIPS file target-mips/op_helper.c and I don't
understand why IRQs need to be handled in op_helper.c:do_mtc0() with reg
= 12. IMHO, the corresponding code should be deleted because the TB is
forced to terminate after mtc0 so that the IRQs can be handled in the
main loop in
CVSROOT:/sources/qemu
Module name:qemu
Branch:
Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 22:52:36
Modified files:
. : Makefile.target
Log message:
correct qemu-system-mipsel naming
CVSWeb URLs:
Fabrice Bellard wrote:
CVSROOT: /sources/qemu
Module name: qemu
Branch:
Changes by: Fabrice Bellard [EMAIL PROTECTED] 06/05/02 22:18:28
Modified files:
hw : mips_r4k.c
Log message:
performance boost (on P4 hosts at least, rdtsc is a _very_
Can someone educate me on what might be wrong here?
[EMAIL PROTECTED]:/scratch/troy/qemu-cvs-patched$ gcc-3.4 --version
gcc-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)
[EMAIL PROTECTED]:/scratch/troy/qemu-cvs-patched$ ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux
20 matches
Mail list logo
