On Fri, Apr 26, 2019 at 12:45:37PM +0100, Peter Maydell wrote: > On Fri, 26 Apr 2019 at 10:17, Stefan Hajnoczi <stefa...@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
signature.asc
Description: PGP signature
