* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-25 18:07 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 24+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-04-25 18:07 UTC (permalink / raw)
To: Peter Maydell, Stefan Hajnoczi
Cc: Jim Mussared, Alex Bennée, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Thomas Huth, Julia Suvorova
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-25 21:48 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 24+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-04-25 21:48 UTC (permalink / raw)
To: Peter Maydell, Stefan Hajnoczi
Cc: Jim Mussared, Julia Suvorova, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Alex Bennée, Thomas Huth
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.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-25 21:48 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 24+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-04-25 21:48 UTC (permalink / raw)
To: Peter Maydell, Stefan Hajnoczi
Cc: Jim Mussared, Alex Bennée, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Thomas Huth, Julia Suvorova
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.
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-26 9:17 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-04-26 9:17 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Peter Maydell, Jim Mussared, Julia Suvorova, QEMU Developers,
Steffen Gortz, qemu-arm, Joel Stanley, Alex Bennée,
Thomas Huth
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-26 9:17 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-04-26 9:17 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Peter Maydell, Jim Mussared, Alex Bennée, QEMU Developers,
Steffen Gortz, qemu-arm, Joel Stanley, Thomas Huth,
Julia Suvorova
[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-26 11:45 ` Peter Maydell
0 siblings, 0 replies; 24+ messages in thread
From: Peter Maydell @ 2019-04-26 11:45 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Philippe Mathieu-Daudé,
Jim Mussared, Julia Suvorova, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Alex Bennée, Thomas Huth
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-26 11:45 ` Peter Maydell
0 siblings, 0 replies; 24+ messages in thread
From: Peter Maydell @ 2019-04-26 11:45 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Jim Mussared, Alex Bennée, Philippe Mathieu-Daudé,
QEMU Developers, Steffen Gortz, qemu-arm, Joel Stanley,
Thomas Huth, Julia Suvorova
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 12:28 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-04-29 12:28 UTC (permalink / raw)
To: Peter Maydell
Cc: Philippe Mathieu-Daudé,
Jim Mussared, Julia Suvorova, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Alex Bennée, Thomas Huth
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 12:28 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-04-29 12:28 UTC (permalink / raw)
To: Peter Maydell
Cc: Jim Mussared, Alex Bennée, Philippe Mathieu-Daudé,
QEMU Developers, Steffen Gortz, qemu-arm, Joel Stanley,
Thomas Huth, Julia Suvorova
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 12:58 ` Peter Maydell
0 siblings, 0 replies; 24+ messages in thread
From: Peter Maydell @ 2019-04-29 12:58 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Philippe Mathieu-Daudé,
Jim Mussared, Julia Suvorova, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Alex Bennée, Thomas Huth
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 12:58 ` Peter Maydell
0 siblings, 0 replies; 24+ messages in thread
From: Peter Maydell @ 2019-04-29 12:58 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Jim Mussared, Alex Bennée, Philippe Mathieu-Daudé,
QEMU Developers, Steffen Gortz, qemu-arm, Joel Stanley,
Thomas Huth, Julia Suvorova
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-05-01 16:25 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-05-01 16:25 UTC (permalink / raw)
To: Peter Maydell
Cc: Stefan Hajnoczi, Jim Mussared, Alex Bennée,
Philippe Mathieu-Daudé,
QEMU Developers, Steffen Gortz, qemu-arm, Joel Stanley,
Thomas Huth, Julia Suvorova
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-05-01 16:25 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-05-01 16:25 UTC (permalink / raw)
To: Peter Maydell
Cc: Jim Mussared, Alex Bennée, Julia Suvorova, QEMU Developers,
Steffen Gortz, qemu-arm, Joel Stanley, Stefan Hajnoczi,
Thomas Huth, Philippe Mathieu-Daudé
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 15:07 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 24+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-04-29 15:07 UTC (permalink / raw)
To: Stefan Hajnoczi, Peter Maydell
Cc: Jim Mussared, Julia Suvorova, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Alex Bennée, Thomas Huth
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...
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 15:07 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 24+ messages in thread
From: Philippe Mathieu-Daudé @ 2019-04-29 15:07 UTC (permalink / raw)
To: Stefan Hajnoczi, Peter Maydell
Cc: Jim Mussared, Alex Bennée, QEMU Developers, Steffen Gortz,
qemu-arm, Joel Stanley, Thomas Huth, Julia Suvorova
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 2088 bytes --]
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...
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 12:53 ` Joel Stanley
0 siblings, 0 replies; 24+ messages in thread
From: Joel Stanley @ 2019-04-29 12:53 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Philippe Mathieu-Daudé,
Peter Maydell, Jim Mussared, Julia Suvorova, QEMU Developers,
Steffen Gortz, qemu-arm, Alex Bennée, Thomas Huth
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-04-29 12:53 ` Joel Stanley
0 siblings, 0 replies; 24+ messages in thread
From: Joel Stanley @ 2019-04-29 12:53 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Peter Maydell, Jim Mussared, Alex Bennée, Julia Suvorova,
QEMU Developers, Steffen Gortz, qemu-arm, Thomas Huth,
Philippe Mathieu-Daudé
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-05-01 16:23 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-05-01 16:23 UTC (permalink / raw)
To: Joel Stanley
Cc: Stefan Hajnoczi, Peter Maydell, Jim Mussared, Alex Bennée,
Julia Suvorova, QEMU Developers, Steffen Gortz, qemu-arm,
Thomas Huth, Philippe Mathieu-Daudé
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-05-01 16:23 ` Stefan Hajnoczi
0 siblings, 0 replies; 24+ messages in thread
From: Stefan Hajnoczi @ 2019-05-01 16:23 UTC (permalink / raw)
To: Joel Stanley
Cc: Peter Maydell, Jim Mussared, Julia Suvorova, QEMU Developers,
Philippe Mathieu-Daudé,
Steffen Gortz, qemu-arm, Stefan Hajnoczi, Thomas Huth,
Alex Bennée
[-- Attachment #1: Type: text/plain, Size: 904 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-05-03 2:04 ` Joel Stanley
0 siblings, 0 replies; 24+ messages in thread
From: Joel Stanley @ 2019-05-03 2:04 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Stefan Hajnoczi, Peter Maydell, Jim Mussared, Alex Bennée,
Julia Suvorova, QEMU Developers, Steffen Gortz, qemu-arm,
Thomas Huth, Philippe Mathieu-Daudé
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.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
@ 2019-05-03 2:04 ` Joel Stanley
0 siblings, 0 replies; 24+ messages in thread
From: Joel Stanley @ 2019-05-03 2:04 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: Peter Maydell, Jim Mussared, Julia Suvorova, QEMU Developers,
Philippe Mathieu-Daudé,
Steffen Gortz, qemu-arm, Stefan Hajnoczi, Thomas Huth,
Alex Bennée
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.
^ permalink raw reply [flat|nested] 24+ messages in thread