Re: [RFC PATCH 0/2] qtest: Log verbosity changes

[Thomas Huth <thuth@redhat.com>]

On 13/09/2024 13.46, Peter Maydell wrote:
> On Fri, 13 Sept 2024 at 12:29, Markus Armbruster <armbru@redhat.com> wrote:
>>
>> Peter Maydell <peter.maydell@linaro.org> writes:
>>> Specifically, if you don't disable the error-exit when qtest
>>> is in use, then the generic qom-test tests which say "can we
>>> at least instantiate every machine?" will fail, because they
>>> assume that "qemu-system-foo -machine bar -accel qtest" will
>>> at least start.
>>>
>>> It doesn't really seem feasible to me to have qom-test
>>> know about every machine's specific requirements for
>>> how to pass a guest image.
>>
>> Yes.
>>
>>> The other approach would be to standardize on "every machine
>>> type should happily start up with no warnings even if there
>>> is no guest code specified by the user and it would simply
>>> execute zeroes". We already do this for quite a lot of
>>> boards, including some major ones, so we're certainly not
>>> consistent about trying to diagnose user errors in this area.

IMHO executing zeros is also a bad idea ... most of those boards crash after 
a while when the program counter reaches an unmapped memory region.

Maybe we could simply put a "branch to self" instruction on the first 
program counter address in case the kernel/firmware cannot be loaded?

>> Fatal error unless qtest is bad, because we take a different path.
>>
>> Silently executing zero can be hard for users to diagnose.
>>
>> Possible compromise: warn unless qtest?
> 
> That runs into the "tests that pass and do what they're
> supposed to do shouldn't provoke warnings" unofficial
> guideline... Some of these qtest_enabled() checks are
> exactly to suppress a warning.

FWIW, I like the idea of having a error_report_user() function that is 
silent when running with qtest_enabled().

  Thomas