> 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
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,
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 l
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 i
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" 32/64
> > 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
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
> >> +#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
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
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 anywhere?
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 b
> -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
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 appropr
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
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
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
=
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
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 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
===
--- qemu.orig/hw/pc.c
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 include
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 en
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% (37449/
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?
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
+
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
=
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 OW/OS
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 defi
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
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 possib
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 (wo
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 15:19:39
Modified files:
tests : test-i386-code16.S
Log message:
suppressed warnings
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386-code16.S?cvsroot
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 15:19:24
Modified files:
tests : Makefile
Log message:
compilation fix
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tests/Makefile?cvsroot=qemu&r1=1.44&r2=1.45
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 14:56:10
Modified files:
tests : test-i386.c
Log message:
compilation fixes - added bswap - comments
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386.
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 aga
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]
cr
- Original Message -
From: "Mulyadi Santosa" <[EMAIL PROTECTED]>
To:
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, this document anyt
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/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 URLs:
http:
On Thursday 31 January 2008 10:46, 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.
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 shadowe
andrzej zaborowski wrote:
> > > Offtoppic about updated regions in Windows: While testing with
> > > Quartzdebug, I realized, that qemu is updating always the whole
> > > screenwidth even if only the mouse is moved... is this a qemu problem,
> > > or is this the default windows behaviour?
> >
> > A
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/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=qemu&r1=1.3&r2=0
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
+
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
> +
> +// Ok, let's see if it is a multib
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/01/31 09:22:27
Modified files:
. : softmmu_template.h softmmu_header.h osdep.h
cpu-defs.h
Log message:
use simpler REGPARM convention - make CPUTLBE
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
start
Unfortunately, it can's apply on tip. Could you attach the diff ?
Thanks
Xiantao
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 arm-
50 matches
Mail list logo
