Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Alex Williamson <alex.williamson@redhat.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>
CC:     "joro@8bytes.org" <joro@8bytes.org>,
        "jgg@nvidia.com" <jgg@nvidia.com>,
        "robin.murphy@arm.com" <robin.murphy@arm.com>,
        "baolu.lu@linux.intel.com" <baolu.lu@linux.intel.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "eric.auger@redhat.com" <eric.auger@redhat.com>,
        "nicolinc@nvidia.com" <nicolinc@nvidia.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
        "chao.p.peng@linux.intel.com" <chao.p.peng@linux.intel.com>,
        "yi.y.sun@linux.intel.com" <yi.y.sun@linux.intel.com>,
        "peterx@redhat.com" <peterx@redhat.com>,
        "jasowang@redhat.com" <jasowang@redhat.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "lulu@redhat.com" <lulu@redhat.com>,
        "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
        "iommu@lists.linux.dev" <iommu@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>,
        "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
        "joao.m.martins@oracle.com" <joao.m.martins@oracle.com>,
        "Zeng, Xin" <xin.zeng@intel.com>,
        "Zhao, Yan Y" <yan.y.zhao@intel.com>
Subject: RE: [PATCH 3/3] vfio: Report PASID capability via VFIO_DEVICE_FEATURE
 ioctl
Thread-Topic: [PATCH 3/3] vfio: Report PASID capability via
 VFIO_DEVICE_FEATURE ioctl
Thread-Index: AQHaIPx2EKyfzMrBBEWzcc+IDcJP4bCkdsqAgACIdDA=
Date:   Tue, 12 Dec 2023 02:16:17 +0000
Message-ID: <BN9PR11MB5276DD7A14E938973DDEBEC18C8EA@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20231127063909.129153-1-yi.l.liu@intel.com>
        <20231127063909.129153-4-yi.l.liu@intel.com>
 <20231211110345.1b4526c6.alex.williamson@redhat.com>
In-Reply-To: <20231211110345.1b4526c6.alex.williamson@redhat.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?IGNHUMVoJikSoGOxjoFU6R+SxG6R6kDraTelirCZ2ga6nl1zf/ERQ/IzhUUP?=
 =?us-ascii?Q?3Z/Ya0Dmnz3SqsdGq+kZTAGebfKNbScv7nQfv6HQlVif9mmZdTWZiuFgV4Tb?=
 =?us-ascii?Q?MouzHNK0NRhkKsCSOWM9q5U6cMhyi/OClPFyQglqsuEZShCS6+UTJcdg2H82?=
 =?us-ascii?Q?/ycM+oZR94ibbxHcT8BTvCsIGn0YAp87CeORXBP5ffgbA8pcLMSZYMiHwbfm?=
 =?us-ascii?Q?h+XWJfpMwfwqz2Z/lE8KDvghZixqlI9L3glWA7h/+cotgC7Aut6kJ6PWKNWO?=
 =?us-ascii?Q?jmyT7gEkPc252ZbBZKViulTZ3443PxaNbCpirlfYsP9DvqmXZD6QpWLTCU7Y?=
 =?us-ascii?Q?ShvHwNIDWWeMCWbj3t4R78TFpv/6O5xF14LBMAC5UnYGjyvVfCcAYRyzMpSo?=
 =?us-ascii?Q?rUUW0fQJ5GweWqOE8VFZTpQ3fw+3YZkS+2vbzhPcUTgbpQyaXYB+DBj+2fmb?=
 =?us-ascii?Q?rykI4baPbChecnzuMWoq0879GRXW7HL5dW1d3A6mDpf4pZdJRBjEEcY3ycxJ?=
 =?us-ascii?Q?c1n4HqvkpOAb7AIJlIQOrhejw9PF1qiEpNWCAduGFTPtUqFyw17ML2Tzbv3W?=
 =?us-ascii?Q?1n+kexKrj3U7OQEbJeVehrxueujy41XjMYHkFZ+3QRvr9MCuRdt4+B6LqdaY?=
 =?us-ascii?Q?ndbe1N60bAsCVMcwoLNE0da6Ldl9YY9GP7fCzEnmdnjvYRo94iKk/9OHPkaB?=
 =?us-ascii?Q?MqQOWfP5clMnOqRnVcyDAmAOfUADOgf3ssZAMMlbFKg0IZohbftiUcc5t+ky?=
 =?us-ascii?Q?HFSGspz/XpIMG/4RLfE9Yz+3mPnr324d95ZbQCKlsPJYqW+UtdgEjd9B+wsW?=
 =?us-ascii?Q?WQfqKwSjcQ9xOPXIxK9CF6luDD+Qoh8RCc5e7zuMF90FmmMTTtQYE2eER17W?=
 =?us-ascii?Q?lfAX7NbRWT27OaYAkNG3OBtjgJ44GKWoXBZKpOU3htErWXJyNZ/bLOPAGjEO?=
 =?us-ascii?Q?57rLqhNuLDwnWBWG8SXUBJOh7AJnxK9KSp7+f23o/0szpPgdcioVpsYFIjjV?=
 =?us-ascii?Q?3uSWh+eqpPhunwk2k48OqKiCQpb7CBzMpZPn4VuBVSg4iQwsXF9jR9tubM6b?=
 =?us-ascii?Q?nRg5mzVZ+i3PatZi80VfdFc+jDT9LP8aXKDLO2vZl+kZkk2kZuNc0TRCGEb9?=
 =?us-ascii?Q?QPeReo6zeUFBzqzz53hy2cM+UTd8Y1ZV20k9zMrvYCdqniukUVluM8KCbZZw?=
 =?us-ascii?Q?bVdcXkcmktFUpvQuURf2GppnG7Ge4PsZZWZsicrpahAH+QyX0okcTI67BcOK?=
 =?us-ascii?Q?Y0dhgRE5tbEScYTIEjR1W7W3UcM2OE19+7YQT4ikk64EQr8oP+7f+u6ZH+kd?=
 =?us-ascii?Q?DvYEIAwIClFVNER5yaBb/ggZok8UCcK4gQaq5xKrYsfM1h0mWOeVq5CCE5s6?=
 =?us-ascii?Q?vQkd5CA4DXlkCumvzNLVxm+ZuSJuT7Zu7ujYv4o9oG3Mgd3qa0k0+tGygtWp?=
 =?us-ascii?Q?kHYug4fkigTmi3Gd/6tFN+fcQmcesDoswnN/ZTeWQkN8xhEzUDLh7Tf/ZvcB?=
 =?us-ascii?Q?FserOp7Yl0v5zBiZDPX9yFCQYnqoORahafxmeb13CcDPMFdu0I2SXyG0QvHy?=
 =?us-ascii?Q?fPLSw8Do/TtWfhD1VeVuKmuObthnSsjCLIV4DeTb?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5276.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: be49b604-8e1d-4c35-04db-08dbfab852a8
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2023 02:16:17.0503
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 4vtRiQZzVl5jxja6SFXbwmhTfuxcsFjGvIEyyhPsothjCJ+a9xAokfF36lA443NPeqERZgnq+D3WOIBlsWazSw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4817
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Mon, 11 Dec 2023 18:20:43 -0800 (PST)

> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Tuesday, December 12, 2023 2:04 AM
>=20
> On Sun, 26 Nov 2023 22:39:09 -0800
> Yi Liu <yi.l.liu@intel.com> wrote:
>=20
> > This reports the PASID capability data to userspace via
> VFIO_DEVICE_FEATURE,
> > hence userspace could probe PASID capability by it. This is a bit diffe=
rent
> > with other capabilities which are reported to userspace when the user
> reads
> > the device's PCI configuration space. There are two reasons for this.
> >
> >  - First, Qemu by default exposes all available PCI capabilities in vfi=
o-pci
> >    config space to the guest as read-only, so adding PASID capability i=
n the
> >    vfio-pci config space will make it exposed to the guest automaticall=
y while
> >    an old Qemu doesn't really support it.
>=20
> Shouldn't we also be working on hiding the PASID capability in QEMU
> ASAP?  This feature only allows QEMU to know PASID control is actually
> available, not the guest.  Maybe we're hoping this is really only used
> by VFs where there's no capability currently exposed to the guest?

We expect this to be used by both PF/VF. It doesn't make sense to have
separate interfaces between them.

I'm not aware of that the PASID capability has been exported today. So
yes we should fix QEMU asap. and also remove the line exposing it
in vfio_pci_config.c.

>=20
> >  - Second, PASID capability does not exit on VFs (instead shares the ca=
p of
>=20
> s/exit/exist/
>=20
> >    the PF). Creating a virtual PASID capability in vfio-pci config spac=
e needs
> >    to find a hole to place it, but doing so may require device specific
> >    knowledge to avoid potential conflict with device specific registers=
 like
> >    hiden bits in VF config space. It's simpler by moving this burden to=
 the
> >    VMM instead of maintaining a quirk system in the kernel.
>=20
> This feels a bit like an incomplete solution though and we might
> already posses device specific knowledge in the form of a variant
> driver.  Should this feature structure include a flag + field that
> could serve to generically indicate to the VMM a location for
> implementing the PASID capability?  The default core implementation
> might fill this only for PFs where clearly an emualted PASID capability
> can overlap the physical capability.  Thanks,
>=20

make sense