[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -ke

From: Stefan Hajnoczi
Subject: Re: [Qemu-arm] [Qemu-devel] [PATCH] Revert "armv7m: Guard against no -kernel argument"
Date: Mon, 29 Apr 2019 08:28:19 -0400
User-agent: Mutt/1.11.3 (2019-02-01)

On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote:
> On Fri, 26 Apr 2019 at 10:17, Stefan Hajnoczi <address@hidden> 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 */

  /* Allow only -device loader */

This doesn't support the gdbstub use case you've described though.  No
heuristics but a bit inflexible.

What do you think?


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]