> From: Tian, Kevin
> Sent: Tuesday, January 16, 2024 8:46 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, January 16, 2024 12:31 AM
> >
> > On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
> >
> > > > Well, for instance, when you ins
> From: Jason Gunthorpe
> Sent: Tuesday, January 16, 2024 12:31 AM
>
> On Tue, Jan 09, 2024 at 10:11:23AM +0800, Yan Zhao wrote:
>
> > > Well, for instance, when you install pages into the KVM the hypervisor
> > > will have taken kernel memory, then zero'd it with cachable writes,
> > > however
> From: Zhao, Yan Y
> Sent: Thursday, December 14, 2023 6:35 PM
>
> - For host non-MMIO pages,
> * virtio guest frontend and host backend driver should be synced to use
> the same memory type to map a buffer. Otherwise, there will be
> potential problem for incorrect memory data. But th
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> These contexts are sleepable, so use the proper annotation. The
> GFP_ATOMIC
> was added mechanically in the prior patches.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Flow it down to alloc_pgtable_page() via pfn_to_dma_pte() and
> __domain_mapping().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> This is eventually called by iommufd through intel_iommu_map_pages() and
> it should not be forced to atomic. Push the GFP_ATOMIC to all callers.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> iommufd follows the same design as KVM and uses memory cgroups to limit
> the amount of kernel memory a iommufd file descriptor can pin down. The
> various internal data structures already use GFP_KERNEL_ACCOUNT.
>
> However,
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Change the sg_alloc_table_from_pages() allocation that was hardwired to
> GFP_KERNEL to use the gfp parameter like the other allocations in this
> function.
>
> Auditing says this is never called from an atomic context, so it
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> Follow the pattern for iommu_map() and remove iommu_map_sg_atomic().
>
> This allows __iommu_dma_alloc_noncontiguous() to use a GFP_KERNEL
> allocation here, based on the provided gfp flags.
>
> Signed-off-by: Jason Gunthorp
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> There is only one call site and it can now just pass the GFP_ATOMIC to the
> normal iommu_map().
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, January 19, 2023 2:01 AM
>
> The internal mechanisms support this, but instead of exposting the gfp to
> the caller it wrappers it into iommu_map() and iommu_map_atomic()
>
> Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
>
> Signed-of
> From: Jason Gunthorpe
> Sent: Tuesday, January 17, 2023 9:30 PM
>
> On Tue, Jan 17, 2023 at 03:35:08AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Saturday, January 7, 2023 12:43 AM
> > >
> > > @@ -2676,7 +2676,7 @@ st
> From: Jason Gunthorpe
> Sent: Saturday, January 7, 2023 12:43 AM
>
> @@ -2368,7 +2372,7 @@ static int iommu_domain_identity_map(struct
> dmar_domain *domain,
>
> return __domain_mapping(domain, first_vpfn,
> first_vpfn, last_vpfn - first_vpfn + 1,
> -
> From: Jason Gunthorpe
> Sent: Saturday, January 7, 2023 12:43 AM
>
> @@ -2676,7 +2676,7 @@ static int copy_context_table(struct intel_iommu
> *iommu,
> if (!old_ce)
> goto out;
>
> - new_ce = alloc_pgtable_page(iommu->node
> From: Jason Gunthorpe
> Sent: Friday, November 11, 2022 1:21 AM
>
> On Thu, Nov 10, 2022 at 03:11:16AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, November 8, 2022 8:53 AM
> > >
> > > +
> > > +int vfio_
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> If the VFIO container is compiled out, give a kconfig option for iommufd
> to provide the miscdev node with the same name and permissions as vfio
> uses.
>
> The compatibility node supports the same ioctls as VFIO and automati
> From: Jason Gunthorpe
> Sent: Thursday, November 10, 2022 3:53 AM
>
> On Wed, Nov 09, 2022 at 10:18:09AM -0700, Alex Williamson wrote:
>
> > DPDK supports no-iommu mode.
>
> Er? Huh? How? I thought no-iommu was for applications that didn't do
> DMA? How is DPDK getting packets in/out without
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> The miscdev is in container.c, so should these related MODULE_ALIAS
> statements. This is necessary for the next patch to be able to fully
> disable /dev/vfio/vfio.
>
> Fixes: cdc71fe4ecbf ("vfio: Move container code into
> dr
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
> consist of all the mdev drivers.
>
> Like the physical drivers, support for iommufd is provided by the driver
> supplying the correct standard ops. Pro
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 1:52 AM
>
> On Tue, Nov 08, 2022 at 03:41:25PM +0800, Yi Liu wrote:
> > On 2022/11/8 14:10, Nicolin Chen wrote:
> > > On Mon, Nov 07, 2022 at 08:52:51PM -0400, Jason Gunthorpe wrote:
> > >
> > > > @@ -795,6 +800,10 @@ static int vfio_dev
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> +
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + /*
> + * I
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> This makes VFIO_GROUP_SET_CONTAINER accept both a vfio container FD
> and an
> iommufd.
>
> In iommufd mode an IOAS will exist after the SET_CONTAINER, but it will
> not be attached to any groups.
>
> For VFIO this means that
> From: Jason Gunthorpe
> Sent: Tuesday, November 8, 2022 8:53 AM
>
> iommufd doesn't establish the iommu_domains until after the device FD is
> opened, even if the container has been set. This design is part of moving
> away from the group centric iommu APIs.
>
> This is fine, except that the n
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 9:11 PM
>
> > If all agree that VFIO_CONTAINER=n is a process to evolve, does it make
> > more sense to remove this patch from this series i.e. let it buried in
> > VFIO_CONTAINER=y for now? Then resolve it in a follow up patch if
> > no
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 8:48 PM
>
> On Wed, Nov 09, 2022 at 09:03:52AM +, Tian, Kevin wrote:
> > every mail in this series is shown thrice in lore:
> >
> > https://lore.kernel.org/all/0-v2-65016290f146+33e-
> vfio_iommufd
every mail in this series is shown thrice in lore:
https://lore.kernel.org/all/0-v2-65016290f146+33e-vfio_iommufd_...@nvidia.com/
not sure what caused it but it's annoying to check the conversation there.
the iommufd series doesn't have this problem.
> From: Jason Gunthorpe
> Sent: Tuesday, No
> From: Jason Gunthorpe
> Sent: Wednesday, November 9, 2022 9:05 AM
>
> On Tue, Nov 08, 2022 at 03:55:20PM -0700, Alex Williamson wrote:
>
> > > > So why exactly isn't this an issue for VDPA? Are we just burying our
> > > > head in the sand that such platforms exists and can still be useful
> >
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 8:49 PM
> > > ---
> > > drivers/gpu/drm/i915/gvt/kvmgt.c | 3 +
> > > drivers/s390/cio/vfio_ccw_ops.c | 3 +
> > > drivers/s390/crypto/vfio_ap_ops.c | 3 +
> > > drivers/vfio/container.c | 108 ++--
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 7:51 PM
>
> On Tue, Nov 01, 2022 at 02:19:04AM -0700, Nicolin Chen wrote:
> > On Tue, Nov 01, 2022 at 08:09:52AM +, Tian, Kevin wrote:
> >
> > > > From: Jason Gunthorpe
> > >
> From: Jason Gunthorpe
> Sent: Tuesday, November 1, 2022 8:26 PM
> And this:
>
> /*
>* If the device does not have
> IOMMU_CAP_ENFORCE_CACHE_COHERENCY then
>* any domain later attached to it will also not support it. If the cap
>* is set then the iommu_domain eventu
> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
>
> With the "mess" sorted out, we should be able to inline the
> vfio_free_device call introduced by commit cb9ff3f3b84c
> ("vfio: Add helpers for unifying vfio_device life cycle")
> and remove them from driver release callbacks.
>
> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
>
> Now that we have a reasonable separation of structs that follow
> the subchannel and mdev lifecycles, there's no reason we can't
> call the official vfio_alloc_device routine for our private data,
> and behave like everyone else.
> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
>
> There's enough separation between the parent and private structs now,
> that it is fine to remove the release completion hack.
>
> Signed-off-by: Eric Farman
Reviewed-by: Kevin Tian
> From: Eric Farman
> Sent: Thursday, October 20, 2022 12:22 AM
>
> @@ -101,15 +101,20 @@ static int vfio_ccw_mdev_probe(struct
> mdev_device *mdev)
> {
> struct subchannel *sch = to_subchannel(mdev->dev.parent);
> struct vfio_ccw_parent *parent = dev_get_drvdata(&sch->dev);
> -
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> if VFIO
> +config VFIO_CONTAINER
> + bool "Support for the VFIO container /dev/vfio/vfio"
> + select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM ||
> ARM64)
> + default y
> + help
> + The VFIO contai
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> Emulated VFIO devices are calling vfio_register_emulated_iommu_dev() and
> consist of all the mdev drivers.
>
> Like the physical drivers, support for iommufd is provided by the driver
> supplying the correct correct standar
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +{
> + u32 ioas_id;
> + u32 device_id;
> + int ret;
> +
> + lockdep_assert_held(&vdev->dev_set->lock);
> +
> + /*
> + * If
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:51 AM
>
> menuconfig VFIO
> tristate "VFIO Non-Privileged userspace driver framework"
> select IOMMU_API
> + depends on IOMMUFD || !IOMMUFD
Out of curiosity. What is the meaning of this dependency claim?
> @@ -717,12
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> iommufd doesn't establish the iommu_domains until after the device FD is
> opened, even if the container has been set. This design is part of moving
> away from the group centric iommu APIs.
>
> This is fine, except that the
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> These functions don't really assign anything anymore, they just increment
> some refcounts and do a sanity check. Call them
> vfio_group_[un]use_container()
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> +err_container:
> + vfio_device_unassign_container(device);
> err_module_put:
> device->kvm = NULL;
err_module_put should be moved after nullifying device->kvm.
otherwise it looks good to me:
Reviewed-by: Kevin
> From: Jason Gunthorpe
> Sent: Wednesday, October 26, 2022 2:17 AM
>
> This error unwind is getting complicated. Move all the code into two
> pair'd function. The functions should be called when the open_count == 1
> after incrementing/before decrementing.
>
> Signed-off-by: Jason Gunthorpe
R
> From: Wang, Zhi A
> Sent: Wednesday, October 19, 2022 5:41 PM
>
> On 10/6/22 18:31, Alex Williamson wrote:
> > On Thu, 6 Oct 2022 08:37:09 -0300
> > Jason Gunthorpe wrote:
> >
> >> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> >>> We can't have a .remove callback that does
> From: Alex Williamson
> Sent: Friday, October 7, 2022 2:31 AM
>
> On Thu, 6 Oct 2022 08:37:09 -0300
> Jason Gunthorpe wrote:
>
> > On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
> > > We can't have a .remove callback that does nothing, this breaks
> > > removing the device w
> From: Alex Williamson
> Sent: Friday, September 30, 2022 2:24 AM
>
> On Thu, 29 Sep 2022 14:49:56 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > > Hi Kevin,
> > >
> > > This introduced the regression discovered here:
> > >
> > >
> htt
> From: Jason Gunthorpe
> Sent: Friday, September 30, 2022 1:49 AM
>
> When converting to directly create the vfio_device the mdev driver has to
> put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> vfio_unregister_group_dev() in the remove.
>
> This was missed for gvt, add it
> From: Jason Gunthorpe
> Sent: Thursday, September 22, 2022 12:10 AM
>
> On Tue, Sep 20, 2022 at 10:55:40PM +, Tian, Kevin wrote:
> > > From: Alex Williamson
> > > Sent: Wednesday, September 21, 2022 4:27 AM
> > >
> > > On Fri, 9
> From: Alex Williamson
> Sent: Wednesday, September 21, 2022 4:27 AM
>
> On Fri, 9 Sep 2022 18:22:47 +0800
> Kevin Tian wrote:
>
> > From: Yi Liu
> >
> > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > sysfs path of the parent, indicating the device is bound to a v
> From: Alex Williamson
> Sent: Wednesday, September 21, 2022 3:17 AM
>
> On Fri, 9 Sep 2022 18:22:38 +0800
> Kevin Tian wrote:
>
> > From: Yi Liu
> >
> > and manage available ports inside @init/@release.
> >
> > Signed-off-by: Yi Liu
> > Signed-off-by: Kevin Tian
> > Reviewed-by: Jason Gun
> From: Ethan Zhao
> Sent: Friday, September 9, 2022 4:24 PM
>
> Hi, Kevin,
>
> 在 2022/9/9 18:22, Kevin Tian 写道:
> > The idea is to let vfio core manage the vfio_device life cycle instead
> > of duplicating the logic cross drivers. This is also a preparatory
> > step for adding struct device int
> From: Jason Gunthorpe
> Sent: Thursday, September 8, 2022 8:37 PM
>
> On Thu, Sep 08, 2022 at 11:39:07AM +0200, Eric Auger wrote:
>
> > >> I am not totally clear about remaining 'struct device *dev;' in
> > >> vfio_device struct. I see it used in some places. Is it supposed to
> > >> disappear
> From: Eric Farman
> Sent: Friday, September 9, 2022 4:51 AM
>
> On Thu, 2022-09-08 at 07:19 +, Tian, Kevin wrote:
> > ping @Eric Farman.
> >
> > ccw is the only tricky player in this series. Please help take a look
> > in case of
> > any oversight h
ping @Eric Farman.
ccw is the only tricky player in this series. Please help take a look in case of
any oversight here.
> From: Tian, Kevin
> Sent: Thursday, September 1, 2022 10:38 PM
>
> ccw is the only exception which cannot use vfio_alloc_device() because
> its private devi
> From: Eric Auger
> Sent: Thursday, September 8, 2022 3:28 AM
> > +/*
> > + * Alloc and initialize vfio_device so it can be registered to vfio
> > + * core.
> > + *
> > + * Drivers should use the wrapper vfio_alloc_device() for allocation.
> > + * @size is the size of the structure to be allocate
> From: Christoph Hellwig
> Sent: Tuesday, September 6, 2022 5:42 PM
>
> What is the point? This adds indirect calls, and actually creates
> more boilerplate code in the drivers. i.g. when using this code there
> is more, and harder to read code.
The point is to align with struct device life cy
> From: Tian, Kevin
> Sent: Thursday, September 1, 2022 10:38 PM
>
> diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev
> b/Documentation/ABI/testing/sysfs-devices-vfio-dev
> new file mode 100644
> index ..e21424fd9666
> --- /dev/null
> +++
> From: Tian, Kevin
> Sent: Thursday, September 1, 2022 10:38 PM
>
> +static const struct vfio_device_ops vfio_amba_ops= {
Above missed a space after vfio_amba_ops.
> From: Alex Williamson
> Sent: Thursday, September 1, 2022 1:15 AM
>
> On Wed, 31 Aug 2022 06:10:51 +0000
> "Tian, Kevin" wrote:
>
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, August 31, 2022 7:53 AM
> > >
> > >
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:35 AM
>
> On Sun, Aug 28, 2022 at 01:10:22AM +0800, Kevin Tian wrote:
>
> > Kevin Tian (6):
> > vfio: Add helpers for unifying vfio_device life cycle
> > drm/i915/gvt: Use the new device life cycle helpers
> > vfio/platform: Use
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:32 AM
>
> On Sun, Aug 28, 2022 at 01:10:37AM +0800, Kevin Tian wrote:
> > From: Yi Liu
> >
> > and replace kref. With it a 'vfio-dev/vfioX' node is created under the
> > sysfs path of the parent, indicating the device is bound to a vfi
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 8:23 AM
>
> On Sun, Aug 28, 2022 at 01:10:32AM +0800, Kevin Tian wrote:
> > From: Yi Liu
> >
> > Export symbol of vfio_release_device_set() so fsl-mc @init can handle
> > the error path cleanly instead of assuming certain vfio core API c
> From: Jason Gunthorpe
> Sent: Wednesday, August 31, 2022 7:53 AM
>
> On Tue, Aug 30, 2022 at 04:18:38PM -0600, Alex Williamson wrote:
> > On Sun, 28 Aug 2022 01:10:37 +0800
> > Kevin Tian wrote:
> >
> > > From: Yi Liu
> > >
> > > and replace kref. With it a 'vfio-dev/vfioX' node is created un
> From: Jason Gunthorpe
> Sent: Tuesday, August 30, 2022 11:10 PM
>
> On Tue, Aug 30, 2022 at 09:42:42AM -0400, Anthony Krowiak wrote:
>
> > > +/*
> > > + * Alloc and initialize vfio_device so it can be registered to vfio
> > > + * core.
> > > + *
> > > + * Drivers should use the wrapper vfio_al
nst-variable]
drivers/vfio/platform/vfio_platform_common.c:608:37: warning: unused variable
'vfio_platform_ops' [-Wunused-const-variable]
> From: Tian, Kevin
> Sent: Sunday, August 28, 2022 1:10 AM
>
> The idea is to let vfio core manage the vfio_device life cycle instead
> of duplica
This missed a Suggested-by from Jason. Will add in next version.
> From: Tian, Kevin
> Sent: Sunday, August 28, 2022 1:11 AM
>
> ccw is the only exception which cannot use vfio_alloc_device() because
> its private device structure is designed to serve both mdev and parent.
>
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> Most of the callers of vfio_pin_pages() want "struct page *" and the
> low-level mm code to pin pages returns a list of "struct page *" too.
> So there's no gain in converting "struct page *" to PFN in between.
>
> Replace the outp
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> Following the updated vfio_pin/unpin_pages(), use the simpler "iova".
>
> Signed-off-by: Nicolin Chen
Reviewed-by: Kevin Tian
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
> /*
> - * Pin a set of guest PFNs and return their associated host PFNs for local
> + * Pin contiguous guest pages and return their associated host pages for
> local
can we replace 'guest' with 'user'?
> * domain only.
> * @device
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> There's only one caller that checks its return value with a WARN_ON_ONCE,
> while all other callers do not check return value at all. So simplify the
> API to return void by embedding similar WARN_ON_ONCEs.
While this change keeps
> From: Nicolin Chen
> Sent: Wednesday, July 6, 2022 2:28 PM
>
> This is a preparatory series for IOMMUFD v2 patches. It prepares for
> replacing vfio_iommu_type1 implementations of vfio_pin/unpin_pages()
> with IOMMUFD version.
>
> There's a gap between these two versions: the vfio_iommu_type1 v
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:27 PM
>
> On Wed, Jun 08, 2022 at 03:47:12AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Wednesday, June 8, 2022 7:02 AM
> > >
> > > Instead of bouncing the f
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:02 AM
>
> Instead of bouncing the function call to the driver op through a blocking
> notifier just have the iommu layer call it directly.
>
> Register each device that is being attached to the iommu with the lower
> driver which then thre
> From: Jason Gunthorpe
> Sent: Wednesday, June 8, 2022 7:02 AM
>
> Instead of having drivers register the notifier with explicit code just
> have them provide a dma_unmap callback op in their driver ops and rely on
> the core code to wire it up.
>
> Suggested-by: Christoph Hellwig
> Reviewed-by
> From: Jason Gunthorpe
> Sent: Saturday, April 23, 2022 2:00 AM
>
> On Fri, Apr 22, 2022 at 01:50:00AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Friday, April 22, 2022 12:29 AM
> > >
> > > Every caller has a readily
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> When the open_device() op is called the container_users is incremented and
> held incremented until close_device(). Thus, so long as drivers call
> functions within their open_device()/close_device() region they do not
> need to
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Now that callers have been updated to use the vfio_device APIs the driver
> facing group interface is no longer used, delete it:
>
> - vfio_group_get_external_user_from_dev()
> - vfio_group_pin_pages()
> - vfio_group_unpin_pages
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> reason to use a group interface here, kvmgt has easy access to a
> vfio_device.
>
> Delete kvmgt_vdev::vfio_group since these calls were the last users
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> Every caller has a readily available vfio_device pointer, use that instead
> of passing in a generic struct device. The struct vfio_device already
> contains the group we need so this avoids complexity, extra refcountings,
> and
> From: Jason Gunthorpe
> Sent: Friday, April 22, 2022 12:29 AM
>
> All callers have a struct vfio_device trivially available, pass it in
> directly and avoid calling the expensive vfio_group_get_from_dev().
>
> To support the unconverted kvmgt mdev driver add
> mdev_legacy_get_vfio_device() whic
> From: Jason Gunthorpe
> Sent: Friday, April 15, 2022 8:07 PM
>
> On Fri, Apr 15, 2022 at 02:32:08AM +, Tian, Kevin wrote:
>
> > While it's a welcomed fix is it actually related to this series? The point
> > of this patch is that those functions are called
> From: Jason Gunthorpe
> Sent: Thursday, April 14, 2022 10:22 PM
>
> On Thu, Apr 14, 2022 at 09:51:49AM -0400, Matthew Rosato wrote:
> > On 4/12/22 11:53 AM, Jason Gunthorpe wrote:
> > > When the open_device() op is called the container_users is incremented
> and
> > > held incremented until clo
> From: Wang, Zhi A
> Sent: Thursday, April 14, 2022 5:09 AM
>
> > Or is it that only the page table levels themselves are GFNs and the
> > actual DMA's are IOVA? The unclear mixing of GFN as IOVA in the code
> > makes it inscrutible.
> >
>
> No. Even the HW is capable of controlling the level o
> From: Jason Gunthorpe
> Sent: Thursday, April 14, 2022 7:12 AM
>
> On Wed, Apr 13, 2022 at 09:08:40PM +, Wang, Zhi A wrote:
> > On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> > > On Wed, Apr 13, 2022 at 07:17:52PM +, Wang, Zhi A wrote:
> > >> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> >
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> The driver core standard is to pass in the properly typed object, the
> properly typed attribute and the buffer data. It stems from the root
> kobject method:
>
> ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> The kobj here is a type-erased version of mdev_type, which is already
> stored in the struct mdev_device being passed in. It was only ever used to
> compute the type_group_id, which is now extracted directly from the mdev.
>
>
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the
> supported_type_groups array, so the type_group_id is also the index into
> gvt->types. Use it directly and remove the string matching.
>
> Signed-off-by: Jason G
> From: Jason Gunthorpe
> Sent: Wednesday, March 24, 2021 1:56 AM
>
> At some point there may have been some reason for this weird split in this
> driver, but today only the VFIO side is actually implemented.
>
> However, it got messed up at some point and mdev code was put in gvt.c and
> is pret
> From: Auger Eric
> Sent: Monday, March 15, 2021 3:52 PM
> To: Christoph Hellwig
> Cc: k...@vger.kernel.org; Will Deacon ; linuxppc-
> d...@lists.ozlabs.org; dri-devel@lists.freedesktop.org; Li Yang
> ; io...@lists.linux-foundation.org;
>
> Hi Christoph,
>
> On 3/14/21 4:58 PM, Christoph Hellwi
> From: Chia-I Wu
> Sent: Saturday, February 22, 2020 2:21 AM
>
> On Fri, Feb 21, 2020 at 7:59 AM Sean Christopherson
> wrote:
> >
> > On Thu, Feb 20, 2020 at 09:39:05PM -0800, Tian, Kevin wrote:
> > > > From: Chia-I Wu
> > > > Sent: Friday,
> From: Chia-I Wu
> Sent: Friday, February 21, 2020 12:51 PM
>
> (resend because gmail did not format to plain text...)
>
> On Thu, Feb 20, 2020 at 8:45 PM Chia-I Wu wrote:
> >
> >
> >
> > On Thu, Feb 20, 2020 at 4:23 PM Tian, Kevin wrote:
> &
> From: Chia-I Wu
> Sent: Friday, February 21, 2020 6:24 AM
>
> On Wed, Feb 19, 2020 at 6:38 PM Tian, Kevin wrote:
> >
> > > From: Tian, Kevin
> > > Sent: Thursday, February 20, 2020 10:05 AM
> > >
> > > > From: Chia-I Wu
> > >
> From: Tian, Kevin
> Sent: Thursday, February 20, 2020 10:05 AM
>
> > From: Chia-I Wu
> > Sent: Thursday, February 20, 2020 3:37 AM
> >
> > On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote:
> > >
> > > > From: Paolo Bonzi
> From: Chia-I Wu
> Sent: Thursday, February 20, 2020 3:18 AM
>
> On Wed, Feb 19, 2020 at 2:00 AM Tian, Kevin wrote:
> >
> > > From: Chia-I Wu
> > > Sent: Saturday, February 15, 2020 5:15 AM
> > >
> > > On Fri, Feb 14, 2020 at 2:26 AM Pao
> From: Chia-I Wu
> Sent: Thursday, February 20, 2020 3:37 AM
>
> On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote:
> >
> > > From: Paolo Bonzini
> > > Sent: Wednesday, February 19, 2020 12:29 AM
> > >
> > > On 14/02/20 23:03, Sean Christop
> From: Chia-I Wu
> Sent: Saturday, February 15, 2020 5:15 AM
>
> On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini wrote:
> >
> > On 13/02/20 23:18, Chia-I Wu wrote:
> > >
> > > The bug you mentioned was probably this one
> > >
> > > https://bugzilla.kernel.org/show_bug.cgi?id=104091
> >
> > Yes,
> From: Paolo Bonzini
> Sent: Wednesday, February 19, 2020 12:29 AM
>
> On 14/02/20 23:03, Sean Christopherson wrote:
> >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote:
> >>> AFAICT, it is currently allowed on ARM (verified) and AMD (not
> >>> verified, but svm_get_mt_mask returns 0 which supp
> From: Jason Wang
> Sent: Wednesday, September 25, 2019 8:45 PM
>
>
> On 2019/9/25 下午5:09, Tian, Kevin wrote:
> >> From: Jason Wang [mailto:jasow...@redhat.com]
> >> Sent: Tuesday, September 24, 2019 9:54 PM
> >>
> >> This patch implements basi
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Tuesday, September 24, 2019 9:54 PM
>
> This patch implements basic support for mdev driver that supports
> virtio transport for kernel virtio driver.
>
> Signed-off-by: Jason Wang
> ---
> include/linux/mdev.h| 2 +
> include/lin
> From: Alex Williamson
> Sent: Wednesday, September 25, 2019 7:07 AM
>
> On Tue, 24 Sep 2019 21:53:29 +0800
> Jason Wang wrote:
>
> > Currently, except for the create and remove, the rest of
> > mdev_parent_ops is designed for vfio-mdev driver only and may not help
> > for kernel mdev driver. W
1 - 100 of 108 matches
Mail list logo
