All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "Michał Winiarski" <michal.winiarski@intel.com>
Cc: linux-pci@vger.kernel.org, intel-xe@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	LKML <linux-kernel@vger.kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Michal Wajdeczko" <michal.wajdeczko@intel.com>,
	"Lucas De Marchi" <lucas.demarchi@intel.com>,
	"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Maxime Ripard" <mripard@kernel.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Matt Roper" <matthew.d.roper@intel.com>
Subject: Re: [PATCH v7 5/6] PCI: Allow drivers to control VF BAR size
Date: Thu, 3 Apr 2025 13:20:58 +0300 (EEST)	[thread overview]
Message-ID: <14a7c29e-31b9-2954-9142-0d1c49988b07@linux.intel.com> (raw)
In-Reply-To: <20250402141122.2818478-6-michal.winiarski@intel.com>

[-- Attachment #1: Type: text/plain, Size: 5670 bytes --]

On Wed, 2 Apr 2025, Michał Winiarski wrote:

> Drivers could leverage the fact that the VF BAR MMIO reservation is
> created for total number of VFs supported by the device by resizing the
> BAR to larger size when smaller number of VFs is enabled.
> 
> Add a pci_iov_vf_bar_set_size() function to control the size and a
> pci_iov_vf_bar_get_sizes() helper to get the VF BAR sizes that will
> allow up to num_vfs to be successfully enabled with the current
> underlying reservation size.
> 
> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
> ---
>  drivers/pci/iov.c   | 69 +++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/pci.h |  6 ++++
>  2 files changed, 75 insertions(+)
> 
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 2fafbd6a998f0..8a62049b56b41 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -1313,3 +1313,72 @@ int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn)
>  	return nr_virtfn;
>  }
>  EXPORT_SYMBOL_GPL(pci_sriov_configure_simple);
> +
> +/**
> + * pci_iov_vf_bar_set_size - set a new size for a VF BAR
> + * @dev: the PCI device
> + * @resno: the resource number
> + * @size: new size as defined in the spec (0=1MB, 31=128TB)
> + *
> + * Set the new size of a VF BAR that supports VF resizable BAR capability.
> + * Unlike pci_resize_resource(), this does not cause the resource that
> + * reserves the MMIO space (originally up to total_VFs) to be resized, which
> + * means that following calls to pci_enable_sriov() can fail if the resources
> + * no longer fit.
> + *
> + * Return: 0 on success, or negative on failure.
> + */
> +int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size)
> +{
> +	int ret;
> +	u32 sizes;

Please reverse the order of these variables.

> +
> +	if (!pci_resource_is_iov(resno))
> +		return -EINVAL;
> +
> +	if (pci_iov_is_memory_decoding_enabled(dev))
> +		return -EBUSY;
> +
> +	sizes = pci_rebar_get_possible_sizes(dev, resno);
> +	if (!sizes)
> +		return -ENOTSUPP;
> +
> +	if (!(sizes & BIT(size)))

Add include for BIT().

Although adding a helper like this would be helpful for multiple callers:

@@ -3780,6 +3780,88 @@ u32 pci_rebar_get_possible_sizes(struct pci_dev *pdev, int bar)
 }
 EXPORT_SYMBOL(pci_rebar_get_possible_sizes);
 
+/**
+ * pci_rebar_size_supported - check if size is supported for a resizable BAR
+ * @pdev: PCI device
+ * @bar: BAR to check
+ * @size: size as defined in the spec (0=1MB, 31=128TB)
+ *
+ * Return: %0 if @size is supported for @bar,
+ *        %-EINVAL if @size is not supported,
+ *        %-ENOTSUPP if @bar is not resizable.
+ */
+int pci_rebar_size_supported(struct pci_dev *pdev, int bar, int size)
+{
+       u64 sizes;
+
+       sizes = pci_rebar_get_possible_sizes(pdev, bar);
+       if (!sizes)
+               return -ENOTSUPP;
+
+       return BIT(size) & sizes ? 0 : -EINVAL;
+}
+EXPORT_SYMBOL_GPL(pci_rebar_size_supported);

