From: Laurent Vivier <lvivier@redhat.com>
To: Greg Kurz <groug@kaod.org>,
Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Cc: Markus Armbruster <armbru@redhat.com>,
qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v2 2/3] spapr: Use error_append_hint() in spapr_caps.c
Date: Thu, 11 Jun 2020 14:36:46 +0200 [thread overview]
Message-ID: <65348bbd-7de2-7a0b-dd16-3fb4eabbdeb5@redhat.com> (raw)
In-Reply-To: <20200611124422.6eea05df@bahia.lan>
On 11/06/2020 12:44, Greg Kurz wrote:
> On Thu, 11 Jun 2020 13:42:48 +0300
> Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> wrote:
>
>> 11.06.2020 13:21, Vladimir Sementsov-Ogievskiy wrote:
>>> 11.06.2020 13:13, Greg Kurz wrote:
>>>> On Thu, 11 Jun 2020 11:50:57 +0200
>>>> Laurent Vivier <lvivier@redhat.com> wrote:
>>>>
>>>>> On 11/06/2020 11:10, Greg Kurz wrote:
>>>>>> We have a dedicated error API for hints. Use it instead of embedding
>>>>>> the hint in the error message, as recommanded in the "qapi/error.h"
>>>>>> header file.
>>>>>>
>>>>>> Since spapr_caps_apply() passes &error_fatal, all functions must
>>>>>> also call the ERRP_AUTO_PROPAGATE() macro for error_append_hint()
>>>>>> to be functional.
>>>>>>
>>>>>> While here, add some missing braces around one line statements that
>>>>>> are part of the patch context. Also have cap_fwnmi_apply(), which
>>>>>> already uses error_append_hint() to call ERRP_AUTO_PROPAGATE() as
>>>>>> well.
>>>>>>
>>>>>> Signed-off-by: Greg Kurz <groug@kaod.org>
>>>>>> ---
>>>>>> hw/ppc/spapr_caps.c | 95 +++++++++++++++++++++++++++++----------------------
>>>>>> 1 file changed, 54 insertions(+), 41 deletions(-)
>>>>>>
>>>>>> diff --git a/hw/ppc/spapr_caps.c b/hw/ppc/spapr_caps.c
>>>>>> index efdc0dbbcfc0..2cb7ba8f005a 100644
>>>>>> --- a/hw/ppc/spapr_caps.c
>>>>>> +++ b/hw/ppc/spapr_caps.c
>>>>> ...
>>>>>> @@ -248,6 +249,7 @@ SpaprCapPossible cap_cfpc_possible = {
>>>>>> static void cap_safe_cache_apply(SpaprMachineState *spapr, uint8_t val,
>>>>>> Error **errp)
>>>>>> {
>>>>>> + ERRP_AUTO_PROPAGATE();
>>>>>> Error *local_err = NULL;
>>>>>
>>>>> I think you should rename it, something like "local_warn" to not be
>>>>> confused with the _auto_errp_prop.local_err...
>>>>>
>>>>> or don't use ERRP_AUTO_PROPAGE(), use the local_err instead and move the
>>>>> warning inside the braces of the if.
>>>>>
>>>>> Same comment for cap_safe_bounds_check_apply() and
>>>>> cap_safe_indirect_branch_apply()
>>>>>
>>>>
>>>> Hmm... local_err isn't useful actually. It looks like we just want
>>>> to call warn_report() directly instead of error_setg(&local_err)
>>>> and warn_report_err(local_err). I'll post a v3.
>>>
>>> something like this I think:
>>>
>>> --- a/hw/ppc/spapr_caps.c
>>> +++ b/hw/ppc/spapr_caps.c
>>> @@ -250,24 +250,23 @@ static void cap_safe_cache_apply(SpaprMachineState *spapr, uint8_t val,
>>> Error **errp)
>>> {
>>> ERRP_AUTO_PROPAGATE();
>>> - Error *local_err = NULL;
>>> uint8_t kvm_val = kvmppc_get_cap_safe_cache();
>>>
>>> if (tcg_enabled() && val) {
>>> /* TCG only supports broken, allow other values and print a warning */
>>> - error_setg(&local_err,
>>> + error_setg(errp,
>>> "TCG doesn't support requested feature, cap-cfpc=%s",
>>> cap_cfpc_possible.vals[val]);
>>> + if (*errp) {
>>> + warn_report_err(*errp);
>>> + *errp = NULL;
>>> + }
>>
>> what a stupid code :) at least, if condition is always true.
>>
>> this all should be substitute by just
>>
>> warn_report("TCG doesn't support requested feature, cap-cfpc=%s", cap_cfpc_possible.vals[val]);
>>
>
> Exactly ! :)
>
Yes, it seems appropriate.
Thanks,
Laurent
next prev parent reply other threads:[~2020-06-11 12:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-11 9:09 [PATCH v2 0/3] spapr: Improve error reporting in spapr_caps.c Greg Kurz
2020-06-11 9:09 ` [PATCH v2 1/3] error: auto propagated local_err Greg Kurz
2020-06-11 9:38 ` Laurent Vivier
2020-06-11 9:10 ` [PATCH v2 2/3] spapr: Use error_append_hint() in spapr_caps.c Greg Kurz
2020-06-11 9:47 ` Vladimir Sementsov-Ogievskiy
2020-06-11 9:50 ` Laurent Vivier
2020-06-11 10:13 ` Greg Kurz
2020-06-11 10:21 ` Vladimir Sementsov-Ogievskiy
2020-06-11 10:30 ` Vladimir Sementsov-Ogievskiy
2020-06-11 10:39 ` Greg Kurz
2020-06-11 10:44 ` Vladimir Sementsov-Ogievskiy
2020-06-11 10:48 ` Vladimir Sementsov-Ogievskiy
2020-06-11 10:42 ` Vladimir Sementsov-Ogievskiy
2020-06-11 10:44 ` Greg Kurz
2020-06-11 12:36 ` Laurent Vivier [this message]
2020-06-11 9:10 ` [PATCH v2 3/3] spapr: Forbid nested KVM-HV in pre-power9 compat mode Greg Kurz
2020-06-11 9:22 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=65348bbd-7de2-7a0b-dd16-3fb4eabbdeb5@redhat.com \
--to=lvivier@redhat.com \
--cc=armbru@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=vsementsov@virtuozzo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).