All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Longfang Liu <liulongfang@huawei.com>
Cc: alex.williamson@redhat.com, shameerali.kolothum.thodi@huawei.com,
	jonathan.cameron@huawei.com, cohuck@redhat.com,
	linux-kernel@vger.kernel.org, linuxarm@openeuler.org
Subject: Re: [PATCH v10 3/5] hisi_acc_vfio_pci: register debugfs for hisilicon migration driver
Date: Fri, 14 Apr 2023 09:24:43 -0300	[thread overview]
Message-ID: <ZDlGC8SUXqKNmfSe@nvidia.com> (raw)
In-Reply-To: <20230408074224.62608-4-liulongfang@huawei.com>

On Sat, Apr 08, 2023 at 03:42:22PM +0800, Longfang Liu wrote:
> +static int hisi_acc_vf_debug_restore(struct seq_file *seq, void *data)
> +{
> +	struct device *vf_dev = seq->private;
> +	struct vfio_pci_core_device *core_device = dev_get_drvdata(vf_dev);
> +	struct vfio_device	*vdev = &core_device->vdev;
> +	struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_get_vf_dev(vdev);
> +	struct hisi_acc_vf_migration_file *migf = hisi_acc_vdev->debug_migf;
> +	int ret;
> +
> +	ret = hisi_acc_vf_debug_check(seq, vdev);
> +	if (ret)
> +		goto restore_err;
> +
> +	ret = vf_qm_state_save(hisi_acc_vdev, migf);
> +	if (ret) {
> +		seq_printf(seq, "%s\n", "failed to save device data!");
> +		goto restore_err;
> +	}
> +
> +	ret = vf_qm_check_match(hisi_acc_vdev, migf);
> +	if (ret) {
> +		seq_printf(seq, "%s\n", "failed to match the VF!");
> +		goto restore_err;
> +	}
> +
> +	ret = vf_qm_load_data(hisi_acc_vdev, migf);
> +	if (ret) {
> +		seq_printf(seq, "%s\n", "failed to recover the VF!");
> +		goto restore_err;
> +	}
> +
> +	vf_qm_fun_reset(&hisi_acc_vdev->vf_qm);
> +	seq_printf(seq, "%s\n", "successful to resume device data!");
> +
> +restore_err:
> +	return 0;
> +}

This is basically an in-kernel self test, it should be protected with
some kind of VFIO selftest kconfig.

Though, I wonder why we need it??? Can't you write a trivial userspace
program under tools/testing to do this sequence with the ioctls?

> +static int hisi_acc_vf_debug_save(struct seq_file *seq, void *data)
> +{
> +	struct device *vf_dev = seq->private;
> +	struct vfio_pci_core_device *core_device = dev_get_drvdata(vf_dev);
> +	struct vfio_device	*vdev = &core_device->vdev;
> +	struct hisi_acc_vf_core_device *hisi_acc_vdev = hisi_acc_get_vf_dev(vdev);
> +	struct hisi_acc_vf_migration_file *migf = hisi_acc_vdev->debug_migf;
> +	int ret;
> +
> +	ret = hisi_acc_vf_debug_check(seq, vdev);
> +	if (ret)
> +		goto save_err;
> +
> +	ret = vf_qm_state_save(hisi_acc_vdev, migf);
> +	if (ret) {
> +		seq_printf(seq, "%s\n", "failed to save device data!");
> +		goto save_err;
> +	}
> +	seq_printf(seq, "%s\n", "successful to save device data!");
> +
> +save_err:
> +	return 0;
> +}

Same kind of commen there, this is a selftest, why does it need a
special kernel interface?

.. and so on..

I thought the non-selftesty bits were OK, maybe split the patch to
match progress

Jason

  reply	other threads:[~2023-04-14 12:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-08  7:42 [PATCH v10 0/5] add debugfs to migration driver Longfang Liu
2023-04-08  7:42 ` [PATCH v10 1/5] vfio/migration: Add debugfs to live " Longfang Liu
2023-04-08  7:42 ` [PATCH v10 2/5] hisi_acc_vfio_pci: extract public functions for container_of Longfang Liu
2023-04-08  7:42 ` [PATCH v10 3/5] hisi_acc_vfio_pci: register debugfs for hisilicon migration driver Longfang Liu
2023-04-14 12:24   ` Jason Gunthorpe [this message]
2023-04-21  3:27     ` liulongfang
2023-04-21  3:32       ` liulongfang
2023-04-21 14:31         ` Jason Gunthorpe
2023-05-16  9:40           ` liulongfang
2023-05-16 10:50             ` liulongfang
2023-05-16 11:50             ` Jason Gunthorpe
2023-06-02  7:07               ` liulongfang
2023-04-08  7:42 ` [PATCH v10 4/5] Documentation: add debugfs description for vfio Longfang Liu
2023-04-08  7:42 ` [PATCH v10 5/5] vfio: update live migration device status Longfang Liu
2023-04-14 12:25   ` Jason Gunthorpe
2023-04-21  3:07     ` liulongfang
2023-04-21 14:30       ` Jason Gunthorpe

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=ZDlGC8SUXqKNmfSe@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@openeuler.org \
    --cc=liulongfang@huawei.com \
    --cc=shameerali.kolothum.thodi@huawei.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.