From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: joro@8bytes.org, will@kernel.org, vivek.gautam@arm.com,
guohanjun@huawei.com, zhukeqian1@huawei.com,
wangzhou1@hisilicon.com, linux-acpi@vger.kernel.org,
zhangfei.gao@linaro.org, lenb@kernel.org,
devicetree@vger.kernel.org, kevin.tian@intel.com,
jacob.jun.pan@linux.intel.com, eric.auger@redhat.com,
vdumpa@nvidia.com, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
shameerali.kolothum.thodi@huawei.com,
iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org,
baolu.lu@linux.intel.com
Subject: Re: [PATCH v13 06/10] iommu: Add a page fault handler
Date: Tue, 23 Mar 2021 11:53:10 +0100 [thread overview]
Message-ID: <YFnIlrecY6nkq5pP@myrica> (raw)
In-Reply-To: <20210303055727.GF1914@otc-nc-03>
On Tue, Mar 02, 2021 at 09:57:27PM -0800, Raj, Ashok wrote:
> > + ret = handle_mm_fault(vma, prm->addr, fault_flags, NULL);
>
> Should we add a trace similar to trace_page_fault_user() or kernel in
> arch/x86/kernel/mm/fault.c
Yes that would definitely be useful for debugging hardware and developping
applications. I can send a separate patch to add tracepoints here and in
the lower-level device fault path.
> or maybe add a perf_sw_event() for device faults?
It does seem like that would fit well alongside the existing
PERF_COUNT_SW_PAGE_FAULTS, but I don't think it would be useful in
practice, because we can't provide a context for the event. Since we're
handling these faults remotely, the only way for a user to get IOPF events
is to enable them on all CPUs and all tasks. Tracepoints can have 'pasid'
and 'device' fields to identify an event, but the perf_sw_event wouldn't
have any useful metadata apart from the faulting address.
We could also add tracepoints on bind(), so users can get the PASID
obtained with the PID they care about and filter fault events based on
that.
I've been wondering about associating a PASID with a PID internally,
because we don't currently have anywhere to send SEGV signals for
unhandled page faults. But I think it would be best to notify the device
driver on unhandled fault and let them deal with it. They'll probably want
that information anyway.
Thanks,
Jean
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com, will@kernel.org,
linux-acpi@vger.kernel.org, zhangfei.gao@linaro.org,
lenb@kernel.org, devicetree@vger.kernel.org,
kevin.tian@intel.com, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org, rjw@rjwysocki.net,
iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org
Subject: Re: [PATCH v13 06/10] iommu: Add a page fault handler
Date: Tue, 23 Mar 2021 11:53:10 +0100 [thread overview]
Message-ID: <YFnIlrecY6nkq5pP@myrica> (raw)
In-Reply-To: <20210303055727.GF1914@otc-nc-03>
On Tue, Mar 02, 2021 at 09:57:27PM -0800, Raj, Ashok wrote:
> > + ret = handle_mm_fault(vma, prm->addr, fault_flags, NULL);
>
> Should we add a trace similar to trace_page_fault_user() or kernel in
> arch/x86/kernel/mm/fault.c
Yes that would definitely be useful for debugging hardware and developping
applications. I can send a separate patch to add tracepoints here and in
the lower-level device fault path.
> or maybe add a perf_sw_event() for device faults?
It does seem like that would fit well alongside the existing
PERF_COUNT_SW_PAGE_FAULTS, but I don't think it would be useful in
practice, because we can't provide a context for the event. Since we're
handling these faults remotely, the only way for a user to get IOPF events
is to enable them on all CPUs and all tasks. Tracepoints can have 'pasid'
and 'device' fields to identify an event, but the perf_sw_event wouldn't
have any useful metadata apart from the faulting address.
We could also add tracepoints on bind(), so users can get the PASID
obtained with the PID they care about and filter fault events based on
that.
I've been wondering about associating a PASID with a PID internally,
because we don't currently have anywhere to send SEGV signals for
unhandled page faults. But I think it would be best to notify the device
driver on unhandled fault and let them deal with it. They'll probably want
that information anyway.
Thanks,
Jean
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: "Raj, Ashok" <ashok.raj@intel.com>
Cc: vivek.gautam@arm.com, guohanjun@huawei.com,
zhukeqian1@huawei.com, will@kernel.org, joro@8bytes.org,
wangzhou1@hisilicon.com, linux-acpi@vger.kernel.org,
zhangfei.gao@linaro.org, lenb@kernel.org,
devicetree@vger.kernel.org, kevin.tian@intel.com,
jacob.jun.pan@linux.intel.com, eric.auger@redhat.com,
robh+dt@kernel.org, linux-arm-kernel@lists.infradead.org,
rjw@rjwysocki.net, shameerali.kolothum.thodi@huawei.com,
iommu@lists.linux-foundation.org, sudeep.holla@arm.com,
robin.murphy@arm.com, linux-accelerators@lists.ozlabs.org,
baolu.lu@linux.intel.com
Subject: Re: [PATCH v13 06/10] iommu: Add a page fault handler
Date: Tue, 23 Mar 2021 11:53:10 +0100 [thread overview]
Message-ID: <YFnIlrecY6nkq5pP@myrica> (raw)
In-Reply-To: <20210303055727.GF1914@otc-nc-03>
On Tue, Mar 02, 2021 at 09:57:27PM -0800, Raj, Ashok wrote:
> > + ret = handle_mm_fault(vma, prm->addr, fault_flags, NULL);
>
> Should we add a trace similar to trace_page_fault_user() or kernel in
> arch/x86/kernel/mm/fault.c
Yes that would definitely be useful for debugging hardware and developping
applications. I can send a separate patch to add tracepoints here and in
the lower-level device fault path.
> or maybe add a perf_sw_event() for device faults?
It does seem like that would fit well alongside the existing
PERF_COUNT_SW_PAGE_FAULTS, but I don't think it would be useful in
practice, because we can't provide a context for the event. Since we're
handling these faults remotely, the only way for a user to get IOPF events
is to enable them on all CPUs and all tasks. Tracepoints can have 'pasid'
and 'device' fields to identify an event, but the perf_sw_event wouldn't
have any useful metadata apart from the faulting address.
We could also add tracepoints on bind(), so users can get the PASID
obtained with the PID they care about and filter fault events based on
that.
I've been wondering about associating a PASID with a PID internally,
because we don't currently have anywhere to send SEGV signals for
unhandled page faults. But I think it would be best to notify the device
driver on unhandled fault and let them deal with it. They'll probably want
that information anyway.
Thanks,
Jean
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-03-23 10:54 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 9:26 [PATCH v13 00/10] iommu: I/O page faults for SMMUv3 Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 01/10] iommu: Fix comment for struct iommu_fwspec Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-25 17:37 ` Will Deacon
2021-03-25 17:37 ` Will Deacon
2021-03-25 17:37 ` Will Deacon
2021-03-02 9:26 ` [PATCH v13 02/10] iommu/arm-smmu-v3: Use device properties for pasid-num-bits Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-25 17:36 ` Will Deacon
2021-03-25 17:36 ` Will Deacon
2021-03-25 17:36 ` Will Deacon
2021-03-02 9:26 ` [PATCH v13 03/10] iommu: Separate IOMMU_DEV_FEAT_IOPF from IOMMU_DEV_FEAT_SVA Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-03 5:04 ` Lu Baolu
2021-03-03 5:04 ` Lu Baolu
2021-03-03 5:04 ` Lu Baolu
2021-03-02 9:26 ` [PATCH v13 04/10] iommu/vt-d: Support IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 05/10] uacce: Enable IOMMU_DEV_FEAT_IOPF Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 06/10] iommu: Add a page fault handler Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 23:59 ` Jacob Pan
2021-03-02 23:59 ` Jacob Pan
2021-03-02 23:59 ` Jacob Pan
2021-03-23 10:50 ` Jean-Philippe Brucker
2021-03-23 10:50 ` Jean-Philippe Brucker
2021-03-23 10:50 ` Jean-Philippe Brucker
2021-03-03 5:27 ` Lu Baolu
2021-03-03 5:27 ` Lu Baolu
2021-03-03 5:27 ` Lu Baolu
2021-03-23 10:51 ` Jean-Philippe Brucker
2021-03-23 10:51 ` Jean-Philippe Brucker
2021-03-23 10:51 ` Jean-Philippe Brucker
2021-03-03 5:57 ` Raj, Ashok
2021-03-03 5:57 ` Raj, Ashok
2021-03-03 5:57 ` Raj, Ashok
2021-03-23 10:53 ` Jean-Philippe Brucker [this message]
2021-03-23 10:53 ` Jean-Philippe Brucker
2021-03-23 10:53 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 07/10] iommu/arm-smmu-v3: Maintain a SID->device structure Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 12:24 ` Keqian Zhu
2021-03-02 12:24 ` Keqian Zhu
2021-03-02 12:24 ` Keqian Zhu
2021-03-25 17:48 ` Will Deacon
2021-03-25 17:48 ` Will Deacon
2021-03-25 17:48 ` Will Deacon
2021-03-26 9:49 ` Jean-Philippe Brucker
2021-03-26 9:49 ` Jean-Philippe Brucker
2021-03-26 9:49 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 08/10] dt-bindings: document stall property for IOMMU masters Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 09/10] ACPI/IORT: Enable stall support for platform devices Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` [PATCH v13 10/10] iommu/arm-smmu-v3: Add " Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-02 9:26 ` Jean-Philippe Brucker
2021-03-19 17:40 ` Auger Eric
2021-03-19 17:40 ` Auger Eric
2021-03-19 17:40 ` Auger Eric
2021-03-26 9:52 ` Auger Eric
2021-03-26 9:52 ` Auger Eric
2021-03-26 9:52 ` Auger Eric
2021-03-18 0:25 ` [PATCH v13 00/10] iommu: I/O page faults for SMMUv3 Krishna Reddy
2021-03-18 0:25 ` Krishna Reddy
2021-03-18 0:25 ` Krishna Reddy
2021-03-30 17:17 ` Jean-Philippe Brucker
2021-03-30 17:17 ` Jean-Philippe Brucker
2021-03-30 17:17 ` Jean-Philippe Brucker
2021-04-01 8:57 ` Will Deacon
2021-04-01 8:57 ` Will Deacon
2021-04-01 8:57 ` Will Deacon
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=YFnIlrecY6nkq5pP@myrica \
--to=jean-philippe@linaro.org \
--cc=ashok.raj@intel.com \
--cc=baolu.lu@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=eric.auger@redhat.com \
--cc=guohanjun@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=lenb@kernel.org \
--cc=linux-accelerators@lists.ozlabs.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=rjw@rjwysocki.net \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=sudeep.holla@arm.com \
--cc=vdumpa@nvidia.com \
--cc=vivek.gautam@arm.com \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=zhangfei.gao@linaro.org \
--cc=zhukeqian1@huawei.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.