On 2025/1/20 13:54, Nicolin Chen wrote:
On Sun, Jan 19, 2025 at 06:40:57PM +0800, Yi Liu wrote:
On 2025/1/19 04:32, Nicolin Chen wrote:
On Sat, Jan 18, 2025 at 04:23:22PM +0800, Yi Liu wrote:
On 2025/1/11 11:32, Nicolin Chen wrote:
+static int iommufd_hwpt_attach_device(struct
On 2025/1/19 04:32, Nicolin Chen wrote:
On Sat, Jan 18, 2025 at 04:23:22PM +0800, Yi Liu wrote:
On 2025/1/11 11:32, Nicolin Chen wrote:
"attach_handle" was added exclusively for the iommufd_fault_iopf_handler()
used by IOPF/PRI use cases, along with the "fault_data". Now,
detach_dev() will check
hwpt->fault before calling it. So just call iommufd_auto_response_faults().
+ if (disable_iopf)
iommufd_fault_iopf_disable(idev);
-
- return 0;
}
void iommufd_fault_destroy(struct iommufd_object *obj)
--
Regards,
Yi Liu
uct iommufd_ucmd *ucmd)
put_unused_fd(fdno);
out_fput:
fput(filep);
- refcount_dec(&fault->obj.users);
- iommufd_ctx_put(fault->ictx);
out_abort:
iommufd_object_abort_and_destroy(ucmd->ictx, &fault->obj);
Reviewed-by: Yi Liu
--
Regards,
Yi Liu
On 2024/10/1 05:59, Nicolin Chen wrote:
On Sun, Sep 29, 2024 at 03:16:55PM +0800, Yi Liu wrote:
I feel these two might act somehow similarly to the two DIDs
during nested translations?
not quite the same. Is it possible that the ASID is the same for stage-1?
Intel VT-d side can have the pasid
On 2024/9/27 20:20, Jason Gunthorpe wrote:
On Fri, Sep 27, 2024 at 08:12:20PM +0800, Yi Liu wrote:
Perhaps calling it a slice sounds more accurate, as I guess all
the confusion comes from the name "vIOMMU" that might be thought
to be a user space object/instance that likely holds a
On 2024/9/28 04:44, Nicolin Chen wrote:
On Fri, Sep 27, 2024 at 08:12:20PM +0800, Yi Liu wrote:
On 2024/9/27 14:32, Nicolin Chen wrote:
On Fri, Sep 27, 2024 at 01:54:45PM +0800, Yi Liu wrote:
Baolu told me that Intel may have the same: different domain IDs
on different IOMMUs; multiple IOMMU
On 2024/9/27 14:32, Nicolin Chen wrote:
On Fri, Sep 27, 2024 at 01:54:45PM +0800, Yi Liu wrote:
Baolu told me that Intel may have the same: different domain IDs
on different IOMMUs; multiple IOMMU instances on one chip:
https://lore.kernel.org/linux-iommu/cf4fe15c-8bcb-4132-a1fd-b2c8ddf27
On 2024/9/27 14:02, Nicolin Chen wrote:
On Fri, Sep 27, 2024 at 01:38:08PM +0800, Yi Liu wrote:
Does it mean each vIOMMU of VM can only have
one s2 HWPT?
Giving some examples here:
- If a VM has 1 vIOMMU, there will be 1 vIOMMU object in the
kernel holding one S2 HWPT.
- If a VM
On 2024/9/27 10:05, Baolu Lu wrote:
On 9/27/24 4:03 AM, Nicolin Chen wrote:
On Thu, Sep 26, 2024 at 04:47:02PM +0800, Yi Liu wrote:
On 2024/9/26 02:55, Nicolin Chen wrote:
On Wed, Sep 25, 2024 at 06:30:20PM +0800, Yi Liu wrote:
Hi Nic,
On 2024/8/28 00:59, Nicolin Chen wrote:
This series
On 2024/9/27 04:03, Nicolin Chen wrote:
On Thu, Sep 26, 2024 at 04:47:02PM +0800, Yi Liu wrote:
On 2024/9/26 02:55, Nicolin Chen wrote:
On Wed, Sep 25, 2024 at 06:30:20PM +0800, Yi Liu wrote:
Hi Nic,
On 2024/8/28 00:59, Nicolin Chen wrote:
This series introduces a new VIOMMU infrastructure
On 2024/9/27 04:10, Nicolin Chen wrote:
On Thu, Sep 26, 2024 at 04:50:46PM +0800, Yi Liu wrote:
On 2024/8/28 00:59, Nicolin Chen wrote:
Now a VIOMMU can wrap a shareable nested parent HWPT. So, it can act like
a nested parent HWPT to allocate a nested HWPT.
Support that in the
ase, the @data_type must be set to a pre-defined type corresponding to an
+ * I/O page table type supported by the underlying IOMMU hardware.
*
* If the @data_type is set to IOMMU_HWPT_DATA_NONE, @data_len and
* @data_uptr should be zero. Otherwise, both @data_len and @data_uptr
--
Regards,
Yi Liu
On 2024/9/26 02:55, Nicolin Chen wrote:
On Wed, Sep 25, 2024 at 06:30:20PM +0800, Yi Liu wrote:
Hi Nic,
On 2024/8/28 00:59, Nicolin Chen wrote:
This series introduces a new VIOMMU infrastructure and related ioctls.
IOMMUFD has been using the HWPT infrastructure for all cases, including a
mu.c
create mode 100644 drivers/iommu/iommufd/viommu_api.c
--
Regards,
Yi Liu
15 matches
Mail list logo
