All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"Xu, Terrence" <terrence.xu@intel.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"Jiang, Yanting" <yanting.jiang@intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"intel-gvt-dev@lists.freedesktop.org"
	<intel-gvt-dev@lists.freedesktop.org>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>
Subject: Re: [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
Date: Wed, 29 Mar 2023 12:57:44 -0300	[thread overview]
Message-ID: <ZCRf+OdpBVnw5ntC@nvidia.com> (raw)
In-Reply-To: <20230329094944.50abde4e.alex.williamson@redhat.com>

On Wed, Mar 29, 2023 at 09:49:44AM -0600, Alex Williamson wrote:
 
> > We could extend bind_iommufd to return the group id or introduce a
> > new ioctl to query it per dev_id.
> 
> That would be ironic to go to all this trouble to remove groups from
> the API only to have them show up here.

Groups always had to be part of the API for advanced cases like qemu -
the point was to make them a small side bit of information not front
and center in control of everything.

> For example, devices within a group cannot be bound to separate
> iommufds due to lack of isolation, which is handled via DMA ownership,
> but barring DMA aliasing issues, due to conventional PCI buses or
> quirks, cdev could allow devices within the same group to be managed by
> separate IOAS's.  

Maybe some future kernel could do this, the API allows it at least..

> So the group information really isn't enough for
> userspace to infer address space restrictions with cdev anyway.
> 
> Therefore aren't we expecting this to be denied at attach_ioas() and
> QEMU shouldn't be making these sorts of assumptions for cdev anyway?

I guess we could make an API specifically to report same-iommu_domina
information?

I was assuming qemu would use the group for now as I don't see a
likely future when we would relax that restriction.. So I was keeping
a "add it when we need it" attitude here.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	"Liu, Yi L" <yi.l.liu@intel.com>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"robin.murphy@arm.com" <robin.murphy@arm.com>,
	"cohuck@redhat.com" <cohuck@redhat.com>,
	"eric.auger@redhat.com" <eric.auger@redhat.com>,
	"nicolinc@nvidia.com" <nicolinc@nvidia.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
	"chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
	"yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
	"peterx@redhat.com" <peterx@redhat.com>,
	"jasowang@redhat.com" <jasowang@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com" 
	<shameerali.kolothum.thodi@huawei.com>,
	"lulu@redhat.com" <lulu@redhat.com>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	"intel-gvt-dev@lists.freedesktop.org" 
	<intel-gvt-dev@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
	"Hao, Xudong" <xudong.hao@intel.com>,
	"Zhao, Yan Y" <yan.y.zhao@intel.com>,
	"Xu, Terrence" <terrence.xu@intel.com>,
	"Jiang, Yanting" <yanting.jiang@intel.com>
Subject: Re: [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO
Date: Wed, 29 Mar 2023 12:57:44 -0300	[thread overview]
Message-ID: <ZCRf+OdpBVnw5ntC@nvidia.com> (raw)
In-Reply-To: <20230329094944.50abde4e.alex.williamson@redhat.com>

On Wed, Mar 29, 2023 at 09:49:44AM -0600, Alex Williamson wrote:
 
> > We could extend bind_iommufd to return the group id or introduce a
> > new ioctl to query it per dev_id.
> 
> That would be ironic to go to all this trouble to remove groups from
> the API only to have them show up here.

Groups always had to be part of the API for advanced cases like qemu -
the point was to make them a small side bit of information not front
and center in control of everything.

> For example, devices within a group cannot be bound to separate
> iommufds due to lack of isolation, which is handled via DMA ownership,
> but barring DMA aliasing issues, due to conventional PCI buses or
> quirks, cdev could allow devices within the same group to be managed by
> separate IOAS's.  

Maybe some future kernel could do this, the API allows it at least..

> So the group information really isn't enough for
> userspace to infer address space restrictions with cdev anyway.
> 
> Therefore aren't we expecting this to be denied at attach_ioas() and
> QEMU shouldn't be making these sorts of assumptions for cdev anyway?

I guess we could make an API specifically to report same-iommu_domina
information?

I was assuming qemu would use the group for now as I don't see a
likely future when we would relax that restriction.. So I was keeping
a "add it when we need it" attitude here.

Jason

  reply	other threads:[~2023-03-29 15:57 UTC|newest]

Thread overview: 117+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27  9:34 [Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset Yi Liu
2023-03-27  9:34 ` Yi Liu
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 01/10] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset() Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 02/10] vfio/pci: Only check ownership of opened devices in hot reset Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 03/10] vfio/pci: Move the existing hot reset logic to be a helper Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-30 23:39   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:39     ` Jason Gunthorpe
2023-03-30 23:44   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:44     ` Jason Gunthorpe
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 04/10] vfio-iommufd: Add helper to retrieve iommufd_ctx and devid for vfio_device Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-30 23:44   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:44     ` Jason Gunthorpe
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 05/10] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-30 23:47   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:47     ` Jason Gunthorpe
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 06/10] vfio: Refine vfio file kAPIs for vfio PCI hot reset Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-30 23:48   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:48     ` Jason Gunthorpe
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 07/10] vfio: Accpet device file from vfio PCI hot reset path Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-30 23:49   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:49     ` Jason Gunthorpe
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 08/10] vfio/pci: Renaming for accepting device fd in " Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 09/10] vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-30 23:50   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:50     ` Jason Gunthorpe
2023-03-27  9:34 ` [Intel-gfx] [PATCH v2 10/10] vfio/pci: Add VFIO_DEVICE_GET_PCI_HOT_RESET_GROUP_INFO Yi Liu
2023-03-27  9:34   ` Yi Liu
2023-03-27 19:26   ` [Intel-gfx] " Alex Williamson
2023-03-27 19:26     ` Alex Williamson
2023-03-27 20:40     ` [Intel-gfx] " Alex Williamson
2023-03-27 20:40       ` Alex Williamson
2023-03-28  3:45       ` [Intel-gfx] " Liu, Yi L
2023-03-28  3:45         ` Liu, Yi L
2023-03-28  3:32     ` [Intel-gfx] " Liu, Yi L
2023-03-28  3:32       ` Liu, Yi L
2023-03-28  6:19       ` [Intel-gfx] " Tian, Kevin
2023-03-28  6:19         ` Tian, Kevin
2023-03-28 14:25         ` [Intel-gfx] " Alex Williamson
2023-03-28 14:25           ` Alex Williamson
2023-03-28 14:38           ` [Intel-gfx] " Liu, Yi L
2023-03-28 14:38             ` Liu, Yi L
2023-03-28 14:46             ` [Intel-gfx] " Alex Williamson
2023-03-28 14:46               ` Alex Williamson
2023-03-28 15:00               ` [Intel-gfx] " Liu, Yi L
2023-03-28 15:00                 ` Liu, Yi L
2023-03-28 15:18                 ` [Intel-gfx] " Alex Williamson
2023-03-28 15:18                   ` Alex Williamson
2023-03-28 15:45                   ` [Intel-gfx] " Liu, Yi L
2023-03-28 15:45                     ` Liu, Yi L
2023-03-28 16:00                     ` [Intel-gfx] " Alex Williamson
2023-03-28 16:00                       ` Alex Williamson
2023-03-29  3:13                       ` [Intel-gfx] " Liu, Yi L
2023-03-29  3:13                         ` Liu, Yi L
2023-03-29  9:41                         ` [Intel-gfx] " Tian, Kevin
2023-03-29  9:41                           ` Tian, Kevin
2023-03-29 15:49                           ` [Intel-gfx] " Alex Williamson
2023-03-29 15:49                             ` Alex Williamson
2023-03-29 15:57                             ` Jason Gunthorpe [this message]
2023-03-29 15:57                               ` Jason Gunthorpe
2023-03-30  1:17                               ` [Intel-gfx] " Tian, Kevin
2023-03-30  1:17                                 ` Tian, Kevin
2023-03-30 22:38                                 ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 22:38                                   ` Jason Gunthorpe
2023-03-30 12:48                             ` [Intel-gfx] " Liu, Yi L
2023-03-30 12:48                               ` Liu, Yi L
2023-03-30 12:56                               ` [Intel-gfx] " Liu, Yi L
2023-03-30 12:56                                 ` Liu, Yi L
2023-03-30 22:44                               ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 22:44                                 ` Jason Gunthorpe
2023-03-30 23:05                                 ` [Intel-gfx] " Alex Williamson
2023-03-30 23:05                                   ` Alex Williamson
2023-03-30 23:18                                   ` [Intel-gfx] " Jason Gunthorpe
2023-03-30 23:18                                     ` Jason Gunthorpe
2023-03-29 15:50                           ` [Intel-gfx] " Jason Gunthorpe
2023-03-29 15:50                             ` Jason Gunthorpe
2023-03-30  1:10                             ` [Intel-gfx] " Tian, Kevin
2023-03-30  1:10                               ` Tian, Kevin
2023-03-30  1:33                               ` [Intel-gfx] " Tian, Kevin
2023-03-30  1:33                                 ` Tian, Kevin
2023-03-28 16:29                   ` [Intel-gfx] " Jason Gunthorpe
2023-03-28 16:29                     ` Jason Gunthorpe
2023-03-28 19:09                     ` [Intel-gfx] " Alex Williamson
2023-03-28 19:09                       ` Alex Williamson
2023-03-28 19:22                       ` [Intel-gfx] " Jason Gunthorpe
2023-03-28 19:22                         ` Jason Gunthorpe
2023-03-28 12:40   ` [Intel-gfx] " Jason Gunthorpe
2023-03-28 12:40     ` Jason Gunthorpe
2023-03-28 14:45     ` [Intel-gfx] " Liu, Yi L
2023-03-28 14:45       ` Liu, Yi L
2023-03-27 11:55 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce new methods for verifying ownership in vfio PCI hot reset (rev2) Patchwork
2023-03-27 12:04 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-27 16:12 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-03-30 15:33 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Introduce new methods for verifying ownership in vfio PCI hot reset (rev3) Patchwork
2023-03-31  3:14 ` [Intel-gfx] [PATCH v2 00/10] Introduce new methods for verifying ownership in vfio PCI hot reset Jiang, Yanting
2023-03-31  3:14   ` Jiang, Yanting
2023-03-31 13:24   ` [Intel-gfx] " Alex Williamson
2023-03-31 13:24     ` Alex Williamson
2023-04-03  2:04     ` [Intel-gfx] " Jiang, Yanting
2023-04-03  2:04       ` Jiang, Yanting
2023-03-31  5:01 ` [Intel-gfx] " Jiang, Yanting
2023-03-31  5:01   ` Jiang, Yanting
2023-03-31 17:27 ` [Intel-gfx] " Xu, Terrence
2023-03-31 17:27   ` Xu, Terrence
2023-03-31 17:49   ` [Intel-gfx] " Alex Williamson
2023-03-31 17:49     ` Alex Williamson
2023-04-01  9:15     ` [Intel-gfx] " Xu, Terrence
2023-04-01  9:15       ` Xu, Terrence
2023-04-01 13:08       ` [Intel-gfx] " Alex Williamson

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=ZCRf+OdpBVnw5ntC@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=chao.p.peng@linux.intel.com \
    --cc=cohuck@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jasowang@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=lulu@redhat.com \
    --cc=mjrosato@linux.ibm.com \
    --cc=nicolinc@nvidia.com \
    --cc=peterx@redhat.com \
    --cc=robin.murphy@arm.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=terrence.xu@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=yan.y.zhao@intel.com \
    --cc=yanting.jiang@intel.com \
    --cc=yi.l.liu@intel.com \
    --cc=yi.y.sun@linux.intel.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.