Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Tian, Kevin" <kevin.tian@intel.com>
To:     Alex Williamson <alex.williamson@redhat.com>
CC:     "Chatre, Reinette" <reinette.chatre@intel.com>,
        "jgg@nvidia.com" <jgg@nvidia.com>,
        "yishaih@nvidia.com" <yishaih@nvidia.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "darwi@linutronix.de" <darwi@linutronix.de>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "Jiang, Dave" <dave.jiang@intel.com>,
        "Liu, Jing2" <jing2.liu@intel.com>,
        "Raj, Ashok" <ashok.raj@intel.com>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        "tom.zanussi@linux.intel.com" <tom.zanussi@linux.intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH V4 10/11] vfio/pci: Support dynamic MSI-X
Thread-Topic: [PATCH V4 10/11] vfio/pci: Support dynamic MSI-X
Thread-Index: AQHZeS7NjeBSeWLT50GaZQKxGXZCA69ARxSQgADG4ICACkQGoIAAiAsAgAEZCCA=
Date:   Sat, 6 May 2023 08:15:00 +0000
Message-ID: <BN9PR11MB52761AAC6808D9B8AC9C186D8C739@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <cover.1682615447.git.reinette.chatre@intel.com>
        <c4c582970fbeaf4b6000845c400aa4c6b7bb2f13.1682615447.git.reinette.chatre@intel.com>
        <BN9PR11MB5276B67702AACB0B5BF1EC0A8C6B9@BN9PR11MB5276.namprd11.prod.outlook.com>
        <296ec21f-fc7d-eaf2-484c-27ae8815c5a8@intel.com>
        <BN9PR11MB5276ED7B47909222093E92438C729@BN9PR11MB5276.namprd11.prod.outlook.com>
 <20230505092808.5c36e1f6.alex.williamson@redhat.com>
