[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BL1PR11MB52718BE8A6D1BC328CE4CF5D8CAC9@BL1PR11MB5271.namprd11.prod.outlook.com>
Date: Thu, 16 Jun 2022 06:29:22 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: Nicolin Chen <nicolinc@...dia.com>,
"joro@...tes.org" <joro@...tes.org>,
"will@...nel.org" <will@...nel.org>,
"marcan@...can.st" <marcan@...can.st>,
"sven@...npeter.dev" <sven@...npeter.dev>,
"robin.murphy@....com" <robin.murphy@....com>,
"robdclark@...il.com" <robdclark@...il.com>,
"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>,
"matthias.bgg@...il.com" <matthias.bgg@...il.com>,
"orsonzhai@...il.com" <orsonzhai@...il.com>,
"baolin.wang7@...il.com" <baolin.wang7@...il.com>,
"zhang.lyra@...il.com" <zhang.lyra@...il.com>,
"jean-philippe@...aro.org" <jean-philippe@...aro.org>,
"alex.williamson@...hat.com" <alex.williamson@...hat.com>,
"jgg@...dia.com" <jgg@...dia.com>
CC: "suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
"alyssa@...enzweig.io" <alyssa@...enzweig.io>,
"dwmw2@...radead.org" <dwmw2@...radead.org>,
"yong.wu@...iatek.com" <yong.wu@...iatek.com>,
"mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
"gerald.schaefer@...ux.ibm.com" <gerald.schaefer@...ux.ibm.com>,
"thierry.reding@...il.com" <thierry.reding@...il.com>,
"vdumpa@...dia.com" <vdumpa@...dia.com>,
"jonathanh@...dia.com" <jonathanh@...dia.com>,
"cohuck@...hat.com" <cohuck@...hat.com>,
"thunder.leizhen@...wei.com" <thunder.leizhen@...wei.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"christophe.jaillet@...adoo.fr" <christophe.jaillet@...adoo.fr>,
"john.garry@...wei.com" <john.garry@...wei.com>,
"chenxiang66@...ilicon.com" <chenxiang66@...ilicon.com>,
"saiprakash.ranjan@...eaurora.org" <saiprakash.ranjan@...eaurora.org>,
"isaacm@...eaurora.org" <isaacm@...eaurora.org>,
"yangyingliang@...wei.com" <yangyingliang@...wei.com>,
"jordan@...micpenguin.net" <jordan@...micpenguin.net>,
"iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
"virtualization@...ts.linux-foundation.org"
<virtualization@...ts.linux-foundation.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>
Subject: RE: [PATCH v2 2/5] vfio/iommu_type1: Prefer to reuse domains vs match
enforced cache coherency
> From: Nicolin Chen <nicolinc@...dia.com>
> Sent: Thursday, June 16, 2022 8:03 AM
>
> From: Jason Gunthorpe <jgg@...dia.com>
>
> The KVM mechanism for controlling wbinvd is based on OR of the coherency
> property of all devices attached to a guest, no matter those devices are
> attached to a single domain or multiple domains.
>
> So, there is no value in trying to push a device that could do enforced
> cache coherency to a dedicated domain vs re-using an existing domain
> which is non-coherent since KVM won't be able to take advantage of it.
> This just wastes domain memory.
>
> Simplify this code and eliminate the test. This removes the only logic
> that needed to have a dummy domain attached prior to searching for a
> matching domain and simplifies the next patches.
>
> It's unclear whether we want to further optimize the Intel driver to
> update the domain coherency after a device is detached from it, at
> least not before KVM can be verified to handle such dynamics in related
> emulation paths (wbinvd, vcpu load, write_cr0, ept, etc.). In reality
> we don't see an usage requiring such optimization as the only device
> which imposes such non-coherency is Intel GPU which even doesn't
> support hotplug/hot remove.
>
> Signed-off-by: Jason Gunthorpe <jgg@...dia.com>
> Signed-off-by: Nicolin Chen <nicolinc@...dia.com>
Reviewed-by: Kevin Tian <kevin.tian@...el.com>
Powered by blists - more mailing lists