qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [Qemu-ppc] [Qemu-devel] Running QEMU without default devi


From: Thomas Huth
Subject: Re: [Qemu-arm] [Qemu-ppc] [Qemu-devel] Running QEMU without default devices / kernel / bios
Date: Wed, 9 May 2018 09:41:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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.

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

 Thomas



reply via email to

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