Hello,
I have some questions when I want to create a new file system of arm-test.
The arm-test could be download from http://fabrice.bellard.free.fr/qemu/arm-
test-0.2.tar.gz .
It is a ramdisk . I could open it to see what it has.
Now I want to create a new ramdisk to run in the same style od
Unfortunately, it can's apply on tip. Could you attach the diff ?
Thanks
Xiantao
On Jan 30, 2008, at 9:30 PM, Mike Kronenberg wrote:
On 30.01.2008, at 19:59, Alexander Graf wrote:
On Jan 21, 2008, at 5:18 PM, Mike Kronenberg wrote:
This is a complete rewrite of cocoa.m to support Core Graphics.
As mentioned in earlier threads, the QuickDraw API is depreciated
On Jan 31, 2008, at 10:58 AM, Kevin Wolf wrote:
Hi,
I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:
+// XXX: multiboot header may be within the first 8192 bytes,
but header
+// is only the first 1024
+
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/01/31 10:43:14
Removed files:
. : i386-vl.ld
Log message:
removed unused file
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/i386-vl.ld?cvsroot=qemur1=1.3r2=0
Anthony Liguori wrote:
VGA framebuffer operations come in as memory operations. They're
tracked by watching what memory gets dirtied. This can only operate at
a page-granularity so this results in scan-line granularity updates.
The VNC front-end goes to great lengths to keep a shadowed
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/01/31 11:32:10
Modified files:
. : Makefile Makefile.target configure
Log message:
Makefile cleanup - more generic support of 32 bit compilation on x86_64
CVSWeb
- Original Message -
From: Mulyadi Santosa [EMAIL PROTECTED]
To: qemu-devel@nongnu.org
Sent: 26.01.2008 16:25
Subject: Re: [Qemu-devel] Slow clock in guest OS
Sorry, did You mean http://fabrice.bellard.free.fr/qemu/qemu-tech.html;
or
what?
yep...that's the one...
As I can see,
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/01/31 14:56:10
Modified files:
tests : test-i386.c
Log message:
compilation fixes - added bswap - comments
CVSWeb URLs:
Hello!
You might be interested to add a link to the qemulator GUI on the qemu
homepage. It's now an official part of the Ubuntu universe packages and it's
also in debian unstable and testing.
Best regards
rainer
--
rainer haage - Developer
http://qemulator.createweb.de
[EMAIL PROTECTED]
Pierre Ficheux wrote:
Hi all,
I would like to debug QEMU with gdb. When starting qemu (x86) inside
gdb, SDL window never appears, it there a way to fix it ?
I dare to say your local environment is borken, not qemu :-. At least
its not a generic issue (works fine here: qemu-cvs, built against
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/01/31 15:19:24
Modified files:
tests : Makefile
Log message:
compilation fix
CVSWeb URLs:
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/01/31 15:19:39
Modified files:
tests : test-i386-code16.S
Log message:
suppressed warnings
CVSWeb URLs:
This patch implements Mac OS X specific parts that are necessary to
get x86_64 versions of qemu working.
It does:
- add x86_64 detection to configure
- add -fomit-frame-pointer if available
- set the pagezero size to 4GB, so 32bit lea still works
- fix redeclarations of int64_t and uint64_t
-
Hi,
supporting Mac OS X on Intel has been a long standing issue. The Q
project has done a fabulous job maintaining patches that make things
work for i386 Mac OS X, but do invasive changes to qemu internals.
This set of patches attempts to make Mac OS X host support as
compatible as
Jan Kiszka wrote:
Pierre Ficheux wrote:
Hi all,
I would like to debug QEMU with gdb. When starting qemu (x86) inside
gdb, SDL window never appears, it there a way to fix it ?
I dare to say your local environment is borken, not qemu :-. At least
its not a generic issue (works fine
This patch implements Mac OS X specific parts that are necessary to
get i386 versions of qemu working.
It does:
- make the GOTO_TB macro more portable
qemu-mac-i386.patch
Description: Binary data
This patch extends the existing support for the Mach-O binary format
in dyngen from PowerPC to PowerPC, i386 and x86_64.
qemu-macho.patch
Description: Binary data
Thiemo Seufer a écrit :
FWIW, I had a similiar problem with QEMU 0.9.0 on PPC/Linux host.
It went away at some point before 0.9.1, I don't remember more details.
Have tested with 0.9.1 with same pb. I work with FC5 may be it's a
distro pb.
Thx.
Thiemo
--
Pierre FICHEUX -/- CTO
This patch implements Mac OS X specific parts that are necessary to
get i386 and x86_64 versions of qemu working. Since both hosts need
this patch, I seperated it from the architecture specific ones.
It does:
- not force always_inline
- only define [u]intXX types if they are not already
Hi,
-soundhw, -M, -cpu, -d, -translation options use the '?' to display the
list of possibilities, whereas -clock uses 'help'. Change it to be
consistent.
Display also the list of available sources if no valid clock name has
been specified.
Index: vl.c
On Jan 31, 2008, at 10:58 AM, Kevin Wolf wrote:
Hi,
I like this idea. When I just tried to load my multiboot kernel it
failed, though, because of the following piece of code:
+// XXX: multiboot header may be within the first 8192 bytes,
but header
+// is only the first 1024
+
is it possible to use an actual PowerPC ROM in qemu-system-ppc? If so, what
would be the minimum Mac ROM that would be used (I'm guessing the blue and
white G3)? If not, why isn't it?
Zhang, Xiantao wrote:
Unfortunately, it can's apply on tip. Could you attach the diff ?
It works for me:
$ git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git
remote: Generating pack...
remote: Done counting 37449 objects.
remote: Deltifying 37449 objects...
remote: 100%
Am 31.01.2008 um 16:41 schrieb C.W. Betts:
is it possible to use an actual PowerPC ROM in qemu-system-ppc?
This question pops up about once a month, so several people are
interested in this. AFAIK, the current answer is:
No, but patches are welcome.
If not, why isn't it?
It needs
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has been included since 2.6.20 and supports Intel VT and
AMD-V. Ports are under way for ia64, embedded PowerPC, and s390.
This set of patches provide basic support for KVM in QEMU. It does not
The -daemonize option is too restrictive when using with SDL. It also switches
the working directory to / too early which causes block devices with a relative
path to fail.
The -daemonize option is needed for my regression testing so I've included this
patch in the series.
Index: qemu/vl.c
KVM supports the ability to use ACPI to shutdown guests. In order to enable
this requires some fixes to be able to generate the SCI interrupt and the
appropriate plumbing.
Index: qemu/hw/acpi.c
===
--- qemu.orig/hw/acpi.c 2008-01-30
Previously, the BIOS would probe the CPUs for SMP guests. This tends to be
very unreliably because of startup timing issues. By passing the number of
CPUs in the CMOS, the BIOS can detect the number of CPUs much more reliably.
Index: qemu/hw/pc.c
FYI, for the new files introduced, Avi should be following up with a
patch to add Copyrights to the files. They will be licensed under the GPL.
Regards,
Anthony Liguori
Anthony Liguori wrote:
KVM is a Linux interface for providing userspace interfaces for accelerated
virtualization. It has
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the appropriate e820 tables.
Index: qemu/cpu-all.h
KVM requires that any ROM memory be registerd through a second interface. This
patch refactors the option ROM loading to simplify adding KVM support (which
will follow in the next patch).
Index: qemu/hw/pc.c
===
---
Jamie Lokier wrote:
Anthony Liguori wrote:
VGA framebuffer operations come in as memory operations. They're
tracked by watching what memory gets dirtied. This can only operate at
a page-granularity so this results in scan-line granularity updates.
The VNC front-end goes to great lengths
On Thursday 31 January 2008, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can build
the
-cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
+cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
smp_cpus is a global variable. Why bother passing it around?
Are the CMOS contents documented anywhere?
Paul
Paul Brook wrote:
On Thursday 31 January 2008, Anthony Liguori wrote:
KVM supports more than 2GB of memory for x86_64 hosts. The following patch
fixes a number of type related issues where int's were being used when they
shouldn't have been. It also introduces CMOS support so the BIOS can
Paul Brook wrote:
-cmos_init(ram_size, above_4g_mem_size, boot_device, hd);
+cmos_init(ram_size, above_4g_mem_size, boot_device, hd, smp_cpus);
smp_cpus is a global variable. Why bother passing it around?
True, I'll update the patch
Are the CMOS contents documented
Anthony Liguori wrote:
That's 16MB/frame on an Apple Cinema display at 32bpp, which is
0.5GB/sec. Not too much, but not free either :-)
But your guest isn't displaying to the entire screen... I was assuming
a 32-pixel height, 1024 pixel wide region.
I don't know about you; I quite
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
This seems fairly arbitrary. Why? Any limit is certainly target specific.
On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
in virtual address space. On a 64-bit host, there isn't this
fundamental limit. If
Paul Brook wrote:
+#define PHYS_RAM_MAX_SIZE (2047 * 1024 * 1024 * 1024ULL)
This seems fairly arbitrary. Why? Any limit is certainly target specific.
On a 32-bit host, a 2GB limit is pretty reasonable since you're limited
in virtual address space. On a 64-bit host, there isn't
Are the CMOS contents documented anywhere?
No, but if you have a suggestion of where to document them, I'll add
documentation.
I suggest in or with the BIOS sources.
As we're using a common BIOS it seems a good idea to make sure this kind of
things is coordinated.
Paul
I just noticed that my previous patch hit one of the subtleties that
Blue Swirl warned about. Changing caddr32_t causes the IP header and
IP header overlay to be different sizes, which essentially breaks
networking altogether.
I humbly offer the following patch, which fixes only the easy
Blue Swirl wrote:
On 1/30/08, Scott Pakin [EMAIL PROTECTED] wrote:
Zhang, Xiantao wrote:
Scott Pakin wrote:
The attached patch corrects a bug in qemu/slirp/tcp_var.h that
defines the seg_next field in struct tcpcb to be 32 bits wide
regardless of 32/64-bitness. seg_next is assigned a
hello Sergey...
On 1/31/08, Sergey Bychkov [EMAIL PROTECTED] wrote:
As I can see, this document anything about what to do if qemu hung :)
reading always helps in some degree :)
After some investigations I can say that with the latest (2008/01/30) qemu
from cvs, compiled with gcc-3.4 on linux
Scott Pakin wrote:
Zhang, Xiantao wrote:
Scott Pakin wrote:
The attached patch corrects a bug in qemu/slirp/tcp_var.h that
defines the seg_next field in struct tcpcb to be 32 bits wide
regardless of 32/64-bitness. seg_next is assigned a pointer value
in qemu/slirp/tcp_subr.c, then cast back
From: Alexander Graf
Subject: Re: [Qemu-devel] [patch] cocoa.m - Core Graphics support
Date: Thu, 31 Jan 2008 09:29:02 +0100
I somehow like the idea of having a GL based video output.
Awhile back, somebody did a patch to allow guest accelerated Windows
OpenGL graphics.
46 matches
Mail list logo
