Message ID | cover.1675320212.git.nicolinc@nvidia.com (mailing list archive) |
---|---|
Headers | show |
Series | Add IO page table replacement support | expand |
> From: Nicolin Chen <nicolinc@nvidia.com> > Sent: Thursday, February 2, 2023 3:05 PM > > QEMU with this feature should have the vIOMMU maintain a cache of the > guest io page table addresses and assign a unique IOAS to each unique > guest page table. I didn't get why we impose such requirement to userspace. > > To apply this series, please rebase on top of the following patches: > 1) [PATCH 00/13] Add vfio_device cdev for iommufd support > https://lore.kernel.org/kvm/20230117134942.101112-1-yi.l.liu@intel.com/ > 2) (Merged) [PATCH v5 0/5] iommu: Retire detach_dev callback > https://lore.kernel.org/linux-iommu/20230110025408.667767-1- > baolu.lu@linux.intel.com/ > 3) (Merged) [PATCH] selftests: iommu: Fix test_cmd_destroy_access() call in > user_copy > https://lore.kernel.org/lkml/20230120074204.1368-1-nicolinc@nvidia.com/ > No need to list merged work as dependency. In concept every commit merged in the version which this series is rebased to is required.
On Fri, Feb 03, 2023 at 08:09:30AM +0000, Tian, Kevin wrote: > > From: Nicolin Chen <nicolinc@nvidia.com> > > Sent: Thursday, February 2, 2023 3:05 PM > > > > QEMU with this feature should have the vIOMMU maintain a cache of the > > guest io page table addresses and assign a unique IOAS to each unique > > guest page table. > > I didn't get why we impose such requirement to userspace. I read this as implementation guidance for qemu. qemu can do what it wants of course Jason
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Friday, February 3, 2023 11:04 PM > > On Fri, Feb 03, 2023 at 08:09:30AM +0000, Tian, Kevin wrote: > > > From: Nicolin Chen <nicolinc@nvidia.com> > > > Sent: Thursday, February 2, 2023 3:05 PM > > > > > > QEMU with this feature should have the vIOMMU maintain a cache of the > > > guest io page table addresses and assign a unique IOAS to each unique > > > guest page table. > > > > I didn't get why we impose such requirement to userspace. > > I read this as implementation guidance for qemu. qemu can do what it > wants of course > sure but I still didn't get why this is a guidance specific to the new replace cmd...
On Mon, Feb 06, 2023 at 06:39:29AM +0000, Tian, Kevin wrote: > > From: Jason Gunthorpe <jgg@nvidia.com> > > Sent: Friday, February 3, 2023 11:04 PM > > > > On Fri, Feb 03, 2023 at 08:09:30AM +0000, Tian, Kevin wrote: > > > > From: Nicolin Chen <nicolinc@nvidia.com> > > > > Sent: Thursday, February 2, 2023 3:05 PM > > > > > > > > QEMU with this feature should have the vIOMMU maintain a cache of the > > > > guest io page table addresses and assign a unique IOAS to each unique > > > > guest page table. > > > > > > I didn't get why we impose such requirement to userspace. > > > > I read this as implementation guidance for qemu. qemu can do what it > > wants of course > > > > sure but I still didn't get why this is a guidance specific to the > new replace cmd... I think the guidance is about the change to VFIO uAPI where it is now possible to change the domain attached, previously that was not possible Jason
> From: Jason Gunthorpe <jgg@nvidia.com> > Sent: Monday, February 6, 2023 9:26 PM > > On Mon, Feb 06, 2023 at 06:39:29AM +0000, Tian, Kevin wrote: > > > From: Jason Gunthorpe <jgg@nvidia.com> > > > Sent: Friday, February 3, 2023 11:04 PM > > > > > > On Fri, Feb 03, 2023 at 08:09:30AM +0000, Tian, Kevin wrote: > > > > > From: Nicolin Chen <nicolinc@nvidia.com> > > > > > Sent: Thursday, February 2, 2023 3:05 PM > > > > > > > > > > QEMU with this feature should have the vIOMMU maintain a cache of > the > > > > > guest io page table addresses and assign a unique IOAS to each > unique > > > > > guest page table. > > > > > > > > I didn't get why we impose such requirement to userspace. > > > > > > I read this as implementation guidance for qemu. qemu can do what it > > > wants of course > > > > > > > sure but I still didn't get why this is a guidance specific to the > > new replace cmd... > > I think the guidance is about the change to VFIO uAPI where it is now > possible to change the domain attached, previously that was not > possible > that is fine. I just didn't get why the original description emphasized the cache and unique IOAS aspects in Qemu.