On Tue, Jul 09, 2024 at 10:33:42AM -0700, Nicolin Chen wrote:
> > We are potentially talking about 5-10 physical smmus and 2-3 FDs per
> > physical? Does that scare anyone?
>
> I think we can share the same FD by adding a viommu_id somewhere
> to indicate what the data/event belongs to. Yet, it s
On 2024/7/10 1:36, Jason Gunthorpe wrote:
On Mon, Jul 01, 2024 at 01:55:12PM +0800, Baolu Lu wrote:
On 2024/6/29 5:17, Jason Gunthorpe wrote:
On Sun, Jun 16, 2024 at 02:11:52PM +0800, Lu Baolu wrote:
+static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
+{
+ struct device *d
t this is bad already, something like SVA could trigger
> IOMMU_PAGE_RESP_FAILURE on a VF without iommufd today. Due to
> memory
> allocation failure in iommu_report_device_fault()
>
> And then we pass in code from userspace and blindly cast it to
> enum iommu_page_response
On Mon, Jul 01, 2024 at 01:55:12PM +0800, Baolu Lu wrote:
> On 2024/6/29 5:17, Jason Gunthorpe wrote:
> > On Sun, Jun 16, 2024 at 02:11:52PM +0800, Lu Baolu wrote:
> > > +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> > > +{
> > > + struct device *dev = idev->dev;
> > > + int r
On Tue, Jul 09, 2024 at 02:00:38PM -0300, Jason Gunthorpe wrote:
> On Mon, Jul 08, 2024 at 11:36:57AM -0700, Nicolin Chen wrote:
> > Maybe something like this?
> >
> > struct iommu_viommu_event_arm_smmuv3 {
> > u64 evt[4];
> > };
> >
> > struct iommu_viommu_event_tegra241_cmdqv {
> > u6
On Thu, Jul 04, 2024 at 03:18:57PM +0100, Will Deacon wrote:
> On Tue, 02 Jul 2024 14:34:34 +0800, Lu Baolu wrote:
> > This series implements the functionality of delivering IO page faults to
> > user space through the IOMMUFD framework. One feasible use case is the
> > nested translation. Nested t
On Mon, Jul 08, 2024 at 11:36:57AM -0700, Nicolin Chen wrote:
> Maybe something like this?
>
> struct iommu_viommu_event_arm_smmuv3 {
> u64 evt[4];
> };
>
> struct iommu_viommu_event_tegra241_cmdqv {
> u64 vcmdq_err_map[2];
> };
>
> enum iommu_event_type {
> IOMMM_HWPT_EVENT_TY
On Mon, Jul 08, 2024 at 01:29:57PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 03, 2024 at 04:06:15PM -0700, Nicolin Chen wrote:
>
> > I learned that this hwpt->fault is exclusively for IOPF/PRI. And
> > Jason suggested me to add a different one for VIOMMU. Yet, after
> > taking a closer look, I f
On Wed, Jul 03, 2024 at 04:06:15PM -0700, Nicolin Chen wrote:
> I learned that this hwpt->fault is exclusively for IOPF/PRI. And
> Jason suggested me to add a different one for VIOMMU. Yet, after
> taking a closer look, I found the fault object in this series is
> seemingly quite generic at the uA
On Fri, Jul 05, 2024 at 12:49:10AM +, Tian, Kevin wrote:
> > > > > > > +enum iommu_fault_type {
> > > > > > > + IOMMU_FAULT_TYPE_HWPT_IOPF,
> > > > > > > + IOMMU_FAULT_TYPE_VIOMMU_IRQ,
> > > > > > > +};
> > > > > > >
> > > > > > >struct iommu_fault_alloc {
> > > > > > >__u3
> From: Nicolin Chen
> Sent: Friday, July 5, 2024 7:19 AM
>
> On Thu, Jul 04, 2024 at 03:32:32PM +0800, Baolu Lu wrote:
> > On 2024/7/4 14:37, Tian, Kevin wrote:
> > > > From: Nicolin Chen
> > > > Sent: Thursday, July 4, 2024 1:36 PM
> > > >
> > > > On Thu, Jul 04, 2024 at 10:59:45AM +0800, Baolu
On Thu, Jul 04, 2024 at 03:32:32PM +0800, Baolu Lu wrote:
> On 2024/7/4 14:37, Tian, Kevin wrote:
> > > From: Nicolin Chen
> > > Sent: Thursday, July 4, 2024 1:36 PM
> > >
> > > On Thu, Jul 04, 2024 at 10:59:45AM +0800, Baolu Lu wrote:
> > > > > On Tue, Jul 02, 2024 at 02:34:40PM +0800, Lu Baolu w
On Tue, 02 Jul 2024 14:34:34 +0800, Lu Baolu wrote:
> This series implements the functionality of delivering IO page faults to
> user space through the IOMMUFD framework. One feasible use case is the
> nested translation. Nested translation is a hardware feature that
> supports two-stage translatio
On 2024/7/4 14:37, Tian, Kevin wrote:
From: Nicolin Chen
Sent: Thursday, July 4, 2024 1:36 PM
On Thu, Jul 04, 2024 at 10:59:45AM +0800, Baolu Lu wrote:
On Tue, Jul 02, 2024 at 02:34:40PM +0800, Lu Baolu wrote:
+enum iommu_fault_type {
+ IOMMU_FAULT_TYPE_HWPT_IOPF,
+ IOMMU_FAULT_TYPE_VI
> From: Nicolin Chen
> Sent: Thursday, July 4, 2024 1:36 PM
>
> On Thu, Jul 04, 2024 at 10:59:45AM +0800, Baolu Lu wrote:
> > > On Tue, Jul 02, 2024 at 02:34:40PM +0800, Lu Baolu wrote:
> > >
> > > +enum iommu_fault_type {
> > > + IOMMU_FAULT_TYPE_HWPT_IOPF,
> > > + IOMMU_FAULT_TYPE_VIOMM
On Thu, Jul 04, 2024 at 10:59:45AM +0800, Baolu Lu wrote:
> > On Tue, Jul 02, 2024 at 02:34:40PM +0800, Lu Baolu wrote:
> >
> > > An iommufd fault object provides an interface for delivering I/O page
> > > faults to user space. These objects are created and destroyed by user
> > > space, and they
On 7/4/24 7:06 AM, Nicolin Chen wrote:
Hi Baolu,
Hi Nicolin,
On Tue, Jul 02, 2024 at 02:34:40PM +0800, Lu Baolu wrote:
An iommufd fault object provides an interface for delivering I/O page
faults to user space. These objects are created and destroyed by user
space, and they can be associate
Hi Baolu,
On Tue, Jul 02, 2024 at 02:34:40PM +0800, Lu Baolu wrote:
> An iommufd fault object provides an interface for delivering I/O page
> faults to user space. These objects are created and destroyed by user
> space, and they can be associated with or dissociated from hardware page
> table ob
On 2024/6/29 6:14, Jason Gunthorpe wrote:
On Sun, Jun 16, 2024 at 02:11:45PM +0800, Lu Baolu wrote:
Lu Baolu (10):
iommu: Introduce domain attachment handle
iommu: Remove sva handle list
iommu: Add attach handle to struct iopf_group
iommu: Extend domain attach group with handle supp
On 2024/6/29 5:17, Jason Gunthorpe wrote:
On Sun, Jun 16, 2024 at 02:11:52PM +0800, Lu Baolu wrote:
+static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
+{
+ struct device *dev = idev->dev;
+ int ret;
+
+ /*
+* Once we turn on PCI/PRI support for VF, the r
On 2024/6/29 6:13, Jason Gunthorpe wrote:
On Sun, Jun 16, 2024 at 02:11:53PM +0800, Lu Baolu wrote:
@@ -308,13 +315,29 @@ int iommufd_hwpt_alloc(struct iommufd_ucmd *ucmd)
goto out_put_pt;
}
+ if (cmd->flags & IOMMU_HWPT_FAULT_ID_VALID) {
+ struct iommu
On 2024/6/29 5:06, Jason Gunthorpe wrote:
On Sun, Jun 16, 2024 at 02:11:49PM +0800, Lu Baolu wrote:
+int iommu_replace_group_handle(struct iommu_group *group,
+ struct iommu_domain *new_domain,
+ struct iommu_attach_handle *handle)
+{
+
On Sun, Jun 16, 2024 at 02:11:51PM +0800, Lu Baolu wrote:
> @@ -6,6 +6,7 @@ iommufd-y := \
> ioas.o \
> main.o \
> pages.o \
> + fault.o \
> vfio_compat.o
Keep sorted
Reviewed-by: Jason Gunthorpe
Jason
On Sun, Jun 16, 2024 at 02:11:47PM +0800, Lu Baolu wrote:
> The struct sva_iommu represents an association between an SVA domain and
> a PASID of a device. It's stored in the iommu group's pasid array and also
> tracked by a list in the per-mm data structure. Removes duplicate tracking
> of sva_iom
On Sun, Jun 16, 2024 at 02:11:48PM +0800, Lu Baolu wrote:
> Previously, the domain that a page fault targets is stored in an
> iopf_group, which represents a minimal set of page faults. With the
> introduction of attach handle, replace the domain with the handle
> so that the fault handler can obta
On Sun, Jun 16, 2024 at 02:11:45PM +0800, Lu Baolu wrote:
> Lu Baolu (10):
> iommu: Introduce domain attachment handle
> iommu: Remove sva handle list
> iommu: Add attach handle to struct iopf_group
> iommu: Extend domain attach group with handle support
> iommufd: Add fault and response
On Sun, Jun 16, 2024 at 02:11:53PM +0800, Lu Baolu wrote:
> @@ -308,13 +315,29 @@ int iommufd_hwpt_alloc(struct iommufd_ucmd *ucmd)
> goto out_put_pt;
> }
>
> + if (cmd->flags & IOMMU_HWPT_FAULT_ID_VALID) {
> + struct iommufd_fault *fault;
> +
> +
On Sun, Jun 16, 2024 at 02:11:46PM +0800, Lu Baolu wrote:
> Currently, when attaching a domain to a device or its PASID, domain is
> stored within the iommu group. It could be retrieved for use during the
> window between attachment and detachment.
>
> With new features introduced, there's a need
On Sun, Jun 16, 2024 at 02:11:52PM +0800, Lu Baolu wrote:
> +static int iommufd_fault_iopf_enable(struct iommufd_device *idev)
> +{
> + struct device *dev = idev->dev;
> + int ret;
> +
> + /*
> + * Once we turn on PCI/PRI support for VF, the response failure code
> + * should
On Sun, Jun 16, 2024 at 02:11:49PM +0800, Lu Baolu wrote:
> +int iommu_replace_group_handle(struct iommu_group *group,
> +struct iommu_domain *new_domain,
> +struct iommu_attach_handle *handle)
> +{
> + struct iommu_domain *old_domain = g
On 6/17/24 3:41 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Sunday, June 16, 2024 2:12 PM
Add a new IOMMU capability flag, IOMMU_CAP_USER_IOASID_TABLE, which
indicates if the IOMMU driver supports user-managed PASID tables. In the
iopf deliver path, if no attach handle found for the iopf PASID,
> From: Lu Baolu
> Sent: Sunday, June 16, 2024 2:12 PM
>
> This series implements the functionality of delivering IO page faults to
> user space through the IOMMUFD framework. One feasible use case is the
> nested translation. Nested translation is a hardware feature that
> supports two-stage tra
> From: Lu Baolu
> Sent: Sunday, June 16, 2024 2:12 PM
>
> Add a new IOMMU capability flag, IOMMU_CAP_USER_IOASID_TABLE, which
> indicates if the IOMMU driver supports user-managed PASID tables. In the
> iopf deliver path, if no attach handle found for the iopf PASID, roll
> back to RID domain wh
> From: Baolu Lu
> Sent: Sunday, June 9, 2024 3:23 PM
>
> On 6/7/24 5:30 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Monday, May 27, 2024 12:05 PM
> >>
> >> Add iopf-capable hw page table attach/detach/replace helpers. The
> pointer
> >> to iommufd_device is stored in the domain attach
> From: Jason Gunthorpe
> Sent: Wednesday, June 12, 2024 9:24 PM
>
> On Fri, Jun 07, 2024 at 09:17:28AM +, Tian, Kevin wrote:
> > > From: Lu Baolu
> > > Sent: Monday, May 27, 2024 12:05 PM
> > >
> > > +static ssize_t iommufd_fault_fops_read(struct file *filep, char __user
> *buf,
> > > +
On 6/13/24 7:49 PM, Jason Gunthorpe wrote:
On Thu, Jun 13, 2024 at 12:23:17PM +0800, Baolu Lu wrote:
struct iommu_ops {
bool (*capable)(struct device *dev, enum iommu_cap);
@@ -600,6 +598,7 @@ struct iommu_ops {
struct iommu_domain *blocked_domain;
struct iommu_doma
On Thu, Jun 13, 2024 at 12:23:17PM +0800, Baolu Lu wrote:
> struct iommu_ops {
> bool (*capable)(struct device *dev, enum iommu_cap);
> @@ -600,6 +598,7 @@ struct iommu_ops {
> struct iommu_domain *blocked_domain;
> struct iommu_domain *release_domain;
> struct iom
On 6/12/24 9:54 PM, Jason Gunthorpe wrote:
On Mon, May 27, 2024 at 12:05:07PM +0800, Lu Baolu wrote:
This series implements the functionality of delivering IO page faults to
user space through the IOMMUFD framework. One feasible use case is the
nested translation. Nested translation is a hardwar
On 6/12/24 9:25 PM, Jason Gunthorpe wrote:
On Sat, Jun 08, 2024 at 05:58:34PM +0800, Baolu Lu wrote:
+static int iommufd_fault_fops_release(struct inode *inode, struct file *filep)
+{
+ struct iommufd_fault *fault = filep->private_data;
+
+ iommufd_ctx_put(fault->ictx);
+ refc
On 6/12/24 9:52 PM, Jason Gunthorpe wrote:
On Mon, May 27, 2024 at 12:05:12PM +0800, Lu Baolu wrote:
+/**
+ * struct iommu_hwpt_pgfault - iommu page fault data
+ * @size: sizeof(struct iommu_hwpt_pgfault)
+ * @flags: Combination of enum iommu_hwpt_pgfault_flags
+ * @dev_id: id of the originated
On 6/12/24 9:50 PM, Jason Gunthorpe wrote:
On Wed, Jun 12, 2024 at 10:19:46AM -0300, Jason Gunthorpe wrote:
I prefer not to mess the definition of user API data and the kernel
driver implementation. The kernel driver may change in the future, but
the user API will remain stable for a long time.
On 6/12/24 9:19 PM, Jason Gunthorpe wrote:
On Fri, Jun 07, 2024 at 09:38:38AM +, Tian, Kevin wrote:
From: Baolu Lu
Sent: Thursday, June 6, 2024 2:28 PM
On 6/5/24 4:28 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
+
+/**
+ * struct iommu_hwpt_page_response - IOM
On 6/12/24 9:41 PM, Jason Gunthorpe wrote:
On Mon, May 27, 2024 at 12:05:11PM +0800, Lu Baolu wrote:
Unlike the SVA case where each PASID of a device has an SVA domain
attached to it, the I/O page faults are handled by the fault handler
of the SVA domain. The I/O page faults for a user page tabl
On 6/12/24 9:37 PM, Jason Gunthorpe wrote:
On Mon, May 27, 2024 at 12:05:10PM +0800, Lu Baolu wrote:
@@ -206,20 +182,49 @@ void iommu_report_device_fault(struct device *dev, struct
iopf_fault *evt)
if (group == &abort_group)
goto err_abort;
- group->domain = get_domai
ere a missing test for the same mm too?
I'd maybe change iommu_attach_handle() to return NULL if there is no
handle and then write it like:
if (IS_ERR(attach_handle) && PTR_ERR(attach_handle) != -ENOENT) {
ret = PTR_ERR(attach_handle);
goto out_unlock;
}
if (!IS_ERR(att
On 6/12/24 9:10 PM, Jason Gunthorpe wrote:
On Thu, Jun 06, 2024 at 01:33:29PM +0800, Baolu Lu wrote:
But if certain path (other than iopf) in the iommu core needs to know
the exact domain pointer then this change breaks it.
The iommu core should not fetch the domain pointer in paths other tha
On Mon, May 27, 2024 at 12:05:07PM +0800, Lu Baolu wrote:
> This series implements the functionality of delivering IO page faults to
> user space through the IOMMUFD framework. One feasible use case is the
> nested translation. Nested translation is a hardware feature that
> supports two-stage tran
On Mon, May 27, 2024 at 12:05:12PM +0800, Lu Baolu wrote:
> +/**
> + * struct iommu_hwpt_pgfault - iommu page fault data
> + * @size: sizeof(struct iommu_hwpt_pgfault)
> + * @flags: Combination of enum iommu_hwpt_pgfault_flags
> + * @dev_id: id of the originated device
> + * @pasid: Process Address
On Wed, Jun 12, 2024 at 10:19:46AM -0300, Jason Gunthorpe wrote:
> > > I prefer not to mess the definition of user API data and the kernel
> > > driver implementation. The kernel driver may change in the future, but
> > > the user API will remain stable for a long time.
> >
> > sure it remains sta
On Mon, May 27, 2024 at 12:05:11PM +0800, Lu Baolu wrote:
> Unlike the SVA case where each PASID of a device has an SVA domain
> attached to it, the I/O page faults are handled by the fault handler
> of the SVA domain. The I/O page faults for a user page table might
> be handled by the domain attac
On Mon, May 27, 2024 at 12:05:10PM +0800, Lu Baolu wrote:
> @@ -206,20 +182,49 @@ void iommu_report_device_fault(struct device *dev,
> struct iopf_fault *evt)
> if (group == &abort_group)
> goto err_abort;
>
> - group->domain = get_domain_for_iopf(dev, fault);
> - if
On Sat, Jun 08, 2024 at 05:58:34PM +0800, Baolu Lu wrote:
> > > +static int iommufd_fault_fops_release(struct inode *inode, struct file
> > > *filep)
> > > +{
> > > + struct iommufd_fault *fault = filep->private_data;
> > > +
> > > + iommufd_ctx_put(fault->ictx);
> > > + refcount_dec(&fault->obj.
On Fri, Jun 07, 2024 at 09:17:28AM +, Tian, Kevin wrote:
> > From: Lu Baolu
> > Sent: Monday, May 27, 2024 12:05 PM
> >
> > +static ssize_t iommufd_fault_fops_read(struct file *filep, char __user
> > *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + size
On Fri, Jun 07, 2024 at 09:38:38AM +, Tian, Kevin wrote:
> > From: Baolu Lu
> > Sent: Thursday, June 6, 2024 2:28 PM
> >
> > On 6/5/24 4:28 PM, Tian, Kevin wrote:
> > >> From: Lu Baolu
> > >> Sent: Monday, May 27, 2024 12:05 PM
> > >>
> > >> +
> > >> +/**
> > >> + * struct iommu_hwpt_page_re
On Thu, Jun 06, 2024 at 01:33:29PM +0800, Baolu Lu wrote:
> > But if certain path (other than iopf) in the iommu core needs to know
> > the exact domain pointer then this change breaks it.
>
> The iommu core should not fetch the domain pointer in paths other than
> attach/detach/replace. There is
s being
asked for here.
It will eventually do this naturally when iommu_attach_device_pasid()
is called with an in-use PASID, but may as well do it here for
clarity.
Also, is there a missing test for the same mm too?
I'd maybe change iommu_attach_handle() to return NULL if there is no
handle and then
On 6/7/24 5:30 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
Add iopf-capable hw page table attach/detach/replace helpers. The pointer
to iommufd_device is stored in the domain attachment handle, so that it
can be echo'ed back in the iopf_group.
this message needs
On 6/7/24 5:17 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
+static ssize_t iommufd_fault_fops_read(struct file *filep, char __user *buf,
+ size_t count, loff_t *ppos)
+{
+ size_t fault_size = sizeof(struct iommu_hwpt_pgfau
> From: Baolu Lu
> Sent: Thursday, June 6, 2024 2:28 PM
>
> On 6/5/24 4:28 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Monday, May 27, 2024 12:05 PM
> >>
> >> +
> >> +/**
> >> + * struct iommu_hwpt_page_response - IOMMU page fault response
> >> + * @size: sizeof(struct iommu_hwpt_page_
> From: Baolu Lu
> Sent: Thursday, June 6, 2024 2:07 PM
>
> On 6/5/24 4:15 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Monday, May 27, 2024 12:05 PM
> >>
> >> - list_for_each_entry(handle, &mm->iommu_mm->sva_handles,
> >> handle_item) {
> >> - if (handle->dev == dev) {
> >> -
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> When allocating a user iommufd_hw_pagetable, the user space is allowed to
> associate a fault object with the hw_pagetable by specifying the fault
> object ID in the page table allocation data and setting the
> IOMMU_HWPT_FAULT_ID_VALID f
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> Add iopf-capable hw page table attach/detach/replace helpers. The pointer
> to iommufd_device is stored in the domain attachment handle, so that it
> can be echo'ed back in the iopf_group.
this message needs an update. now the device poi
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> +static ssize_t iommufd_fault_fops_read(struct file *filep, char __user *buf,
> +size_t count, loff_t *ppos)
> +{
> + size_t fault_size = sizeof(struct iommu_hwpt_pgfault);
> + struct iommufd_fa
On 6/5/24 4:28 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
+
+/**
+ * struct iommu_hwpt_page_response - IOMMU page fault response
+ * @size: sizeof(struct iommu_hwpt_page_response)
+ * @flags: Must be set to 0
+ * @dev_id: device ID of target device for the respons
On 6/5/24 4:23 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
@@ -249,6 +249,12 @@ enum iommu_cap {
*/
IOMMU_CAP_DEFERRED_FLUSH,
IOMMU_CAP_DIRTY_TRACKING, /* IOMMU supports dirty
tracking */
+ /*
+* IOMMU driver supports us
On 6/5/24 4:15 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
@@ -69,11 +68,16 @@ static struct iommu_mm_data
*iommu_alloc_mm_data(struct mm_struct *mm, struct de
*/
struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
mm_struct *mm)
{
+ str
On 6/5/24 4:02 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Monday, May 27, 2024 12:05 PM
@@ -99,7 +99,9 @@ struct iommu_sva *iommu_sva_bind_device(struct device
*dev, struct mm_struct *mm
/* Search for an existing domain. */
list_for_each_entry(domain, &mm->iommu_mm->sva_domain
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> +
> +/**
> + * struct iommu_hwpt_page_response - IOMMU page fault response
> + * @size: sizeof(struct iommu_hwpt_page_response)
> + * @flags: Must be set to 0
> + * @dev_id: device ID of target device for the response
> + * @pasid: Proces
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> @@ -249,6 +249,12 @@ enum iommu_cap {
>*/
> IOMMU_CAP_DEFERRED_FLUSH,
> IOMMU_CAP_DIRTY_TRACKING, /* IOMMU supports dirty
> tracking */
> + /*
> + * IOMMU driver supports user-managed IOASID table. There
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> @@ -69,11 +68,16 @@ static struct iommu_mm_data
> *iommu_alloc_mm_data(struct mm_struct *mm, struct de
> */
> struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct
> mm_struct *mm)
> {
> + struct iommu_group *group =
> From: Lu Baolu
> Sent: Monday, May 27, 2024 12:05 PM
>
> @@ -99,7 +99,9 @@ struct iommu_sva *iommu_sva_bind_device(struct device
> *dev, struct mm_struct *mm
>
> /* Search for an existing domain. */
> list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
> - r
On 5/27/24 9:33 AM, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Friday, May 24, 2024 10:25 PM
On Mon, May 20, 2024 at 03:39:54AM +, Tian, Kevin wrote:
From: Baolu Lu
Sent: Monday, May 20, 2024 10:19 AM
On 5/15/24 4:50 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 20
> From: Jason Gunthorpe
> Sent: Friday, May 24, 2024 10:25 PM
>
> On Mon, May 20, 2024 at 03:39:54AM +, Tian, Kevin wrote:
> > > From: Baolu Lu
> > > Sent: Monday, May 20, 2024 10:19 AM
> > >
> > > On 5/15/24 4:50 PM, Tian, Kevin wrote:
> > > >> From: Lu Baolu
> > > >> Sent: Tuesday, April
> From: Jason Gunthorpe
> Sent: Friday, May 24, 2024 10:15 PM
>
> On Mon, May 20, 2024 at 04:59:18AM +, Tian, Kevin wrote:
> > > From: Baolu Lu
> > > Sent: Monday, May 20, 2024 11:33 AM
> > >
> > > On 5/20/24 11:24 AM, Tian, Kevin wrote:
> > > >> From: Baolu Lu
> > > >> Sent: Sunday, May 19
On Mon, May 20, 2024 at 03:39:54AM +, Tian, Kevin wrote:
> > From: Baolu Lu
> > Sent: Monday, May 20, 2024 10:19 AM
> >
> > On 5/15/24 4:50 PM, Tian, Kevin wrote:
> > >> From: Lu Baolu
> > >> Sent: Tuesday, April 30, 2024 10:57 PM
> > >>
> > >> @@ -308,6 +314,19 @@ int iommufd_hwpt_alloc(str
On Mon, May 20, 2024 at 09:24:09AM +0800, Baolu Lu wrote:
> On 5/15/24 4:37 PM, Tian, Kevin wrote:
> > > +static ssize_t iommufd_fault_fops_write(struct file *filep, const char
> > > __user
> > > *buf,
> > > + size_t count, loff_t *ppos)
> > > +{
> > > + size_t resp
On Mon, May 20, 2024 at 04:59:18AM +, Tian, Kevin wrote:
> > From: Baolu Lu
> > Sent: Monday, May 20, 2024 11:33 AM
> >
> > On 5/20/24 11:24 AM, Tian, Kevin wrote:
> > >> From: Baolu Lu
> > >> Sent: Sunday, May 19, 2024 10:38 PM
> > >>
> > >> On 2024/5/15 15:43, Tian, Kevin wrote:
> > F
> From: Baolu Lu
> Sent: Monday, May 20, 2024 11:33 AM
>
> On 5/20/24 11:24 AM, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Sunday, May 19, 2024 10:38 PM
> >>
> >> On 2024/5/15 15:43, Tian, Kevin wrote:
> From: Lu Baolu
> Sent: Tuesday, April 30, 2024 10:57 PM
>
> + *
On 5/20/24 11:39 AM, Tian, Kevin wrote:
From: Baolu Lu
Sent: Monday, May 20, 2024 10:19 AM
On 5/15/24 4:50 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
@@ -308,6 +314,19 @@ int iommufd_hwpt_alloc(struct iommufd_ucmd
*ucmd)
goto out_put_pt;
On 5/20/24 11:35 AM, Tian, Kevin wrote:
From: Baolu Lu
Sent: Monday, May 20, 2024 10:10 AM
On 5/15/24 4:43 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
+
+int iommufd_fault_domain_replace_dev(struct iommufd_device *idev,
+str
> From: Baolu Lu
> Sent: Monday, May 20, 2024 10:19 AM
>
> On 5/15/24 4:50 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, April 30, 2024 10:57 PM
> >>
> >> @@ -308,6 +314,19 @@ int iommufd_hwpt_alloc(struct iommufd_ucmd
> >> *ucmd)
> >>goto out_put_pt;
> >>}
> >>
> From: Baolu Lu
> Sent: Monday, May 20, 2024 10:10 AM
>
> On 5/15/24 4:43 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, April 30, 2024 10:57 PM
> >> +
> >> +int iommufd_fault_domain_replace_dev(struct iommufd_device *idev,
> >> + struct iommufd_hw_
On 5/20/24 11:24 AM, Tian, Kevin wrote:
From: Baolu Lu
Sent: Sunday, May 19, 2024 10:38 PM
On 2024/5/15 15:43, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
iommu_hwpt_pgfaults represent fault messages that the userspace can
retrieve. Multiple iommu_hwpt_pgfaults m
> From: Baolu Lu
> Sent: Monday, May 20, 2024 9:34 AM
>
> On 5/15/24 4:37 PM, Tian, Kevin wrote:
> >> +
> >> + iopf_group_response(group, response.code);
> > PCIe spec states that a response failure disables the PRI interface. For SR-
> IOV
> > it'd be dangerous allowing user to trigger
On 5/20/24 11:26 AM, Tian, Kevin wrote:
From: Baolu Lu
Sent: Monday, May 20, 2024 8:41 AM
On 5/15/24 3:57 PM, Tian, Kevin wrote:
From: Baolu Lu
Sent: Wednesday, May 8, 2024 6:05 PM
On 2024/5/8 8:11, Jason Gunthorpe wrote:
On Tue, Apr 30, 2024 at 10:57:06PM +0800, Lu Baolu wrote:
diff --git
> From: Baolu Lu
> Sent: Monday, May 20, 2024 8:41 AM
>
> On 5/15/24 3:57 PM, Tian, Kevin wrote:
> >> From: Baolu Lu
> >> Sent: Wednesday, May 8, 2024 6:05 PM
> >>
> >> On 2024/5/8 8:11, Jason Gunthorpe wrote:
> >>> On Tue, Apr 30, 2024 at 10:57:06PM +0800, Lu Baolu wrote:
> diff --git a/dr
> From: Baolu Lu
> Sent: Sunday, May 19, 2024 10:38 PM
>
> On 2024/5/15 15:43, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, April 30, 2024 10:57 PM
> >>
> >> iommu_hwpt_pgfaults represent fault messages that the userspace can
> >> retrieve. Multiple iommu_hwpt_pgfaults might be put
> From: Baolu Lu
> Sent: Sunday, May 19, 2024 10:04 PM
>
> On 2024/5/15 15:31, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, April 30, 2024 10:57 PM
> >>
> >> + handle = iommu_attach_handle_get(dev->iommu_group, pasid, 0);
> >> + if (IS_ERR(handle))
> >> + return PTR_ERR(
> From: Baolu Lu
> Sent: Sunday, May 19, 2024 6:14 PM
>
> On 5/15/24 3:21 PM, Tian, Kevin wrote:
> >> From: Lu Baolu
> >> Sent: Tuesday, April 30, 2024 10:57 PM
> >>
> >> #else
> >> -static inline struct iommu_sva *
> >> +static inline struct iommu_attach_handle *
> >> iommu_sva_bind_device(
On 5/15/24 4:50 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
@@ -227,7 +233,7 @@ iommufd_hwpt_nested_alloc(struct iommufd_ctx
*ictx,
refcount_inc(&parent->common.obj.users);
hwpt_nested->parent = parent;
- hwpt->domain = ops->domain_alloc_u
On 5/15/24 4:43 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
+
+int iommufd_fault_domain_replace_dev(struct iommufd_device *idev,
+struct iommufd_hw_pagetable *hwpt,
+struct iommufd_hw_pagetab
On 5/15/24 4:37 PM, Tian, Kevin wrote:
+ iopf_free_group(group);
+ done += response_size;
+
+ iommufd_put_object(fault->ictx, &idev->obj);
get/put is unpaired:
if (!idev || idev->obj.id != response.dev_id)
idev =
On 5/15/24 4:37 PM, Tian, Kevin wrote:
+
+ iopf_group_response(group, response.code);
PCIe spec states that a response failure disables the PRI interface. For SR-IOV
it'd be dangerous allowing user to trigger such code to VF to close the entire
shared PRI interface.
Just another e
On 5/15/24 4:37 PM, Tian, Kevin wrote:
+static ssize_t iommufd_fault_fops_write(struct file *filep, const char __user
*buf,
+ size_t count, loff_t *ppos)
+{
+ size_t response_size = sizeof(struct iommu_hwpt_page_response);
+ struct iommufd_fault *
On 5/15/24 4:37 PM, Tian, Kevin wrote:
@@ -395,6 +396,8 @@ struct iommufd_device {
/* always the physical device */
struct device *dev;
bool enforce_cache_coherency;
+ /* outstanding faults awaiting response indexed by fault group id */
+ struct xarray faults;
On 5/15/24 3:57 PM, Tian, Kevin wrote:
From: Baolu Lu
Sent: Wednesday, May 8, 2024 6:05 PM
On 2024/5/8 8:11, Jason Gunthorpe wrote:
On Tue, Apr 30, 2024 at 10:57:06PM +0800, Lu Baolu wrote:
diff --git a/drivers/iommu/iommu-priv.h b/drivers/iommu/iommu-priv.h
index ae65e0b85d69..1a0450a83bd0 1
On 2024/5/15 15:43, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
iommu_hwpt_pgfaults represent fault messages that the userspace can
retrieve. Multiple iommu_hwpt_pgfaults might be put in an iopf group,
with the IOMMU_PGFAULT_FLAGS_LAST_PAGE flag set only for the las
On 2024/5/15 15:31, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
Previously, the domain that a page fault targets is stored in an
iopf_group, which represents a minimal set of page faults. With the
introduction of attachment handle, replace the domain with the handle
On 5/15/24 3:21 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
#else
-static inline struct iommu_sva *
+static inline struct iommu_attach_handle *
iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
{
- return NULL;
+ return ERR_PTR(-E
On 5/15/24 3:17 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Tuesday, April 30, 2024 10:57 PM
+/* Add an attach handle to the group's pasid array. */
+static struct iommu_attach_handle *
+iommu_attach_handle_set(struct iommu_domain *domain,
+ struct iommu_group *group, ioas
1 - 100 of 6524 matches
Mail list logo
