From: Auger Eric <eric.auger@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Peter Xu <peterx@redhat.com>,
Eric Auger <eric.auger.pro@gmail.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] hw/arm/smmuv3: Remove spurious error messages on IOVA invalidations
Date: Fri, 14 Jun 2019 15:56:23 +0200 [thread overview]
Message-ID: <b7d5155a-08e2-33c4-8550-4b0821b11585@redhat.com> (raw)
In-Reply-To: <CAFEAcA8N_uaq9kbS2MWDtdy1wz-j33OVo4wQbFZxvc-2uyMd0A@mail.gmail.com>
Hi Peter,
On 6/14/19 3:23 PM, Peter Maydell wrote:
> On Tue, 11 Jun 2019 at 15:29, Eric Auger <eric.auger@redhat.com> wrote:
>>
>> An IOVA/ASID invalidation is notified to all IOMMU Memory Regions
>> through smmuv3_inv_notifiers_iova/smmuv3_notify_iova.
>>
>> When the notification occurs it is possible that some of the
>> PCIe devices associated to the notified regions do not have a
>> valid stream table entry. In that case we output a LOG_GUEST_ERROR
>> message.
>>
>> invalid sid=<SID> (L1STD span=0)
>> "smmuv3_notify_iova error decoding the configuration for iommu mr=<MR>
>>
>> This is unfortunate as the user gets the impression that there
>> are some translation decoding errors whereas there are not.
>>
>> This patch adds a new field in SMMUEventInfo that tells whether
>> the detction of an invalid STE msut lead to an error report.
>> invalid_ste_allowed is set before doing the invalidations and
>> kept unset on actual translation.
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>>
>> I also experimented to pass Error handles to all the subfunctions
>> and handle the Error at top level but that's intricate to sort
>> out the various kinds of errors, whether they need to be logged,
>> and if so if they match LOG_GUEST_ERRoR mask or unimplemented
>> mask. So I think just passing this boolean has a lesser impact on
>> the code base.
>> ---
>> hw/arm/smmuv3-internal.h | 1 +
>> hw/arm/smmuv3.c | 11 +++++------
>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
>> index b160289cd1..d190181ef1 100644
>> --- a/hw/arm/smmuv3-internal.h
>> +++ b/hw/arm/smmuv3-internal.h
>> @@ -381,6 +381,7 @@ typedef struct SMMUEventInfo {
>> uint32_t sid;
>> bool recorded;
>> bool record_trans_faults;
>> + bool inval_ste_allowed;
>> union {
>> struct {
>> uint32_t ssid;
>> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
>> index fd8ec7860e..e2f07d2864 100644
>> --- a/hw/arm/smmuv3.c
>> +++ b/hw/arm/smmuv3.c
>> @@ -404,7 +404,7 @@ static int smmu_find_ste(SMMUv3State *s, uint32_t sid, STE *ste,
>>
>> span = L1STD_SPAN(&l1std);
>>
>> - if (!span) {
>> + if (!span && !event->inval_ste_allowed) {
>> /* l2ptr is not valid */
>> qemu_log_mask(LOG_GUEST_ERROR,
>> "invalid sid=%d (L1STD span=0)\n", sid);
>
> Why is this specific qemu_log_mask() the only one we need
> to suppress ?
I focused on messages related to STE invalidity. This one corresponds to
the 2-level stream table case where the top-level entry is invalid.
In linear stream table case, the STE is fetched in smmu_get_ste(): this
shouldn't fail as the STE table was allocated. Then its validity is
checked in decode_ste() but up to now there is no tracing if the STE in
not valid. I should revise this in the future though.
Then obviously the config decoding is not over but I considered that if
the STE is valid, the rest of the config should be valid as well. If we
were to detect any error afterwards, those would deserve to be reported.
Thanks
Eric
>
> thanks
> -- PMM
>
next prev parent reply other threads:[~2019-06-14 14:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-11 14:28 [Qemu-devel] [PATCH 0/2] ARM SMMUv3: Fix spurious notification errors and stall with vfio-pci Eric Auger
2019-06-11 14:28 ` [Qemu-devel] [PATCH 1/2] hw/arm/smmuv3: Remove spurious error messages on IOVA invalidations Eric Auger
2019-06-14 13:23 ` Peter Maydell
2019-06-14 13:56 ` Auger Eric [this message]
2019-06-11 14:28 ` [Qemu-devel] [PATCH 2/2] hw/arm/smmuv3: Implement dummy replay Eric Auger
2019-06-14 13:26 ` Peter Maydell
2019-06-14 13:40 ` Auger Eric
2019-06-14 13:45 ` Peter Maydell
2019-06-14 14:09 ` Auger Eric
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=b7d5155a-08e2-33c4-8550-4b0821b11585@redhat.com \
--to=eric.auger@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).