Re: [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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...