Re: [Qemu-devel] qemu-system-m68k and booting m68k images
On Wednesday 10 October 2007 10:20:41 pm Ian Graeme Hilt wrote: On Wed, Oct 10, 2007 at 06:20:57PM -0500, Rob Landley wrote: On Saturday 06 October 2007 8:59:02 pm Ian Graeme Hilt wrote: Two questions: 1. Why does qemu-system-m68k require a kernel image? I'd actually be pretty happy if I could figure out which kernel image I could build that the sucker would boot. Have you tried http://fabrice.bellard.free.fr/qemu/coldfire-test-0.1.tar.bz2 Er, yes. coldfire. Not m68k. Says so right on the tin. Back in July, Andreas Schwab posted a patch to upgrade the coldfire support to full m68k support (or at least the instructions output by gcc): http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00015.html I thought it would have been merged by now (or that there would at least be some kind of follow up on it), but apparently not. Coldfire is a subset of m68k (plus some weird floating point instructions and probably some other stuff). There doesn't seem to be a way to get a coldfire toolchain from unmodified gcc source code, instead you go download a different gcc source tarball from code sourcery: http://www.codesourcery.com/gnu_toolchains/coldfire If there's a way to build a coldfire toolchain from the gcc 4.1.2 release, Google isn't finding it. gcc 4.1.2 was released Febuary 13, 2007, and the gcc developers announced the integration of coldfire support on March 9, 2007 so maybe it's in 4.2... Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] [PATCH] syscall_target_errno.patch
On Wed, 2007-10-10 at 21:38 -0600, Thayne Harbaugh wrote: I appreciate the work that Jocelyn did to correct the types used throughout linux-user/syscall.c. Along those same lines I am working on several patches to eliminate some incorrect constructs that have crept into syscall.c - some of which I have ignorantly propagated in previous patches that I have submitted. I have noticed that many functions in syscall.c return a *host* errno when a *target* errno should be return. At the same time, there are several places in syscall.c:do_syscall() that immediately return an errno rather than setting the return value and exiting through the syscall return value reporting at the end of do_syscall(). This patch addresses both of those problems at once rather than touching the exact same errno return lines twice in do_syscall(). It also touches a few functions in linux-user/signal.c that are called from do_syscall(). Please send comments - I have several more patches that will build on this one as well as a few more patches that will fix other incorrect constructs with target/host address handling. Thanks. Hi, there are still a lot of problems hidden in syscalls.c and signal.c, as you noticed. Your patch seems OK to me and adding all those comments is imho really great. My only remark is a cosmetic one: I don't like too much hidding 'goto' in macros... -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Fabrice Bellard wrote: Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. Doesn't work for MIPS64, since it doesn't quite have a compatibility mode in the traditional sense. It needs to retain 64bit register width when running N32 ABI binaries. (Thus the somewhat odd overrides I added for the preliminary N32 support.) Thiemo
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On 10/11/07, Thiemo Seufer [EMAIL PROTECTED] wrote: Fabrice Bellard wrote: Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. Doesn't work for MIPS64, since it doesn't quite have a compatibility mode in the traditional sense. It needs to retain 64bit register width when running N32 ABI binaries. (Thus the somewhat odd overrides I added for the preliminary N32 support.) CPU registers (and storage for full width registers) would still be 64 bits. The ABI uses of target_ulong need to be changed to, for example abi_ulong so that the size can be changed. Sparc64 does not have a compatibility mode either (except for address masking), it can run Sparc32 binaries because of the cleverly designed instruction set. Ops use full 64 bits of a register, but there are two sets of CPU flags, 32 and 64 bits.
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Blue Swirl wrote: [snip] I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. Doesn't work for MIPS64, since it doesn't quite have a compatibility mode in the traditional sense. It needs to retain 64bit register width when running N32 ABI binaries. (Thus the somewhat odd overrides I added for the preliminary N32 support.) CPU registers (and storage for full width registers) would still be 64 bits. The ABI uses of target_ulong need to be changed to, for example abi_ulong so that the size can be changed. I see. Sparc64 does not have a compatibility mode either (except for address masking), it can run Sparc32 binaries because of the cleverly designed instruction set. Ops use full 64 bits of a register, but there are two sets of CPU flags, 32 and 64 bits. For MIPS it's not even that much, sign-extension magic handles everything. Thiemo
Re: [Qemu-devel] RFC: cleanups: CPU_MEM_INDEX
J. Mayer wrote: On Wed, 2007-10-10 at 07:06 +0200, J. Mayer wrote: On Wed, 2007-10-10 at 01:12 +0100, Thiemo Seufer wrote: J. Mayer wrote: Here's a proposal to add a int cpu_mem_index (CPUState *env) function in targets cpu.h header. The idea of this patch is: - avoid many #ifdef TARGET_xxx in exec-all.h and softmmu_header.h then make the code more readable - avoid multiple implementation of the same code (3, in that particular case) this to avoid potential conflicts if the definition has to be updated for any reason (ie support for new memory access modes, emulation optimisation...) Please comment. -- J. Mayer [EMAIL PROTECTED] Never organized [...] Here's an updated version of the patch. My comments about it stay valid, with two additions: 1/ when is user is needed to maintain compatibility with existing code, I now define it as: int is_user = mmu_idx == MMU_USER_IDX; instead of just is_user = mmu_idx. This definition will then remain correct even if the definition of the MMU modes are later changed for a specific target 2/ I now precompute the mmu_idx on PowerPC platform as it can never change inside a single TB. This may save a few instructions for every memory access. I guess the same optimisation can be made for the other targets, but not knowing exactly when it would have to be recomputed, for most targets, I prefer not to do this optimisation myself. I like this version. Tested with x86 and mips, on Linux/ppc host. Thiemo
Re: [Qemu-devel] qemu-system-m68k and booting m68k images
On Thu, Oct 11, 2007 at 02:15:25AM -0500, Rob Landley wrote: On Wednesday 10 October 2007 10:20:41 pm Ian Graeme Hilt wrote: On Wed, Oct 10, 2007 at 06:20:57PM -0500, Rob Landley wrote: On Saturday 06 October 2007 8:59:02 pm Ian Graeme Hilt wrote: Two questions: 1. Why does qemu-system-m68k require a kernel image? I'd actually be pretty happy if I could figure out which kernel image I could build that the sucker would boot. Have you tried http://fabrice.bellard.free.fr/qemu/coldfire-test-0.1.tar.bz2 Er, yes. coldfire. Not m68k. Says so right on the tin. Ok. In my case, the target's processor is a MC68030 with a VME bus. It was built by Microware back in the late 80s to early 90s and has OSK (OS-9 for a MC680x0) installed. Back in July, Andreas Schwab posted a patch to upgrade the coldfire support to full m68k support (or at least the instructions output by gcc): http://lists.gnu.org/archive/html/qemu-devel/2007-07/msg00015.html I thought it would have been merged by now (or that there would at least be some kind of follow up on it), but apparently not. I've tried building QEmu current with gcc-3.4.6 and this patch applied. qemu-system-m68k hung when attempting to boot the kernel image in coldfire-test-0.1.tar.bz2. [...] If there's a way to build a coldfire toolchain from the gcc 4.1.2 release, Google isn't finding it. gcc 4.1.2 was released Febuary 13, 2007, and the gcc developers announced the integration of coldfire support on March 9, 2007 so maybe it's in 4.2... I think the Linux kernel supports a MC68030 and the VME option. Even if gcc was capable of creating a kernel image for this specific arch, I don't think this would help me(?) since I want to boot the OSK OS floppy and harddrive images. I've used OS9Exec from sourceforge to boot these images and it works rather well. A problem with it is when an OS9 command tries to access hardware a bus error is generated. The reason I was inquiring about the rationale behind the kernel image is that I was going to try writing code to boot the floppy images I have with QEmu. Unfortunately I have very little programming experience, so any information is helpful. -- Ian Graeme Hilt
Re: [Qemu-devel] Pending Disk I/O requests during live VM migration
In ioemu/vl.c: do_savevm(), before saving the current VM state for live VM migration (qemu_savevm_state()), it calls qemu_aio_flush() in ioemu/block-raw.c. Now qemu_aio_flush() internally calls qemu_aio_poll() where we loop through the linked list of RawAIOCB structures and remove the request (qemu_aio_release()) only if the request is CANCELED or NOT IN PROGRESS. I am not really sure then why ioemu/hw/ide.c:pci_ide_save() has a comment saying If a transfer is pending, we do not save it yet. Looking at qemu_aio_poll() doesn't seem to indicate so... Also, looking at /usr/include/aio.h sees to suggest that the pending requests get stored in the aio_buf of struct aiocb structure. Do the responses to these requests go in the same buffer (in which case the aio_buf and aio_nbytes would get overwritten by the response) ?? any help in this regard would be helful. -Kaushik Blue Swirl wrote: On 10/4/07, Kaushik Bhandankar [EMAIL PROTECTED] wrote: 1) I guess the IDE disk code is in ioemu/hw/ide.c. But where is the IDE disk controller code located ?? Same file, see ide_ioport_write(). 2) I do not really understand BMDMA in ioemu/hw/ide.c. google doesnt seem to be helping much here. Any documentation about the QEMU IDE disks would be greatly appreciated. No idea. 3) vl.c:5522 seems to be not the correct code (I guess our vl.c codes are different).. Could you point me to the routine in vl.c where the pending disk IO requests are flushed before VM save (I guess the VM save happens in qemu_savevm_state() in vl.c wherein it invokes all the registered save handlers)? It's in: void do_savevm(const char *name) 4) Somebody told me that the pending disk IO requests are stored somewhere in quemu's I/O disk model but I am not sure exactly whereCan somebody help me with this ? Qemu uses asynchronous IO, grepping aio or AIO should find something. -- question = ( to ) ? be : ! be; -- Wm. Shakespeare
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On Thu, 2007-10-11 at 22:26 +0300, Blue Swirl wrote: On 10/10/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. I made a patch to rename target_ulong/long to abi_ulong/long and also add a new emulator target that uses the 32 bit ABI with 64 bit CPU. Some Sparc32 binaries run, others don't, possibly indicating bugs in the Sparc64 emulation! The patch is quite large because of the renaming, but this shouldn't have effect to any other target. Any comments? Great ! The patch seems safe, at first look, then I noticed a few things that are not correct or may be improved: * In linux-user/main.c: PowerPC DCR access should keep using target_ulong. This is a hardware bus, not an ABI dependent stuff. If a 32 bits cast is needed, it would be done in the micro-ops that handle the DCR bus accesses. * in linux-user/qemu.h: why is there still a OVERRIDE_ELF_CLASS variable, when checking TARGET_ABI32 should be sufficient ? It seems to me that having 2 defines which are, in fact, synonymous may be a source of confusion. * in configure: you also added a sparc64-softmmu target, which seems not related with this particular patch. * in configure: why add a specific TARGET_ABI32_DIR variable for that case ? It seems to me that a TARGET_ABI_DIR variable could be useful for all targets. Let me give an example: I want to add a ppcemb-linux-user target, emulating a PowerPC 32 with 64 bits registers and SIMD extensions but I don't want to duplicate the linux-user/ppc subdirectory. Having a TARGET_ABI_DIR available for all targets would solve my problem. In fact, even ppc and ppc64 could be merged... As you need this feature in your case, I think it would be a good idea to add it for all targets. And then, the kludge in Makefile.target could be replaced by: -CPPFLAGS+=-I$(SRC_PATH)/linux-user -I $(SRC_PATH)/linux-user/$(TARGET_ARCH) +CPPFLAGS+=-I$(SRC_PATH)/linux-user -I $(SRC_PATH)/linux-user/$(TARGET_ABI_DIR) which is simpler and easier to understand, imho. -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] RFC: cleanups: CPU_MEM_INDEX
On Thu, 2007-10-11 at 18:46 +0100, Thiemo Seufer wrote: J. Mayer wrote: On Wed, 2007-10-10 at 07:06 +0200, J. Mayer wrote: On Wed, 2007-10-10 at 01:12 +0100, Thiemo Seufer wrote: J. Mayer wrote: Here's a proposal to add a int cpu_mem_index (CPUState *env) function in targets cpu.h header. The idea of this patch is: - avoid many #ifdef TARGET_xxx in exec-all.h and softmmu_header.h then make the code more readable - avoid multiple implementation of the same code (3, in that particular case) this to avoid potential conflicts if the definition has to be updated for any reason (ie support for new memory access modes, emulation optimisation...) Please comment. -- J. Mayer [EMAIL PROTECTED] Never organized [...] Here's an updated version of the patch. My comments about it stay valid, with two additions: 1/ when is user is needed to maintain compatibility with existing code, I now define it as: int is_user = mmu_idx == MMU_USER_IDX; instead of just is_user = mmu_idx. This definition will then remain correct even if the definition of the MMU modes are later changed for a specific target 2/ I now precompute the mmu_idx on PowerPC platform as it can never change inside a single TB. This may save a few instructions for every memory access. I guess the same optimisation can be made for the other targets, but not knowing exactly when it would have to be recomputed, for most targets, I prefer not to do this optimisation myself. I like this version. Tested with x86 and mips, on Linux/ppc host. Thanks for testing. I guess it's safe... but I'd like to get more reports or comments about it before applying this ! -- J. Mayer [EMAIL PROTECTED] Never organized
[Fwd: [Qemu-devel] RFC: avoid #ifdef for target cpu list]
Forwarded Message From: J. Mayer [EMAIL PROTECTED] Reply-To: qemu-devel@nongnu.org To: qemu-devel@nongnu.org Subject: [Qemu-devel] RFC: avoid #ifdef for target cpu list Date: Wed, 10 Oct 2007 07:14:22 +0200 This tiny patch unifies the -cpu ? option for all cpu that actually can handle it. It changes the arm_cpu_list to use the same prototype as ppc, mips and sparc and add a new define cpu_list in target_xxx/cpu.h As the cpu selection is not implemented for all targets, I had to protect the call to cpu_list with a #if defined(cpu_list) that will have to be suppressed once all target will implement this feature. Please comment. If there is no objection about it, I'll apply it today. -- J. Mayer [EMAIL PROTECTED] Never organized
[Qemu-devel] Kqemu on x86_64 host with x86_64 guest
Hey there, Just wanted to check if there is any progress with a x86_64 guest on a x86_64 host when the kernel module kqemu is enabled. As long the module is disabled the system boots fine. Setting: Gentoo x86_64 box as host, guest is a Debian AMD64 Execution: /usr/local/bin/qemu-system-x86_64 -kernel-kqemu -localtime -net user -net nic,vlan=0,model=rtl8139,macaddr=52:54:00:00:EE:01 The qemu crashes with the following output: RAX=0022 RBX=0022 RCX=00fa RDX=810007e31fd8 RSI=0100 RDI=810007cad040 RBP=80524100 RSP=804c0f60 R8 =0003 R9 =0004 R10=0046 R11=00010246 R12=000a R13= R14=810007cad040 R15=0004 RIP=80210376 RFL=00010202 [---] CPL=3 II=0 A20=1 SMM=0 HLT=0 ES = CS =0010 00affa00 SS = 00cff200 DS = FS = GS = LDT= 8000 TR =0040 810001003000 206f 8900 GDT= 80532000 0080 IDT= 804c7000 0fff CR0=8005003b CR2=2ab037600a80 CR3=0742d000 CR4=06e0 Unsupported return value: 0x
