Re: [PATCH v4 2/4] s390/pci: Preserve FMB state in device re-enablement

[Alex Williamson <alex@shazbot.org>]

On Fri, 12 Jun 2026 14:10:46 -0400
Omar Elghoul <oelghoul@linux.ibm.com> wrote:
> +int zpci_fmb_reenable_device(struct zpci_dev *zdev)
> +{
> +	u64 req = ZPCI_CREATE_REQ(zdev->fh, 0, ZPCI_MOD_FC_SET_MEASURE);
> +	struct zpci_fib fib = {0};
> +	u8 cc, status;
> +	int rc;
> +
> +	lockdep_assert_held(&zdev->fmb_lock);
> +
> +	if (!zdev->fmb)
> +		return zpci_fmb_enable_device(zdev);
> +
> +	fib.gd = zdev->gisa;
> +	cc = zpci_mod_fc(req, &fib, &status); /* Disable function measurement */
> +
> +	/* Unlike in zpci_fmb_disable_device(), cc == 3 is not a valid state here
> +	 * because we are re-enabling function measurement for the same function
> +	 * handle.
> +	 */
> +	if (cc)
> +		return -EIO;
> +
> +	zpci_fmb_clear_iommu_ctrs(zdev);
> +
> +	rc = zpci_fmb_do_enable(zdev);
> +	if (rc) {
> +		kmem_cache_free(zdev_fmb_cache, zdev->fmb);
> +		zdev->fmb = NULL;
> +	}
> +
> +	return rc;
> +}
> +EXPORT_SYMBOL_GPL(zpci_fmb_reenable_device);

Why is this exported?  Maybe this is leftover from the previous version
where it was noted that the API claimed a failure on double enable that
didn't actually occur because if used reenable.  Now we seem to have
the alternate inconsistency, that FMB is automatically enabled as part
of the standard PCI enable path, so the only initial operation
available to userspace is to first disable FMB, which is an awkward
API.  The v3 problem could have been solved in documentation, noting
that a nested enable resets counters[1], while a nested disable
generates an errno.  Thanks,

Alex

[1] Also note the sashiko question whether reenable actually zeros the
current fmb buffer or only the internal counters
https://sashiko.dev/#/message/20260612182632.E4EE71F000E9%40smtp.kernel.org