All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron via <qemu-arm@nongnu.org>
To: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>,
	<eric.auger@redhat.com>, <peter.maydell@linaro.org>,
	<nicolinc@nvidia.com>, <nathanc@nvidia.com>, <mochs@nvidia.com>,
	<jan@nvidia.com>, <jgg@nvidia.com>, <zhangfei.gao@linaro.org>,
	<zhenzhong.duan@intel.com>, <kjaju@nvidia.com>
Subject: Re: [PATCH v6 4/5] hw/arm/smmuv3: Introduce a helper function for event propagation
Date: Mon, 16 Feb 2026 16:30:10 +0000	[thread overview]
Message-ID: <20260216163010.00007797@huawei.com> (raw)
In-Reply-To: <20260213103942.142823-5-skolothumtho@nvidia.com>

On Fri, 13 Feb 2026 10:39:41 +0000
Shameer Kolothum <skolothumtho@nvidia.com> wrote:

> Factor out the code that propagates event records to the guest into a
> helper function. The accelerated SMMUv3 path can use this to propagate
> host events in a subsequent patch.
> 
> Since this helper may be called from outside the SMMUv3 core, take the
> mutex before accessing the Event Queue.

Totally trivial but it might be worth stating that / why it is harmless
(or indeed necessary?) to take the lock in existing paths. I was kind
of expecting to see locked helper wrapping an unlocked version that was
used to replace the original code.  So guess I'm missing something.

> 
> No functional change intended.
> 
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
>  hw/arm/smmuv3-internal.h |  4 ++++
>  hw/arm/smmuv3.c          | 21 +++++++++++++++------
>  hw/arm/trace-events      |  2 +-
>  3 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
> index a6464425ec..b666109ad9 100644
> --- a/hw/arm/smmuv3-internal.h
> +++ b/hw/arm/smmuv3-internal.h
> @@ -352,7 +352,11 @@ typedef struct SMMUEventInfo {
>              (x)->word[6] = (uint32_t)(addr & 0xffffffff); \
>      } while (0)
>  
> +#define EVT_GET_TYPE(x)  extract32((x)->word[0], 0, 8)
> +#define EVT_GET_SID(x)   ((x)->word[1])
> +
>  void smmuv3_record_event(SMMUv3State *s, SMMUEventInfo *event);
> +void smmuv3_propagate_event(SMMUv3State *s, Evt *evt);
>  int smmu_find_ste(SMMUv3State *s, uint32_t sid, STE *ste, SMMUEventInfo *event);
>  
>  static inline int oas2bits(int oas_field)
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index f804d3af25..bcb9176c51 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -168,10 +168,23 @@ static MemTxResult smmuv3_write_eventq(SMMUv3State *s, Evt *evt)
>      return MEMTX_OK;
>  }
>  
> +void smmuv3_propagate_event(SMMUv3State *s, Evt *evt)
> +{
> +    MemTxResult r;
> +
> +    trace_smmuv3_propagate_event(smmu_event_string(EVT_GET_TYPE(evt)),
> +                                 EVT_GET_SID(evt));
> +    qemu_mutex_lock(&s->mutex);

Could use 
    QEMU_LOCK_GUARD(&s->mutex);

though gain is minor so feel free to not do so.

> +    r = smmuv3_write_eventq(s, evt);
> +    if (r != MEMTX_OK) {
> +        smmuv3_trigger_irq(s, SMMU_IRQ_GERROR, R_GERROR_EVENTQ_ABT_ERR_MASK);
> +    }
> +    qemu_mutex_unlock(&s->mutex);
> +}




WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via qemu development <qemu-devel@nongnu.org>
To: Shameer Kolothum <skolothumtho@nvidia.com>
Cc: <qemu-arm@nongnu.org>, <qemu-devel@nongnu.org>,
	<eric.auger@redhat.com>, <peter.maydell@linaro.org>,
	<nicolinc@nvidia.com>, <nathanc@nvidia.com>, <mochs@nvidia.com>,
	<jan@nvidia.com>, <jgg@nvidia.com>, <zhangfei.gao@linaro.org>,
	<zhenzhong.duan@intel.com>, <kjaju@nvidia.com>
Subject: Re: [PATCH v6 4/5] hw/arm/smmuv3: Introduce a helper function for event propagation
Date: Mon, 16 Feb 2026 16:30:10 +0000	[thread overview]
Message-ID: <20260216163010.00007797@huawei.com> (raw)
In-Reply-To: <20260213103942.142823-5-skolothumtho@nvidia.com>

On Fri, 13 Feb 2026 10:39:41 +0000
Shameer Kolothum <skolothumtho@nvidia.com> wrote:

> Factor out the code that propagates event records to the guest into a
> helper function. The accelerated SMMUv3 path can use this to propagate
> host events in a subsequent patch.
> 
> Since this helper may be called from outside the SMMUv3 core, take the
> mutex before accessing the Event Queue.

Totally trivial but it might be worth stating that / why it is harmless
(or indeed necessary?) to take the lock in existing paths. I was kind
of expecting to see locked helper wrapping an unlocked version that was
used to replace the original code.  So guess I'm missing something.

