Re: [Qemu-devel] qemu block-qcow.c block-qcow2.c block-vmdk.c bl...
IMHO it would be much simpler to do all the tests in the block format handlers. Fabrice. Aurelien Jarno wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Aurelien Jarno aurel32 08/03/11 17:17:59 Modified files: . : block-qcow.c block-qcow2.c block-vmdk.c block.c block.h block_int.h Log message: Fix CVE-2008-0928 - insufficient block device address range checking Qemu 0.9.1 and earlier does not perform range checks for block device read or write requests, which allows guest host users with root privileges to access arbitrary memory and escape the virtual machine. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow.c?cvsroot=qemur1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/qemu/block-qcow2.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/block-vmdk.c?cvsroot=qemur1=1.19r2=1.20 http://cvs.savannah.gnu.org/viewcvs/qemu/block.c?cvsroot=qemur1=1.54r2=1.55 http://cvs.savannah.gnu.org/viewcvs/qemu/block.h?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/block_int.h?cvsroot=qemur1=1.16r2=1.17
Re: [Qemu-devel] qemu block-qcow.c block-qcow2.c block-vmdk.c bl...
Aurelien Jarno wrote:
Fabrice Bellard a écrit :
IMHO it would be much simpler to do all the tests in the block format
handlers.
Do you mean move all the tests into block-{qcow,qcow2,vmdk}.c ?
I suggest reverting the patch and writing correct tests in
block-{qcow,qcow2,vmdk}.c. BTW, bs-total_sectors is not a good
indicator of the device size in case of removable devices for example.
Fabrice.
Re: [Qemu-devel] [PATCH] Modify qemu-img to mount locally disk image using NBD (v2)
Laurent Vivier wrote:
This patch is a new version of qemu-img using NBD device to mount Qemu
disk image.
To not hang on UP system, it needs following patch:
http://article.gmane.org/gmane.linux.drivers.nbd.general/42
If you want to use loop to see partitions, you need this patch:
http://article.gmane.org/gmane.linux.kernel/651269
otherwise use kpartx (see kpartx package of your distro).
This patch implements in qemu-img the client and the server of the nbd
protocol.
Moreover, to avoid to specify a port to use, it creates a UNIX socket instead
of
a INET socket.
It adds two actions to qemu-img:
- bind, to bind a disk image to a NBD device,
qemu-img bind [-d] [-f fmt] device filename
('-d' to daemonize)
- unbind, to unbind it.
qemu-img unbind device
[...]
Perhaps adding a new specialized tool would be better as there is no
direct relation with qemu-img.
Fabrice.
[Qemu-devel] Re: TCG on i386 can't generate qemu_st64 for 32-bit target
Blue Swirl wrote: Hi, There is a problem with the Sparc32 target on i386 host. Store double word op (std) cannot be generated and TCG just aborts. It looks like the registers are so few on i386 that TCG can't find registers for the qemu_st64 call. The problem does not appear on x86_64 host, or for Sparc64 target (stx/ldx) on i386, or with 64-bit load (ldd) on Sparc32 target. The attached patch would work around the problem, but I agree that it's ugly and it would bring back one instance of T2 use. I also tried preallocating a 64-bit register but that didn't help. I suppose instead the following piece (tcg/i386/tcg-target.c:737) could be modified to lower the pressure for registers but I'm not that familiar with x86 assembly. [...] There are not enough free registers because of the legacy 3 cpu_T[n] fixed registers. Once you have no helpers using cpu_T[n] implicitely, it will be possible to allocate cpu_T[n] as normal temporaries and to free the associated fixed registers. Before that your solution is acceptable. Another hack would be to force the 'r_dword' variable to be stored in cpu_T[1] and cpu_T[2], but TCG gives no clean way to do it. Fabrice.
[Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
Blue Swirl wrote: The attached patch enables most TCG ops for Qemu Sparc32/64 target. Sparc32 softmmu and linux-user are OK, but Sparc64 and Sparc32plus targets do not work. Comments? It would be nice to get rid of T2 usage in std (also stda and casa/casxa) but I don't know how to pass a 64-bit value from legacy op to TCG stores and loads on a 32-bit target and host. [...] Also don't forget that T2 is used in CPU restore state to handle delay slots. This part of the SPARC target is tricky and should be simplified. Another point is that you should define TCG globals for each SPARC GPR. It was not done for i386 because I feared performance regressions when accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have this issue. Regarding the generic xxx_tl defines, I did not move it into TCG because I wanted TCG to be target independent. Since it is no longer the case because of the target memory access instructions, I think it is a good idea now. But do not mix the target specific defines with target independent defines (in tcg-op.h there is a specific section for target specific defines). Regards, Fabrice.
[Qemu-devel] Re: [PATCH, RFC, WIP] TCG for Qemu target Sparc32/64
[...] Another point is that you should define TCG globals for each SPARC GPR. It was not done for i386 because I feared performance regressions when accessing to 16 bit or 8 bit sub-registers. On SPARC you do not have this issue. Nice idea. Would this also work for windowed registers? Yes, provided you use a fixed register to store regwptr. Then you can define the windowed registers as globals using this register as base. The real problem is to save and restore this register in cpu_exec() and in all the places where the regwptr CPU state field is accessed directly. TCG will handle these problems generically soon, but before it does it you can implement it by hand. Regards, Fabrice.
Re: [Qemu-devel] [PATCH] OpenGL for OS X
Anthony Liguori wrote: Johannes Schindelin wrote: Hi, On Tue, 5 Feb 2008, Anthony Liguori wrote: I would really like to use OpenGL on non-Apple platforms. OpenGL gives much better scaling than SDL. Typically, and OpenGL app has very little platform specific code. It would be nice if we could use similar code here. But SDL runs on many more platforms than those which have OpenGL. So if at all, this should be optional, and not replace SDL. Absolutely. My thinking was just that if we're already going to have OpenGL code to support OS X (where SDL isn't an option), then we might as well make it so it's usable elsewhere. This is an SDL related issue (i.e. SDL may or may not use OpenGL to display graphics). Fixing SDL for Mac OS X would also be interesting. Regards, Fabrice.
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 22:26:57 Modified files: linux-user : syscall.c Log message: lock_iovec() fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.161r2=1.162
[Qemu-devel] qemu/tcg tcg.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 22:03:16 Modified files: tcg: tcg.c Log message: win32: suppress alloca() warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] qemu dyngen.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 22:00:42 Modified files: . : dyngen.c Log message: win32 fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemur1=1.60r2=1.61
[Qemu-devel] qemu/tcg/x86_64 tcg-target.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/03 21:06:03 Modified files: tcg/x86_64 : tcg-target.c Log message: compare fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemur1=1.1r2=1.2
[Qemu-devel] qemu/tcg/i386 tcg-target.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/03 21:06:23 Modified files: tcg/i386 : tcg-target.c Log message: compare fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemur1=1.1r2=1.2
[Qemu-devel] qemu/tcg README tcg-op.h tcg-opc.h tcg.c tcg.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/02/04 00:37:54 Modified files: tcg: README tcg-op.h tcg-opc.h tcg.c tcg.h Log message: fixed sign extensions - added explicit side effect op flag - added discard instruction CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-opc.h?cvsroot=qemur1=1.1r2=1.2 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] qemu/tcg LICENSE README TODO tcg-dyngen.c tcg-o...
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 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=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/README?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/TODO?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-dyngen.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-op.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-opc.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg-runtime.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/tcg.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/i386/tcg-target.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/tcg/x86_64/tcg-target.h?cvsroot=qemurev=1.1
[Qemu-devel] qemu/tcg
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
[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 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
[Qemu-devel] qemu TODO
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
[Qemu-devel] qemu/tcg/i386
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
[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 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 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=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.241r2=1.242 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.183r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.82r2=1.83 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-defs.h?cvsroot=qemur1=1.29r2=1.30 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.131r2=1.132 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.c?cvsroot=qemur1=1.59r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/exec-all.h?cvsroot=qemur1=1.73r2=1.74 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.122r2=1.123 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.24r2=1.25 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen-op.h?cvsroot=qemur1=1.1r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/dyngen.h?cvsroot=qemur1=1.18r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/translate-op.c?cvsroot=qemur1=1.4r2=0 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op.c?cvsroot=qemur1=1.5r2=1.6 http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/translate.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op.c?cvsroot=qemur1=1.28r2=1.29 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/translate.c?cvsroot=qemur1=1.59r2=1.60 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/op.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/translate.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemur1=1.40r2=1.41 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemur1=1.98r2=1.99 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/op.c?cvsroot=qemur1=1.52r2=1.53 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/opreg_template.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/translate.c?cvsroot=qemur1=1.76r2=1.77 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.h?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/op.c?cvsroot=qemur1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/translate.c?cvsroot=qemur1=1.22r2=1.23 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/op.c?cvsroot=qemur1=1.90r2=1.91 http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate.c?cvsroot=qemur1=1.120r2=1.121 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op.c?cvsroot=qemur1=1.68r2=1.69 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/translate.c?cvsroot=qemur1=1.115r2=1.116 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/op.c?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sh4/translate.c?cvsroot=qemur1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.46r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.85r2=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] qemu/tcg README
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
[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] qemu cpu-all.h cpu-exec.c qemu-doc.texi vl.c
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: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.83r2=1.84 http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-exec.c?cvsroot=qemur1=1.132r2=1.133 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.183r2=1.184 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.401r2=1.402
[Qemu-devel] qemu i386-vl.ld
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/31 10:43:14 Removed files: . : i386-vl.ld Log message: removed unused file CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/i386-vl.ld?cvsroot=qemur1=1.3r2=0
[Qemu-devel] qemu Makefile Makefile.target configure
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/31 11:32:10 Modified files: . : Makefile Makefile.target configure Log message: Makefile cleanup - more generic support of 32 bit compilation on x86_64 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.143r2=1.144 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.240r2=1.241 http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.182r2=1.183
[Qemu-devel] qemu/tests test-i386.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/31 14:56:10 Modified files: tests : test-i386.c Log message: compilation fixes - added bswap - comments CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386.c?cvsroot=qemur1=1.56r2=1.57
[Qemu-devel] qemu/tests Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/31 15:19:24 Modified files: tests : Makefile Log message: compilation fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/Makefile?cvsroot=qemur1=1.44r2=1.45
[Qemu-devel] qemu/tests test-i386-code16.S
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/31 15:19:39 Modified files: tests : test-i386-code16.S Log message: suppressed warnings CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386-code16.S?cvsroot=qemur1=1.5r2=1.6
Re: [Qemu-devel] [PATCH 0/5] SCSI passthrough cleanup
Two questions: - Why do you use AIO ? If the Linux sg device supports selects, then using the QEMU select() callback suffices. - Why do you use a block device ? Regards, Fabrice. Laurent Vivier wrote: This series of patches makes some cleanups in SCSI passthrough and add functionnalities. [PATCH 1/5] reverse scsi-generic Reverse previous implementation and restore block-raw-posix.c. [PATCH 2/5] Move AIO This patche moves raw AIO part from block-raw-posix.c to qemu-aio-raw.c. [PATCH 3/5] Add block SG interface This patch re-implement scsi-generic.c using a new block interface. [PATCH 4/5] DVD movie support This patch allows to read a protected/encrypted movie from a DVD. [PATCH 5/5] SCSI device DMA split This patch allows to split a READ or WRITE into several READ or WRITE. Laurent
[Qemu-devel] qemu softmmu_header.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemur1=1.18r2=1.19
Re: [Qemu-devel] qemu softmmu_header.h
Johannes Schindelin wrote: Hi, On Mon, 21 Jan 2008, Fabrice Bellard wrote: CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/21 15:07:18 Modified files: . : softmmu_header.h Log message: fixed register constraint CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_header.h?cvsroot=qemur1=1.18r2=1.19 As has been pointed out already, this breaks compilation _at least_ with gcc 3.4.2 on MinGW. If it does, it is a very weird gcc bug. The previous code was clearly incorrect. Fabrice.
Re: [Qemu-devel] [PATCH 1/5] Fix i386 Host
Alexander Graf wrote: This patch is mostly a cleanup of Michael Matz's patch with the ideas that came last time included. I must say I don't like such patches because they are likely to break with every new GCC version. Moreover, I will commit in the next few days a new code generator in QEMU which will utimately solve the compilation problems. In its current form it still relies on dyngen so that legacy micro operations still work, but in the end dyngen will be completely suppressed. A side effect of these commits will be that only the x86 and x86_64 hosts will be supported during some time. Regards, Fabrice.
[Qemu-devel] qemu Changelog VERSION
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/06 17:10:54 Modified files: . : Changelog VERSION Log message: version change CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Changelog?cvsroot=qemur1=1.150r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/VERSION?cvsroot=qemur1=1.31r2=1.32
[Qemu-devel] qemu qemu-img.c vl.c linux-user/main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/06 17:21:49 Modified files: . : qemu-img.c vl.c linux-user : main.c Log message: copyright update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-img.c?cvsroot=qemur1=1.27r2=1.28 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.393r2=1.394 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.158r2=1.159
[Qemu-devel] qemu configure Makefile.target
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/06 18:27:58 Modified files: . : configure Makefile.target Log message: fixed ppc64abi32 executable name CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/configure?cvsroot=qemur1=1.177r2=1.178 http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.237r2=1.238
Re: [Qemu-devel] [PATCH] SCSI passthrough: DVD support
Can you explain why you use the block layer (block-raw-posix.c) to send
your low level SCSI commands ? I suggest to remove your patches to
block-raw-posix.c and to implement all the SCSI passthough in
scsi-generic.c.
Regards,
Fabrice.
Laurent Vivier wrote:
This patch allows to use SCSI passthrough to read movies from DVD.
It has been tested with PowerDVD and XP.
It also introduces some comments in block-raw-posix.c to explain behavior of
negative offset and negative nb_sectors.
It restores original value of aio_num and aio_threads.
Laurent
---
block-raw-posix.c |7 +--
hw/scsi-generic.c | 14 --
2 files changed, 17 insertions(+), 4 deletions(-)
Index: qemu/hw/scsi-generic.c
===
--- qemu.orig/hw/scsi-generic.c 2008-01-06 18:43:44.0 +0100
+++ qemu/hw/scsi-generic.c2008-01-06 18:55:46.0 +0100
@@ -44,9 +44,12 @@ do { fprintf(stderr, scsi-generic: fm
#include scsi/sg.h
#include scsi/scsi.h
+#define BLANK 0xa1
+#define SEND_KEY 0xa3
+#define REPORT_KEY 0xa4
#define LOAD_UNLOAD 0xa6
+#define READ_DVD_STRUCTURE 0xad
#define SET_CD_SPEED 0xbb
-#define BLANK 0xa1
#define SCSI_CMD_BUF_SIZE 16
#define SCSI_SENSE_BUF_SIZE 32
@@ -166,7 +169,7 @@ static void scsi_command_complete(void *
sense = s-sensebuf[2] 0x0f;
}
-DPRINTF(Command complete 0x%p tag=0x%x sense=%d\n, r, r-tag, sense);
+DPRINTF(Command complete %p tag=0x%x sense=%d\n, r, r-tag, sense);
tag = r-tag;
scsi_remove_request(r);
s-completion(s-opaque, SCSI_REASON_DONE, tag, sense);
@@ -427,6 +430,12 @@ static int scsi_length(uint8_t *cmd, int
case READ_12:
*len *= blocksize;
break;
+ case READ_DVD_STRUCTURE:
+ case SEND_KEY:
+ case REPORT_KEY:
+ *len = 0x;
+ break;
+
}
return 0;
}
@@ -464,6 +473,7 @@ static int is_write(int command)
case MEDIUM_SCAN:
case SEND_VOLUME_TAG:
case WRITE_LONG_2:
+case SEND_KEY:
return 1;
}
return 0;
Index: qemu/block-raw-posix.c
===
--- qemu.orig/block-raw-posix.c 2008-01-06 18:43:44.0 +0100
+++ qemu/block-raw-posix.c2008-01-06 18:45:38.0 +0100
@@ -151,6 +151,8 @@ static int raw_pread(BlockDriverState *b
if (ret 0)
return ret;
+/* if offset 0, we don't make lseek() */
+
if (offset = 0 lseek(s-fd, offset, SEEK_SET) == (off_t)-1) {
++(s-lseek_err_cnt);
if(s-lseek_err_cnt = 10) {
@@ -276,8 +278,8 @@ void qemu_aio_init(void)
seems to fix the problem. */
struct aioinit ai;
memset(ai, 0, sizeof(ai));
-ai.aio_threads = 16;
-ai.aio_num = 16;
+ai.aio_threads = 1;
+ai.aio_num = 1;
ai.aio_idle_time = 365 * 10;
aio_init(ai);
}
@@ -387,6 +389,7 @@ static RawAIOCB *raw_aio_setup(BlockDriv
acb-aiocb.aio_sigevent.sigev_signo = aio_sig_num;
acb-aiocb.aio_sigevent.sigev_notify = SIGEV_SIGNAL;
acb-aiocb.aio_buf = buf;
+/* if nb_sectors 0, -nb_sectors is a number of bytes */
if (nb_sectors 0)
acb-aiocb.aio_nbytes = -nb_sectors;
else
[Qemu-devel] qemu block-raw-posix.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 08/01/06 18:53:07 Modified files: . : block-raw-posix.c Log message: restore original values for ai.aio_threads and ai.aio_num CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/block-raw-posix.c?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] QEMU version 0.9.1
Hi, QEMU version 0.9.1 is out ! You can get it from: http://bellard.org/qemu/download.html . Fabrice.
Re: [Qemu-devel] qemu cpu-all.h exec.c
Blue Swirl wrote: On 1/3/08, Paul Brook [EMAIL PROTECTED] wrote: On Wednesday 02 January 2008, Blue Swirl wrote: On 1/2/08, Paul Brook [EMAIL PROTECTED] wrote: Also the opaque parameter may need to be different for each function, it just didn't matter for the unassigned memory case. Do you really have systems where independent devices need to respond to different sized accesses to the same address? I don't think so. But one day unassigned or even normal RAM memory access may need an opaque parameter, so passing the device's opaque to unassigned memory handler is wrong. I'm not convinced. Your current implementation seems to introduce an extra level of indirection without any plausible benefit. If you're treating unassigned memory differently it needs to be handled much earlier that so you can raise CPU exceptions. Earlier, where's that? Another approach could be conditional stacked handlers, where a higher level handler could pass the access request to lower one (possibly modifying it in flight) or handle completely. Maybe this solves the longstanding generic DMA issue if taken to the device to memory direction. As I said earlier, the only correct way to handle memory accesses is to be able to consider a memory range and its associated I/O callbacks as an object which can be installed _and_ removed. It implies that there is a priority system close to what you described. It is essential to correct long standing PCI bugs for example. Regards, Fabrice.
Re: [Qemu-devel] qemu cpu-all.h exec.c
Blue Swirl wrote: CVSROOT: /cvsroot/qemu Module name: qemu Changes by: Blue Swirl blueswir1 08/01/01 16:57:19 Modified files: . : cpu-all.h exec.c Log message: Support for registering address space only for some access widths CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.80r2=1.81 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.120r2=1.121 This patch breaks the behaviour of the memory callbacks if the callbacks are changed dynamically (see cirrus_update_memory_access() to see what I mean). You are lucky that no one does that in the subpage case ! Regards, Fabrice.
Re: [Qemu-devel] [PATCH 2/2 v2][UPDATED] Direct IDE I/O
Laurent Vivier wrote: This patch enhances the -drive ,cache=off mode with IDE drive emulation by removing the buffer used in the IDE emulation. --- block.c | 10 +++ block.h |2 block_int.h |1 cpu-all.h |1 exec.c | 19 ++ hw/ide.c| 176 +--- vl.c|1 7 files changed, 204 insertions(+), 6 deletions(-) [...] Unfortunately it is more complicated to write to the CPU memory. In particular, specific action should be done when translated code is present. A consistent API must include something like cpu_page_lock() / unlock(). Look at cpu_physical_memory_rw() to see the various issues which must be handled. Moreover, it would be better to add bus specific APIs (at least for PCI), but I can accept a CPU memory API for now. Fabrice.
Re: [Qemu-devel] [PATCH 1/2 v2][UPDATE] Add cache parameter to -drive
Laurent Vivier wrote: This patch adds a new parameter to -drive Using cache=off with -drive will open the disk image file using O_DIRECT. By default, cache is set to on to keep original behavior of qemu. example: -drive file=my_disk.qcow2,cache=off --- block-raw-posix.c |8 block-raw-win32.c |4 block.c |2 +- block.h |1 + hw/fdc.c |7 ++- hw/ide.c | 18 ++ hw/scsi-disk.c|3 ++- hw/sd.c | 11 ++- osdep.c | 20 osdep.h |1 + vl.c | 28 11 files changed, 91 insertions(+), 12 deletions(-) [...] I suggest trying to remove the malloc/free which are done at every blk_read/write for sd.c. Fabrice.
Re: [Qemu-devel] [PATCH 2 of 3] Optionally link against libuuid if present
Filip Navara wrote: Hi Ryan others, now I have been holding a SMBIOS patch on my hard disk for way to long it seems. I used a different approach from yours, so I decided to publish it for review or further ideas. What I did was to modify the bochs bios to produce the SMBIOS tables and I get the UUID using VMware backdoor port from the virtual machine. Attached are just the changed files, creating a patch will take a while because it's against VERY OLD version of the sources. Oh, it also contains ACPI patch for the processor descriptors which was needed for some Windows versions and Darwin. Similar patch was used in KVM before, but this one dynamically detects the number of CPUs. I strongly prefer your solution (Bochs BIOS) compared to modifying QEMU: I already spent a lot of time moving the ACPI tables and other stuff to the Bochs BIOS just for that ! Regards, Fabrice.
Re: [Qemu-devel] [PATCH] arm eabi TLS
Thayne Harbaugh wrote: I believe Paul Brook did the original patch for arm eabi TLS. The patch has bounced around for a bit but hasn't been applied. We've been using this patch for a while and have tweaked it to be a bit more correct as far as code organization. Please let me know what else should be improved for this so that it can be applied. - the clone() syscall must be disabled when it is used to create a thread because it cannot work reliably in its current state. - the system to intercept calls to the syscall page must be made more generic to be used at least by arm user and x86_64 user. - It would be good to limit the changes in the CPU emulation code to handle the TLS. For example, on MIPS, the TLS register must not be stored in the CPU state. Same for ARM. Regards, Fabrice.
Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API
Hi, At this point I am not interested in integrating it into QEMU as it is one more API level to maintain in addition to the command line monitor. However, I can change my mind if several projects insists to have a similar interface. Regards, Fabrice. Yuval Kashtan wrote: Some answers: - If there is interest I can re-create the patch so it will work against the current head. I thought to receive some comments about it first.. - thanks for the styling and configuration remarks, I will certainly fix these. But before I invest more time in it, I would like to hear what ppl think in general of management API? How do you like DBus as the infrastructure for that? and what do you think of the proposed implementation? - Currently only commands are implemented (with very few getters), but of course this can be further extended to include values reading and statistics. - This is very useful when you want to manage and control QEMU, for instance developing a GUI to attach and detach usb devices or controlling more than one instance of QEMU from a single management point, receiving parameters externally and more. On Dec 10, 2007 10:51 PM, Blue Swirl [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 12/10/07, Yuval Kashtan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello All, Attached is a proposed patch which adds DBus support to QEMU. DBus is a standard message bus for linux ( http://www.freedesktop.org/wiki/Software/dbus ) The idea behind this is to allow for external programs such as controlling GUI or HyperVisors to communicate and control QEMU, in a standard manner. Although it is possible to connect to the monitor, an API is more standard, theres no need to parse texts and error messages, no internationalization problems and in general is a much better idea. Implementation: This is done by creating a DBus server from QEMU which raise signals and act upon methods. Methods mainly implement same logic as the current command line options and monitor does. How to use: To enable DBus support you'll have to add --enable-dbus when you execure configure script. Then when you execute QEMU, you'll have to add -dbus-service service_name where service_name follows the DBus naming convention ( xxx.xxx.xxx) To support QEMU configuration through DBus, you'll also have to add -dbus_configuration which will cause QEMU to wait until ConfigDone is called through the DBus interface. this allows external programs time to call DBus methods starting with Config_ which changes configuration (just as the CLI does) thus enabling invocation of QEMU without parameters (beside the DBus ones). With that, we have implemented a nice python script that reads VM's configuration from INI file. To compile this you will also have to compile the attached freedesktop.org http://freedesktop.org dsrv library (it is also attach for those who can't handle GIT) from: git://people.freedesktop.org/~shaharf/dsrv Features: Currently support was added to all important CLI configuration and some online monitor functions (such as connecting and disconnecting usb devices). configuration methods begins with Config_ prefix and monitor ones with Monitor_. For a complete list you can just execute qemu and connect with dbus-viewer to see what is supported. All the dbus handling routines can be found in dbus-monitor.c. I have two different implementations of this: 1) A single threaded version. which comply to the qemu standard of not opening additional threads. 2) A multi threaded version which open an additional, single, thread which handles all the DBus load. I actually believe this version is better as it allows QEMU to continue execution of guest operations even when there are DBus methods/signals to handle, whereas in the first option, DBus is integrated into QEMU mainloop. Also this makes it possible to monitor even during long operations (like monitoring the progress of savevm) Please comment both on the idea of management API and the proposed implementation. Attached are: RFC-QEMU-Dbus.patch - patch file including all necessary changes to qemu. was made against QEMU HEAD as of 23/9 morning. RFC-QEMU-Dbus-Interface.xml - the xml description of the DBus interface that I suggest. dsrv.tar.gz.txt - the dbus server library. I have no idea if this is useful. I would have tried the patch, but it does not apply to current CVS. Other comments: When configure is invoked with --enable-dbus, it should check for DBUS
Re: [Qemu-devel] Re: [PATCH] mark host pages as reserved
Magnus Damm wrote: Hi everyone, On Dec 5, 2007 5:45 PM, Magnus Damm [EMAIL PROTECTED] wrote: Hi all, This patch teaches the user space emulator about host pages. It marks present host page mappings with PAGE_RESERVED so mmap_find_vma() properly can detect that pages at mmap_next_start should be skipped over instead of being overwritten using mmap(). Without this patch I experience crashes with the arm or sh4 user space emulator together with sbox2. This combination sometimes result in that host libraries are mapped into the qemu process space starting from 0x4xxx instead of 0xb7xx. This together with the initial value of mmap_next_start results in a segfault when the elf loader overwrites the mapped host libraries with the target binary. Comments anyone? Any reason for not applying this patch? This fixes user space emulation for all targets. It seems OK. Fabrice.
Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API
Daniel P. Berrange wrote: On Tue, Dec 11, 2007 at 09:16:43AM +0200, Yuval Kashtan wrote: - This is very useful when you want to manage and control QEMU, for instance developing a GUI to attach and detach usb devices or controlling more than one instance of QEMU from a single management point, receiving parameters externally and more. This capability is already possible using the monitor API. I've implemented it in libvirt, and in virt-manager and can easily hotplug/remove USB devices. So DBus is not required to do this and does not really make it any easier to use. DBus is very verbose to use from languages like C, so switching from the monitor to DBus API would not really help simplify my existing code. On the other hand, having a library providing a simple client side C API to send receive monitor commands, would be beneficial For the short term I think it is better as you said to rely on libvirt which already has some support for QEMU. As it was suggested, improving the monitor seems the easiest, maybe with an additionnal mode to provide a standardized way to get a return value for each command. Providing an example client code to directly use the monitor seems a good idea too. Regarding the configuration, I can assure there will be soon a QEMU configuration file. The question is whether it will be included before the next release is out ! Regards, Fabrice.
Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Laurent Vivier wrote: This patch enhances the -drive ,cache=off mode with IDE drive emulation by removing the buffer used in the IDE emulation. --- block.c | 10 +++ block.h |2 block_int.h |1 cpu-all.h |1 exec.c | 19 ++ hw/ide.c| 176 +--- vl.c|1 7 files changed, 204 insertions(+), 6 deletions(-) What's the use of keeping the buffered case ? Fabrice.
Re: [Qemu-devel] qemu hw/ppc_oldworld.c target-ppc/cpu.h target-...
Thiemo Seufer wrote: Paul Brook wrote: I think what you mean is that they work the way that ppc64 is defined, to remain compatible with ppc32. IMHO this is entirely irrelevant as we're emulating a ppc32. You could replace the high bits with garbage and nothing would ever be able to tell the difference. PowerPC is a 64 bits architecture. PowerPC 32 on 32 bits host is optimized not to compute the 32 highest bits, the same way it's allowed to cut down the GPR when implementing a CPU that would not support the 64 bits mode (but this is a tolerance, this is not the architecture is defined). No. PowerPC is defined as a 64-bit archirecure. However there is a subset of this architecture (aka ppc32) that is a complete 32-bit architecture in its own right. By your own admission, we can get away with not calculating the high 32 bit of the register. If follows that the high bits are completely meaningless. This btw. also means that the ppc32 emulation on 32-bit hosts is needlessly inefficient if the high bits are carried around. The qemu ppc32 emulation is implemented in such a way that on 64-bit hosts it looks a lot like a ppc64 implementation. However this need not, and should not be exposed to the user. OK. Those are real bugs to be fixed. I'll take a look But I'll try not to break the GPR dump. In fact, GPR should always dumped as 64 bits, even when runnig on 32 bits hosts. This would be more consistent with the specification. I disagree. qemu is implementing ppc32. Showing more than 32 bits of register is completely bogus. Any differences between a 32-bit host and a 64-bit host are a qemu bug. If you display 64 bits, then those 64 bits had better be the same when run on 32-bit hosts. I strongly agree with Paul. I strongly agree too and I suggest to remove the type ppc_gpr_t and to replace it with target_ulong (and uint32_t for the high part of the SPE extensions). Regards, Fabrice.
Re: [Qemu-devel] [PATCH] SH4 Fix missing 6th arg of syscall.
Can you provide a glibc and busybox binary for sh4eb so that I can include them in the linux user tests ? Regards, Fabrice. Tomoyoshi ASANO wrote: Hello, I tested big-endian binaries by sh4(eb)-linux-user with a small patch(attached) for building sh4eb-linux-user. But I don't understand that this patch is needed or not. sh4eb-linux-user is OK using static link binaries. But I feel that sh4eb-linux-users has some problem(?) using dynamic link binaries. 1) If host-os has /etc/ld.so.cache, sh4eb-linux-users is NG. [EMAIL PROTECTED] ~] qemu-sh4eb -strace /usr/qemu-sh4eb/bin/busybox 28575 uname(0x4007f818) = 0 28575 brk(0,132617,1074264468,57,1074325300,4096) = 0x00487000 28575 access(/etc/ld.so.preload,04) = -1 errno=2 (No such file or directory) 28575 open(/etc/ld.so.cache,0,01) = 3 28575 fstat64(3,0x4007f234) = 0 28575 mmap(0,66277,1,2,3,0) = 0x42081000 28575 close(3) = 0 Unhandled trap: 0xa0 pc=0x400870d0 sr=0x8001 pr=0x40086e32 fpscr=0x0008 r0=0x0348 r1=0xb61a0ff4 r2=0x2a2c1010 r3=0x000c r4=0x400a4000 r5=0x40092afc r6=0x000b r7=0x0002 r8=0x7411fff4 r9=0x000102e5 r10=0x1f017fff r11=0x17dd02d5 r12=0x400a4000 r13=0x3e02 r14=0x4007f2b0 r15=0x4007f2b0 r16=0x r17=0x r18=0x r19=0x r20=0x r21=0x r22=0x r23=0x But if no /etc/ld.so.cache in host-os, sh4eb-linux-users is OK. 2) If host-os has /lib/tls/*, sh4eb-linux-users is NG. [EMAIL PROTECTED] ~] qemu-sh4eb -strace /usr/qemu-sh4eb/bin/busybox 28580 uname(0x4007f818) = 0 28580 brk(0,132617,1074264468,57,1074325300,4096) = 0x00487000 28580 access(/etc/ld.so.preload,04) = -1 errno=2 (No such file or directory) 28580 open(/etc/ld.so.cache,0,01) = -1 errno=2 (No such file or directory) 28580 open(/lib/tls/libm.so.6,0,012) = 3 28580 read(3,0x4007f308,512) = 512 28580 close(3) = 0 28580 writev(2,0x4007efb8,0xa)/usr/qemu-sh4eb/bin/busybox: error while loading shared libraries: /lib/tls/libm.so.6: ELF file data encoding not big-endian = 125 28580 exit_group(127) But if no /lib/tls in host-os, sh4eb-linux-users is OK. please help if possible. Thanks, -- On Wed, 21 Nov 2007 10:43:49 +0900 Tomoyoshi ASANO [EMAIL PROTECTED] wrote: Hell, This is very nice! I tested using glibc-2.5 It seems good. Thank you On Wed, 21 Nov 2007 09:24:41 +0900 Magnus Damm [EMAIL PROTECTED] wrote: Hi there, On Nov 20, 2007 11:48 PM, [EMAIL PROTECTED] wrote: I found 6th arg for syscall is missing on SH4 linux-user emulation. This seems to be the cause of shared library mapping failure. I successfully run shared-lib'd binary, after applying following fix. Hehe, I managed to create the exact same patch yesterday evening. So this email is just to acknowledge this fix. Dynamically linked binaries using uclibc-0.9.29 or glibc-2.3.6 both work well. Thank you. / magnus
[Qemu-devel] qemu/target-i386 helper2.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/21 16:18:22 Modified files: target-i386: helper2.c Log message: typo fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper2.c?cvsroot=qemur1=1.57r2=1.58
Re: [Qemu-devel] Online image backup
Matteo Bertini wrote: Hello everyone, is there any support for an online image backup? Or some direction to have it? Imagine I have an emulated server. How can I make an online backup of the server state? If I'm right in the actual design this is very hard. Or there are some image internals update rules that permit a consistent copy possible? It should not be difficult provided the VM is using the QEMU qcow2 image format (doing a backup can be seen as a kind of snapshot). Fabrice.
Re: [Qemu-devel] qemu softmmu_template.h
andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 11:14 +0100, andrzej zaborowski wrote: On 17/11/2007, J. Mayer [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 09:53 +, Andrzej Zaborowski wrote: CVSROOT: /sources/qemu Module name: qemu Changes by: Andrzej Zaborowski balrog 07/11/17 09:53:42 Modified files: . : softmmu_template.h Log message: Check permissions for the last byte first in unaligned slow_st accesses (patch from TeLeMan). CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu_template.h?cvsroot=qemur1=1.19r2=1.20 Has it been checked that it's legal for all architectures and cannot have any nasty side effect to do accesses in the reverse order ? Real hardware do not ever seem to do this... For real hardware the store is a single operation. For PowerPC, at least, only aligned stores are defined as atomic. It's absolutely legal for an implementation to split all non-atomic accesses into smaller aligned accesses. And I guess it is the same for all architecture that can do unaligned accesses. Logically it shouldn't have any side effects, but if it does then it would rather mean that other code for that architecture is (also) broken, I believe. I've only tested ARM, mips, x86 and x86_64 before committing, so please test. I figured that the patch won't get any comments on the mailing list if it isn't merged. I don't think it's so easy to test because it may be very hard to trigger the cases that would have side effects, which are target dependent. I then am very curious to know how you did check that there is no problem with this patch Well, for ARM, x86 and x86_64 I only checked that unaligned accesses still work, i.e. that I haven't made an obvious typo. I haven't tested cross-page accesses with the access to the second page being invalid, I also don't know how the specifications for other architectures define the effect of such accesses, so maybe I shouldn't have committed this, but I assumed a common sense in the design of cpu archs, meaning that in the example given by TeLeMan the addition is not performed two times on some bytes. Regards I agree with this patch is the sense that the previous behaviour was clearly incorrect. Now this patch relies on the fact that tlb_fill() does not remove the previous page from the TLB cache which is an important hidden constraint. Fabrice.
[Qemu-devel] qemu arm-semi.c m68k-semi.c softmmu-semi.h linu...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/16 10:46:05 Modified files: . : arm-semi.c m68k-semi.c softmmu-semi.h linux-user : elfload.c flatload.c linuxload.c main.c qemu.h syscall.c target-arm/nwfpe: fpa11_cpdt.c Log message: suppressed tgetx and tputx (initial patch by Thayne Harbaugh) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/arm-semi.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/m68k-semi.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu-semi.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.56r2=1.57 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flatload.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/linuxload.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.153r2=1.154 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.49r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.152r2=1.153 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/nwfpe/fpa11_cpdt.c?cvsroot=qemur1=1.6r2=1.7
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/15 15:27:03 Modified files: linux-user : main.c Log message: x86_64 fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.151r2=1.152
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/15 15:37:50 Modified files: linux-user : main.c Log message: force correct ppc64 cpu CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.152r2=1.153
[Qemu-devel] qemu Makefile tests/Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 10:34:57 Modified files: . : Makefile tests : Makefile Log message: removed obsolete test2 target CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile?cvsroot=qemur1=1.130r2=1.131 http://cvs.savannah.gnu.org/viewcvs/qemu/tests/Makefile?cvsroot=qemur1=1.43r2=1.44
[Qemu-devel] qemu cpu-all.h exec.c linux-user/qemu.h linux-u...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 10:51:01 Modified files: . : cpu-all.h exec.c linux-user : qemu.h syscall.c Log message: suppressed page_unprotect_range() - fixed access_ok() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/cpu-all.h?cvsroot=qemur1=1.77r2=1.78 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.114r2=1.115 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.47r2=1.48 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.149r2=1.150
[Qemu-devel] qemu/linux-user mmap.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 11:29:07 Modified files: linux-user : mmap.c Log message: fixed target_mmap() if host page size TARGET_PAGE_SIZE CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/mmap.c?cvsroot=qemur1=1.18r2=1.19
[Qemu-devel] qemu/linux-user main.c syscall.c i386/syscall.h...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 15:18:40 Modified files: linux-user : main.c syscall.c linux-user/i386: syscall.h linux-user/x86_64: syscall.h Log message: i386 TLS support CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.149r2=1.150 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.150r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/i386/syscall.h?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/x86_64/syscall.h?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] qemu/linux-user qemu.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 15:16:52 Modified files: linux-user : qemu.h Log message: always define TARGET_ABI32 if 32 bit user CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.48r2=1.49
[Qemu-devel] qemu/linux-user strace.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 18:04:06 Modified files: linux-user : strace.c Log message: printf format fix CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/strace.c?cvsroot=qemur1=1.5r2=1.6
[Qemu-devel] qemu linux-user/main.c linux-user/syscall.c lin...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/14 18:08:56 Modified files: linux-user : main.c syscall.c syscall_defs.h linux-user/x86_64: syscall.h target-i386: cpu.h helper.c Log message: x86_64 linux user emulation CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.150r2=1.151 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.151r2=1.152 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemur1=1.45r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/x86_64/syscall.h?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/cpu.h?cvsroot=qemur1=1.55r2=1.56 http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemur1=1.93r2=1.94
Re: [Qemu-devel] [PATCH] target_posix_types.h
Thayne Harbaugh wrote: This patch, 44_target_posix_types.patch provides target specific posix types. These types improve target structure creation, code similarity to kernel code and improve type casting for assignment between target and host. Why is it needed ? Fabrice.
Re: [Qemu-devel] [PATCH] Fix TLS support on x86
Thayne Harbaugh wrote: On Tue, 2007-11-13 at 19:44 +0100, Stefan Weil wrote: Hi, I'd like to test user mode emulation on MIPS host. Do you have newer versions of your patches which match current CVS HEAD? TLS support is still missing there, so QEMU user mode emulation is not really usable without working patches. I don't know about anyone else, but I have some patches for TLS for arm and i386. The patches are significantly out of date with the recent linux-user changes. I won't be updating them until I finish with the current set of changes to linux-user. I'll try to merge and improve the i386 TLS patch ASAP. Moreover, after having looked again at the linux-user code and at the regression tests, my conclusion is that the linux-user QEMU targets must be statically linked and that it should not depend on host libraries such as the C library. Fabrice.
[Qemu-devel] qemu/target-alpha op_mem.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/12 21:16:08 Modified files: target-alpha : op_mem.h Log message: reduce verbosity CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op_mem.h?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] qemu/target-m68k helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/12 23:12:17 Modified files: target-m68k: helper.c Log message: added missing return CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/helper.c?cvsroot=qemur1=1.9r2=1.10
[Qemu-devel] Linux user mode tests updated
I put new architectures in the Linux user mode regression tests available at http://bellard.org/qemu/download.html . The interested developpers can try to fix the following targets: x86_64 sh4 alpha ppc64 hppa. The challenge is to make a dynamically linked ls -l work ! I might spend some time on x86_64. Fabrice.
[Qemu-devel] qemu target-alpha/op_helper.c target-arm/op_hel...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 12:35:55 Modified files: target-alpha : op_helper.c target-arm : op_helper.c target-cris: op_helper.c target-m68k: op_helper.c target-ppc : op_helper.c Log message: fixed invalid type CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-alpha/op_helper.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-arm/op_helper.c?cvsroot=qemur1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/qemu/target-cris/op_helper.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/target-m68k/op_helper.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/target-ppc/op_helper.c?cvsroot=qemur1=1.65r2=1.66
[Qemu-devel] qemu Makefile.target arm-semi.c exec.c m68k-sem...
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 14:26:48 Modified files: . : Makefile.target arm-semi.c exec.c m68k-semi.c softmmu-semi.h linux-user : elfload.c flatload.c linuxload.c qemu.h signal.c strace.c syscall.c vm86.c Added files: linux-user : uaccess.c Log message: Linux user memory access API change (initial patch by Thayne Harbaugh) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.222r2=1.223 http://cvs.savannah.gnu.org/viewcvs/qemu/arm-semi.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/exec.c?cvsroot=qemur1=1.113r2=1.114 http://cvs.savannah.gnu.org/viewcvs/qemu/m68k-semi.c?cvsroot=qemur1=1.3r2=1.4 http://cvs.savannah.gnu.org/viewcvs/qemu/softmmu-semi.h?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/elfload.c?cvsroot=qemur1=1.55r2=1.56 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/flatload.c?cvsroot=qemur1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/linuxload.c?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.45r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.49r2=1.50 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/strace.c?cvsroot=qemur1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.143r2=1.144 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/vm86.c?cvsroot=qemur1=1.12r2=1.13 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/uaccess.c?cvsroot=qemurev=1.1
[Qemu-devel] qemu/tests test-i386.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 14:43:13 Modified files: tests : test-i386.c Log message: compilation fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/test-i386.c?cvsroot=qemur1=1.55r2=1.56
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 14:46:06 Modified files: linux-user : main.c Log message: -strace option CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.145r2=1.146
[Qemu-devel] qemu/linux-user vm86.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 14:50:32 Modified files: linux-user : vm86.c Log message: fixed error codes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/vm86.c?cvsroot=qemur1=1.13r2=1.14
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 14:57:14 Modified files: linux-user : syscall.c Log message: no longer use get_errno for do_modify_ldt() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.144r2=1.145
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 15:11:20 Modified files: linux-user : syscall.c Log message: move get_errno() inside do_fcntl() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.145r2=1.146
[Qemu-devel] qemu/slirp misc.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 16:05:35 Modified files: slirp : misc.c Log message: removed warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/slirp/misc.c?cvsroot=qemur1=1.12r2=1.13
[Qemu-devel] qemu/linux-user signal.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 16:22:17 Modified files: linux-user : signal.c Log message: removed warnings - fixed arm stack copy bug CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.50r2=1.51
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:22:48 Modified files: linux-user : main.c Log message: printf format fixes CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.146r2=1.147
[Qemu-devel] qemu/linux-user qemu.h strace.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:23:29 Modified files: linux-user : qemu.h strace.c Log message: use correct types CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/qemu.h?cvsroot=qemur1=1.46r2=1.47 http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/strace.c?cvsroot=qemur1=1.3r2=1.4
[Qemu-devel] qemu/linux-user m68k-sim.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:25:52 Modified files: linux-user : m68k-sim.c Log message: fixed invalid cast CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/m68k-sim.c?cvsroot=qemur1=1.2r2=1.3
[Qemu-devel] qemu/tests Makefile
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:26:22 Modified files: tests : Makefile Log message: use -fno-strict-aliasing CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/tests/Makefile?cvsroot=qemur1=1.42r2=1.43
[Qemu-devel] qemu translate-all.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:26:45 Modified files: . : translate-all.c Log message: removed warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/translate-all.c?cvsroot=qemur1=1.20r2=1.21
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:39:19 Modified files: linux-user : syscall.c Log message: improved cmsg handling - improved shm memory code CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.146r2=1.147
[Qemu-devel] qemu/linux-user syscall_defs.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:39:38 Modified files: linux-user : syscall_defs.h Log message: suppressed invalid TARGET_CMSG_FIRSTHDR macro CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall_defs.h?cvsroot=qemur1=1.44r2=1.45
[Qemu-devel] qemu/hw sh7750.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:51:40 Modified files: hw : sh7750.c Log message: removed invalid use of _INTC_ARRAY CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/sh7750.c?cvsroot=qemur1=1.9r2=1.10
[Qemu-devel] qemu/linux-user strace.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 17:55:50 Modified files: linux-user : strace.c Log message: hex numbers must have a leading 0x CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/strace.c?cvsroot=qemur1=1.4r2=1.5
[Qemu-devel] qemu thunk.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:31:34 Modified files: . : thunk.c Log message: better than nothing 64 bit support - added sign extension for TYPE_LONG CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/thunk.c?cvsroot=qemur1=1.9r2=1.10
[Qemu-devel] qemu/linux-user main.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:32:53 Modified files: linux-user : main.c Log message: sparc64_[get|set]_context are not meaningful in abi32 mode CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/main.c?cvsroot=qemur1=1.147r2=1.148
[Qemu-devel] qemu/linux-user syscall.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:34:33 Modified files: linux-user : syscall.c Log message: removed warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/syscall.c?cvsroot=qemur1=1.147r2=1.148
[Qemu-devel] qemu/linux-user signal.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:45:10 Modified files: linux-user : signal.c Log message: removed warnings - improved sparc32/64 signal frame setup - disabled x86 frame setup for x86_64 CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/linux-user/signal.c?cvsroot=qemur1=1.51r2=1.52
[Qemu-devel] qemu/target-i386 exec.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:45:49 Modified files: target-i386: exec.h Log message: removed warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/exec.h?cvsroot=qemur1=1.38r2=1.39
[Qemu-devel] qemu/target-sparc op_helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:46:09 Modified files: target-sparc : op_helper.c Log message: removed warning CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.51r2=1.52
[Qemu-devel] qemu/hw usb-uhci.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:46:37 Modified files: hw : usb-uhci.c Log message: removed unused code CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/usb-uhci.c?cvsroot=qemur1=1.20r2=1.21
[Qemu-devel] qemu/hw slavio_timer.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:47:02 Modified files: hw : slavio_timer.c Log message: fixed invalid constant CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/slavio_timer.c?cvsroot=qemur1=1.18r2=1.19
[Qemu-devel] qemu/hw pxa2xx_dma.c pxa.h spitz.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:47:59 Modified files: hw : pxa2xx_dma.c pxa.h spitz.c Log message: use correct printf format CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx_dma.c?cvsroot=qemur1=1.4r2=1.5 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa.h?cvsroot=qemur1=1.7r2=1.8 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/spitz.c?cvsroot=qemur1=1.13r2=1.14
[Qemu-devel] qemu/hw pxa2xx.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:48:34 Modified files: hw : pxa2xx.c Log message: removed unused variables CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/pxa2xx.c?cvsroot=qemur1=1.20r2=1.21
[Qemu-devel] qemu/hw omap.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:48:47 Modified files: hw : omap.c Log message: fixed cast CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/omap.c?cvsroot=qemur1=1.20r2=1.21
[Qemu-devel] qemu/hw mips_mipssim.c mips_pica61.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard bellard 07/11/11 19:49:08 Modified files: hw : mips_mipssim.c mips_pica61.c Log message: removed unused variable CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemur1=1.6r2=1.7 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_pica61.c?cvsroot=qemur1=1.11r2=1.12
