Thomas Huth <th...@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.
