From: Matthew Brost <matthew.brost@intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Michał Winiarski" <michal.winiarski@intel.com>,
"Alex Williamson" <alex.williamson@redhat.com>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Yishai Hadas" <yishaih@nvidia.com>,
"Kevin Tian" <kevin.tian@intel.com>,
"Shameer Kolothum" <shameerali.kolothum.thodi@huawei.com>,
intel-xe@lists.freedesktop.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, dri-devel@lists.freedesktop.org,
"Michal Wajdeczko" <michal.wajdeczko@intel.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Lukasz Laguna" <lukasz.laguna@intel.com>
Subject: Re: [PATCH 26/26] vfio/xe: Add vendor-specific vfio_pci driver for Intel graphics
Date: Tue, 21 Oct 2025 16:14:30 -0700 [thread overview]
Message-ID: <aPgT1u1YO3C3YozC@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <20251021230328.GA21554@ziepe.ca>
On Tue, Oct 21, 2025 at 08:03:28PM -0300, Jason Gunthorpe wrote:
> On Sat, Oct 11, 2025 at 09:38:47PM +0200, Michał Winiarski wrote:
> > + /*
> > + * "STOP" handling is reused for "RUNNING_P2P", as the device doesn't have the capability to
> > + * selectively block p2p DMA transfers.
> > + * The device is not processing new workload requests when the VF is stopped, and both
> > + * memory and MMIO communication channels are transferred to destination (where processing
> > + * will be resumed).
> > + */
> > + if ((cur == VFIO_DEVICE_STATE_RUNNING && new == VFIO_DEVICE_STATE_STOP) ||
> > + (cur == VFIO_DEVICE_STATE_RUNNING && new == VFIO_DEVICE_STATE_RUNNING_P2P)) {
> > + ret = xe_sriov_vfio_stop(xe_vdev->pf, xe_vdev->vfid);
>
> This comment is not right, RUNNING_P2P means the device can still
> receive P2P activity on it's BAR. Eg a GPU will still allow read/write
> to its framebuffer.
>
> But it is not initiating any new transactions.
>
> > +static void xe_vfio_pci_migration_init(struct vfio_device *core_vdev)
> > +{
> > + struct xe_vfio_pci_core_device *xe_vdev =
> > + container_of(core_vdev, struct xe_vfio_pci_core_device, core_device.vdev);
> > + struct pci_dev *pdev = to_pci_dev(core_vdev->dev);
> > +
> > + if (!xe_sriov_vfio_migration_supported(pdev->physfn))
> > + return;
> > +
> > + /* vfid starts from 1 for xe */
> > + xe_vdev->vfid = pci_iov_vf_id(pdev) + 1;
> > + xe_vdev->pf = pdev->physfn;
>
> No, this has to use pci_iov_get_pf_drvdata, and this driver should
> never have a naked pf pointer flowing around.
>
> The entire exported interface is wrongly formed:
>
> +bool xe_sriov_vfio_migration_supported(struct pci_dev *pdev);
> +int xe_sriov_vfio_wait_flr_done(struct pci_dev *pdev, unsigned int vfid);
> +int xe_sriov_vfio_stop(struct pci_dev *pdev, unsigned int vfid);
> +int xe_sriov_vfio_run(struct pci_dev *pdev, unsigned int vfid);
> +int xe_sriov_vfio_stop_copy_enter(struct pci_dev *pdev, unsigned int vfid);
>
> None of these should be taking in a naked pci_dev, it should all work
> on whatever type the drvdata is.
This seems entirely backwards. Why would the Xe module export its driver
structure to the VFIO module? That opens up potential vectors for
abuse—for example, the VFIO module accessing internal Xe device
structures. In my opinion, it's much cleaner to keep interfaces between
modules as opaque / generic as possible.
Matt
>
> And this gross thing needs to go away too:
>
> > + if (pdev->is_virtfn && strcmp(pdev->physfn->dev.driver->name, "xe") == 0)
> > + xe_vfio_pci_migration_init(core_vdev);
>
> Jason
next prev parent reply other threads:[~2025-10-21 23:14 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-11 19:38 [PATCH 00/26] vfio/xe: Add driver variant for Xe VF migration Michał Winiarski
2025-10-11 19:38 ` [PATCH 01/26] drm/xe/pf: Remove GuC version check for migration support Michał Winiarski
2025-10-12 18:31 ` Michal Wajdeczko
2025-10-20 14:46 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 02/26] drm/xe: Move migration support to device-level struct Michał Winiarski
2025-10-12 18:58 ` Michal Wajdeczko
2025-10-20 14:48 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 03/26] drm/xe/pf: Add save/restore control state stubs and connect to debugfs Michał Winiarski
2025-10-12 20:09 ` Michal Wajdeczko
2025-10-11 19:38 ` [PATCH 04/26] drm/xe/pf: Extract migration mutex out of its struct Michał Winiarski
2025-10-12 19:08 ` Matthew Brost
2025-10-20 14:50 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 05/26] drm/xe/pf: Add data structures and handlers for migration rings Michał Winiarski
2025-10-12 21:06 ` Michal Wajdeczko
2025-10-20 14:56 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 06/26] drm/xe/pf: Add helpers for migration data allocation / free Michał Winiarski
2025-10-12 19:12 ` Matthew Brost
2025-10-21 0:26 ` Michał Winiarski
2025-10-13 10:15 ` Michal Wajdeczko
2025-10-21 0:01 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 07/26] drm/xe/pf: Add support for encap/decap of bitstream to/from packet Michał Winiarski
2025-10-11 22:28 ` kernel test robot
2025-10-13 10:46 ` Michal Wajdeczko
2025-10-21 0:25 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 08/26] drm/xe/pf: Add minimalistic migration descriptor Michał Winiarski
2025-10-11 22:52 ` kernel test robot
2025-10-13 10:56 ` Michal Wajdeczko
2025-10-21 0:31 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 09/26] drm/xe/pf: Expose VF migration data size over debugfs Michał Winiarski
2025-10-12 19:15 ` Matthew Brost
2025-10-21 0:37 ` Michał Winiarski
2025-10-13 11:04 ` Michal Wajdeczko
2025-10-21 0:42 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 10/26] drm/xe: Add sa/guc_buf_cache sync interface Michał Winiarski
2025-10-12 18:06 ` Matthew Brost
2025-10-21 0:45 ` Michał Winiarski
2025-10-13 11:20 ` Michal Wajdeczko
2025-10-21 0:44 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 11/26] drm/xe: Allow the caller to pass guc_buf_cache size Michał Winiarski
2025-10-11 23:35 ` kernel test robot
2025-10-13 11:08 ` Michal Wajdeczko
2025-10-21 0:47 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 12/26] drm/xe/pf: Increase PF GuC Buffer Cache size and use it for VF migration Michał Winiarski
2025-10-13 11:27 ` Michal Wajdeczko
2025-10-21 0:50 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 13/26] drm/xe/pf: Remove GuC migration data save/restore from GT debugfs Michał Winiarski
2025-10-13 11:36 ` Michal Wajdeczko
2025-10-11 19:38 ` [PATCH 14/26] drm/xe/pf: Don't save GuC VF migration data on pause Michał Winiarski
2025-10-13 11:42 ` Michal Wajdeczko
2025-10-11 19:38 ` [PATCH 15/26] drm/xe/pf: Switch VF migration GuC save/restore to struct migration data Michał Winiarski
2025-10-11 19:38 ` [PATCH 16/26] drm/xe/pf: Handle GuC migration data as part of PF control Michał Winiarski
2025-10-13 11:56 ` Michal Wajdeczko
2025-10-21 0:52 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 17/26] drm/xe/pf: Add helpers for VF GGTT migration data handling Michał Winiarski
2025-10-13 12:17 ` Michal Wajdeczko
2025-10-21 1:00 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 18/26] drm/xe/pf: Handle GGTT migration data as part of PF control Michał Winiarski
2025-10-13 12:36 ` Michal Wajdeczko
2025-10-21 1:16 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 19/26] drm/xe/pf: Add helpers for VF MMIO migration data handling Michał Winiarski
2025-10-13 13:28 ` Michal Wajdeczko
2025-10-11 19:38 ` [PATCH 20/26] drm/xe/pf: Handle MMIO migration data as part of PF control Michał Winiarski
2025-10-11 19:38 ` [PATCH 21/26] drm/xe/pf: Add helper to retrieve VF's LMEM object Michał Winiarski
2025-10-11 19:38 ` [PATCH 22/26] drm/xe/migrate: Add function for raw copy of VRAM and CCS Michał Winiarski
2025-10-12 18:54 ` Matthew Brost
2025-10-11 19:38 ` [PATCH 23/26] drm/xe/pf: Handle VRAM migration data as part of PF control Michał Winiarski
2025-10-11 19:38 ` [PATCH 24/26] drm/xe/pf: Add wait helper for VF FLR Michał Winiarski
2025-10-13 13:49 ` Michal Wajdeczko
2025-10-11 19:38 ` [PATCH 25/26] drm/xe/pf: Export helpers for VFIO Michał Winiarski
2025-10-12 18:32 ` Matthew Brost
2025-10-21 1:38 ` Michał Winiarski
2025-10-13 14:02 ` Michal Wajdeczko
2025-10-21 1:49 ` Michał Winiarski
2025-10-11 19:38 ` [PATCH 26/26] vfio/xe: Add vendor-specific vfio_pci driver for Intel graphics Michał Winiarski
2025-10-13 19:00 ` Rodrigo Vivi
[not found] ` <20251021230328.GA21554@ziepe.ca>
2025-10-21 23:14 ` Matthew Brost [this message]
[not found] ` <20251021233811.GB21554@ziepe.ca>
2025-10-22 1:15 ` Matthew Brost
2025-10-22 9:05 ` Michał Winiarski
2025-10-27 7:02 ` Tian, Kevin
2025-10-11 19:48 ` ✗ CI.checkpatch: warning for vfio/xe: Add driver variant for Xe VF migration Patchwork
2025-10-11 19:49 ` ✗ CI.KUnit: failure " Patchwork
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=aPgT1u1YO3C3YozC@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=airlied@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=lukasz.laguna@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=michal.winiarski@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tursulin@ursulin.net \
--cc=yishaih@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox