On Wed, 17 Apr 2024 22:31:41 +0800
Xin Zeng <xin.zeng@xxxxxxxxx> wrote:
> Add vfio pci variant driver for Intel QAT SR-IOV VF devices. This driver
> registers to the vfio subsystem through the interfaces exposed by the
> susbsystem. It follows the live migration protocol v2 defined in
> uapi/linux/vfio.h and interacts with Intel QAT PF driver through a set
> of interfaces defined in qat/qat_mig_dev.h to support live migration of
> Intel QAT VF devices.
>From here down could actually just be a comment towards the top of the
driver.
> The migration data of each Intel QAT GEN4 VF device is encapsulated into
> a 4096 bytes block. The data consists of two parts.
>
> The first is a pre-configured set of attributes of the VF being migrated,
> which are only set when it is created. This can be migrated during pre-copy
> stage and used for a device compatibility check.
>
> The second is the VF state. This includes the required MMIO regions and
> the shadow states maintained by the QAT PF driver. This part can only be
> saved when the VF is fully quiesced and be migrated during stop-copy stage.
>
> Both these 2 parts of data are saved in hierarchical structures including
> a preamble section and several raw state sections.
>
> When the pre-configured part of the migration data is fully retrieved from
> user space, the preamble section are used to validate the correctness of
> the data blocks and check the version compatibility. The raw state
> sections are then used to do a device compatibility check.
>
> When the device transits from RESUMING state, the VF states are extracted
> from the raw state sections of the VF state part of the migration data and
> then loaded into the device.
>
> This version only covers migration for Intel QAT GEN4 VF devices.
>
> Co-developed-by: Yahui Cao <yahui.cao@xxxxxxxxx>
> Signed-off-by: Yahui Cao <yahui.cao@xxxxxxxxx>
> Signed-off-by: Xin Zeng <xin.zeng@xxxxxxxxx>
> Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@xxxxxxxxx>
> Reviewed-by: Kevin Tian <kevin.tian@xxxxxxxxx>
> ---
> MAINTAINERS | 8 +
> drivers/vfio/pci/Kconfig | 2 +
> drivers/vfio/pci/Makefile | 2 +
> drivers/vfio/pci/qat/Kconfig | 12 +
> drivers/vfio/pci/qat/Makefile | 3 +
> drivers/vfio/pci/qat/main.c | 679 ++++++++++++++++++++++++++++++++++
> 6 files changed, 706 insertions(+)
> create mode 100644 drivers/vfio/pci/qat/Kconfig
> create mode 100644 drivers/vfio/pci/qat/Makefile
> create mode 100644 drivers/vfio/pci/qat/main.c
...
> +static struct file *qat_vf_pci_step_device_state(struct qat_vf_core_device *qat_vdev, u32 new)
> +{
> + u32 cur = qat_vdev->mig_state;
> + int ret;
> +
> + /*
> + * As the device is not capable of just stopping P2P DMAs, suspend the
> + * device completely once any of the P2P states are reached.
> + * On the opposite direction, resume the device after transiting from
> + * the P2P state.
> + */
> + if ((cur == VFIO_DEVICE_STATE_RUNNING && new == VFIO_DEVICE_STATE_RUNNING_P2P) ||
> + (cur == VFIO_DEVICE_STATE_PRE_COPY && new == VFIO_DEVICE_STATE_PRE_COPY_P2P)) {
> + ret = qat_vfmig_suspend(qat_vdev->mdev);
> + if (ret)
> + return ERR_PTR(ret);
> + return NULL;
> + }
This doesn't appear to be a valid way to support P2P, the P2P states
are defined as running states. The guest driver may legitimately
access and modify the device state during P2P states. Should this
device be advertising support for P2P? Thanks,
Alex