In-Reply-To: <20230505092808.5c36e1f6.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?m8zy5NdL8IO+UNIHcqSH4CPFRasIP9ekZUT8OYsGxNULc0Zl4HO1OfYrNgud?=
 =?us-ascii?Q?Uq2JaDi9ToVNys8TnaUTs7fvNMW7M0ot7tIDblp37whfDb5lgTuBZm/KJFDT?=
 =?us-ascii?Q?owIh8Z74948iwpBF3S2dOZtQbAzvCGmIcsf80VbeiNU/xsIR/5bcKH7pbI+o?=
 =?us-ascii?Q?zPP7nPPUFYWvLbg6aUeI6EyOARz491M9+X/sGzL25P9u4dT8oGbYL8+Dtw0f?=
 =?us-ascii?Q?+4z7SnfaejJQ4sdneEq7rsDuM7JM+81sxDRJ16BsEl8HmlMyNaEzZVxhgG3R?=
 =?us-ascii?Q?X4MBgDCYnhdP0wMELlpaT3dlUc17Dia6AXwVDmPxHSyRkh+kOBLSBeYoEnQ6?=
 =?us-ascii?Q?t3ph4IzuJjXe5H0cqNrprJdYVEqp9JONa0KMgcbO577YJ9MQCt94m4N6MEMS?=
 =?us-ascii?Q?26galwqFG0B7z1fFTtzNlmMBqEbf9K5KiaOqB3ACoTNxfspgSksrwFiBrhxi?=
 =?us-ascii?Q?EfYrpSfE5PMwU4bR9RM+HHoI2I8HuRae6G8YXlSHBUpqUzfqZ84/BUDeMqZE?=
 =?us-ascii?Q?4DcxasPKLLHi0eS9Is49ulDFjAbn08dDpnzfVilNtuWiKx3CLRbDbYYH/acC?=
 =?us-ascii?Q?noMq1dS6rn/KPj1xLMEbCfNk+0KXNOYtMtejNJfdV8gpUGvo7Q54XSipJOqP?=
 =?us-ascii?Q?N0h5PpWEHT7UIShX2++3d+YcfC0hiua1NspUhVlvL1a5TnZsoP2sdoa2oQ5J?=
 =?us-ascii?Q?bGSOKes7bMqgacHeBkklaW2fyeWIEpmeb7B2Zo1z2u/eliq2K+j92OHxBvik?=
 =?us-ascii?Q?69efQTbFyyaXBKUnDgzV/OrHVRlifKDZqttwAnarneJR5v2cxv225QM3hr3k?=
 =?us-ascii?Q?tmosMwmFXUE/a75q/nawwKfrOy1E9siGXrCcUKv0RbIJ0TG84ZSkM5NqF/lk?=
 =?us-ascii?Q?MUtFJEtNvXPQdY4DaxGLrukrXSUE8v+pj0Xrl3/UnbmXOZwcEoJ6xIDQ7mGh?=
 =?us-ascii?Q?qr3GapVj4x1FQ61A5nmNyViwTD50cjvBV/he/xSByHu2cFimt2jzMOxzhhf3?=
 =?us-ascii?Q?HoKi+7Fli/ahGIYtgz6CCb5ckVjiFZbqJIjpga5ggtM8HC9bhGRltHPbBnsc?=
 =?us-ascii?Q?ZxpzfvvTIdvGrkOIg4jePGOIzjNsWzjtvznI8aW098iTK9oB6ZWvOIJoXx5P?=
 =?us-ascii?Q?3Ga8aPl/CXeh83JEURMxfh36eBUF0Xnyto493wtKd2hAvTVJniVc26qWKN8T?=
 =?us-ascii?Q?dSpuPum7/G++CxAjhp3dIKI8Q5znjIYHMr1MGLEAyyVQu2XlIPqFAR17L46Y?=
 =?us-ascii?Q?bb7MmZtp3KclrP4iTOvQA8zKdJxO9MipcG0Oy+AoUNTFdQs1NbAhcX1Nm/86?=
 =?us-ascii?Q?1Peu2xORA53+BSihWJ73zkqOxQx/YuFvbhlcWtWMmNtLHI3Pz2jwrXfC4T8O?=
 =?us-ascii?Q?37/Elkd2sYibCBUwUR67hWVJCgJ9xnTfam1hSCz8piY4VJGt90tNB6ZlQIzb?=
 =?us-ascii?Q?Lyds9gLmmX8kzOvefTwFM4I09zrARiYXmYrJ4Imo4SsMbLbjO1hRKqDAydCN?=
 =?us-ascii?Q?xN8MIsfWCOeHnG2LRhRaIn/Mx9lHLIaC/uj7WoLHVPczqMes5jJcwEaQjPJ3?=
 =?us-ascii?Q?6T03bfLsmbPCZiy86hA=3D?=
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: 407090c7-8278-4efb-b352-08db4e09fca9
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2023 08:15:00.3509
 (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: 4zEHMb5bgdEH42AFF7+dR0vC68+QaaekrENB1dFQZ3YQinfDHZDo0emn+hqhyA8LkfRU5HaGaT6TOFvKvaSxlA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5562
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no
        version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> From: Alex Williamson <alex.williamson@redhat.com>
> Sent: Friday, May 5, 2023 11:28 PM
>=20
> On Fri, 5 May 2023 08:10:33 +0000
> "Tian, Kevin" <kevin.tian@intel.com> wrote:
>=20
> > > From: Chatre, Reinette <reinette.chatre@intel.com>
> > > Sent: Saturday, April 29, 2023 2:35 AM
> > >
> > > Hi Kevin,
> > >
> > > On 4/27/2023 11:50 PM, Tian, Kevin wrote:
> > >
> > > > Should this behavior be something configurable?
> > >
> > > This is not clear to me and I look to you for guidance here. From pra=
ctical
> > > side it looks like configuration via module parameters is supported b=
ut
> > > whether it should be done is not clear to me.
> > >
> > > When considering this we need to think about what the user may expect
> > > when
> > > turning on/off the configuration. For example, MSI-X continues to
> allocate a
> > > range of interrupts during enabling. These have always been treated a=
s a
> > > "cache" (interrupts remain allocated, whether they have an associated
> > > trigger
> > > or not). If there is new configurable behavior, do you expect that th=
e
> > > driver needs to distinguish between the original "cache" that the use=
r is
> > > used to and the new dynamic allocations? That is, should a dynamic MS=
I-
> X
> > > capable device always free interrupts when user space removes an
> eventfd
> > > or should only interrupts that were allocated dynamically be freed
> > > dynamically?
> >
> > That looks tricky. Probably that is why Alex suggested doing this simpl=
e
> > scheme and it is on par with the old logic anyway. So I'll withdraw thi=
s
> > comment.
>=20
> Don't forget we're also releasing the irq reservations when the guest
> changes interrupt mode, ex. reboot, so the "caching" is really only
> within a session of the guest/userspace driver where it would be
> unusual to have an unused reservation for an extended period.  Thanks,
>=20

Yeah, that makes sense.