From: Alex Williamson <alex.williamson@redhat.com>
To: "K V P, Satyanarayana" <satyanarayana.k.v.p@intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
cohuck@redhat.com, jgg@ziepe.ca, kevin.tian@intel.com,
michal.winiarski@intel.com, dave.jiang@intel.com,
ashok.raj@intel.com
Subject: Re: [PATCH v2] vfio/pci: Add DVSEC PCI Extended Config Capability to user visible list.
Date: Tue, 11 Apr 2023 13:28:06 -0600 [thread overview]
Message-ID: <20230411132806.4da1c86f.alex.williamson@redhat.com> (raw)
In-Reply-To: <20230317082222.3355912-1-satyanarayana.k.v.p@intel.com>
On Fri, 17 Mar 2023 08:22:22 +0000
"K V P, Satyanarayana" <satyanarayana.k.v.p@intel.com> wrote:
> The Designated Vendor-Specific Extended Capability (DVSEC Capability) is an
> optional Extended Capability that is permitted to be implemented by any PCI
> Express Function. This allows PCI Express component vendors to use
> the Extended Capability mechanism to expose vendor-specific registers that can
> be present in components by a variety of vendors. A DVSEC Capability structure
> can tell vendor-specific software which features a particular component
> supports.
>
> An example usage of DVSEC is Intel Platform Monitoring Technology (PMT) for
> enumerating and accessing hardware monitoring capabilities on a device.
> PMT encompasses three device monitoring features, Telemetry (device metrics),
> Watcher (sampling/tracing), and Crashlog. The DVSEC is used to discover these
> features and provide a BAR offset to their registers with the Intel vendor code.
>
> The current VFIO driver does not pass DVSEC capabilities to Virtual Machine (VM)
> which makes PMT not to work inside the virtual machine. This series adds DVSEC
> capability to user visible list to allow its use with VFIO. VFIO supports
> passing of Vendor Specific Extended Capability (VSEC) and raw write access to
> device. DVSEC also passed to VM in the same way as of VSEC.
>
> Signed-off-by: K V P Satyanarayana <satyanarayana.k.v.p@intel.com>
>
> Changes since Version V2:
> - Added support for raw pci write for DVSEC same as VSEC.
> ---
> drivers/vfio/pci/vfio_pci_config.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Applied to vfio next branch for v6.4. Thanks,
Alex
>
> diff --git a/drivers/vfio/pci/vfio_pci_config.c b/drivers/vfio/pci/vfio_pci_config.c
> index 523e0144c86f..948cdd464f4e 100644
> --- a/drivers/vfio/pci/vfio_pci_config.c
> +++ b/drivers/vfio/pci/vfio_pci_config.c
> @@ -96,6 +96,7 @@ static const u16 pci_ext_cap_length[PCI_EXT_CAP_ID_MAX + 1] = {
> [PCI_EXT_CAP_ID_SECPCI] = 0, /* not yet */
> [PCI_EXT_CAP_ID_PMUX] = 0, /* not yet */
> [PCI_EXT_CAP_ID_PASID] = 0, /* not yet */
> + [PCI_EXT_CAP_ID_DVSEC] = 0xFF,
> };
>
> /*
> @@ -1101,6 +1102,7 @@ int __init vfio_pci_init_perm_bits(void)
> ret |= init_pci_ext_cap_err_perm(&ecap_perms[PCI_EXT_CAP_ID_ERR]);
> ret |= init_pci_ext_cap_pwr_perm(&ecap_perms[PCI_EXT_CAP_ID_PWR]);
> ecap_perms[PCI_EXT_CAP_ID_VNDR].writefn = vfio_raw_config_write;
> + ecap_perms[PCI_EXT_CAP_ID_DVSEC].writefn = vfio_raw_config_write;
>
> if (ret)
> vfio_pci_uninit_perm_bits();
> @@ -1440,6 +1442,11 @@ static int vfio_ext_cap_len(struct vfio_pci_core_device *vdev, u16 ecap, u16 epo
> return PCI_TPH_BASE_SIZEOF + (sts * 2) + 2;
> }
> return PCI_TPH_BASE_SIZEOF;
> + case PCI_EXT_CAP_ID_DVSEC:
> + ret = pci_read_config_dword(pdev, epos + PCI_DVSEC_HEADER1, &dword);
> + if (ret)
> + return pcibios_err_to_errno(ret);
> + return PCI_DVSEC_HEADER1_LEN(dword);
> default:
> pci_warn(pdev, "%s: unknown length for PCI ecap %#x@%#x\n",
> __func__, ecap, epos);
prev parent reply other threads:[~2023-04-11 19:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-17 8:22 K V P, Satyanarayana
2023-04-11 19:28 ` Alex Williamson [this message]
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=20230411132806.4da1c86f.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=cohuck@redhat.com \
--cc=dave.jiang@intel.com \
--cc=jgg@ziepe.ca \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.winiarski@intel.com \
--cc=satyanarayana.k.v.p@intel.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
all inboxes | Powered by JetHome®