From: Alex Williamson <alex.williamson@redhat.com>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Liu, Yi L" <yi.l.liu@intel.com>,
Nicolin Chen <nicolinc@nvidia.com>,
"Lu, Baolu" <baolu.lu@intel.com>
Subject: Re: vPASID capability for VF
Date: Wed, 10 May 2023 11:24:49 -0600 [thread overview]
Message-ID: <20230510112449.4d766f6f.alex.williamson@redhat.com> (raw)
In-Reply-To: <BN9PR11MB52764BE569672A02FE2A8CCA8C769@BN9PR11MB5276.namprd11.prod.outlook.com>
On Tue, 9 May 2023 08:34:53 +0000
"Tian, Kevin" <kevin.tian@intel.com> wrote:
> According to PCIe spec (7.8.9 PASID Extended Capability Structure):
>
> The PASID configuration of the single non-VF Function representing
> the device is also used by all VFs in the device. A PF is permitted
> to implement the PASID capability, but VFs must not implement it.
>
> To enable PASID on VF then one open is where to locate the PASID
> capability in VF's vconfig space. vfio-pci doesn't know which offset
> may contain VF specific config registers. Finding such offset must
> come from a device specific knowledge.
Backup for a moment, VFs are governed by the PASID capability on the
PF. The PASID capability exposes control registers that imply the
ability to manage various feature enable bits. The VF owner does not
have privileges to manipulate those bits. For example, the PASID Enable
bit should restrict the endpoint from sending TLPs with a PASID prefix,
but this can only be changed at the PF level for all associated VFs.
The protocol specified in 7.8.9.3 defines this enable bit as RW. How do
we virtualize that? Either it's virtualized to be read-only and we
violate the spec or we allow it to be read-write and it has no effect,
which violates the spec.
Is this capability really intended to be mirrored by software to the
VFs or do we need to expose the PASID capabilities of the VF in some
other way? Thanks,
Alex
next prev parent reply other threads:[~2023-05-10 17:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 8:34 vPASID capability for VF Tian, Kevin
2023-05-09 22:43 ` Jason Gunthorpe
2023-05-09 22:57 ` Tian, Kevin
2023-05-09 23:13 ` Jason Gunthorpe
2023-05-09 23:41 ` Tian, Kevin
2023-05-10 0:31 ` Alex Williamson
2023-05-10 0:59 ` Jason Gunthorpe
2023-05-10 2:16 ` Tian, Kevin
2023-05-10 20:39 ` Jason Gunthorpe
2023-05-11 7:42 ` Tian, Kevin
2023-05-10 17:24 ` Alex Williamson [this message]
2023-05-10 20:15 ` Jason Gunthorpe
2023-05-11 7:27 ` Tian, Kevin
2023-05-11 11:34 ` Baolu Lu
2023-05-12 2:59 ` Tian, Kevin
2023-05-12 21:01 ` Jason Gunthorpe
2023-05-17 5:09 ` Tian, Kevin
2023-05-11 15:45 ` Alex Williamson
2023-05-12 2:52 ` Tian, Kevin
2023-05-17 5:22 ` Tian, Kevin
2023-07-27 1:17 ` Tian, Kevin
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=20230510112449.4d766f6f.alex.williamson@redhat.com \
--to=alex.williamson@redhat.com \
--cc=baolu.lu@intel.com \
--cc=jgg@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=yi.l.liu@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