(Yes, I've some rebar helpers pending so this is extract from that.)

> +		return -EINVAL;
> +
> +	ret = pci_rebar_set_size(dev, resno, size);
> +	if (ret)
> +		return ret;
> +
> +	pci_iov_resource_set_size(dev, resno, pci_rebar_size_to_bytes(size));
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(pci_iov_vf_bar_set_size);
> +
> +/**
> + * pci_iov_vf_bar_get_sizes - get VF BAR sizes allowing to create up to num_vfs
> + * @dev: the PCI device
> + * @resno: the resource number
> + * @num_vfs: number of VFs
> + *
> + * Get the sizes of a VF resizable BAR that can accommodate @num_vfs within
> + * the currently assigned size of the resource @resno.
> + *
> + * Return: A bitmask of sizes in format defined in the spec (bit 0=1MB,
> + * bit 31=128TB).
> + */
> +u32 pci_iov_vf_bar_get_sizes(struct pci_dev *dev, int resno, int num_vfs)
> +{
> +	resource_size_t vf_len = pci_resource_len(dev, resno);
> +	u32 sizes;
> +
> +	if (!num_vfs)
> +		return 0;
> +
> +	do_div(vf_len, num_vfs);

Add include for do_div().

> +	sizes = (roundup_pow_of_two(vf_len + 1) - 1) >> ilog2(SZ_1M);

Doesn't resource_size() already do that + 1 so why is a second one needed 
here?

Add include for ilog() and SZ_*.

> +
> +	return sizes & pci_rebar_get_possible_sizes(dev, resno);
> +}
> +EXPORT_SYMBOL_GPL(pci_iov_vf_bar_get_sizes);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 0e8e3fd77e967..c8708f3749757 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2389,6 +2389,8 @@ int pci_sriov_set_totalvfs(struct pci_dev *dev, u16 numvfs);
>  int pci_sriov_get_totalvfs(struct pci_dev *dev);
>  int pci_sriov_configure_simple(struct pci_dev *dev, int nr_virtfn);
>  resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno);
> +int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size);
> +u32 pci_iov_vf_bar_get_sizes(struct pci_dev *dev, int resno, int num_vfs);
>  void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe);
>  
>  /* Arch may override these (weak) */
> @@ -2441,6 +2443,10 @@ static inline int pci_sriov_get_totalvfs(struct pci_dev *dev)
>  #define pci_sriov_configure_simple	NULL
>  static inline resource_size_t pci_iov_resource_size(struct pci_dev *dev, int resno)
>  { return 0; }
> +static inline int pci_iov_vf_bar_set_size(struct pci_dev *dev, int resno, int size)
> +{ return -ENODEV; }
> +static inline u32 pci_iov_vf_bar_get_sizes(struct pci_dev *dev, int resno, int num_vfs)
> +{ return 0; }
>  static inline void pci_vf_drivers_autoprobe(struct pci_dev *dev, bool probe) { }
>  #endif
>  
> 

-- 
 i.

  reply	other threads:[~2025-04-03 10:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-02 14:11 [PATCH v7 0/6] PCI: VF resizable BAR Michał Winiarski
2025-04-02 14:11 ` [PATCH v7 1/6] PCI/IOV: Restore VF resizable BAR state after reset Michał Winiarski
2025-04-02 14:11 ` [PATCH v7 2/6] PCI: Add a helper to convert between VF BAR number and IOV resource Michał Winiarski
2025-04-03  9:24   ` Ilpo Järvinen
2025-04-02 14:11 ` [PATCH v7 3/6] PCI: Allow IOV resources to be resized in pci_resize_resource() Michał Winiarski
2025-04-03  9:45   ` Ilpo Järvinen
2025-04-02 14:11 ` [PATCH v7 4/6] PCI/IOV: Check that VF BAR fits within the reservation Michał Winiarski
2025-04-03  9:54   ` Ilpo Järvinen
2025-04-02 14:11 ` [PATCH v7 5/6] PCI: Allow drivers to control VF BAR size Michał Winiarski
2025-04-03 10:20   ` Ilpo Järvinen [this message]
2025-05-26 21:54     ` Michał Winiarski
2025-04-02 14:11 ` [PATCH v7 6/6] drm/xe/pf: Set VF LMEM " Michał Winiarski
2025-04-02 14:18 ` ✗ CI.Patch_applied: failure for PCI: VF resizable BAR (rev6) Patchwork
2025-04-03  8:23 ` 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=14a7c29e-31b9-2954-9142-0d1c49988b07@linux.intel.com \
    --to=ilpo.jarvinen@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=kw@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lucas.demarchi@intel.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=michal.wajdeczko@intel.com \
    --cc=michal.winiarski@intel.com \
    --cc=mripard@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.