Re: [Qemu-devel] [Qemu-ppc] Running QEMU without default devices / kernel / bios

[Markus Armbruster <armbru@redhat.com>]

Thomas Huth <thuth@redhat.com> writes:

> On 08.05.2018 18:40, Eduardo Habkost wrote:
>> On Tue, May 08, 2018 at 07:33:46AM +0200, Thomas Huth wrote:
>>> On 07.05.2018 21:32, Eduardo Habkost wrote:
>>>> On Mon, May 07, 2018 at 09:13:57PM +0200, Thomas Huth wrote:
> [...]
>>>>> Without "-accel qtest", things are not that easy, unfortunately. Lots of
>>>>> boards require "-kernel" or "-bios" and refuse to work without. So you
>>>>> can hardly test "-nodefaults" automatically in the normal tcg mode. (But
>>>>> maybe all boards should allow to start QEMU in case you've at least also
>>>>> specified "-S" ? ... in that case we've got plenty of work for
>>>>> BiteSizeTasks ;-) )
>>>>
>>>> Hmm, maybe it's not a bite-sized task after all.  :)
>>>>
>>>> Should we do this gradually?
>>>>
>>>> * Working with -accel qtest is useful, and sounds like an easier goal;
>>>
>>> We're pretty much there already. Apart from the SD card problem (and the
>>> xen boards), all machines should work with -nodefaults in qtest mode now.
>>>
>>>> * working with -S seems desirable too;
>>>
>>> Yes, it could be interesting to load the firmware / OS via HMP or GDB
>>> after QEMU has been started.
>>>
>>> Maybe we'd simply need a new function a la:
>>>
>>> bool cpu_starts_automatically()
>>> {
>>>     return autostart && !qtest_enabled();
>>> }
>>>
>>> And then replace all spots where we exit due to missing -kernel or -bios
>>> parameters, e.g.:
>>>
>>> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
>>> --- a/hw/m68k/mcf5208.c
>>> +++ b/hw/m68k/mcf5208.c
>>> @@ -286,7 +286,7 @@ static void mcf5208evb_init(MachineState *machine)
>>>
>>>      /* Load kernel.  */
>>>      if (!kernel_filename) {
>>> -        if (qtest_enabled()) {
>>> +        if (!cpu_starts_automatically()) {
>>>              return;
>>>          }
>>>          error_report("Kernel image must be specified");
>>>
>>> Does that sound like a plan?
>> 
>> Not sure.  If a given command-line fails without -S, I would
>> expect it to also fail if using -S and the "cont" monitor command
>> is issued.  (But not necessarily if "-S" is used and "cont" is
>> never issued.)
>> 
>>>
>>>> * working without -S (even if the emulated CPU crashes and burns)
>>>>   would be interesting.
>>>
>>> Not sure whether we really need this. It's likely better to give the
>>> user a proper error message to use "-kernel" instead of just showing a
>>> crash.
>> 
>> I think I agree.
>> 
>>>
>>>> Related question: what are the use cases where we require
>>>> "-accel qtest" and "-S" wouldn't work?
>>>
>>> Maybe there are some boards where you can not load code via HMP or GDB
>>> once you've started QEMU with "-S"? You'd end up with a mostly useless
>>> HMP prompt in that case, which is a little bit ugly, but not fatal.
>> 
>> You have a point.  I guess the definition of "useless" here
>> depend on what are the use cases we want to address with -S: are
>> there reasonable use cases for using -S and never issuing "cont"?
>> 
>> Would it be OK if we reported errors like "kernel image must be
>> specified"  only when/if "cont" is issued?
>
> From a users point of view, this would be great, yes. You could start
> QEMU with -S, set up your machine via HMP, QMP oder GDB, and then try to
> start with "cont". If you'd screw it up, "cont" would yell at you and
> you could try again.
>
> From a developers point of view, this sounds like a nightmare to get it
> right with all the QEMU machines that we support, though.
>
>>> Apart from that ... I can't think of a case where "-S" would not work at
>>> all once we've introduce something like cpu_starts_automatically().
>> 
>> I'm being convinced that "-accel qtest" and "-S" are not expected
>> to be equivalent, so my main priority right now is to document
>> what are the differences.
>
> Hmmm, I think I originally slightly misunderstood your original
> question.... and until now, I also thought that "-accel qtest" would
> enable the qtest interface in qtest.c, but it seems like this is rather
> done by the "-qtest" parameter instead.
>
> So as far as I can see, it theoretically should be possible to replace
> "-accel qtest" with "-S". But I'm also not an expert here.

-S makes QEMU remain in RUN_STATE_PRELAUNCH.  Without it, QEMU enters
RUN_STATE_RUNNING.

RUN_STATE_RUNNING with accel=qtest is not obviously equivalent to
RUN_STATE_PRELAUNCH!  The state transition does more than just resuming
CPUs.

>> I'm reaching two conclusions from this thread:
>> 
>> 1) "-accel qtest" has additional purposes other than the "don't
>>    run any guest code".  We need to document them clearly,
>>    and it probably can't be replaced by -S directly.
>
> There are just two things that come to my mind why we could not
> immediately replace "-accel qtest" by "-S":
>
> - There are some few qtest which override "-accel qtest" with "-accel
>   tcg". But I think they could simply be changed to use the "cont"
>   command instead.
>
> - We should also consider that it is possible nowadays to build QEMU
>   with --disable-tcg. In that case, you depend on KVM to be available
>   as accelerator. As long as there's still "-accel qtest", it should
>   be possible to run "make test" (just the tests that really need tcg
>   don't work anymore). But if we remove "-accel qtest" and replace it
>   with "-S", the tests can't be run anymore if the host machine does
>   not offer KVM (e.g. on an automated builder machine). We could add
>   an "-accel none" mode instead, but from a users point of view, that's
>   pretty much the same as the current "-accel qtest" mode...

Different name, same thing, not worth changing.