Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
On Wed, 29 Sept 2021 at 16:24, abhijeet inamdar wrote: > > I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: 'int,exec,cpu' are probably also helpful. > [New Thread 0x7fffe700 (LWP 44283)] > > IN: > 0x: andeqr0, r0, r0 We started at address 0 in not-thumb mode. Your ELF file is almost certainly not correct (ie it does not include a suitable vector table for the CPU to get its reset PC and SP from). -- PMM
Re: riscv64 system emulation maximum core count with virt machine
If you want to boot with more than 8 harts then you also need to increase the CONFIG_NR_CPUS in the kernel. Along with change in QEMU - VIRT_CPUS_MAX in "include/hw/riscv/virt.h" But, the limit of 8 is low and should be increased. Don't know the reason why its 8. On Sep 22 2021, at 10:19 pm, Mark Wyse wrote: > Hello all, > > Apologies if I missed the answer in the docs, but I am wondering why the virt > machine is limited to only 8 cores when running RISC-V 64 system emulation? I > am interested in booting a 16, 24, or even 32 core SMP Linux kernel with > OpenSBI as the bootloader on the generic virt machine before adding a custom > machine definition. I was able to successfully boot Linux kernel 5.9.0 with > OpenSBI v0.9 and 8 cores/harts with an ext4 filesystem provided by Buildroot. > > I poked around the docs and source code a bit, and found mention of the core > count limit in the docs > (https://qemu.readthedocs.io/en/latest/system/riscv/virt.html), but no reason > as to why this is the limit. It also appears that providing a custom device > tree blob and setting QEMU's -smp option to match might overcome this > limitation, but it would be better if more than 8 cores was supported > directly. > > Best, > Mark > > Mark Wyse > pronouns: he/him/his > PhD Student > Paul G. Allen School of Computer Science & Engineering > University of Washington > > > > > > >
Re: qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
I tried to add -d in_asm,out_asm,guest_errors it gives out as follows: PROLOGUE: [size=45] 0x70849000: 55 pushq%rbp 0x70849001: 53 pushq%rbx 0x70849002: 41 54pushq%r12 0x70849004: 41 55pushq%r13 0x70849006: 41 56pushq%r14 0x70849008: 41 57pushq%r15 0x7084900a: 48 8b ef movq %rdi, %rbp 0x7084900d: 48 81 c4 78 fb ff ff addq $-0x488, %rsp 0x70849014: ff e6jmpq *%rsi 0x70849016: 33 c0xorl %eax, %eax 0x70849018: 48 81 c4 88 04 00 00 addq $0x488, %rsp 0x7084901f: c5 f8 77 vzeroupper 0x70849022: 41 5fpopq %r15 0x70849024: 41 5epopq %r14 0x70849026: 41 5dpopq %r13 0x70849028: 41 5cpopq %r12 0x7084902a: 5b popq %rbx 0x7084902b: 5d popq %rbp 0x7084902c: c3 retq [New Thread 0x7fffe700 (LWP 44283)] IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849100: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849103: 85 dbtestl%ebx, %ebx 0x70849105: 0f 8c 1f 00 00 00jl 0x7084912a 0x7084910b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849112: 48 8b fd movq %rbp, %rdi 0x70849115: be 12 00 00 00 movl $0x12, %esi 0x7084911a: ba 00 00 00 02 movl $0x200, %edx 0x7084911f: b9 01 00 00 00 movl $1, %ecx 0x70849124: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084912a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849131: e9 e2 fe ff ff jmp 0x70849018 0x70849136: 90 nop 0x70849137: 90 nop 0x70849138: .quad 0x55a70e01 IN: 0x: andeqr0, r0, r0 OUT: [size=64] 0x70849240: 8b 5d f0 movl -0x10(%rbp), %ebx 0x70849243: 85 dbtestl%ebx, %ebx 0x70849245: 0f 8c 1f 00 00 00jl 0x7084926a 0x7084924b: c7 45 3c 00 00 00 00 movl $0, 0x3c(%rbp) 0x70849252: 48 8b fd movq %rbp, %rdi 0x70849255: be 12 00 00 00 movl $0x12, %esi 0x7084925a: ba 00 00 00 02 movl $0x200, %edx 0x7084925f: b9 01 00 00 00 movl $1, %ecx 0x70849264: ff 15 0e 00 00 00callq*0xe(%rip) 0x7084926a: 48 8d 05 12 ff ff ff leaq -0xee(%rip), %rax 0x70849271: e9 a2 fd ff ff jmp 0x70849018 0x70849276: 90 nop 0x70849277: 90 nop 0x70849278: .quad 0x55a70e01 qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00= R01= R02= R03= R04= R05= R06= R07= R08= R09= R10= R11= R12= R13=ffe0 R14=fff9 R15= XPSR=4003 -Z-- A handler FPSCR: Thread 3 "qemu-system-arm" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe700 (LWP 44283)] 0x75f31438 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) n [Thread 0x7fffe700 (LWP 44283) exited] [Thread 0x73049700 (LWP 44282) exited] Program terminated with signal SIGABRT, Aborted. The program no longer exists. (gdb) it aborts in the next step only. How can I proceed? Thank you, Abhijeet. On Fri, Sep 17, 2021 at 11:11 AM Peter Maydell wrote: > On Thu, 16 Sept 2021 at 20:13, abhijeet inamdar > > wrote: > > > > Is there any way/s to check where actually is it failing or point which > file? > > Use the usual debugging facilities -- gdbstub or -d debug logging. > > -- PMM >
Logging program execution artifacts in TCG
Hello all, I have a requirement to record a few artifacts when I start a program execution in the TCG mode of QEMU. I use 'nochain,exec' debug flags when starting QEMU in TCG mode. This is for the x86_64 host and target architectures. I am using QEMU version 5.0.1. 1. sequence of memory instructions [ld/st and virtual address] 2. sequence of instruction accesses [cr3+virtual IP of executing instructions] 3. sequence of annotated instructions [cr3+virtual IP of instruction, opcode, if ld/st instruction, also virtual address] I presume that the virtual IP and cr3 values can be obtained through the "CPUX86State *env" variable that is passed around at translation time. But I am not sure how I will be able to do part 1 and part 3 in the TCG mode of QEMU. Can you please provide me ideas as to how the artifacts in Part 1 and Part 3 be recorded? Thank you very much. Best Regards, Arnabjyoti Kalita
