Alexander Graf schrieb:
I also implemented module parameters. Kevin needed this to boot a
homebrew kernel.
Well, in fact you needed it for Xen as well. ;-)
This new version of the patch works fine for me.
Kevin
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 10:05:41
Added files:
tcg: LICENSE README TODO tcg-dyngen.c tcg-op.h
tcg-opc.h tcg-runtime.c tcg.c tcg.h
tcg/i386 : tcg-target.c
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 10:03:35
New directory:
tcg
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/?cvsroot=qemu
Anthony Liguori wrote:
This patch actually enables KVM support for QEMU. I apologize that it is so
large but this was the only sane way to preserve bisectability.
The goal of this patch is to add KVM support, but not to impact users when
KVM isn't being used. It achieves this by using a
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 10:02:52
Modified files:
. : Makefile
Log message:
typo
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.144r2=1.145
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 10:03:18
Modified files:
. : TODO
Log message:
update
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/TODO?cvsroot=qemur1=1.40r2=1.41
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 10:03:47
New directory:
tcg/i386
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/?cvsroot=qemu
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 appropriate e820 tables.
[...]
+
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 10:50:12
Modified files:
. : LICENSE Makefile.target configure cpu-all.h
cpu-defs.h cpu-exec.c dyngen.c exec-all.h
Hi,
I added a new code generator (TCG) in QEMU. Read the file
qemu/tcg/README to have technical information. A new code generator was
needed in order to avoid problems with the various GCC versions and to
get better performance.
I made minimal modifications in each target so that they can
Fabrice Bellard wrote:
Anthony Liguori wrote:
+/* above 4giga memory allocation */
+if (above_4g_mem_size 0) {
+ram_addr = qemu_ram_alloc(above_4g_mem_size);
+cpu_register_physical_memory(0x1, above_4g_mem_size,
ram_addr);
+}
+
Why do you need this ? All
Fabrice Bellard wrote:
Some questions:
- QEMU already maintains modified page status for VGA memory (and
kqemu for example fully supports that), so I don't see why KVM needs a
new method.
KQEMU passes the dirty bitmap directly to the kernel. KVM does
aggressive shadow page table caching
Avi Kivity wrote:
Anthony Liguori wrote:
I think I'll change this too into a single qemu_ram_alloc. That will
fix the bug with KVM when using -kernel and large memory anyway :-)
Won't that cause all of the memory in the hole to be wasted?
You could munmap() it, but it's hardly
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 13:01:47
Modified files:
tcg: README
Log message:
typos
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemur1=1.1r2=1.2
Samuel Thibault wrote:
Hello,
Hi Samuel,
We were wondering whether it could be useful to have e.g. a git
repository holding the patches from Xen and KVM: while they are being
merged upstream, they could at least be shared by both projects...
KVM currently maintains a git tree of it's
Hello,
We were wondering whether it could be useful to have e.g. a git
repository holding the patches from Xen and KVM: while they are being
merged upstream, they could at least be shared by both projects...
Samuel
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate amount of ram was for
In message: [EMAIL PROTECTED]
Robert William Fuller [EMAIL PROTECTED] writes:
: Avi Kivity wrote:
: Anthony Liguori wrote:
: Fabrice Bellard wrote:
: Anthony Liguori wrote:
: +/* above 4giga memory allocation */
: +if (above_4g_mem_size 0) {
: +ram_addr =
Avi Kivity wrote:
Anthony Liguori wrote:
Fabrice Bellard wrote:
Anthony Liguori wrote:
+/* above 4giga memory allocation */
+if (above_4g_mem_size 0) {
+ram_addr = qemu_ram_alloc(above_4g_mem_size);
+cpu_register_physical_memory(0x1,
above_4g_mem_size,
Well, it compiles fine on Windows using gcc 3.4.5. Haven't tried Linux yet.
- Original Message -
From: Fabrice Bellard [EMAIL PROTECTED]
To: qemu-devel@nongnu.org
Sent: Friday, February 01, 2008 6:13 AM
Subject: [Qemu-devel] TCG
Hi,
I added a new code generator (TCG) in QEMU. Read
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct
types to enable 2G support):
The alternative is to change all the places that assume phys_ram_base +
PA which I don't like very much.
We would ideally like to do this for Xen, at least in the places we
care about.
Paul Brook wrote:
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate amount of
After a little discussion on the list, I made this patch for cocoa.m,
to replace CoreGraphic by OpenGL.
It's way faster than CG, but it requires a Mac with OpenGL capable
Graphics Card and at least 8mb of VRAM.
I think starting with G4 and Highend G3, this requirements are met.
features:
On 1 Feb 2008, at 16:09, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Robert William Fuller [EMAIL PROTECTED] writes:
: Avi Kivity wrote:
: Anthony Liguori wrote:
: I think I'll change this too into a single qemu_ram_alloc.
That will
: fix the bug with KVM when using
Hi,
here it bails out:
-- snip --
gcc -Wall -O2 -g -fno-strict-aliasing -fno-reorder-blocks -fno-gcse
-fno-tree-ch -fno-optimize-sibling-calls -fno-crossjumping
-fno-align-labels -fno-align-jumps -fno-align-functions
-mpreferred-stack-boundary=2 -fomit-frame-pointer
Paul Brook wrote:
I agree with the fact that ram_size should be 64 bit. Maybe each
machine could test the value and emit an error message if it is too
big. Maybe an uint64_t would be better though.
uint64_t is probably more reasonable. I wouldn't begin to know what the
appropriate
Ian Jackson wrote:
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to
enable 2G support):
The alternative is to change all the places that assume phys_ram_base +
PA which I don't like very much.
We would ideally like to do this for Xen, at least in
Hi,
On Fri, 1 Feb 2008, Christian Laursen wrote:
Gervase Lam [EMAIL PROTECTED] writes:
From my minimal understanding of what he is saying, it seems he would
prefer there to be a BOCHS graphics adapter, which would then pass the
OpenGL commands from Windows to Linux OpenGL. Also,
On Friday 01 February 2008, Johannes Schindelin wrote:
Hi,
On Fri, 1 Feb 2008, Christian Laursen wrote:
Gervase Lam [EMAIL PROTECTED] writes:
From my minimal understanding of what he is saying, it seems he would
prefer there to be a BOCHS graphics adapter, which would then pass the
On Fri, Feb 01, 2008 at 11:53:02AM -0600, Anthony Liguori wrote:
Ian Jackson wrote:
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use
correct types to enable 2G support):
The alternative is to change all the places that assume phys_ram_base +
PA which I don't
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl blueswir1 08/02/01 20:12:41
Modified files:
hw : sun4m.c
pc-bios: README openbios-sparc32
Log message:
Move AUX1 and AUX2 to correct locations
Update
Daniel P. Berrange wrote:
On Fri, Feb 01, 2008 at 11:53:02AM -0600, Anthony Liguori wrote:
Ian Jackson wrote:
Anthony Liguori writes ([Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to
enable 2G support):
The alternative is to change all the places that assume
virtio could still be made to work with map cache. You would just have
to change it to be able to map more than one page contiguously. As I
mentioned though, it just starts getting ugly.
That's why you should be using the cpu_physical_memory_rw routines :-)
Anything that assume large linear
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.
For v2 of this page, I've moved
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.
This patch hasn't
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.
Since v1, I've incorporated Fabrice's feedback so this is now a
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.
This patch hasn't changed since v1.
Index: qemu/hw/acpi.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
This was never corrected during the ram_alloc() conversion.
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c 2008-02-01 10:01:47.0 -0600
+++ qemu/hw/pc.c2008-02-01 10:57:01.0 -0600
@@ -869,7 +869,7 @@
}
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard bellard 08/02/01 22:18:51
Modified files:
. : cpu-all.h cpu-exec.c qemu-doc.texi vl.c
Log message:
reverted -translation option support
CVSWeb URLs:
And attached is v2 which updates both uses of ram_size instead of just
the one :-)
Regards,
Anthony Liguori
Anthony Liguori wrote:
This was never corrected during the ram_alloc() conversion.
Index: qemu/hw/pc.c
===
---
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook pbrook 08/02/01 22:45:05
Modified files:
. : Makefile.target
Log message:
Add missing dependencies on generated files (for parallel build).
CVSWeb URLs:
I made minimal modifications in each target so that they can still work
by using TCG and legacy dyngen micro operations. More work will be
needed to convert each target to TCG, but it can be done progressively.
Only the x86 and x86_64 targets have been significantly modified to use
TCG.
When
43 matches
Mail list logo
