Re: [Qemu-devel] [PATCH] x86 Multiboot support (extended)
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
[Qemu-devel] qemu/tcg/x86_64
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
[Qemu-devel] qemu/tcg LICENSE README TODO tcg-dyngen.c tcg-o...
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-target.h tcg/x86_64 : tcg-target.c tcg-target.h Log message: TCG code generator CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/LICENSE?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/TODO?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-dyngen.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-opc.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-runtime.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.h?cvsroot=qemu&rev=1.1
[Qemu-devel] qemu/tcg
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
[Qemu-devel] Re: [PATCH 6/6] QEMU support for the Kernel Virtual Machine interface
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_enabled() macro that evaluates to (0) when KVM support is not enabled. An if (kvm_enabled()) is just as good as using an #ifdef since GCC will eliminate the dead code. This patches touches a lot of areas. For performance reasons, the guest CPU state is not kept in sync with CPUState. This requires an explicit synchronization whenever CPUState is required. KVM also uses it's own main loop as it runs each VCPU in it's own thread. Trapping VGA updates via MMIO is far too slow when running KVM so there is additional logic to allow VGA memory to be accessed as RAM. We use KVM's shadow page tables to keep track of which portions of RAM have been dirtied. KVM also supports an in-kernel APIC implementation as a performance enhancement. Finally, KVM supports APIC TPR patching. This allows TPR accesses (which are very frequently for Windows) to be patches into CALL instructions to the BIOS (for 32-bit guests). This results in a very sigificant performance improvement for Windows guests. While this patch is very large, the new files are only included when KVM support is compiled in. Every change to QEMU is wrapped in an if (kvm_enabled()) so the code disappears when KVM support is not compiled in. This is done to ensure no regressions are introduced to normal QEMU. 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. - Why is kvm_cpu_register_physical_memory() needed ? kqemu can work without it because there is a remapping between physical memory and RAM address. I suggest to add that feature in KVM or to modify cpu_register_physical_memory() to hide it. - If KVM implements its own CPU loop, why are there patches in libqemu.a (CPU core) ? Regards, Fabrice.
[Qemu-devel] qemu Makefile
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
[Qemu-devel] qemu TODO
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
[Qemu-devel] qemu/tcg/i386
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
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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.
> [...]
+/* 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 the RAM can be registered with a single call.
I fear you need to do that because of KVM RAM handling limitations.
Index: qemu/osdep.c
===
--- qemu.orig/osdep.c 2008-01-30 13:47:00.0 -0600
+++ qemu/osdep.c2008-01-30 13:47:31.0 -0600
@@ -113,7 +113,7 @@
int64_t free_space;
int ram_mb;
-extern int ram_size;
+extern int64_t ram_size;
free_space = (int64_t)stfs.f_bavail * stfs.f_bsize;
if ((ram_size + 8192 * 1024) >= free_space) {
ram_mb = (ram_size / (1024 * 1024));
@@ -202,7 +202,7 @@
#ifdef _BSD
return valloc(size);
#else
-return memalign(4096, size);
+return memalign(TARGET_PAGE_SIZE, size);
#endif
}
No fully correct because it is intended to be the host page size.
+extern int64_t ram_size;
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.
Fabrice.
[Qemu-devel] qemu LICENSE Makefile.target configure cpu-all....
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 translate-all.c target-alpha : op.c translate.c target-arm : op.c translate.c target-cris: op.c translate.c target-i386: exec.h helper.c op.c opreg_template.h translate.c target-m68k: op.c translate.c target-mips: op.c translate.c target-ppc : op.c translate.c target-sh4 : op.c translate.c target-sparc : op.c translate.c Added files: target-i386: helper.h Removed files: . : dyngen-op.h dyngen.h translate-op.c Log message: use the TCG code generator CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/LICENSE?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemu&r1=1.241&r2=1.242 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemu&r1=1.183&r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemu&r1=1.82&r2=1.83 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemu&r1=1.29&r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.131&r2=1.132 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemu&r1=1.59&r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemu&r1=1.73&r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemu&r1=1.122&r2=1.123 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemu&r1=1.24&r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen-op.h?cvsroot=qemu&r1=1.1&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.h?cvsroot=qemu&r1=1.18&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-op.c?cvsroot=qemu&r1=1.4&r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op.c?cvsroot=qemu&r1=1.5&r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/translate.c?cvsroot=qemu&r1=1.8&r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op.c?cvsroot=qemu&r1=1.28&r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemu&r1=1.59&r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/op.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/translate.c?cvsroot=qemu&r1=1.3&r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemu&r1=1.40&r2=1.41 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.98&r2=1.99 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/op.c?cvsroot=qemu&r1=1.52&r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/opreg_template.h?cvsroot=qemu&r1=1.4&r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemu&r1=1.76&r2=1.77 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.h?cvsroot=qemu&rev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/op.c?cvsroot=qemu&r1=1.14&r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemu&r1=1.22&r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemu&r1=1.90&r2=1.91 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemu&r1=1.120&r2=1.121 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemu&r1=1.68&r2=1.69 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemu&r1=1.115&r2=1.116 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemu&r1=1.10&r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemu&r1=1.21&r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemu&r1=1.46&r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemu&r1=1.85&r2=1.86
[Qemu-devel] TCG
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 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. TCG currently only supports x86 and x86_64 hosts. The support of other hosts is broken in QEMU. I don't consider it is a priority to support other hosts although TCG is generic enough to allow it. The performance should not change much at this point. On x86_64 hosts, the x86 and x86_64 targets are faster because of some assembly language optimizations. On x86 hosts, the x86_64 target is faster because TCG can do some optimizations related to the conversion from 64 to 32 bits. No performance change should be noticed on non x86 targets because they are not converted yet. Fabrice.
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 the RAM can be registered with a single
call. I fear you need to do that because of KVM RAM handling
limitations.
On the x86, there is a rather large hole at the top of memory.
Currently, we do separate allocations around this whole.You can't
get away from doing multiple cpu_register_physical_memory calls here.
We've discussed just allocating a single chunk with qemu_ram_alloc since
so many places in QEMU assume that you can do phys_ram_base + PA.
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 :-)
Index: qemu/osdep.c
===
--- qemu.orig/osdep.c2008-01-30 13:47:00.0 -0600
+++ qemu/osdep.c2008-01-30 13:47:31.0 -0600
@@ -113,7 +113,7 @@
int64_t free_space;
int ram_mb;
-extern int ram_size;
+extern int64_t ram_size;
free_space = (int64_t)stfs.f_bavail * stfs.f_bsize;
if ((ram_size + 8192 * 1024) >= free_space) {
ram_mb = (ram_size / (1024 * 1024));
@@ -202,7 +202,7 @@
#ifdef _BSD
return valloc(size);
#else
-return memalign(4096, size);
+return memalign(TARGET_PAGE_SIZE, size);
#endif
}
No fully correct because it is intended to be the host page size.
Indeed. I'm dropping this. It was added for the ia64 port and since
that's not included in this patch set, I'll let them fix it properly
when they submit support for ia64.
+extern int64_t ram_size;
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 each machine though so I'll let the
appropriate people handle that :-)
Regards,
Anthony Liguori
Fabrice.
[Qemu-devel] Re: [PATCH 6/6] QEMU support for the Kernel Virtual Machine interface
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 though so maintaining the bitmap requires removing write protection from the shadow page table entries explicitly whenever you want to reset it. This is not something you would want to do every time you go back and forth between userspace/kernelspace. KVM also doesn't pass the phys_map to the kernel like KQEMU does. Instead, it divides memory into a set of slots. slots are contiguous areas of RAM memory. An IO access that does fall into a slot is treated as MMIO and is then sent to userspace. We then use the phys_map in userspace to dispatch the MMIO operation. There are only a handful of slots and they happen to be arranged in order of most frequent access (I believe) such that you can very quickly determine whether memory is MMIO or not. - Why is kvm_cpu_register_physical_memory() needed ? kqemu can work without it because there is a remapping between physical memory and RAM address. I suggest to add that feature in KVM or to modify cpu_register_physical_memory() to hide it. The only reason the second call exists is to simplify the backwards compatibility code. I will fix it properly though because I do agree with you that it shouldn't be necessary. - If KVM implements its own CPU loop, why are there patches in libqemu.a (CPU core) ? Good question! I looked through the code and some of it was just dead code from before we had our own main loop. The rest is as follows: In exec.c, we need to bump the size of the phys_map to support larger memory (since we use it to dispatch MMIO). We also need to ensure that cpu_interrupt calls into KVM code. There are also hooks for debugging support. We've added more flags to cpu.h that we use when synchronizing KVM register state to CPUState. We also added some additional state to CPUState that we need to use. Other than that, I've removed everything else. Regards, Anthony Liguori Regards, Fabrice.
[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support
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 elegant. It only gets wasted if it gets faulted in. Any it won't get faulted in, so it won't increase the RSS size. We could madvise(MADV_DONTNEED) just to ensure that it's not occupying swap space if you were really paranoid about it. I don't think munmap()'ing malloc()'d memory is a very good idea. glibc may freak out. The alternative is to change all the places that assume phys_ram_base + PA which I don't like very much. Regards, Anthony Liguori
[Qemu-devel] qemu/tcg README
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
Re: [Qemu-devel] Common Xen/KVM patchqueue repository?
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 QEMU changes so unfortunately, things aren't nicely separated into patches. As you may have noticed, I've posted the core KVM support patches and I'm hoping we can merge them pretty soon. I am then going to follow up and try to get the remainder of the patches merged. In the short term, we will probably continue maintaining a git tree against QEMU as a staging repository but I hope that we can regularly sync up (just like we do with Linux). In the long term, I'd like KVM not to maintain a QEMU tree at all. In a broader sense, I know there are concerns about patches getting missed on qemu-devel. I don't think the solution is to maintain a separate patch queue, but to get the patches merged more quickly in the first place. Regards, Anthony Liguori Samuel
[Qemu-devel] Common Xen/KVM patchqueue repository?
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
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
> > 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 each machine though so I'll let the > appropriate people handle that :-) I'd say ram_addr_t is an appropriate type. Currently this is defined in cpu-defs.h. It should probably be moved elsewhere because in the current implementation it's really a host type. If we ever implement >2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). Paul
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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);
+}
+
Why do you need this ? All the RAM can be registered with a single
call. I fear you need to do that because of KVM RAM handling
limitations.
On the x86, there is a rather large hole at the top of memory.
Currently, we do separate allocations around this whole.You can't
get away from doing multiple cpu_register_physical_memory calls here.
We've discussed just allocating a single chunk with qemu_ram_alloc
since so many places in QEMU assume that you can do phys_ram_base + PA.
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 elegant.
--
Any sufficiently difficult bug is indistinguishable from a feature.
Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 = qemu_ram_alloc(above_4g_mem_size);
: +cpu_register_physical_memory(0x1,
: above_4g_mem_size, ram_addr);
: +}
: +
: >>>
: >>> Why do you need this ? All the RAM can be registered with a single
: >>> call. I fear you need to do that because of KVM RAM handling
: >>> limitations.
: >>
: >> On the x86, there is a rather large hole at the top of memory.
: >> Currently, we do separate allocations around this whole.You can't
: >> get away from doing multiple cpu_register_physical_memory calls here.
: >> We've discussed just allocating a single chunk with qemu_ram_alloc
: >> since so many places in QEMU assume that you can do phys_ram_base + PA.
: >>
: >> 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 elegant.
: >
:
: Linux doesn't commit mapped memory until it's faulted. As for other
: platforms, who knows?
Most BSDs are also similarly overcommitted. 95% of the users think
this is a feature, but the other 5 argue 20 times harder sometimes :-(
Warner
Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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_addr);
+}
+
Why do you need this ? All the RAM can be registered with a single
call. I fear you need to do that because of KVM RAM handling
limitations.
On the x86, there is a rather large hole at the top of memory.
Currently, we do separate allocations around this whole.You can't
get away from doing multiple cpu_register_physical_memory calls here.
We've discussed just allocating a single chunk with qemu_ram_alloc
since so many places in QEMU assume that you can do phys_ram_base + PA.
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 elegant.
Linux doesn't commit mapped memory until it's faulted. As for other
platforms, who knows?
Re: [Qemu-devel] TCG
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/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 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. TCG currently only supports x86 and x86_64 hosts. The support of other hosts is broken in QEMU. I don't consider it is a priority to support other hosts although TCG is generic enough to allow it. The performance should not change much at this point. On x86_64 hosts, the x86 and x86_64 targets are faster because of some assembly language optimizations. On x86 hosts, the x86_64 target is faster because TCG can do some optimizations related to the conversion from 64 to 32 bits. No performance change should be noticed on non x86 targets because they are not converted yet. Fabrice.
Re: [Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support
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. (Xen uses less of the qemu tree than KVM, I think.)
In Xen, the guest memory is not in general mapped into the host qemu's
address space.
Ian.
[Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 was for each machine though so I'll let the appropriate people handle that :-) I'd say ram_addr_t is an appropriate type. Currently this is defined in cpu-defs.h. It should probably be moved elsewhere because in the current implementation it's really a host type. If we ever implement >2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). I agree. Fabrice.
[Qemu-devel] [PATCH] OpenGL for OS X
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:
[new] draws dirty lines of the window as needed, implemented with
OpenGL (used the extensions as proposed by Pierre)
[new] window can be resized
[fix] conditional builds for Leopard, without linking to a specific sdk
[fix] lineflicker in fullscreen mode
The Question is, where to draw the line - or - if it needs a switch
for CG/OpenGL support for cocoa.
Please test and comment.
Mike
[1] http://www.kberg.ch/qemu/091patches/cocoa_m_OpenGL.diff.gz
--- /Users/mike/Documents/Qemu091gcc4/qemu/cocoa.m_original.m
2008-01-21 17:11:30.0 +0100
+++ /Users/mike/Documents/Qemu091gcc4/qemu/cocoa.m 2008-02-01
17:11:41.0 +0100
@@ -22,12 +22,17 @@
* THE SOFTWARE.
*/
+#include
+
#import
+#import
+
#include "qemu-common.h"
#include "console.h"
#include "sysemu.h"
+#define titleBarHeight 21.0
//#define DEBUG
@@ -54,6 +59,16 @@
int bitsPerPixel;
} QEMUScreen;
+typedef struct {
+float x;
+float y;
+float width;
+float height;
+float dx;
+float dy;
+float zoom;
+} COCOADisplayProperties;
+
int qemu_main(int argc, char **argv); // main defined in qemu/vl.c
NSWindow *normalWindow;
id cocoaView;
@@ -246,18 +261,19 @@
QemuCocoaView
--
*/
[EMAIL PROTECTED] QemuCocoaView : NSView
[EMAIL PROTECTED] QemuCocoaView : NSOpenGLView
{
QEMUScreen screen;
+COCOADisplayProperties displayProperties;
NSWindow *fullScreenWindow;
-float cx,cy,cw,ch,cdx,cdy;
-CGDataProviderRef dataProviderRef;
+GLuint screen_tex;
int modifiers_state[256];
BOOL isMouseGrabed;
BOOL isFullscreen;
BOOL isAbsoluteEnabled;
BOOL isTabletEnabled;
}
+- (void) setContentDimensionsForFrame:(NSRect)rect;
- (void) resizeContentToWidth:(int)w height:(int)h displayState:
(DisplayState *)ds;
- (void) grabMouse;
- (void) ungrabMouse;
@@ -266,17 +282,16 @@
- (void) setAbsoluteEnabled:(BOOL)tIsAbsoluteEnabled;
- (BOOL) isMouseGrabed;
- (BOOL) isAbsoluteEnabled;
-- (float) cdx;
-- (float) cdy;
- (QEMUScreen) gscreen;
+- (COCOADisplayProperties) displayProperties;
@end
@implementation QemuCocoaView
-- (id)initWithFrame:(NSRect)frameRect
+- (id)initWithFrame:(NSRect)frameRect pixelFormat:
(NSOpenGLPixelFormat *)format
{
-COCOA_DEBUG("QemuCocoaView: initWithFrame\n");
+COCOA_DEBUG("QemuCocoaView: initWithFrame:pixelFormat\n");
-self = [super initWithFrame:frameRect];
+self = [super initWithFrame:frameRect pixelFormat:format];
if (self) {
screen.bitsPerComponent = 8;
@@ -284,6 +299,8 @@
screen.width = frameRect.size.width;
screen.height = frameRect.size.height;
+displayProperties.zoom = 1.0;
+
}
return self;
}
@@ -295,110 +312,118 @@
if (screenBuffer)
free(screenBuffer);
-if (dataProviderRef)
-CGDataProviderRelease(dataProviderRef);
-
[super dealloc];
}
- (void) drawRect:(NSRect) rect
{
-COCOA_DEBUG("QemuCocoaView: drawRect\n");
+COCOA_DEBUG("QemuCocoaView: drawRect: NSRect(%f, %f, %f, %f)\n",
rect.origin.x, rect.origin.y, rect.size.width, rect.size.height);
if ((int)screenBuffer == -1)
return;
-// get CoreGraphic context
-CGContextRef viewContextRef = [[NSGraphicsContext currentContext]
graphicsPort];
-CGContextSetInterpolationQuality (viewContextRef,
kCGInterpolationNone);
-CGContextSetShouldAntialias (viewContextRef, NO);
-
-// draw screen bitmap directly to Core Graphics context
-if (dataProviderRef) {
-CGImageRef imageRef = CGImageCreate(
-screen.width, //width
-screen.height, //height
-screen.bitsPerComponent, //bitsPerComponent
-screen.bitsPerPixel, //bitsPerPixel
-(screen.width * 4), //bytesPerRow
+// remove old texture
+if( screen_tex != 0) {
+glDeleteTextures(1, &screen_tex);
+}
+
+screen_tex = 1;
+float onePixel[2];
+onePixel[0] = 2.0 / displayProperties.width;
+onePixel[1] = 2.0 / displayProperties.height;
+
+//calculate the texure rect
+NSRect clipRect;
+clipRect = NSMakeRect(
+0.0, // we update the whole width, as QEMU in vga is always
updating whole memory pages)
+floor((float)screen.height - (rect.origin.y +
rect.size.height) / displayProperties.dy),
+(float)screen.width,
+ceil(rect.size.height / displayProperties.dy));
+int start = (int)clipRect.origin.y * screen.width * 4;
+unsigned char *startPointer = screenBuffer;
+
+//adapt the drawRect to the textureRect
+rect = NSMakeRect(
+0.0, // we update the whole width, as QEMU in vga is al
Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 -kernel and large memory anyway :-) : > Won't that cause all of the memory in the hole to be wasted? : Linux doesn't commit mapped memory until it's faulted. As for other : platforms, who knows? It would appear that modern Windows also overcommits: "This memory isn’t allocated until the application explicitly uses it. Once the application uses the page, it becomes committed." "When an application touches a virtual memory page (reads/write/ programmatically commits) the page becomes a committed page. It is now backed by a physical memory page. This will usually be a physical RAM page, but could eventually be a page in the page file on the hard disk, or it could be a page in a memory mapped file on the hard disk." -- http://blogs.msdn.com/ntdebugging/archive/2007/10/10/the-memory- shell-game.aspx So it looks like you could get away with this on the two big host platforms. Most BSDs are also similarly overcommitted. 95% of the users think this is a feature, but the other 5 argue 20 times harder sometimes :-( Some of us don't like the idea that our operating systems lie about how many resources they have available, then have to club innocent processes over the head when their lies catch up with them. ;) Phil
Re: [Qemu-devel] TCG
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_LINUX_COMPILER_H=1 -m32 -I. -I.. -I/home/qemu/target-i386
-I/home/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -I/home/qemu/tcg -I/home/qemu/tcg/i386
-I/home/qemu/fpu -I/home/qemu/linux-user -I/home/qemu/linux-user/i386 -c
-o op.o /home/qemu/target-i386/op.c
/home/qemu/target-i386/ops_sse.h: In function ‘op_pshufw_mmx’:
/home/qemu/target-i386/ops_sse.h:593: error: unable to find a register to
spill in class ‘GENERAL_REGS’
/home/qemu/target-i386/ops_sse.h:593: error: this is the insn:
(insn:HI 17 16 18 0 /home/qemu/target-i386/ops_sse.h:588 (set
(strict_low_part (subreg:HI (reg/v:DI 63 [ r ]) 0))
(mem/s/j:HI (plus:SI (mult:SI (reg:SI 64)
(const_int 2 [0x2]))
(reg/v/f:SI 59 [ s ])) [0 ._w S2 A16])) 40
{*movstricthi_1} (insn_list:REG_DEP_TRUE 51 (insn_list:REG_DEP_TRUE 12
(insn_list:REG_DEP_TRUE 16 (nil
(expr_list:REG_DEAD (reg:SI 64)
(nil)))
/home/qemu/target-i386/ops_sse.h:593: confused by earlier errors, bailing
out
-- snap --
and in i386-softmmu it is similar:
-- 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_LINUX_COMPILER_H=1 -m32 -I. -I.. -I/home/qemu/target-i386
-I/home/qemu -MMD -MP -DNEED_CPU_H -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -I/home/qemu/tcg -I/home/qemu/tcg/i386
-I/home/qemu/fpu -DHAS_AUDIO -DHAS_AUDIO_CHOICE -I/home/qemu/slirp -c -o
op.o /home/qemu/target-i386/op.c
/home/qemu/target-i386/ops_template_mem.h: In function
‘op_cmpxchgb_kernel_T0_T1_EAX_cc’:
../softmmu_header.h:170: error: can't find a register in class ‘Q_REGS’
while reloading ‘asm’
-- snap --
This is on OpenSUSE 10.2, gcc (GCC) 4.1.2 20061115 (prerelease) (SUSE
Linux), with "./configure --disable-gcc-check", and this patch on top of
": typos, Fri Feb 1 13:01:47 2008 +":
-- snip --
[PATCH] Some Linux setups need linux/compiler.h; if it exists, include it
Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---
configure |3 +++
usb-linux.c |3 +++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index bcb958d..330020d 100755
--- a/configure
+++ b/configure
@@ -194,6 +194,9 @@ linux_user="yes"
if [ "$cpu" = "i386" -o "$cpu" = "x86_64" ] ; then
kqemu="yes"
fi
+if [ -f /usr/include/linux/compiler.h ] ; then
+OS_CFLAGS="-DCONFIG_HAS_LINUX_COMPILER_H=1"
+fi
;;
esac
diff --git a/usb-linux.c b/usb-linux.c
index d3e4e2e..68fdbd2 100644
--- a/usb-linux.c
+++ b/usb-linux.c
@@ -28,6 +28,9 @@
#if defined(__linux__)
#include
#include
+#ifdef CONFIG_HAS_LINUX_COMPILER_H
+#include
+#endif
#include
#include
#include
--
1.5.4.rc5.32.gc7b9
-- snap --
Ciao,
Dscho
[Qemu-devel] Re: [kvm-devel] [PATCH 1/6] Use correct types to enable > 2G support
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 was for each machine though so I'll let the appropriate people handle that :-) I'd say ram_addr_t is an appropriate type. Currently this is defined in cpu-defs.h. It should probably be moved elsewhere because in the current implementation it's really a host type. Okay, it turns out that patch needed a lot of refactoring. I agree that changing ram_addr_t to a host type is the right thing to do. If we ever implement >2G ram on a 32-bit host this may need some rethinking. We can deal with that if/when it happens though. Requiring a 64-bit host for large quantities of ram seems an acceptable limitation (N.B. I'm only talking about ram size, not target physical address size). My current limitation is < 2GB if HOST_BITS==32 or defined(USE_KQEMU). USE_KQEMU restricts the size of the phys_map which limits the maximum physical address size. I guess technically USE_KQEMU could allow up to around 3GB of ram but I preferred to simplify the logic. Regards, Anthony Liguori Paul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 the places we
care about. (Xen uses less of the qemu tree than KVM, I think.)
Support for the map cache in the Xen tree is a rather big change that
I'm not going to attempt to support it in this patch series.
I'd rather preserve the phys_ram_base + PA assumption because it allows
us to be able to do support > 1 page DMA operations for our virtual IO
drivers. If you break the assumption that physically contiguous memory
in the guest is virtual contiguous memory in the host, things get pretty
ugly.
Regards,
Anthony Liguori
In Xen, the guest memory is not in general mapped into the host qemu's
address space.
Ian.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [Qemu-devel] 3D acceleration
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 Wine. I don't care much about the 3D stuff but wouldn't a BOCHS graphics adapter with a special driver for the guest OS allow arbitrary screen resolutions with minimal effort? I would really like that feature. -- Christian Laursen
Re: [Qemu-devel] 3D acceleration
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, Direct3D commands > > would be passed from Windows to Linux Wine. > > I don't care much about the 3D stuff but wouldn't a BOCHS graphics > adapter with a special driver for the guest OS allow arbitrary screen > resolutions with minimal effort? Yes, I agree. Since it is minimal effort, when do you start? Thanks, Dscho
Re: [Qemu-devel] 3D acceleration
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 > > > OpenGL commands from Windows to Linux OpenGL. Also, Direct3D commands > > > would be passed from Windows to Linux Wine. > > > > I don't care much about the 3D stuff but wouldn't a BOCHS graphics > > adapter with a special driver for the guest OS allow arbitrary screen > > resolutions with minimal effort? > > Yes, I agree. Since it is minimal effort, when do you start? Or you could just use the VMware adapter that already exists. Paul
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 like very much.
> >>
> >
> > We would ideally like to do this for Xen, at least in the places we
> > care about. (Xen uses less of the qemu tree than KVM, I think.)
> >
>
> Support for the map cache in the Xen tree is a rather big change that
> I'm not going to attempt to support it in this patch series.
>
> I'd rather preserve the phys_ram_base + PA assumption because it allows
> us to be able to do support > 1 page DMA operations for our virtual IO
> drivers. If you break the assumption that physically contiguous memory
> in the guest is virtual contiguous memory in the host, things get pretty
> ugly.
Well Xen i386 has no choice but to use the map cache, since PAE lets
i386 guests have as much as 100 GB of memory & there's no way you can
map that into QEMU's 32-bit userspace. So if virt IO has a dependancy
on contigious memory access in QEMU its not going to play nice with
Xen.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Re: [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 won't randomly crash when too much memory is faulted, but will return 0 from malloc() earlier. For those few systems, use MAP_NORESERVE if you still need to allocate the address space. -- Jamie
[Qemu-devel] qemu hw/sun4m.c pc-bios/README pc-bios/openbios...
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 OpenBIOS image to SVN revision 185. Changes: r184: Enforce malloc alignment r185: Move AUX1 and AUX2 to correct locations, rename APC CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sun4m.c?cvsroot=qemu&r1=1.82&r2=1.83 http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemu&r1=1.20&r2=1.21 http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemu&rev=1.15
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
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 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. (Xen uses less of the qemu tree than KVM, I think.)
Support for the map cache in the Xen tree is a rather big change that
I'm not going to attempt to support it in this patch series.
I'd rather preserve the phys_ram_base + PA assumption because it allows
us to be able to do support > 1 page DMA operations for our virtual IO
drivers. If you break the assumption that physically contiguous memory
in the guest is virtual contiguous memory in the host, things get pretty
ugly.
Well Xen i386 has no choice but to use the map cache, since PAE lets
i386 guests have as much as 100 GB of memory & there's no way you can
map that into QEMU's 32-bit userspace. So if virt IO has a dependancy
on contigious memory access in QEMU its not going to play nice with
Xen.
For KVM (and it sounds like QEMU), we're just making the statement that
32-bit hosts cannot support > 2GB guests. I know that's a regression
for Xen but in all fairness, I did raise this as an objection when the
map cache was first introduced :-)
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.
Regards,
Anthony Liguori
Dan.
Re: [Qemu-devel] [PATCH 0/4] Intel Mac OS X Host support
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 make Mac OS X host support as compatible as possible to the existing Linux host and PowerPC Mac OS X support. Of course this means, that as long as Linux gcc4 support is broken, it won't work on Mac OS X either. Nevertheless all changes necessary to support the binary format (Mach-O) and several other minor issues that are Mac specific can be easily added to the existing code base without harming other platforms. This way people who want to run qemu on Mac OS X only have to maintain gcc4 patches and no Apple specific ones. Please comment on these patches. Commits are welcome too. Regards, Alex Hi Alex, txs for preparing Ground for mach-o. I think this is the right way to go, as these patches in one or the other form are needed with tcg, too. ATM I try to test on a i386 Mac, but I somehow lost track of all patches. I tried a build with qemu 20081018 and gcc patches 1/5, 2/5, 3/5, 4/5 and 1/4, 2/4, 3/4 and 4/4... it builds, but loads of /var/folders/Td/TdBadE0bFQuD2AmzgK43qTI/-Tmp-//ccIs2Keq.s: 31549:indirect call without `*' and the binary segfaults immediately. Did I miss a patch... or is that where i start to debug? ;) Mike smime.p7s Description: S/MIME cryptographic signature
Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/6] Use correct types to enable > 2G support
> 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 accesses (Currently only some of the embedded LCD controllers) is going to break as soon as you start introducing IOMMUs. There have been several threads on this list about having a sane DMA infrastructure. Paul
[Qemu-devel] [PATCH 2/6] Use correct types to enable > 2G support (v2)
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_t to cpu-all.h and switched
ram_size to be a ram_addr_t. I've also removed the memory limit check for
x86_64 (provided kqemu isn't enabled) and enabled the use of a 'M' or 'G'
suffix for the -m option. I've also tried to do a more thorough job of
updating the code to use the proper types.
This patch also includes support for setting up > 2GB of memory for
TARGET_I386. KVM works quite happily with 5GB of ram but I suspect there
are still some uint32_t's in the non-KVM does not work when using more than
3GB of RAM.
Index: qemu/cpu-all.h
===
--- qemu.orig/cpu-all.h 2008-02-01 15:24:45.0 -0600
+++ qemu/cpu-all.h 2008-02-01 15:28:48.0 -0600
@@ -695,7 +695,7 @@
/* page related stuff */
-#define TARGET_PAGE_SIZE (1 << TARGET_PAGE_BITS)
+#define TARGET_PAGE_SIZE (1ul << TARGET_PAGE_BITS)
#define TARGET_PAGE_MASK ~(TARGET_PAGE_SIZE - 1)
#define TARGET_PAGE_ALIGN(addr) (((addr) + TARGET_PAGE_SIZE - 1) &
TARGET_PAGE_MASK)
@@ -814,9 +814,12 @@
int cpu_inl(CPUState *env, int addr);
#endif
+/* address in the RAM (different from a physical address) */
+typedef unsigned long ram_addr_t;
+
/* memory API */
-extern int phys_ram_size;
+extern ram_addr_t phys_ram_size;
extern int phys_ram_fd;
extern uint8_t *phys_ram_base;
extern uint8_t *phys_ram_dirty;
@@ -844,7 +847,7 @@
unsigned long size,
unsigned long phys_offset);
uint32_t cpu_get_physical_page_desc(target_phys_addr_t addr);
-ram_addr_t qemu_ram_alloc(unsigned int size);
+ram_addr_t qemu_ram_alloc(unsigned long size);
void qemu_ram_free(ram_addr_t addr);
int cpu_register_io_memory(int io_index,
CPUReadMemoryFunc **mem_read,
Index: qemu/exec.c
===
--- qemu.orig/exec.c2008-02-01 15:24:45.0 -0600
+++ qemu/exec.c 2008-02-01 15:28:48.0 -0600
@@ -73,6 +73,8 @@
#define TARGET_VIRT_ADDR_SPACE_BITS 42
#elif defined(TARGET_PPC64)
#define TARGET_PHYS_ADDR_SPACE_BITS 42
+#elif defined(TARGET_X86_64) && !defined(USE_KQEMU)
+#define TARGET_PHYS_ADDR_SPACE_BITS 42
#else
/* Note: for compatibility with kqemu, we use 32 bits for x86_64 */
#define TARGET_PHYS_ADDR_SPACE_BITS 32
@@ -87,7 +89,7 @@
uint8_t code_gen_buffer[CODE_GEN_BUFFER_SIZE] __attribute__((aligned (32)));
uint8_t *code_gen_ptr;
-int phys_ram_size;
+ram_addr_t phys_ram_size;
int phys_ram_fd;
uint8_t *phys_ram_base;
uint8_t *phys_ram_dirty;
@@ -112,7 +114,7 @@
typedef struct PhysPageDesc {
/* offset in host memory of the page + io_index in the low 12 bits */
-uint32_t phys_offset;
+ram_addr_t phys_offset;
} PhysPageDesc;
#define L2_BITS 10
@@ -1980,7 +1982,7 @@
static int subpage_register (subpage_t *mmio, uint32_t start, uint32_t end,
int memory);
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys,
int orig_memory);
#define CHECK_SUBPAGE(addr, start_addr, start_addr2, end_addr, end_addr2, \
need_subpage) \
@@ -2084,12 +2086,12 @@
}
/* XXX: better than nothing */
-ram_addr_t qemu_ram_alloc(unsigned int size)
+ram_addr_t qemu_ram_alloc(unsigned long size)
{
ram_addr_t addr;
if ((phys_ram_alloc_offset + size) >= phys_ram_size) {
-fprintf(stderr, "Not enough memory (requested_size = %u, max memory =
%d)\n",
-size, phys_ram_size);
+fprintf(stderr, "Not enough memory (requested_size = %lu, max memory =
%" PRIu64 ")\n",
+size, (uint64_t)phys_ram_size);
abort();
}
addr = phys_ram_alloc_offset;
@@ -2432,7 +2434,7 @@
return 0;
}
-static void *subpage_init (target_phys_addr_t base, uint32_t *phys,
+static void *subpage_init (target_phys_addr_t base, ram_addr_t *phys,
int orig_memory)
{
subpage_t *mmio;
Index: qemu/hw/boards.h
===
--- qemu.orig/hw/boards.h 2008-02-01 15:23:46.0 -0600
+++ qemu/hw/boards.h2008-02-01 15:28:48.0 -0600
@@ -3,7 +3,7 @@
#ifndef HW_BOARDS_H
#define HW_BOARDS_H
-typedef void QEMUMachineInitFunc(int ram_size, int vga_ram_size,
+typedef void QEMUMachineInitFunc(ram_addr_t ram_size, int vga_ram_size,
const char *boot_device, DisplayState *ds,
const char *kernel_filename,
const
[Qemu-devel] [PATCH 4/6] Fix daemonize options (v2)
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 changed since v1.
Index: qemu/vl.c
===
--- qemu.orig/vl.c 2008-02-01 11:53:42.0 -0600
+++ qemu/vl.c 2008-02-01 11:53:44.0 -0600
@@ -8779,11 +8779,6 @@
}
#ifndef _WIN32
-if (daemonize && !nographic && vnc_display == NULL) {
- fprintf(stderr, "Can only daemonize if using -nographic or -vnc\n");
- daemonize = 0;
-}
-
if (daemonize) {
pid_t pid;
@@ -8821,7 +8816,6 @@
exit(1);
umask(027);
- chdir("/");
signal(SIGTSTP, SIG_IGN);
signal(SIGTTOU, SIG_IGN);
@@ -9087,6 +9081,7 @@
if (len != 1)
exit(1);
+ chdir("/");
TFR(fd = open("/dev/null", O_RDWR));
if (fd == -1)
exit(1);
[Qemu-devel] [PATCH 5/6] Tell BIOS about the number of CPUs (v2)
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-liner. Index: qemu/hw/pc.c === --- qemu.orig/hw/pc.c 2008-02-01 11:53:47.0 -0600 +++ qemu/hw/pc.c2008-02-01 11:53:52.0 -0600 @@ -210,6 +210,7 @@ rtc_set_memory(s, 0x5c, (unsigned int)above_4g_mem_size >> 24); rtc_set_memory(s, 0x5d, (uint64_t)above_4g_mem_size >> 32); } +rtc_set_memory(s, 0x5f, smp_cpus - 1); if (ram_size > (16 * 1024 * 1024)) val = (ram_size / 65536) - ((16 * 1024 * 1024) / 65536);
[Qemu-devel] [PATCH 3/6] SCI fixes (v2)
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
===
--- qemu.orig/hw/acpi.c 2008-02-01 10:00:45.0 -0600
+++ qemu/hw/acpi.c 2008-02-01 11:12:46.0 -0600
@@ -49,6 +49,7 @@
uint8_t smb_data1;
uint8_t smb_data[32];
uint8_t smb_index;
+qemu_irq irq;
} PIIX4PMState;
#define RTC_EN (1 << 10)
@@ -71,6 +72,8 @@
#define SMBHSTDAT1 0x06
#define SMBBLKDAT 0x07
+PIIX4PMState *pm_state;
+
static uint32_t get_pmtmr(PIIX4PMState *s)
{
uint32_t d;
@@ -97,11 +100,12 @@
pmsts = get_pmsts(s);
sci_level = (((pmsts & s->pmen) &
(RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
-qemu_set_irq(s->dev.irq[0], sci_level);
+qemu_set_irq(s->irq, sci_level);
/* schedule a timer interruption if needed */
if ((s->pmen & TMROF_EN) && !(pmsts & TMROF_EN)) {
expire_time = muldiv64(s->tmr_overflow_time, ticks_per_sec, PM_FREQ);
qemu_mod_timer(s->tmr_timer, expire_time);
+s->tmr_overflow_time += 0x80;
} else {
qemu_del_timer(s->tmr_timer);
}
@@ -467,7 +471,8 @@
return 0;
}
-i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base)
+i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+ qemu_irq sci_irq)
{
PIIX4PMState *s;
uint8_t *pci_conf;
@@ -475,6 +480,7 @@
s = (PIIX4PMState *)pci_register_device(bus,
"PM", sizeof(PIIX4PMState),
devfn, NULL, pm_write_config);
+pm_state = s;
pci_conf = s->dev.config;
pci_conf[0x00] = 0x86;
pci_conf[0x01] = 0x80;
@@ -514,5 +520,16 @@
register_savevm("piix4_pm", 0, 1, pm_save, pm_load, s);
s->smbus = i2c_init_bus();
+s->irq = sci_irq;
return s->smbus;
}
+
+#if defined(TARGET_I386)
+void qemu_system_powerdown(void)
+{
+if(pm_state->pmen & PWRBTN_EN) {
+pm_state->pmsts |= PWRBTN_EN;
+ pm_update_sci(pm_state);
+}
+}
+#endif
Index: qemu/hw/mips_malta.c
===
--- qemu.orig/hw/mips_malta.c 2008-02-01 11:06:54.0 -0600
+++ qemu/hw/mips_malta.c2008-02-01 11:12:46.0 -0600
@@ -905,7 +905,7 @@
piix4_devfn = piix4_init(pci_bus, 80);
pci_piix4_ide_init(pci_bus, hd, piix4_devfn + 1, i8259);
usb_uhci_piix4_init(pci_bus, piix4_devfn + 2);
-smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100);
+smbus = piix4_pm_init(pci_bus, piix4_devfn + 3, 0x1100, i8259[9]);
eeprom_buf = qemu_mallocz(8 * 256); /* XXX: make this persistent */
for (i = 0; i < 8; i++) {
/* TODO: Populate SPD eeprom data. */
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c 2008-02-01 11:07:04.0 -0600
+++ qemu/hw/pc.c2008-02-01 11:12:46.0 -0600
@@ -1006,7 +1006,7 @@
i2c_bus *smbus;
/* TODO: Populate SPD eeprom data. */
-smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100);
+smbus = piix4_pm_init(pci_bus, piix3_devfn + 3, 0xb100, i8259[9]);
for (i = 0; i < 8; i++) {
smbus_eeprom_device_init(smbus, 0x50 + i, eeprom_buf + (i * 256));
}
Index: qemu/hw/pc.h
===
--- qemu.orig/hw/pc.h 2008-02-01 10:00:45.0 -0600
+++ qemu/hw/pc.h2008-02-01 11:12:46.0 -0600
@@ -88,7 +88,8 @@
/* acpi.c */
extern int acpi_enabled;
-i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base);
+i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t smb_io_base,
+ qemu_irq sci_irq);
void piix4_smbus_register_device(SMBusDevice *dev, uint8_t addr);
void acpi_bios_init(void);
Index: qemu/hw/piix_pci.c
===
--- qemu.orig/hw/piix_pci.c 2008-02-01 10:00:45.0 -0600
+++ qemu/hw/piix_pci.c 2008-02-01 11:12:46.0 -0600
@@ -220,7 +220,6 @@
{
int i, pic_irq, pic_level;
-piix3_dev->config[0x60 + irq_num] &= ~0x80; // enable bit
pci_irq_levels[irq_num] = level;
/* now we change the pic irq level according to the piix irq mappings */
Index: qemu/sysemu.h
===
--- qemu.orig/sysemu.h 2008-02-01 11:06:54.0 -0600
+++ qemu/sysemu.h 2008-02-01 11:12:46.0 -0600
@@ -31,12 +31,16 @@
void qemu_system_reset_request(void);
void qemu_system_shutdown_request(void);
void qemu_system_powerdown_request(void);
-#if !defined(TARGET_SPARC)
+int qemu_shutdown_requested(void);
+int qemu_reset_requested(void);
+int
[Qemu-devel] [PATCH 0/6] Support for the Kernel Virtual Machine interface (v2)
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 all of the changes in the KVM QEMU branch (such as virtio, live migration, extboot, etc). However, if we can get these first portions merged, I will follow up with the remainder of the changes and I believe we can be fully merged in the very near future. The first 5 patches of this series are not KVM specific but are critical fixes for KVM to be functional. The 6th patch provides KVM support. The goal in providing KVM support is to make sure that when KVM support is not compiled in, the code paths aren't changed at all. I hope this makes it very easy to merge. KVM moves very quickly, so I'd appreciate if these patches can be reviewed as soon as possible as it's going to be tough to keep them in sync with the main KVM tree while they're out of tree. To enable KVM support, you have to have to libkvm installed. You should also explicitly specify the location of your kernel tree (with KVM headers) with the --kernel-path option. We will improve libkvm such that this isn't required in future versions. KVM also has an enhanced Bochs BIOS. I've tested these patches with out it and it's not strictly necessary for basic functionality. I would recommend pulling in a copy of it though as it has useful fixes even in the absence of KVM. A very large number of people have contributed to these patches with Avi Kivity being the main developer of this support. For a full listing of contributers, please consult the KVM ChangeLog[1]. Since v2, I've incorporated all the feedback received for v1. I was able to drop the option ROM refactoring too but introduced a new patch to fix an obvious bug with the VMware vga initialization pointed out by Paul Brook. [1] http://kvm.qumranet.com/kvmwiki/ChangeLog
[Qemu-devel] [PATCH 1/6] Fix VMware VGA init call
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 @@
} else if (vmsvga_enabled) {
if (pci_enabled)
pci_vmsvga_init(pci_bus, ds, phys_ram_base + ram_size,
-ram_size, vga_ram_size);
+vga_ram_addr, vga_ram_size);
else
fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
} else {
[Qemu-devel] qemu cpu-all.h cpu-exec.c qemu-doc.texi vl.c
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/qemu/cpu-all.h?cvsroot=qemu&r1=1.83&r2=1.84 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemu&r1=1.132&r2=1.133 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemu&r1=1.183&r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.401&r2=1.402
[Qemu-devel] Re: [PATCH 1/6] Fix VMware VGA init call
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/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 @@
} else if (vmsvga_enabled) {
if (pci_enabled)
pci_vmsvga_init(pci_bus, ds, phys_ram_base + ram_size,
-ram_size, vga_ram_size);
+vga_ram_addr, vga_ram_size);
else
fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
} else {
Subject: [PATCH 1/6] Fix VMware VGA init call (v2)
Cc: Avi Kivity <[EMAIL PROTECTED]>
Cc: Fabrice Bellard <[EMAIL PROTECTED]>
Cc: Paul Brook <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
This was never corrected during the ram_alloc() conversion.
Since v1, we update both uses of ram_size.
Index: qemu/hw/pc.c
===
--- qemu.orig/hw/pc.c 2008-02-01 16:21:40.0 -0600
+++ qemu/hw/pc.c 2008-02-01 16:22:04.0 -0600
@@ -868,8 +868,8 @@
}
} else if (vmsvga_enabled) {
if (pci_enabled)
-pci_vmsvga_init(pci_bus, ds, phys_ram_base + ram_size,
-ram_size, vga_ram_size);
+pci_vmsvga_init(pci_bus, ds, phys_ram_base + vga_ram_size,
+vga_ram_addr, vga_ram_size);
else
fprintf(stderr, "%s: vmware_vga: no PCI bus\n", __FUNCTION__);
} else {
[Qemu-devel] qemu Makefile.target
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/qemu/Makefile.target?cvsroot=qemu&r1=1.242&r2=1.243
Re: [Qemu-devel] TCG
> 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 playing with this a bit with the ARM target I found it very easy to get variables, immediate values and register indexes mixed up. e.g. using gen_add_i32 instead of gen_add_i32, or gen_mov_i32(foo, rn) instead of gen_ld_i32(foo, cpu_env, offsetof(CPUState, regs[rn]). Would you object to a patch that changed then gen_* functions in tgc_op to use an opaque type for variables? For performance reasons we probably want to keep it as an in in production builds, but for debugging it's nice to be able to catch the types of error mentioned above. IMHO it also helps to improve the clarity of the code. The changes should be mostly mechanical. Paul
