[Qemu-devel] qemu Makefile.target qemu-doc.texi vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/17 13:08:32 Modified files: . : Makefile.target qemu-doc.texi vl.c vl.h Log message: MIPSsim pseudo machine emulation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/Makefile.target?cvsroot=qemur1=1.210r2=1.211 http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.159r2=1.160 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemur1=1.348r2=1.349 http://cvs.savannah.gnu.org/viewcvs/qemu/vl.h?cvsroot=qemur1=1.278r2=1.279
[Qemu-devel] fat rw status
Hi, I've sent a message 4 days ago but got no answer :( http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00314.html From: Ricardo Almeida Subject:[Qemu-devel] fat rw Date: Sat, 13 Oct 2007 23:50:17 +0100 Hi, I've found the fat:rw:dir option for harddrives and want to use it :) But when I run: qemu-system-x86_64 -kernel-kqemu -m 256 -hda winxp.qcow -hdb fat:rw:/media/lacie/ I get: qemu: could not open hard disk image 'fat:rw:/media/lacie/' I've seen in qemu forums (http://qemu-forum.ipi.fi/viewtopic.php?p=12250) someone with a similar problem and the following solution: [QUOTE] I am not sure this the correct solution, and I have no idea of what I am doing, but by changing the bdrv_create call in enable_write_target to: Code: if (bdrv_create(bdrv_qcow, s-qcow_filename, s-sector_count, NULL, 0) 0) This causes QEMU to start correctly and writes to the virtual disk work correctly. [/QUOTE] I'm using Kubuntu Gutsy with QEmu 0.9.0 from repository package with kqemu_1.3.0pre11, so I can't patch QEmu. I would like to know if this is already fixed on CVS or what's the current status. Regards, Ricardo Almeida
Re: [Qemu-devel] Mips target '-kernel' option bug
J. Mayer wrote: I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. I think this patch is the correct fix. Please test and comment. Thiemo Index: qemu-work/elf_ops.h === --- qemu-work.orig/elf_ops.h2007-10-17 14:18:09.0 +0100 +++ qemu-work/elf_ops.h 2007-10-17 14:20:20.0 +0100 @@ -159,7 +159,7 @@ goto fail; if (pentry) - *pentry = (uint64_t)ehdr.e_entry; + *pentry = (uint64_t)(elf_sword)ehdr.e_entry; glue(load_symbols, SZ)(ehdr, fd, must_swab); @@ -206,9 +206,9 @@ } qemu_free(phdr); if (lowaddr) -*lowaddr = (uint64_t)low; +*lowaddr = (uint64_t)(elf_sword)low; if (highaddr) -*highaddr = (uint64_t)high; +*highaddr = (uint64_t)(elf_sword)high; return total_size; fail: qemu_free(data); Index: qemu-work/loader.c === --- qemu-work.orig/loader.c 2007-10-17 14:18:09.0 +0100 +++ qemu-work/loader.c 2007-10-17 14:20:19.0 +0100 @@ -173,6 +173,7 @@ #define SZ 32 #define elf_worduint32_t +#define elf_swordint32_t #define bswapSZs bswap32s #include elf_ops.h @@ -182,6 +183,7 @@ #undef elf_sym #undef elf_note #undef elf_word +#undef elf_sword #undef bswapSZs #undef SZ #define elfhdr elf64_hdr @@ -190,6 +192,7 @@ #define elf_shdr elf64_shdr #define elf_symelf64_sym #define elf_worduint64_t +#define elf_swordint64_t #define bswapSZs bswap64s #define SZ 64 #include elf_ops.h
[Qemu-devel] qemu qemu-doc.texi hw/mips_mipssim.c hw/mipsnet.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/17 13:39:42 Modified files: . : qemu-doc.texi Added files: hw : mips_mipssim.c mipsnet.c Log message: Second half of mipssim support, plus documentation improvements. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu-doc.texi?cvsroot=qemur1=1.160r2=1.161 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mips_mipssim.c?cvsroot=qemurev=1.1 http://cvs.savannah.gnu.org/viewcvs/qemu/hw/mipsnet.c?cvsroot=qemurev=1.1
[Qemu-devel] qemu/target-mips TODO
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/17 13:43:58 Modified files: target-mips: TODO Log message: Update TODO. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/TODO?cvsroot=qemur1=1.16r2=1.17
[Qemu-devel] qemu/pc-bios README
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/10/17 17:34:18 Modified files: pc-bios: README Log message: Update Sparc32 OpenBIOS image to SVN revision 171. Changes: r170: Fix exception handling and printout r171: Fix 8 byte alignment problems CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/README?cvsroot=qemur1=1.16r2=1.17
[Qemu-devel] qemu/target-sparc translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/10/17 17:34:58 Modified files: target-sparc : translate.c Log message: Enable all alignment checks CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.77r2=1.78
[Qemu-devel] qemu/target-sparc op_helper.c op_mem.h
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/10/17 17:37:13 Modified files: target-sparc : op_helper.c op_mem.h Log message: Use ldq and stq for 8 byte accesses (original patch by Robert Reif) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_helper.c?cvsroot=qemur1=1.45r2=1.46 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op_mem.h?cvsroot=qemur1=1.11r2=1.12
[Qemu-devel] qemu/pc-bios openbios-sparc32
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/10/17 17:42:21 Modified files: pc-bios: openbios-sparc32 Log message: Really update the image CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/pc-bios/openbios-sparc32?cvsroot=qemurev=1.11
Re: [Qemu-devel] Mips target '-kernel' option bug
On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote: J. Mayer wrote: I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. I think this patch is the correct fix. Please test and comment. Thanks, I'll test it at home tonight. To satisfy my curiosity, is there a specific reason to have a positive VIRT_TO_PHYS_ADDEND ? [...]
Re: [Qemu-devel] Mips target '-kernel' option bug
Jocelyn Mayer wrote: On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote: J. Mayer wrote: I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. I think this patch is the correct fix. Please test and comment. Thanks, I'll test it at home tonight. To satisfy my curiosity, is there a specific reason to have a positive VIRT_TO_PHYS_ADDEND ? So it wraps around correctly WRT the sign extension rules. Thiemo
Re: [Qemu-devel] Mips target '-kernel' option bug
On 10/17/07, Jocelyn Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote: J. Mayer wrote: I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. I think this patch is the correct fix. Please test and comment. Thanks, I'll test it at home tonight. To satisfy my curiosity, is there a specific reason to have a positive VIRT_TO_PHYS_ADDEND ? On Sparc, OpenBIOS image is loaded to a physical address that is higher in the address space than the virtual address: #define PROM_PADDR 0xff000ULL #define PROM_VADDR 0xffd0 and #define PROM_ADDR0x1fff000ULL #define PROM_VADDR 0x000ffd0ULL
Re: [Qemu-devel] Mips target '-kernel' option bug
On Wed, 2007-10-17 at 22:06 +0300, Blue Swirl wrote: On 10/17/07, Jocelyn Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote: J. Mayer wrote: I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. I think this patch is the correct fix. Please test and comment. Thanks, I'll test it at home tonight. To satisfy my curiosity, is there a specific reason to have a positive VIRT_TO_PHYS_ADDEND ? On Sparc, OpenBIOS image is loaded to a physical address that is higher in the address space than the virtual address: #define PROM_PADDR 0xff000ULL #define PROM_VADDR 0xffd0 and #define PROM_ADDR0x1fff000ULL #define PROM_VADDR 0x000ffd0ULL OK, thanks. And the patch seems OK for me, it may be a good idea to commit it ! -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] fat rw status
Hi, On Wed, 17 Oct 2007, Ricardo Almeida wrote: I've sent a message 4 days ago but got no answer :( http://lists.gnu.org/archive/html/qemu-devel/2007-10/msg00314.html Patience! Either you convince the committers that your patch is correct, or you wait for me to have some time to look into it. Ciao, Dscho
[Qemu-devel] qemu elf_ops.h loader.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/10/17 23:07:31 Modified files: . : elf_ops.h loader.c Log message: Cast ELF datatypes properly to host 64bit types. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/elf_ops.h?cvsroot=qemur1=1.10r2=1.11 http://cvs.savannah.gnu.org/viewcvs/qemu/loader.c?cvsroot=qemur1=1.8r2=1.9
Re: [Qemu-devel] Mips target '-kernel' option bug
J. Mayer wrote: On Wed, 2007-10-17 at 22:06 +0300, Blue Swirl wrote: On 10/17/07, Jocelyn Mayer [EMAIL PROTECTED] wrote: On Wed, 2007-10-17 at 14:51 +0100, Thiemo Seufer wrote: J. Mayer wrote: I failed to run Mips target test image on my amd64 machine and I now found the reason of the bug: the kernel loader code used in hw/mips_r4k.c and hw/mips_malta.c implicitelly assumes that the ram_addr_t is 32 bits long. Unfortunatelly, on 64 bits hosts, this won't be the case and the kernel load address then is over 4 GB. Then, when computing the initrd_offset, the code always concludes that there's not enough RAM available to load it at the top of the kernel. I found 2 ways of fixing the bug, but I don't know which one is correct in Mips execution environment. The first patch is to make the VIRT_TO_PHYS_ADDEND negative, thus translating the kernel virtual address from 0x8000 to the physical one 0x (instead of 0x1, when running on 64 bits hosts). The second solution would be to explicitelly always cast the kernel_high value to 32 bits. As I do not really know if some Mips target specific constraints would make one of the other solution prefered, I'd better let the specialist choose ! The good news is that, once this issue is fixed, the Mips test images run with the reverse-endian softmmu patch applied. I think this patch is the correct fix. Please test and comment. Thanks, I'll test it at home tonight. To satisfy my curiosity, is there a specific reason to have a positive VIRT_TO_PHYS_ADDEND ? On Sparc, OpenBIOS image is loaded to a physical address that is higher in the address space than the virtual address: #define PROM_PADDR 0xff000ULL #define PROM_VADDR 0xffd0 and #define PROM_ADDR0x1fff000ULL #define PROM_VADDR 0x000ffd0ULL OK, thanks. And the patch seems OK for me, it may be a good idea to commit it ! Committed. Thiemo
Re: [Qemu-devel] Questions on hidden functions in QEMU source code
On 10/16/07, Johannes Schindelin [EMAIL PROTECTED] wrote: Hi, On Tue, 16 Oct 2007, Stuart Brady wrote: On Tue, Oct 16, 2007 at 05:28:24PM +0900, Jun Koi wrote: For example, functions like compute_all_incb() and compute_c_incl() in target-i386/op.c are never defined anywhere. compute_all_inc* are defined in ops_template.h:~171. You'll notice that ops_template.h is included four times from op.c. If you wonder why it is included four times, this might help: http://libvncserver.sourceforge.net/qemu/qemu-templates-ala-Fabrice.txt Now it is clear that those stuffs are generated by dyngen, thanks. But still it it not obvious to me what is the purpose of OPPROTO when defining micro-ops. May you elaborate this a bit more? Many thanks, Jun Hth, Dscho
