On 3/27/06, Fabrice Bellard <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I just released a new version of kqemu which fixes some recently
> discovered issues. The fixes are the following:
>
> - Support for guest Linux kernels compiled with gcc >= 3.3
Hello,
I tried the Mandriva boot.iso and it now boots f
Hi,
ELF loader feature for MIPS in patch
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00033.html
was rejected because it breaks loading of raw kernel images:
http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00082.html
What about the patch in attachment? It first tries to loa
Hi,
I just released a new version of kqemu which fixes some recently
discovered issues. The fixes are the following:
- Support for guest Linux kernels compiled with gcc >= 3.3
- x86_64 host support is working again (only i386 on x86_64 full
virtualization has been tested, x86_64 on x86_64 is
Hi,
On 24/03/06, Dirk Behme <[EMAIL PROTECTED]> wrote:
[...]
> But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
> (0x1)? Adding
You're looking at the values before the qemu internal bootloader is
ran. This bootloader will correctly set PC to 0x1.
>
> env->regs[15] = KERNEL_LOAD
Hi,
now, after ARM, I try to debug some low level system init
code on MIPS as well. For this, I use
qemu-snapshot-2006-03-21_23 because this already includes
little endian MIPS (--target-list=mipsel-softmmu). I can
load my program to MIPS default start address 0x8001,
use mipsel-linux-gd
Hi,
I updated a serial patch. -serial pipe: and -serial file: option are
supported.
Here is a patch and binary.
http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060320-serial-3.patch
http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060320-serial.zip
Option's examples are:
-serial pipe:com_1
-s
Hi all,
I started looking QEMU source code recently and I saw that Makefile was
missing a "uninstall" profile, that enables user to remove all files
installed when using "make install". I don't know if this list is the
proper way of sending patches but I'm assuming it is (I subscribed on
it today).
G'day all,
The -kernel-kqemu with linux guest bug is still at large, however it appears if you compile your
kernel with gcc-3.2.2 it will work. (yay!). Further investigation continues.
I've posted a monolithic 2.6.16 kernel compiled with gcc-3.2.2 at
http://fnarfbargle.dyndns.org:81/qemu/
Som
On Thu, Mar 23, 2006 at 08:48:25PM +0100, Stefan Weil wrote:
> Hello,
>
> according to MIPS32 4KE User's Manual, coprocessor CP0 is
> always usable when the processor is running in kernel mode.
>
> So in kernel mode, exception "CP0 is not usable" should
> not happen.
>
> I think the boolean expr
On Wed, Mar 22, 2006 at 02:45:11PM -0600, Troy Benjegerdes wrote:
> On Sat, Mar 11, 2006 at 02:57:03PM -0500, Daniel Jacobowitz wrote:
> > On Wed, Mar 08, 2006 at 10:55:21AM -0600, Troy Benjegerdes wrote:
> > > The only think I can track down so far is that BITS_PER_LONG is only
> > > defined in /u
Hello,
I was wondering if it is possible to insert some code into the translated
basic-block in order to dump the processor state to a file after every
single instcution? This would be every single executed instruction,
(meaning it couldn't be just dump the state once at translation time).
I'm t
Andrew Barr wrote:
I'm running a Windows 2000 SP4 guest on a Linux 2.6.16 host with Qemu CVS and
kqemu 1.3.0pre3. I am trying to use -kernel-kqemu. I have been allocating 256
MB of RAM to my guest (out of 768 MB total) and I have found that using that
amount of memory with -kernel-kqemu causes
Hi again. I'm still working on my Windows 2000 SP4 VM, and I've discovered
that running Windows Update (Internet Explorer 6) causes behavior similar to
the "disk full" bug encountered during Windows 2000 setup. When it gets to
the part where it's looking for updates (the green scrolling bar), th
I've just committed a relatively large patch to the qemu usermode emulation
code. Before the patch the userspace emulation code assumed that host and
guest address spaces were the same. The goal of these changes is to remove
that assumption. This allows us to do two things:
- Offset the guest a
On Friday 24 March 2006 16:51, Dirk Behme wrote:
> Paul Brook wrote:
> >>But PC is still wrong. Who sets the PC to KERNEL_LOAD_ADDR
> >>(0x1)?
> >
> > What makes you think ti's wrong? There's a small bootloader built into
> > qemu.
>
> Uups. Then it seems that I start things the wrong way. I
>
Paul Brook wrote:
If I load the binary version of image u-boot.bin into QEMU,
how does QEMU know to which start address the image was
linked to? Or do I have to load the ELF file?
qemu assumes it's loading a raw binary kernel zImage. Currently it is loaded
at 0x1. The linux kernel don't c
16 matches
Mail list logo
