From: Bjorn Helgaas <helgaas@kernel.org>
To: "Michał Winiarski" <michal.winiarski@intel.com>
Cc: linux-pci@vger.kernel.org, intel-xe@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.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 v3 4/5] PCI/IOV: Allow extending VF BAR within original resource boundary
Date: Thu, 10 Oct 2024 17:27:35 -0500 [thread overview]
Message-ID: <20241010222735.GA580854@bhelgaas> (raw)
In-Reply-To: <20241010103203.382898-5-michal.winiarski@intel.com>
On Thu, Oct 10, 2024 at 12:32:02PM +0200, Michał Winiarski wrote:
> VF MMIO resource reservation, either created by system firmware and
> inherited by Linux PCI subsystem or created by the subsystem itself,
> contains enough space to fit the BAR of all SR-IOV Virtual Functions
> that can potentially be created (total VFs supported by the device).
It's *possible* that this is true, but there's no guarantee that
firmware has assigned enough space for all BARs of all possible VFs.
> This can be leveraged when the device is exposing lower than optimal BAR
> size as a default, allowing access to the entire resource when lower
> number of VFs are created.
> It is achieved by dynamically resizing the BAR to largest possible value
> that allows to fit all newly created VFs within the original resource
> boundary.
Add blank lines between paragraphs.
This log doesn't actually say what the patch does. It describes a
possible configuration and ways that it may be used, and even *how*
something might be done, but something along the lines of the subject
line should be included in the commit log.
> +static void pci_iov_resource_do_extend(struct pci_dev *dev, int resno, u16 num_vfs)
Please wrap to fit in 80 columns like the rest of the file.
> +int pci_iov_resource_extend(struct pci_dev *dev, int resno, bool enable)
Please add kerneldoc here to help users of this exported function.
> @@ -480,6 +560,11 @@ static ssize_t sriov_numvfs_store(struct device *dev,
> goto exit;
> }
>
> + for (i = 0; i < PCI_SRIOV_NUM_BARS; i++) {
> + if (pdev->sriov->rebar_extend[i])
> + pci_iov_resource_do_extend(pdev, i + PCI_IOV_RESOURCES, num_vfs);
Wrap to fit in 80 columns.
Bjorn
next prev parent reply other threads:[~2024-10-10 22:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-10 10:31 [PATCH v3 0/5] PCI: VF resizable BAR Michał Winiarski
2024-10-10 10:31 ` [PATCH v3 1/5] PCI/IOV: Restore VF resizable BAR state after reset Michał Winiarski
2024-10-10 11:01 ` Ilpo Järvinen
2024-10-10 22:31 ` Bjorn Helgaas
2024-10-10 10:32 ` [PATCH v3 2/5] PCI: Add a helper to identify IOV resources Michał Winiarski
2024-10-10 10:46 ` Ilpo Järvinen
2024-10-10 22:30 ` Bjorn Helgaas
2024-10-10 10:32 ` [PATCH v3 3/5] PCI: Allow IOV resources to be resized in pci_resize_resource Michał Winiarski
2024-10-10 11:17 ` Ilpo Järvinen
2024-10-10 11:42 ` Michał Winiarski
2024-10-10 22:36 ` Bjorn Helgaas
2024-10-10 10:32 ` [PATCH v3 4/5] PCI/IOV: Allow extending VF BAR within original resource boundary Michał Winiarski
2024-10-10 22:27 ` Bjorn Helgaas [this message]
2024-10-10 10:32 ` [PATCH v3 5/5] drm/xe/pf: Extend the VF LMEM BAR Michał Winiarski
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=20241010222735.GA580854@bhelgaas \
--to=helgaas@kernel.org \
--cc=airlied@gmail.com \
--cc=bhelgaas@google.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=ilpo.jarvinen@linux.intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox