kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Tian, Kevin" <kevin.tian@intel.com>
To: Brett Creeley <brett.creeley@amd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"shameerali.kolothum.thodi@huawei.com"
	<shameerali.kolothum.thodi@huawei.com>,
	"yishaih@nvidia.com" <yishaih@nvidia.com>,
	"jgg@ziepe.ca" <jgg@ziepe.ca>
Cc: "shannon.nelson@amd.com" <shannon.nelson@amd.com>
Subject: RE: [PATCH vfio] vfio/pds: Rework and simplify reset flows
Date: Mon, 5 Feb 2024 06:58:51 +0000	[thread overview]
Message-ID: <BL1PR11MB52712B162AE5FEC2E24614F98C472@BL1PR11MB5271.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20240126183225.19193-1-brett.creeley@amd.com>

> From: Brett Creeley <brett.creeley@amd.com>
> Sent: Saturday, January 27, 2024 2:32 AM
> 
> The current logic for handling resets based on
> whether they were initiated from the DSC or
> host/VMM is slightly confusing and incorrect.
> The incorrect behavior can cause the VF device
> to be unusable on the destination on failed
> migrations due to incompatible configurations.
> Fix this by setting the state back to
> VFIO_DEVICE_STATE_RUNNING when an FLR is
> triggered, so the VF device is put back in
> an "initial" pre-configured state after failures.

any reason for putting short lines (<50 chars) in commit msg?

> 
> Also, while here clean-up the reset logic to
> make the source of the reset more obvious.

as a fix the a 'Fixed' tag is preferred and CC stable

also separate the real fix from the cleanup so stable kernel doesn't need
to backport unnecessary code.

btw the commit msg is not clear to me. It says fixing the problem
by setting the state to _ERROR for the DSC path and to _RUNNING for
the FLR path.

But looks it's already such case with old code:

pds_vfio_recovery()
	pds_vfio->deferred_reset = true;
	pds_vfio->deferred_reset_state = VFIO_DEVICE_STATE_ERROR;

pds_vfio_reset()
	pds_vfio->deferred_reset = true;
	pds_vfio->deferred_reset_state = VFIO_DEVICE_STATE_RUNNING;

pds_vfio_state_mutex_unlock()
	if (pds_vfio->deferred_reset) {
		...
		pds_vfio->state = pds_vfio->deferred_reset_state;
		...
	}

it's same as what this patch does:

pds_vfio_recovery()
	pds_vfio->deferred_reset_type = PDS_VFIO_DEVICE_RESET;

pds_vfio_reset()
	pds_vfio->deferred_reset_state = PDS_VFIO_HOST_RESET;

pds_vfio_state_mutex_unlock()
	if (pds_vfio->deferred_reset) {
		...
		if (pds_vfio->deferred_reset_type == PDS_VFIO_HOST_RESET)
			pds_vfio->state = VFIO_DEVICE_STATE_RUNNING;
		else
			pds_vfio->state = VFIO_DEVICE_STATE_ERROR;
		...
	}

looks the actual functional difference is from below change:

> @@ -32,13 +32,14 @@ void pds_vfio_state_mutex_unlock(struct
> pds_vfio_pci_device *pds_vfio)
>  	mutex_lock(&pds_vfio->reset_mutex);
>  	if (pds_vfio->deferred_reset) {
>  		pds_vfio->deferred_reset = false;
> -		if (pds_vfio->state == VFIO_DEVICE_STATE_ERROR) {
> -			pds_vfio_put_restore_file(pds_vfio);
> -			pds_vfio_put_save_file(pds_vfio);
> +		pds_vfio_put_restore_file(pds_vfio);
> +		pds_vfio_put_save_file(pds_vfio);

above two are changed from conditional to always.

> +		if (pds_vfio->deferred_reset_type == PDS_VFIO_HOST_RESET)
> {
> +			pds_vfio->state = VFIO_DEVICE_STATE_RUNNING;
> +		} else {
>  			pds_vfio_dirty_disable(pds_vfio, false);

and this is now only for the DSC path.

need a better explanation here.

  reply	other threads:[~2024-02-05  6:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 18:32 [PATCH vfio] vfio/pds: Rework and simplify reset flows Brett Creeley
2024-02-05  6:58 ` Tian, Kevin [this message]
2024-02-05 17:25   ` Brett Creeley

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=BL1PR11MB52712B162AE5FEC2E24614F98C472@BL1PR11MB5271.namprd11.prod.outlook.com \
    --to=kevin.tian@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=brett.creeley@amd.com \
    --cc=jgg@ziepe.ca \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shannon.nelson@amd.com \
    --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;
as well as URLs for NNTP newsgroup(s).