> 
> No functional change intended.
> 
> Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
> Reviewed-by: Eric Auger <eric.auger@redhat.com>
> Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Shameer Kolothum <skolothumtho@nvidia.com>
> ---
>  hw/arm/smmuv3-internal.h |  4 ++++
>  hw/arm/smmuv3.c          | 21 +++++++++++++++------
>  hw/arm/trace-events      |  2 +-
>  3 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/hw/arm/smmuv3-internal.h b/hw/arm/smmuv3-internal.h
> index a6464425ec..b666109ad9 100644
> --- a/hw/arm/smmuv3-internal.h
> +++ b/hw/arm/smmuv3-internal.h
> @@ -352,7 +352,11 @@ typedef struct SMMUEventInfo {
>              (x)->word[6] = (uint32_t)(addr & 0xffffffff); \
>      } while (0)
>  
> +#define EVT_GET_TYPE(x)  extract32((x)->word[0], 0, 8)
> +#define EVT_GET_SID(x)   ((x)->word[1])
> +
>  void smmuv3_record_event(SMMUv3State *s, SMMUEventInfo *event);
> +void smmuv3_propagate_event(SMMUv3State *s, Evt *evt);
>  int smmu_find_ste(SMMUv3State *s, uint32_t sid, STE *ste, SMMUEventInfo *event);
>  
>  static inline int oas2bits(int oas_field)
> diff --git a/hw/arm/smmuv3.c b/hw/arm/smmuv3.c
> index f804d3af25..bcb9176c51 100644
> --- a/hw/arm/smmuv3.c
> +++ b/hw/arm/smmuv3.c
> @@ -168,10 +168,23 @@ static MemTxResult smmuv3_write_eventq(SMMUv3State *s, Evt *evt)
>      return MEMTX_OK;
>  }
>  
> +void smmuv3_propagate_event(SMMUv3State *s, Evt *evt)
> +{
> +    MemTxResult r;
> +
> +    trace_smmuv3_propagate_event(smmu_event_string(EVT_GET_TYPE(evt)),
> +                                 EVT_GET_SID(evt));
> +    qemu_mutex_lock(&s->mutex);

Could use 
    QEMU_LOCK_GUARD(&s->mutex);

though gain is minor so feel free to not do so.

> +    r = smmuv3_write_eventq(s, evt);
> +    if (r != MEMTX_OK) {
> +        smmuv3_trigger_irq(s, SMMU_IRQ_GERROR, R_GERROR_EVENTQ_ABT_ERR_MASK);
> +    }
> +    qemu_mutex_unlock(&s->mutex);
> +}




  reply	other threads:[~2026-02-16 16:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-13 10:39 [PATCH v6 0/5] vEVENTQ support for accelerated SMMUv3 devices Shameer Kolothum
2026-02-13 10:39 ` [PATCH v6 1/5] backends/iommufd: Introduce iommufd_backend_alloc_veventq Shameer Kolothum
2026-02-13 22:19   ` Nicolin Chen
2026-02-13 10:39 ` [PATCH v6 2/5] hw/arm/smmuv3-accel: Add viommu free helper Shameer Kolothum
2026-02-13 10:39 ` [PATCH v6 3/5] hw/arm/smmuv3-accel: Allocate vEVENTQ for accelerated SMMUv3 devices Shameer Kolothum
2026-02-13 22:19   ` Nicolin Chen
2026-02-16  8:58     ` Shameer Kolothum Thodi
2026-02-16 16:57       ` Peter Maydell
2026-02-16 17:28         ` Shameer Kolothum Thodi
2026-02-16 16:16   ` Jonathan Cameron via
2026-02-16 16:16     ` Jonathan Cameron via qemu development
2026-02-13 10:39 ` [PATCH v6 4/5] hw/arm/smmuv3: Introduce a helper function for event propagation Shameer Kolothum
2026-02-16 16:30   ` Jonathan Cameron via [this message]
2026-02-16 16:30     ` Jonathan Cameron via qemu development
2026-02-16 17:52     ` Shameer Kolothum Thodi
2026-02-13 10:39 ` [PATCH v6 5/5] hw/arm/smmuv3-accel: Read and propagate host vIOMMU events Shameer Kolothum
2026-02-13 22:29   ` Nicolin Chen
2026-02-13 22:31 ` [PATCH v6 0/5] vEVENTQ support for accelerated SMMUv3 devices Nicolin Chen
2026-02-16  9:13   ` Shameer Kolothum Thodi

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=20260216163010.00007797@huawei.com \
    --to=qemu-arm@nongnu.org \
    --cc=eric.auger@redhat.com \
    --cc=jan@nvidia.com \
    --cc=jgg@nvidia.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kjaju@nvidia.com \
    --cc=mochs@nvidia.com \
    --cc=nathanc@nvidia.com \
    --cc=nicolinc@nvidia.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=skolothumtho@nvidia.com \
    --cc=zhangfei.gao@linaro.org \
    --cc=zhenzhong.duan@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.