[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <BN9PR11MB52764BE569672A02FE2A8CCA8C769@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Tue, 9 May 2023 08:34:53 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Alex Williamson <alex.williamson@...hat.com>,
Jason Gunthorpe <jgg@...dia.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Liu, Yi L" <yi.l.liu@...el.com>,
Nicolin Chen <nicolinc@...dia.com>,
"Lu, Baolu" <baolu.lu@...el.com>
Subject: vPASID capability for VF
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.
iirc we haven't closed this open in previous discussion. It's probably
right time to revisit it and agree on a solution now.
Three options on the table:
1) Use vfio-pci variant driver. Easy to support especially when the VF
also plans to support live migration. is it overburdened otherwise?
2) Have vfio-pci maintain a table tracking hard-coded offset per
vendor/device ID.
3) Extend PCI core to allow PF driver specifying the offset for VF
Which one is cleanest in your view?
Thanks
Kevin
Powered by blists - more mailing lists