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 Bellard08/02/01 10:03:48
New directory:
tcg/x86_64
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/?cvsroot=qemu
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/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 tcg-targe
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/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 kvm_en
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:02:52
Modified files:
. : Makefile
Log message:
typo
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemu&r1=1.144&r2=1.145
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 10:03:18
Modified files:
. : TODO
Log message:
update
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/TODO?cvsroot=qemu&r1=1.40&r2=1.41
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/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 Bellard08/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
exec.c tran
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 st
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 th
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 elegan
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/02/01 13:01:47
Modified files:
tcg: README
Log message:
typos
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&r1=1.1&r2=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 wa
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, ram_addr);
+}
+
Wh
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) {
: +
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, ram_ad
Well, it compiles fine on Windows using gcc 3.4.5. Haven't tried Linux yet.
- Original Message -
From: "Fabrice Bellard" <[EMAIL PROTECTED]>
To:
Sent: Friday, February 01, 2008 6:13 AM
Subject: [Qemu-devel] TCG
Hi,
I added a new code generator (TCG) in QEMU. Read the file qemu/tcg/
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 abou
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 ram
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:
[n
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 u
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
-DCONFIG_HAS_LI
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
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
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, Direct3D commands
> would be passed from Windows to Linux
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. A
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
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 w
Robert William Fuller wrote:
> Linux doesn't commit mapped memory until it's faulted. As for other
> platforms, who knows?
Correction: most Linux installations don't commit mapped memory until
it's faulted. A few do, as a matter of policy (it depends on kernel
settings), so that applications wo
CVSROOT:/cvsroot/qemu
Module name:qemu
Changes by: Blue Swirl 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 Sparc32 OpenBI
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
On 31.01.2008, at 16:55, Alexander Graf wrote:
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 mak
> 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 line
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 ram_addr_
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 chan
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 1-lin
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 include
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 @@
} els
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Fabrice Bellard08/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:
http://cvs.savannah.gnu.org/viewcvs
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
===
--- qemu.orig
CVSROOT:/sources/qemu
Module name:qemu
Changes by: Paul Brook 08/02/01 22:45:05
Modified files:
. : Makefile.target
Log message:
Add missing dependencies on generated files (for parallel build).
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/q
> 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.
48 matches
Mail list logo
