Re: [Qemu-devel] Missing ARMv6 instructions?
The way I understand this is that anyone who got ARM documentation with the license that Paul mentioned, could not contribute patches that implement v6 emulation. If, however, someone else (who has not signed such a license) were to buy documentation about the ARMv6 architecture that comes without a license (for example, the ARM System Developer's Guide, by Sloss, Symes, and Wright, Elsevier 2004), that someone should be able to contribute (at least in those aspects of the ARM that are disclosed by the book). In that case, ARM should not have any legal hooks except copyright, and since at that point you are not using any of their code, there is no case. However, I am not a lawyer, so don't take my word for it. As to the threats to ARM's business model, I could see them threatened if someone emulated the ARM on hardware of similar performance (without licensing ARM IP) -- that would undermine sales of the real ARM cores, depending on the price/performance point of the replacement. Software emulation of an ARM core on a 4 GHz Pentium is hardly an alternative to buying the real thing, though... I also find it hard to believe that building a product competitive to an ARM is possible using a description of the instruction set alone. That said, I agree with Paul that lobbying ARM to change their license is probably a better route to go. I believe software emulators like qemu are really in ARMs best interest since they support ARM development and thereby increase the availability of software for ARM cores. - Wolfgang Disclaimer: The views stated above are entirely mine, and do not necessarily reflect the views of my employer. Paul wrote on 30.03.2006 00:01:41: I could understand a claim if someone acquired ARM's documentation under an agreement to not produce an emulator. That's exactly where the restriction comes from. Theoretically it may be possible to reverse engineer a good proportion of ARMv6 from other sources (eg. gcc). However if that were done it would mean anyone with access to the real ARM documentation (i.e. me and probably anyone else with any professional/commercial interest in ARM emulation) would be unable to contribute to qemu. And if there is a possibility of that - in which countries do they have any weight? Dare I suggest encouraging the development of patches they don't like to countries where they have no legal weight? I don't think that's particularly helpful or practical suggestion. Better would be to lobby ARM to allow open source emulators. I'd like to use ARM hardware for big project, but qemu doesn't support ARMv7 so I'm thinking of using PowerPC instead is a particularly good argument ;-) Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Keyboard/Mouse issues on WinXP loadvm
Am Mittwoch, den 29.03.2006, 21:26 -0500 schrieb Andrew Barr: The virtual keyboard and mouse appear to be confused after loadvm'ing on Windows XP SP2 (and 2000 SP4 as well) guest (Qemu CVS on Linux host). The control key appears to be stuck down. While looking for something unrelated in the mailing list archives, I found these: http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00021.html http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg0.html It appears to be describing the exact same problem, but on a Linux guest. The suggested solution was to press Ctrl, Shift, Alt one after the other after restoring the VM. This doesn't appear to work on my Windows guest. Is there another way to fix this? i dont know if it is the exactly same bahavior i encountered: here the keys were totaly messed up (i used cvs version) on #qemu irc-channel a patch for this was posted at the url: http://jma-box.student.umd.edu:8080/ps2.diff this might help - at least it did help fixing my problem. cheers maestro p.s. paul brooks: is this to be going into cvs at some point, or did it already happen and i missed it ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Thiemo Seufer wrote: On Tue, Mar 28, 2006 at 08:57:15AM +0200, Dirk Behme wrote: What about the patch in attachment? It first tries to load image as an ELF file. If this fails it falls back to raw image load. Additionally, it takes feature of patch above to go on even if no BIOS is found. A slightly more polished version with less noisy messages is appended. It also adjusts the ramdisk load address to physical addressing, similiar to the binary kernel load. One question I just found: If we go on if no BIOS is found/executed and we load some stuff to e.g. 0x8001, where is the default address translation made? As I understand MIPS, code in kseg0 (0x8000) and kseg1 (0xA000) should be executable without MMU/TLB setup because it is mapped by default to physical 0x0. But looks to me that I get a cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 for it. Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
On Thu, Mar 30, 2006 at 03:40:25PM +0200, Dirk Behme wrote: Thiemo Seufer wrote: On Tue, Mar 28, 2006 at 08:57:15AM +0200, Dirk Behme wrote: What about the patch in attachment? It first tries to load image as an ELF file. If this fails it falls back to raw image load. Additionally, it takes feature of patch above to go on even if no BIOS is found. A slightly more polished version with less noisy messages is appended. It also adjusts the ramdisk load address to physical addressing, similiar to the binary kernel load. One question I just found: If we go on if no BIOS is found/executed and we load some stuff to e.g. 0x8001, where is the default address translation made? As I understand MIPS, code in kseg0 (0x8000) and kseg1 (0xA000) should be executable without MMU/TLB setup because it is mapped by default to physical 0x0. But looks to me that I get a cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 That comes not from the MIPS TLB mapping (which is for KSEG0/1 a fixed translation involving the high bits) but the underlying qemu softmmu support. The whole thing works but eats significant performance, there should be room for improvements. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] savevm
Hello, http://www.boblycat.org/~malc/savevm.patch.gz The problem is Paul Brook had broken the save state for keyboard by introducing translate and not saving/loading it. -- mailto:[EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Thiemo Seufer [EMAIL PROTECTED] wrote: cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 That comes not from the MIPS TLB mapping (which is for KSEG0/1 a fixed translation involving the high bits) but the underlying qemu softmmu support. I'm trying to implement a mips_bios, unfortunately, quemu seems can't run a code at the 0xbfc0 region. See a http://pastebin.com/628591 The conventional 'move k0,zero' instruction (line 35) causes an general exceprion to 0xbfc00380, see line 70 -- -=AV=- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Wolfgang Schildbach wrote: The way I understand this is that anyone who got ARM documentation with the license that Paul mentioned, could not contribute patches that implement v6 emulation. If, however, someone else (who has not signed such a license) were to buy documentation about the ARMv6 architecture that comes without a license (for example, the ARM System Developer's Guide, by Sloss, Symes, and Wright, Elsevier 2004), that someone should be able to contribute (at least in those aspects of the ARM that are disclosed by the book). In that case, ARM should not have any legal hooks except copyright, and since at that point you are not using any of their code, there is no case. However, I am not a lawyer, so don't take my word for it. I wonder about patents (and their validity). A MIPS hardware implementation that I worked with had all the basic MIPS integer instructions except one small group, on the ground that those instructions were covered by a MIPS patent and so they dared not include it. It was the instruction used for unaligned memory word access. For that reason, we used a modified GCC specially for that chip. I also find it hard to believe that building a product competitive to an ARM is possible using a description of the instruction set alone. (I meant a description of the architectural behaviour... not just the instruction set. Compilers are moving beyond merely implementing user space code, to optimising paths between security levels, analysing memory orderings between threads, etc. And for that matter, so are decompilers.) It's not possible.. yet. Believe me, there are people working on it. And it doesn't have to be competitive for ARM to have a reaction... as we're seeing with software emulatation. That said, I agree with Paul that lobbying ARM to change their license is probably a better route to go. I believe software emulators like qemu are really in ARMs best interest since they support ARM development and thereby increase the availability of software for ARM cores. That makes sense to me. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
On Thu, Mar 30, 2006 at 03:30:30PM +0100, Jamie Lokier wrote: I wonder about patents (and their validity). A MIPS hardware implementation that I worked with had all the basic MIPS integer instructions except one small group, on the ground that those instructions were covered by a MIPS patent and so they dared not include it. It was the instruction used for unaligned memory word access. For that reason, we used a modified GCC specially for that chip. Note that the new ARM ABI being pushed by ARM ltd, which is called EABI, mandates using a thumb-related instruction (bx) in the function exit path. In other words, if the arm-compatible core that you wrote for your FPGA board to play with does not implement that instruction (possibly because you want to avoid infringing on ARM patents), you won't be able to run any EABI-using ARM distros on it. --L ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Note that the new ARM ABI being pushed by ARM ltd, which is called EABI, mandates using a thumb-related instruction (bx) in the function exit path. No it doesn't. The EABI mandates that code be interworking safe. It's possible to implement this is an way that only uses bx when actually returning to Thumb code, ie when you already know your hardware supports bx. In practice many distros may assume Thumb capable hardware in the same way many x86 distros assume at least i486 or i686, but that's an entirely different issue. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add MIPS ELF loader
Alexander Voropay wrote: I'm trying to implement a mips_bios, unfortunately, quemu seems can't run a code at the 0xbfc0 region. See a http://pastebin.com/628591 The conventional 'move k0,zero' instruction (line 35) causes an general exceprion to 0xbfc00380, see line 70 Try to change the following lines in hw/mips_r4k.c: //#define KERNEL_LOAD_ADDR 0x8001 #define KERNEL_LOAD_ADDR 0xBFC0 //cpu_register_physical_memory(0, ram_size, IO_MEM_RAM); cpu_register_physical_memory(0x1fc0, ram_size, IO_MEM_RAM); //kernel_size = load_image(kernel_filename, //phys_ram_base + (kernel_base - 0x8000)); kernel_size = load_image(kernel_filename, phys_ram_base); Works for me: (gdb) p/x $pc $1 = 0xbfc0 (gdb) x/2i $pc 0xbfc0 _start:b 0xbfc00400 reset 0xbfc4 _start+4: nop (gdb) x/2i 0x1fc0 0x1fc0: b 0x1fc00400 0x1fc4: nop (gdb) Best regards Dirk ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Improving timer/clock for win32
Hi, This patch improves timer/clock for win32. Here is the patch and a binary. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060330-timer.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060330-timer.zip It supports 1ms interval interrupt. It also improves the delay when it is used with Kqemu/Qvm86. A main reason of delay of time is that when main_loop_wait is slept and an interrupt timer is expired, the timer interrupt doesn't occured. I used an event object to wake up the main loop. I used QueryPerformanceCounter/QueryPerformanceFrequency to measure time. It uses ACPI PM Timer on my system. Some system use RDTSC value. It depends on your system. It might be possible to run on SMP(HT or Multi-core) system. I haven't tested it, though. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
I tried various guests today on winXP host. * No crash and good speed for std kqemu (no kernel-kqemu) * Crash of winXP host systematically on all guests (linux + ms) It's hard to debug what is the problem. The only thing I have the time to see is a BSOD (blue screen of d**th) and the error message, informative ? TRAP_CAUSE_UNKNOWN Good job overall :) Kudos to the developpers. Maybe we can make it a bartpe plugin one day, automatically started with kqemu on ? That would be nice to promote qemu virtualization features... On 3/27/06, Fabrice Bellard [EMAIL PROTECTED] wrote: Hi, I just released a new version of kqemu which fixes some recently discovered issues. The fixes are the following: - Workaround for full virtualization on Windows host (more tests needed). -- Christian ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Hello, I have the same issues as Christian : I'm unable to get -kernel-kqemu option to work. My configuration : Host : Windows XPpro SP2 on Intel P4HT QEMU : 0.8.0 latest CVS version. qemu.exe process' affinity set to second 'CPU' (with ImageCfg, but the result is the same if set with ProcExp or with TaskMgr) Guests : * Windows 2000 SP4 : freezes just after loading splash screen... * Ubuntu 5.10 : gives a kernel panic... Procexp shows about 100% CPU usage in kernel mode... but it's possible to switch to QEMU console and 'q'uit. Everything works great when I don't use kernel-kqemu... Am I missing something ? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
