This reverts commit 01fd41ab3fb69971c24a69ed49cde96086d81278.
The generic loader device (-device loader,file=kernel.bin) can be used
to load a kernel instead of the -kernel option. Some boards have flash
memory (pflash) that is set via the -pflash or -drive options.
Allow starting QEMU without the -kernel option to accommodate these
scenarios.
Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
hw/arm/armv7m.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/hw/arm/armv7m.c b/hw/arm/armv7m.c
index 4bf9131b81..f444652830 100644
--- a/hw/arm/armv7m.c
+++ b/hw/arm/armv7m.c
@@ -285,11 +285,6 @@ void armv7m_load_kernel(ARMCPU *cpu, const char *kernel_filename, int mem_size)
big_endian = 0;
#endif
- if (!kernel_filename && !qtest_enabled()) {
- error_report("Guest image must be specified (using -kernel)");
- exit(1);
- }
-
if (arm_feature(&cpu->env, ARM_FEATURE_EL3)) {
asidx = ARMASIdx_S;
} else {
--
2.20.1
On Thu, 3 Jan 2019 at 14:41, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > This reverts commit 01fd41ab3fb69971c24a69ed49cde96086d81278. > > The generic loader device (-device loader,file=kernel.bin) can be used > to load a kernel instead of the -kernel option. Some boards have flash > memory (pflash) that is set via the -pflash or -drive options. > > Allow starting QEMU without the -kernel option to accommodate these > scenarios. > > Suggested-by: Peter Maydell <peter.maydell@linaro.org> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Applied to target-arm.next, thanks. -- PMM
Hi Peter, Stefan, On 1/4/19 4:16 PM, Peter Maydell wrote: > On Thu, 3 Jan 2019 at 14:41, Stefan Hajnoczi <stefanha@redhat.com> wrote: >> >> This reverts commit 01fd41ab3fb69971c24a69ed49cde96086d81278. >> >> The generic loader device (-device loader,file=kernel.bin) can be used >> to load a kernel instead of the -kernel option. Some boards have flash >> memory (pflash) that is set via the -pflash or -drive options. >> >> Allow starting QEMU without the -kernel option to accommodate these >> scenarios. >> >> Suggested-by: Peter Maydell <peter.maydell@linaro.org> >> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Previous to this commit (v3.1), we have: $ qemu-system-aarch64 -M netduino2 qemu-system-aarch64: Guest image must be specified (using -kernel) Now (v4.0) we get: $ qemu-system-aarch64 -M netduino2 qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) R00=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000 XPSR=40000003 -Z-- A handler FPSCR: 00000000 Aborted (core dumped) This is confusing. (same happens with emcraft-sf2, microbit, musca-*) Regards, Phil.
On Thu, Apr 25, 2019 at 08:07:06PM +0200, Philippe Mathieu-Daudé wrote: > On 1/4/19 4:16 PM, Peter Maydell wrote: > > On Thu, 3 Jan 2019 at 14:41, Stefan Hajnoczi <stefanha@redhat.com> wrote: > >> > >> This reverts commit 01fd41ab3fb69971c24a69ed49cde96086d81278. > >> > >> The generic loader device (-device loader,file=kernel.bin) can be used > >> to load a kernel instead of the -kernel option. Some boards have flash > >> memory (pflash) that is set via the -pflash or -drive options. > >> > >> Allow starting QEMU without the -kernel option to accommodate these > >> scenarios. > >> > >> Suggested-by: Peter Maydell <peter.maydell@linaro.org> > >> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > > Previous to this commit (v3.1), we have: > > $ qemu-system-aarch64 -M netduino2 > qemu-system-aarch64: Guest image must be specified (using -kernel) > > Now (v4.0) we get: > > $ qemu-system-aarch64 -M netduino2 > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) A user-friendly error message is needed here. The check for -kernel was too specific and is not desirable for microbit where we use -device loader. Old boards probably want to continue using -kernel. New boards like microbit may use just -device loader. Perhaps there is even a group that wants both options. A solution is to introduce explicit checks so that we can tell the user the appropriate option for the machine type. I can work on this if you like, but probably won't be able to send a patch until Tuesday. Stefan
On Fri, 26 Apr 2019 at 10:17, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > On Thu, Apr 25, 2019 at 08:07:06PM +0200, Philippe Mathieu-Daudé wrote: > > Previous to this commit (v3.1), we have: > > > > $ qemu-system-aarch64 -M netduino2 > > qemu-system-aarch64: Guest image must be specified (using -kernel) > > > > Now (v4.0) we get: > > > > $ qemu-system-aarch64 -M netduino2 > > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > A user-friendly error message is needed here. The check for -kernel was > too specific and is not desirable for microbit where we use -device > loader. It's consistent with how many of our other board models work. If you try to run them without providing any guest code in any way, then they just do something not very useful. (For A-profile this used to often be "die with the 'execution from something not ROM or RAM' message" and is now "just steam through executing garbage and/or taking exceptions in a tight loop.") This is how real hardware also works :-) (Strictly speaking this message appearing is a defect in QEMU's emulation -- the 'lockup' state behaviour is architecturally well-defined and is supposed to cause the CPU to sit there doing continual instruction fetches from a specific (non-valid) address until either the system is reset or an NMI handler kicks in which might be able to rescue it. We don't bother to emulate this detail because lockup is pretty much always a guest bug and the only thing I've seen using the lockup behaviour and expecting to recover from it is test code.) > Old boards probably want to continue using -kernel. New boards like > microbit may use just -device loader. Perhaps there is even a group > that wants both options. > > A solution is to introduce explicit checks so that we can tell the user > the appropriate option for the machine type. I can work on this if you > like, but probably won't be able to send a patch until Tuesday. But it's difficult to tell how to identify whether there's really any guest code there. For instance the user might want to start QEMU, connect via the gdbstub and load guest code from gdb. Or they might be using the generic-loader device. Or they might really be using -kernel but with a broken guest image which doesn't have a vector table in it, which will result in the same message. I guess you could have a heuristic for "if an M-profile CPU is in reset and the value it loads for the starting PC is zero and the gdb stub is not connected, then print a warning that the guest image is missing or there's no vector table" but I'm not a big fan of heuristics... thanks -- PMM
On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote: > On Fri, 26 Apr 2019 at 10:17, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > On Thu, Apr 25, 2019 at 08:07:06PM +0200, Philippe Mathieu-Daudé wrote: > > Old boards probably want to continue using -kernel. New boards like > > microbit may use just -device loader. Perhaps there is even a group > > that wants both options. > > > > A solution is to introduce explicit checks so that we can tell the user > > the appropriate option for the machine type. I can work on this if you > > like, but probably won't be able to send a patch until Tuesday. > > But it's difficult to tell how to identify whether there's really > any guest code there. For instance the user might want to start > QEMU, connect via the gdbstub and load guest code from gdb. > Or they might be using the generic-loader device. Or they might > really be using -kernel but with a broken guest image which doesn't > have a vector table in it, which will result in the same message. > I guess you could have a heuristic for "if an M-profile CPU is in reset > and the value it loads for the starting PC is zero and the gdb > stub is not connected, then print a warning that the guest image > is missing or there's no vector table" but I'm not a big fan of > heuristics... I was going to add a function to check kernel_filename and the presence of -device loader. Then each machine type init function would call the function with flags indicating which modes are allowed: /* Allow both -kernel and -device loader */ check_kernel_loaded(KERNEL_CMDLINE | KERNEL_LOADER); /* Allow only -kernel */ check_kernel_loaded(KERNEL_CMDLINE); /* Allow only -device loader */ check_kernel_loaded(KERNEL_LOADER); This doesn't support the gdbstub use case you've described though. No heuristics but a bit inflexible. What do you think? Stefan
On Mon, 29 Apr 2019 at 13:28, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote: > I was going to add a function to check kernel_filename and the presence > of -device loader. Then each machine type init function would call the > function with flags indicating which modes are allowed: > > /* Allow both -kernel and -device loader */ > check_kernel_loaded(KERNEL_CMDLINE | KERNEL_LOADER); > > /* Allow only -kernel */ > check_kernel_loaded(KERNEL_CMDLINE); > > /* Allow only -device loader */ > check_kernel_loaded(KERNEL_LOADER); Every machine should permit -device loader: the point of it is that it is entirely generic and works the same way on every machine. thanks -- PMM
On Mon, Apr 29, 2019 at 01:58:46PM +0100, Peter Maydell wrote: > On Mon, 29 Apr 2019 at 13:28, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > > > On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote: > > I was going to add a function to check kernel_filename and the presence > > of -device loader. Then each machine type init function would call the > > function with flags indicating which modes are allowed: > > > > /* Allow both -kernel and -device loader */ > > check_kernel_loaded(KERNEL_CMDLINE | KERNEL_LOADER); > > > > /* Allow only -kernel */ > > check_kernel_loaded(KERNEL_CMDLINE); > > > > /* Allow only -device loader */ > > check_kernel_loaded(KERNEL_LOADER); > > Every machine should permit -device loader: the point > of it is that it is entirely generic and works the same > way on every machine. It seems every person has a slightly different preference :). Can we reach a consensus? 1. Should QEMU print a readable error message when launched without a kernel? If yes: 2. What checks are sensible? Stefan
On 4/29/19 2:28 PM, Stefan Hajnoczi wrote: > On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote: >> On Fri, 26 Apr 2019 at 10:17, Stefan Hajnoczi <stefanha@redhat.com> wrote: >>> On Thu, Apr 25, 2019 at 08:07:06PM +0200, Philippe Mathieu-Daudé wrote: >>> Old boards probably want to continue using -kernel. New boards like >>> microbit may use just -device loader. Perhaps there is even a group >>> that wants both options. >>> >>> A solution is to introduce explicit checks so that we can tell the user >>> the appropriate option for the machine type. I can work on this if you >>> like, but probably won't be able to send a patch until Tuesday. >> >> But it's difficult to tell how to identify whether there's really >> any guest code there. For instance the user might want to start >> QEMU, connect via the gdbstub and load guest code from gdb. >> Or they might be using the generic-loader device. Or they might >> really be using -kernel but with a broken guest image which doesn't >> have a vector table in it, which will result in the same message. >> I guess you could have a heuristic for "if an M-profile CPU is in reset >> and the value it loads for the starting PC is zero and the gdb >> stub is not connected, then print a warning that the guest image >> is missing or there's no vector table" but I'm not a big fan of >> heuristics... > > I was going to add a function to check kernel_filename and the presence > of -device loader. Then each machine type init function would call the > function with flags indicating which modes are allowed: > > /* Allow both -kernel and -device loader */ > check_kernel_loaded(KERNEL_CMDLINE | KERNEL_LOADER); > > /* Allow only -kernel */ > check_kernel_loaded(KERNEL_CMDLINE); > > /* Allow only -device loader */ > check_kernel_loaded(KERNEL_LOADER); > > This doesn't support the gdbstub use case you've described though. No > heuristics but a bit inflexible. > What do you think? We can check for QEMU_OPTION_gdb/QEMU_OPTION_s, if present display warning, else display error? Or no warning at all...
On Fri, 26 Apr 2019 at 09:17, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > A user-friendly error message is needed here. The check for -kernel was > too specific and is not desirable for microbit where we use -device > loader. > > Old boards probably want to continue using -kernel. New boards like > microbit may use just -device loader. Perhaps there is even a group > that wants both options. FWIW, I used -kernel exclusively when working on the microbit model. Other users may chose to use the device loader/hex file. I am all for usability, but getting rid of the ability to use -kernel on some machine types would be a step in the wrong direction. Cheers, Joel > > A solution is to introduce explicit checks so that we can tell the user > the appropriate option for the machine type. I can work on this if you > like, but probably won't be able to send a patch until Tuesday. > > Stefan
On Mon, Apr 29, 2019 at 12:53:48PM +0000, Joel Stanley wrote: > On Fri, 26 Apr 2019 at 09:17, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > > > A user-friendly error message is needed here. The check for -kernel was > > too specific and is not desirable for microbit where we use -device > > loader. > > > > Old boards probably want to continue using -kernel. New boards like > > microbit may use just -device loader. Perhaps there is even a group > > that wants both options. > > FWIW, I used -kernel exclusively when working on the microbit model. > Other users may chose to use the device loader/hex file. > > I am all for usability, but getting rid of the ability to use -kernel > on some machine types would be a step in the wrong direction. -kernel doesn't support the .hex file format that is most commonly used for micro:bit programs. Are you loading ELFs? Stefan
On Wed, 1 May 2019 at 16:23, Stefan Hajnoczi <stefanha@gmail.com> wrote: > > On Mon, Apr 29, 2019 at 12:53:48PM +0000, Joel Stanley wrote: > > On Fri, 26 Apr 2019 at 09:17, Stefan Hajnoczi <stefanha@redhat.com> wrote: > > > > > > A user-friendly error message is needed here. The check for -kernel was > > > too specific and is not desirable for microbit where we use -device > > > loader. > > > > > > Old boards probably want to continue using -kernel. New boards like > > > microbit may use just -device loader. Perhaps there is even a group > > > that wants both options. > > > > FWIW, I used -kernel exclusively when working on the microbit model. > > Other users may chose to use the device loader/hex file. > > > > I am all for usability, but getting rid of the ability to use -kernel > > on some machine types would be a step in the wrong direction. > > -kernel doesn't support the .hex file format that is most commonly used > for micro:bit programs. Are you loading ELFs? Yes, I am loading ELFs.
On 4/25/19 8:07 PM, Philippe Mathieu-Daudé wrote: > Hi Peter, Stefan, > > On 1/4/19 4:16 PM, Peter Maydell wrote: >> On Thu, 3 Jan 2019 at 14:41, Stefan Hajnoczi <stefanha@redhat.com> wrote: >>> >>> This reverts commit 01fd41ab3fb69971c24a69ed49cde96086d81278. >>> >>> The generic loader device (-device loader,file=kernel.bin) can be used >>> to load a kernel instead of the -kernel option. Some boards have flash >>> memory (pflash) that is set via the -pflash or -drive options. >>> >>> Allow starting QEMU without the -kernel option to accommodate these >>> scenarios. >>> >>> Suggested-by: Peter Maydell <peter.maydell@linaro.org> >>> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> > > Previous to this commit (v3.1), we have: > > $ qemu-system-aarch64 -M netduino2 > qemu-system-aarch64: Guest image must be specified (using -kernel) > > Now (v4.0) we get: > > $ qemu-system-aarch64 -M netduino2 > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) > > R00=00000000 R01=00000000 R02=00000000 R03=00000000 > R04=00000000 R05=00000000 R06=00000000 R07=00000000 > R08=00000000 R09=00000000 R10=00000000 R11=00000000 > R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000 > XPSR=40000003 -Z-- A handler > FPSCR: 00000000 > Aborted (core dumped) (gdb) bt #0 0x00007fd14f39457f in raise () at /lib64/libc.so.6 #1 0x00007fd14f37e895 in abort () at /lib64/libc.so.6 #2 0x000056286da2695c in cpu_abort (cpu=0x5628705c43c0, fmt=0x56286dfdc450 "Lockup: can't escalate %d to HardFault (current priority %d)\n") at /source/qemu/exec.c:1282 #3 0x000056286dada4ea in do_armv7m_nvic_set_pending (opaque=0x5628705a5030, irq=3, secure=false, derived=false) at /source/qemu/hw/intc/armv7m_nvic.c:632 #4 0x000056286dada568 in armv7m_nvic_set_pending (opaque=0x5628705a5030, irq=6, secure=false) at /source/qemu/hw/intc/armv7m_nvic.c:650 #5 0x000056286db3ae1b in arm_v7m_cpu_do_interrupt (cs=0x5628705c43c0) at /source/qemu/target/arm/helper.c:8822 #6 0x000056286dad2e9e in cpu_handle_exception (cpu=0x5628705c43c0, ret=0x7fd13d9fbe2c) at /source/qemu/accel/tcg/cpu-exec.c:504 #7 0x000056286dad350a in cpu_exec (cpu=0x5628705c43c0) at /source/qemu/accel/tcg/cpu-exec.c:709 #8 0x000056286da77497 in tcg_cpu_exec (cpu=0x5628705c43c0) at /source/qemu/cpus.c:1431 #9 0x000056286da77caf in qemu_tcg_cpu_thread_fn (arg=0x5628705c43c0) at /source/qemu/cpus.c:1735 #10 0x000056286deb5dce in qemu_thread_start (args=0x5628705ea850) at /source/qemu/util/qemu-thread-posix.c:502 #11 0x00007fd14f52a58e in start_thread () at /lib64/libpthread.so.0 #12 0x00007fd14f459683 in clone () at /lib64/libc.so.6 Running with -d in_asm,int: ---------------- IN: 0x00000000: 00000000 andeq r0, r0, r0 Taking exception 18 [v7M INVSTATE UsageFault] ...BusFault with BFSR.STKERR ...taking pending nonsecure exception 3 ---------------- IN: 0x00000000: 00000000 andeq r0, r0, r0 Taking exception 18 [v7M INVSTATE UsageFault] qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1) Since I didn't provided anything to bootstrap the guest, the bootvector in flash is obviously empty. > > This is confusing. > > (same happens with emcraft-sf2, microbit, musca-*) > > Regards, > > Phil. >
© 2016 - 2024 Red Hat, Inc.