Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory
On Mon, Aug 05, 2013 at 07:19:08AM +0200, Stefan Weil wrote: Am 05.08.2013 00:37, schrieb Peter Maydell: On 4 August 2013 23:04, Aurélien Jarno aurel...@aurel32.net wrote: The real hardware probably returns all 1 or all 0 for addresses not decoded to a device. This is what QEMU should model, and it should not trigger a DBE or IBE exception. Looking at the current MIPS documentation, Bus Error is defined as: A bus error exception occurs when an instruction or data access makes a bus request (due to a cache miss or an uncacheable reference) and that request terminates in an error. Older CPU documentation like the R4000 have a more precise definition: A Bus Error exception is raised by board-level circuitry for events such as bus time-out, backplane bus parity errors, and invalid physical memory addresses or access types. As we don't model this kind of errors, we should definitely just not trigger an exception in that case, and even logging the event as unimplemented is probably wrong. Well, we certainly can model invalid-physical-address and bus-timeout where that's what the board does for accesses to non-decoded addresses; but presumably in this case it doesn't... -- PMM Is there anybody who has access to physical Malta hardware? It would be interesting to see whether there is an exception during the gcmp test or not. With latest QEMU, the MIPS Malta system emulation starts handling the exception caused by the gcmp test, but then gets a second exception which is fatal (see below). There might be something missing in our very simple bios emulation. Booting YAMON in QEMU also shows the same behaviour, that is trying to access to the 1fbf8008 address and getting a DBE exception, causing it to fail. So it is clearly not due to our simple bios emulation, but rather to the way the I/O are emulated. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory
On Mon, Aug 05, 2013 at 10:45:31AM +0200, Andreas Färber wrote: Am 05.08.2013 00:04, schrieb Aurélien Jarno: On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote: Am 27.07.2013 22:58, schrieb Stefan Weil: Am 27.07.2013 22:43, schrieb Andreas Färber: Am 27.07.2013 21:37, schrieb Stefan Weil: Am 27.07.2013 19:43, schrieb Peter Maydell: On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote: Another solution would be to add a big dummy memory regions on all MIPS boards to catch memory accesses and not raise an exception. However, this means that each MIPS board will have its own unassigned memory handler, different from the global QEMU one. Better would be to at least provide fake RAZ/WI implementations of devices for the boards, rather than making the dummy region cover the whole of the address space. Not 1.6 material, though. For MIPS Malta, Linux boot can be fixed by handling read access for two addresses: 0x1fbf8008 0x1bc80110 The corresponding definitions in the Linux kernel code seem to be these lines: #define GCMP_BASE_ADDR 0x1fbf8000 #define GCMP_ADDRSPACE_SZ (256 * 1024) #define GCMP_GCB_GCMPB_OFS 0x0008 /* Global GCMP Base */ #define MSC01_BIU_REG_BASE 0x1bc8 #define MSC01_BIU_ADDRSPACE_SZ (256 * 1024) #define MSC01_SC_CFG_OFS0x0110 = mips_malta.c needs a handler for reads of (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS). I don't think it would be correct to emulate them as this are not present on the real Malta board, at least for the model emulated by QEMU. Theses addresses correspond to the SMP controller, and is therefore only present when an SMP daughter card is installed. The Linux kernel probes theses addresses, and look if they return something consistent. If not the corresponding devices are latter ignored. The real hardware probably returns all 1 or all 0 for addresses not decoded to a device. This is what QEMU should model, and it should not trigger a DBE or IBE exception. [snip] Have you tested Jan's patches limiting the new unassigned read value -1 to PIO? I have tried this patches, and they don't fix the problem. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory
On Mon, Aug 05, 2013 at 03:53:08PM +0200, Hervé Poussineau wrote: Andreas Färber a écrit : [snip] Have you tested Jan's patches limiting the new unassigned read value -1 to PIO? I have tried this patches, and they don't fix the problem. Too bad. So what do you propose? Restoring #ifdef and using empty_slot_init() have been suggested so far, any other concrete ideas? Another idea (not tested): override the CPUClass-do_unassigned_level on board level, to only raise IBE and no DBE. That way, right behaviour is kept in global code, and bad code is only at board level, where it can be removed later board after board. The problem is that it looks like the code is not bad. It seems that real hardware just ignore such accesses, so this should stay forever. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory
On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote: Am 27.07.2013 22:58, schrieb Stefan Weil: Am 27.07.2013 22:43, schrieb Andreas Färber: Am 27.07.2013 21:37, schrieb Stefan Weil: Am 27.07.2013 19:43, schrieb Peter Maydell: On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote: Another solution would be to add a big dummy memory regions on all MIPS boards to catch memory accesses and not raise an exception. However, this means that each MIPS board will have its own unassigned memory handler, different from the global QEMU one. Better would be to at least provide fake RAZ/WI implementations of devices for the boards, rather than making the dummy region cover the whole of the address space. Not 1.6 material, though. For MIPS Malta, Linux boot can be fixed by handling read access for two addresses: 0x1fbf8008 0x1bc80110 The corresponding definitions in the Linux kernel code seem to be these lines: #define GCMP_BASE_ADDR 0x1fbf8000 #define GCMP_ADDRSPACE_SZ (256 * 1024) #define GCMP_GCB_GCMPB_OFS 0x0008 /* Global GCMP Base */ #define MSC01_BIU_REG_BASE 0x1bc8 #define MSC01_BIU_ADDRSPACE_SZ (256 * 1024) #define MSC01_SC_CFG_OFS0x0110 = mips_malta.c needs a handler for reads of (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS). I don't think it would be correct to emulate them as this are not present on the real Malta board, at least for the model emulated by QEMU. Theses addresses correspond to the SMP controller, and is therefore only present when an SMP daughter card is installed. The Linux kernel probes theses addresses, and look if they return something consistent. If not the corresponding devices are latter ignored. The real hardware probably returns all 1 or all 0 for addresses not decoded to a device. This is what QEMU should model, and it should not trigger a DBE or IBE exception. Looking at the current MIPS documentation, Bus Error is defined as: A bus error exception occurs when an instruction or data access makes a bus request (due to a cache miss or an uncacheable reference) and that request terminates in an error. Older CPU documentation like the R4000 have a more precise definition: A Bus Error exception is raised by board-level circuitry for events such as bus time-out, backplane bus parity errors, and invalid physical memory addresses or access types. As we don't model this kind of errors, we should definitely just not trigger an exception in that case, and even logging the event as unimplemented is probably wrong. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] [PULL 00/58] ppc patch queue 2013-03-22
On Fri, Mar 22, 2013 at 03:28:34PM +0100, Alexander Graf wrote:
Hi Blue / Aurelien,
This is my current patch queue for ppc. Please pull.
Alex
The following changes since commit afed26082219b49443193b4ac32d113bbcf967fd:
Edgar E. Iglesias (1):
microblaze: Ignore non-cpu accesses to unmapped areas
are available in the git repository at:
git://github.com/agraf/qemu.git ppc-for-upstream
David Gibson (52):
pseries: Fix breakage in CPU QOM conversion
pseries: Remove busname property for PCI host bridge
target-ppc: Remove CONFIG_PSERIES dependency in kvm.c
pseries: Move XICS initialization before cpu initialization
target-ppc: Remove vestigial PowerPC 620 support
target-ppc: Trivial cleanups in mmu_helper.c
target-ppc: Remove address check for logging
target-ppc: Move SLB handling into a mmu-hash64.c
target-ppc: Disentangle pte_check()
target-ppc: Disentangle find_pte()
target-ppc: Disentangle get_segment()
target-ppc: Rework get_physical_address()
target-ppc: Disentangle get_physical_address() paths
target-ppc: Disentangle hash mmu paths for cpu_ppc_handle_mmu_fault
target-ppc: Disentangle hash mmu versions of cpu_get_phys_page_debug()
target-ppc: Disentangle hash mmu helper functions
target-ppc: Don't share get_pteg_offset() between 32 and 64-bit
target-ppc: Disentangle BAT code for 32-bit hash MMUs
target-ppc: mmu_ctx_t should not be a global type
mmu-hash*: Add header file for definitions
mmu-hash*: Add hash pte load/store helpers
mmu-hash*: Reduce use of access_type
mmu-hash64: Remove nx from mmu_ctx_hash64
mmu-hash*: Remove eaddr field from mmu_ctx_hash{32, 64}
mmu-hash*: Combine ppc_hash{32, 64}_get_physical_address and
get_segment{32, 64}()
mmu-hash32: Split out handling of direct store segments
mmu-hash32: Split direct store segment handling into a helper
mmu-hash*: Cleanup segment-level NX check
mmu-hash*: Don't keep looking for PTEs after we find a match
mmu-hash*: Separate PTEG searching from permissions checking
mmu-hash*: Make find_pte{32, 64} do more of the job of finding ptes
mmu-hash*: Remove permission checking from find_pte{32, 64}()
mmu-hash64: Clean up ppc_hash64_htab_lookup()
mmu-hash*: Fold pte_check*() logic into caller
mmu-hash32: Remove odd pointer usage from BAT code
mmu-hash32: Split BAT size logic from permissions logic
mmu-hash32: Clean up BAT matching logic
mmu-hash32: Cleanup BAT lookup
mmu-hash32: Don't look up page tables on BAT permission error
mmu-hash*: Don't update PTE flags when permission is denied
mmu-hash32: Remove nx from context structure
mmu-hash*: Clean up permission checking
mmu-hash64: Factor SLB N bit into permissions bits
mmu-hash*: Clean up PTE flags update
mmu-hash*: Clean up real address calculation
mmu-hash*: Correctly mask RPN from hash PTE
mmu-hash*: Don't use full ppc_hash{32, 64}_translate() path for
get_phys_page_debug()
mmu-hash*: Merge translate and fault handling functions
mmu-hash64: Implement Virtual Page Class Key Protection
target-ppc: Split user only code out of mmu_helper.c
target-ppc: Move ppc tlb_fill implementation into mmu_helper.c
target-ppc: Use QOM method dispatch for MMU fault handling
Fabien Chouteau (1):
PPC/GDB: handle read and write of fpscr
Richard Henderson (5):
target-ppc: Fix add and subf carry generation in narrow mode
target-ppc: Use NARROW_MODE macro for branches
target-ppc: Use NARROW_MODE macro for comparisons
target-ppc: Use NARROW_MODE macro for addresses
target-ppc: Use NARROW_MODE macro for tlbie
gdbstub.c |3 +-
hw/ppc/spapr.c| 16 +-
hw/ppc/spapr_hcall.c | 102 ++
hw/ppc/xics.c | 57 ++--
hw/spapr_pci.c| 30 ++-
hw/spapr_pci.h|4 +-
hw/xics.h |3 +-
monitor.c |4 -
target-ppc/Makefile.objs |7 +-
target-ppc/cpu-models.c |2 +-
target-ppc/cpu-qom.h |4 +
target-ppc/cpu.h | 91 +
target-ppc/fpu_helper.c |5 +
target-ppc/helper.h |1 -
target-ppc/kvm.c |3 +-
target-ppc/machine.c |4 +-
target-ppc/mem_helper.c | 38 --
target-ppc/misc_helper.c |6 -
target-ppc/mmu-hash32.c | 560 +++
target-ppc/mmu-hash32.h | 102 +
target-ppc/mmu-hash64.c | 546 +++
target-ppc/mmu-hash64.h | 124 ++
target-ppc/mmu_helper.c | 835
-
target-ppc/translate.c
Re: [Qemu-devel] TCG broken in system mode (was TCG assertion with qemu-system-mipsel)
On Thu, Mar 21, 2013 at 04:04:44PM +0900, Yeongkyoon Lee wrote: On 03/18/2013 07:27 AM, Aurélien Jarno wrote: On Wed, Mar 06, 2013 at 07:10:17AM +0100, Aurélien Jarno wrote: On Wed, Mar 06, 2013 at 11:05:15AM +0900, Yeongkyoon Lee wrote: On 03/05/2013 11:18 PM, Aurélien Jarno wrote: On Mon, Mar 04, 2013 at 05:37:31PM +0100, Aurélien Jarno wrote: Hi, On Sat, Feb 23, 2013 at 11:10:18PM +0100, Stefan Weil wrote: This assertion occured with latest git master: qemu-system-mipsel: /src/qemu/tcg/tcg-op.h:2589: tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask (1 idx)) == 0' failed. Aborted QEMU was built with --enable-debug and running a Debian MIPS Lenny (NFS root). The assertion happened when running apt-get update in the guest. Is it something reproductible or more or less random? Have you Cc:ed Richard because it's related to the latest patches? On my side I am experiencing random segfaults in various guests (at least PowerPC, MIPS, SH4 and ARM). I have found a way to bisect it, even if it is quite long (building Perl + the testsuite). Currently I know that 1.3 is affected, while 1.2 is not. I have found that the issue comes from the following commits, which unfortunately are not bisectable one by one (though it won't change the results a lot): commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699 Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:25 2012 +0900 tcg: Optimize qemu_ld/st by generating slow paths at the end of a block Add optimized TCG qemu_ld/st generation which locates the code of TLB miss cases at the end of a block after generating the other IRs. Currently, this optimization supports only i386 and x86_64 hosts. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com commit fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:24 2012 +0900 tcg: Add extended GETPC mechanism for MMU helpers with ldst optimization Add GETPC_EXT which is used by MMU helpers to selectively calculate the code address of accessing guest memory when called from a qemu_ld/st optimized code or a C function. Currently, it supports only i386 and x86-64 hosts. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com commit 32761257c0b9fa7ee04d2871a6e48a41f119c469 Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:23 2012 +0900 configure: Add CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization Enable CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization only when a host is i386 or x86_64. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com I will try to understand why. Hi Aurélien, Do you mean that those random segfaults occurred only when configured with --enable-debug? Although I cannot see how my commits affect debug built image at a glance, I'll do double-check. Thanks. The problem is there even without configuring QEMU with --enable-debug. It justs doesn't happens very often, and very randomly. The only way to reproduce it each time is to launch a big task in the guest (for me building Perl) and see if it completes or now. It can take up to one hour until it happens. I should precise that the segfault is on the guest side. I have tried to look at your patches, and so far I haven't found the issue. It seems the two first patches are fine, ie I have verified the return address is always correctly computed. I still haven't found the issue, but on the other hand I can't find any problem in your code, after reading it dozen of times. I also tried to modify it as less as possible while issuing the slow path back inside the TB and it fixes the problem. So it really looks like to be due to the slow path being at the end of the TB, and not to a bug in the code generating it. After adding various checks, I am also convinced the address computed in GETPC_EXT() is always correct. I have to say I am running out of ideas. One way to reproduce the issue more easily is to reduce the size of the generated code buffer, for example by setting it to 512kB for both MIN_CODE_GEN_BUFFER_SIZE and MAX_CODE_GEN_BUFFER_SIZE in translate-all.c. That way booting an ARM guest triggers plenty of segmentation faults or other strange issues with your patch but not without. OTOH increasing this size make the issue to almost disappear even when building perl including the testsuite (for that it has to be at least 512MB). Although I've not succeeded to reproduce the problem, I've found a suspicious code stub about boundary-checking
Re: [Qemu-devel] TCG broken in system mode (was TCG assertion with qemu-system-mipsel)
On Wed, Mar 06, 2013 at 07:10:17AM +0100, Aurélien Jarno wrote: On Wed, Mar 06, 2013 at 11:05:15AM +0900, Yeongkyoon Lee wrote: On 03/05/2013 11:18 PM, Aurélien Jarno wrote: On Mon, Mar 04, 2013 at 05:37:31PM +0100, Aurélien Jarno wrote: Hi, On Sat, Feb 23, 2013 at 11:10:18PM +0100, Stefan Weil wrote: This assertion occured with latest git master: qemu-system-mipsel: /src/qemu/tcg/tcg-op.h:2589: tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask (1 idx)) == 0' failed. Aborted QEMU was built with --enable-debug and running a Debian MIPS Lenny (NFS root). The assertion happened when running apt-get update in the guest. Is it something reproductible or more or less random? Have you Cc:ed Richard because it's related to the latest patches? On my side I am experiencing random segfaults in various guests (at least PowerPC, MIPS, SH4 and ARM). I have found a way to bisect it, even if it is quite long (building Perl + the testsuite). Currently I know that 1.3 is affected, while 1.2 is not. I have found that the issue comes from the following commits, which unfortunately are not bisectable one by one (though it won't change the results a lot): commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699 Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:25 2012 +0900 tcg: Optimize qemu_ld/st by generating slow paths at the end of a block Add optimized TCG qemu_ld/st generation which locates the code of TLB miss cases at the end of a block after generating the other IRs. Currently, this optimization supports only i386 and x86_64 hosts. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com commit fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:24 2012 +0900 tcg: Add extended GETPC mechanism for MMU helpers with ldst optimization Add GETPC_EXT which is used by MMU helpers to selectively calculate the code address of accessing guest memory when called from a qemu_ld/st optimized code or a C function. Currently, it supports only i386 and x86-64 hosts. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com commit 32761257c0b9fa7ee04d2871a6e48a41f119c469 Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:23 2012 +0900 configure: Add CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization Enable CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization only when a host is i386 or x86_64. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com I will try to understand why. Hi Aurélien, Do you mean that those random segfaults occurred only when configured with --enable-debug? Although I cannot see how my commits affect debug built image at a glance, I'll do double-check. Thanks. The problem is there even without configuring QEMU with --enable-debug. It justs doesn't happens very often, and very randomly. The only way to reproduce it each time is to launch a big task in the guest (for me building Perl) and see if it completes or now. It can take up to one hour until it happens. I should precise that the segfault is on the guest side. I have tried to look at your patches, and so far I haven't found the issue. It seems the two first patches are fine, ie I have verified the return address is always correctly computed. I still haven't found the issue, but on the other hand I can't find any problem in your code, after reading it dozen of times. I also tried to modify it as less as possible while issuing the slow path back inside the TB and it fixes the problem. So it really looks like to be due to the slow path being at the end of the TB, and not to a bug in the code generating it. After adding various checks, I am also convinced the address computed in GETPC_EXT() is always correct. I have to say I am running out of ideas. One way to reproduce the issue more easily is to reduce the size of the generated code buffer, for example by setting it to 512kB for both MIN_CODE_GEN_BUFFER_SIZE and MAX_CODE_GEN_BUFFER_SIZE in translate-all.c. That way booting an ARM guest triggers plenty of segmentation faults or other strange issues with your patch but not without. OTOH increasing this size make the issue to almost disappear even when building perl including the testsuite (for that it has to be at least 512MB). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] TCG assertion with qemu-system-mipsel
On Mon, Mar 04, 2013 at 05:37:31PM +0100, Aurélien Jarno wrote: Hi, On Sat, Feb 23, 2013 at 11:10:18PM +0100, Stefan Weil wrote: This assertion occured with latest git master: qemu-system-mipsel: /src/qemu/tcg/tcg-op.h:2589: tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask (1 idx)) == 0' failed. Aborted QEMU was built with --enable-debug and running a Debian MIPS Lenny (NFS root). The assertion happened when running apt-get update in the guest. Is it something reproductible or more or less random? Have you Cc:ed Richard because it's related to the latest patches? On my side I am experiencing random segfaults in various guests (at least PowerPC, MIPS, SH4 and ARM). I have found a way to bisect it, even if it is quite long (building Perl + the testsuite). Currently I know that 1.3 is affected, while 1.2 is not. I have found that the issue comes from the following commits, which unfortunately are not bisectable one by one (though it won't change the results a lot): commit b76f0d8c2e3eac94bc7fd90a510cb7426b2a2699 Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:25 2012 +0900 tcg: Optimize qemu_ld/st by generating slow paths at the end of a block Add optimized TCG qemu_ld/st generation which locates the code of TLB miss cases at the end of a block after generating the other IRs. Currently, this optimization supports only i386 and x86_64 hosts. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com commit fdbb84d1332ae0827d60f1a2ca03c7d5678c6edd Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:24 2012 +0900 tcg: Add extended GETPC mechanism for MMU helpers with ldst optimization Add GETPC_EXT which is used by MMU helpers to selectively calculate the code address of accessing guest memory when called from a qemu_ld/st optimized code or a C function. Currently, it supports only i386 and x86-64 hosts. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com commit 32761257c0b9fa7ee04d2871a6e48a41f119c469 Author: Yeongkyoon Lee yeongkyoon@samsung.com Date: Wed Oct 31 16:04:23 2012 +0900 configure: Add CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization Enable CONFIG_QEMU_LDST_OPTIMIZATION for TCG qemu_ld/st optimization only when a host is i386 or x86_64. Signed-off-by: Yeongkyoon Lee yeongkyoon@samsung.com Signed-off-by: Blue Swirl blauwir...@gmail.com I will try to understand why. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] TCG assertion with qemu-system-mipsel
Hi, On Sat, Feb 23, 2013 at 11:10:18PM +0100, Stefan Weil wrote: This assertion occured with latest git master: qemu-system-mipsel: /src/qemu/tcg/tcg-op.h:2589: tcg_gen_goto_tb: Assertion `(tcg_ctx.goto_tb_issue_mask (1 idx)) == 0' failed. Aborted QEMU was built with --enable-debug and running a Debian MIPS Lenny (NFS root). The assertion happened when running apt-get update in the guest. Is it something reproductible or more or less random? Have you Cc:ed Richard because it's related to the latest patches? On my side I am experiencing random segfaults in various guests (at least PowerPC, MIPS, SH4 and ARM). I have found a way to bisect it, even if it is quite long (building Perl + the testsuite). Currently I know that 1.3 is affected, while 1.2 is not. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
