Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 27 Sep 2021 15:32:06 -0300
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Leon Romanovsky <leonro@nvidia.com>
Cc:     Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "mgurtovoy@nvidia.com" <mgurtovoy@nvidia.com>,
        liulongfang <liulongfang@huawei.com>,
        "Zengtao (B)" <prime.zeng@hisilicon.com>,
        Jonathan Cameron <jonathan.cameron@huawei.com>,
        "Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: Re: [PATCH v3 6/6] hisi_acc_vfio_pci: Add support for VFIO live
 migration
Message-ID: <20210927183206.GA1576241@nvidia.com>
References: <20210915130742.GJ4065468@nvidia.com>
 <fe5d6659e28244da82b7028b403e11ae@huawei.com>
 <20210916135833.GB327412@nvidia.com>
 <a440256250c14182b9eefc77d5d399b8@huawei.com>
 <20210927150119.GB964074@nvidia.com>
 <YVHqlzyIX3099Gtz@unreal>
 <20210927160627.GC964074@nvidia.com>
 <YVIKr48e8G1wSxYX@unreal>
 <20210927182224.GA1575668@nvidia.com>
 <YVINv17OEHplrpeS@unreal>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YVINv17OEHplrpeS@unreal>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?WBPy+5ylFhEb56ePMrHXtogaRAo04HYABITEr7nn6nMDtEI0hrVLJuMeOu/l?=
 =?us-ascii?Q?1+6c/DuEztMlDPbuznB7/ED3ffhMcQ1odLiJRKVrBycI8wTLMmSc42ck4m/Z?=
 =?us-ascii?Q?ROaLw51Oti93MFWGEmilhdh3AKRvyCADuBZACuYXJolAqIDsFcIVrl2ohLOZ?=
 =?us-ascii?Q?5Wuklche4D7Fs+mCspanw5xoB1/1+lgfxNo8sfO7E4IviHrb97iGinfe6azY?=
 =?us-ascii?Q?m4ZT0kywAiYVqV6nazWs7dmRcGQH2y/BwWWc1F3vlrKI2j8/xBFqt4lqAuOx?=
 =?us-ascii?Q?6I20f/DcteQvXWFlXNqxGMcgEkT3Eh2vqIxc27FzfEkT7RquFg70NaLubNEq?=
 =?us-ascii?Q?2z+hdAtaQf9HFloGsEdjDZTySjd/YNSr04DI4jakuw8qCQq48lYdIG29HV6t?=
 =?us-ascii?Q?7Ckqe4BXdGTWT6IZtYk783B1kuGop+oycJYoWfKwozr1UKFpBXFcdan5Ed4K?=
 =?us-ascii?Q?PIB8j/HdF1NMon8Q9coELk7HV1VUp0EosPuQva9ql/RQVw1t17C6q46HBgpF?=
 =?us-ascii?Q?gh71UwLPDEVVbHt2UKodET2cicVAo655QikvifHEVBgqvoaLi4P9bVuZ9emL?=
 =?us-ascii?Q?VG8LSYFUBK1E/+RgbESMLUeUtAqHL2++o2WVVQrmWyJkGuD9tl11UreCzi1w?=
 =?us-ascii?Q?kIP8GZsOTIrE5I3ESl7G7GhT8ZccV/l2GAUzXZ6WxN4Le3Ia+UIeszBwY1Bi?=
 =?us-ascii?Q?2ERvwj39SBbOM3l/v08srkwfdTbqDr7NvRyY8aITGzuia4xv0GS6CZeL1CFO?=
 =?us-ascii?Q?YeMacNMLqoWWu/n+qc8lbpONj2BIh7i+A14D1h1g3nrHcplb8G6N/Mnv+JrQ?=
 =?us-ascii?Q?RKnm61Gdux781a0y5mxS8wiIqcNRrkyJ+ns6sP+zLwWMOCh2/2SXA6CMkFd8?=
 =?us-ascii?Q?vlHw1dH2RVci0uFTQVb2MhcfL9wt0d/2/mrHzZSyijeUO+rRu5TrrJ7QJMZH?=
 =?us-ascii?Q?iDzSe1RdxMNdABRG9r4fqiJu8/tiNIpAjNwXL4/bM4b2XJT0xqCnLZOKS4e1?=
 =?us-ascii?Q?p/VyTP0XWPhJpYh9EXrqjqL41fuawgB1pLM/j0N7r+hXOXIR/5IeC2ZOoF2i?=
 =?us-ascii?Q?4GR/DaECb5F38ckGLQNot9aZtvoLgd8q9fHCcTeU6EehHF+pLSD5uRDidi7E?=
 =?us-ascii?Q?VSM7oTdM2G4zjHFrBDuQ40IOBFId+4dNpQM1w8MVeXKgEe814DfrXWdZR2mI?=
 =?us-ascii?Q?qgRea+eae2Rpb1LTe/yofqggrfYYl9t6K3YhmNK+eb5mzYNapOUwm0MMakNR?=
 =?us-ascii?Q?uFRjaqECrHjR/jrj1vgfrziq42e40q+7ftQ8tX7XRTcUmJ/SDixIcxonNKX6?=
 =?us-ascii?Q?LCeXqmGWI4cam6DUdX7JGY/d?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4b94781e-5625-4f86-9153-08d981e51cb6
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Sep 2021 18:32:08.0290
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8E031iIiQkMSK7M5yTN0DUO2AR5pyy1W8WE6WGbJxfI5jmxeh2pWIZNF8fz5dmak
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB5554
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On Mon, Sep 27, 2021 at 09:30:23PM +0300, Leon Romanovsky wrote:
> On Mon, Sep 27, 2021 at 03:22:24PM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 27, 2021 at 09:17:19PM +0300, Leon Romanovsky wrote:
> > 
> > > > The point is to all out a different locking regime that relies on the
> > > > sriov enable/disable removing the VF struct devices
> > > 
> > > You can't avoid trylock, because this pci_get_sriov_pf_devdata() will be
> > > called in VF where it already holds lock, so attempt to take PF lock
> > > will cause to deadlock.
> > 
> > My whole point is we cannot use the device_lock *at all* and a
> > pci_get_sriov_pf_devdata() would not have it.
> 
> Right
> 
> > 
> > Instead it would have some test to confirm that the 'current' struct
> > device is a VF of the 'target' struct device and thus the drvdata
> > must be valid so long as the 'current' struct device hasn't completed
> > remove.
> 
> I'm curious to see how can you implement it without holding VF lock.

The VF lock is fine, it is the PF lock you can't take

And you don't need the VF lock or the PF lock if it is called in a
context that blocks VF remove() from completing - which describes an
entire VFIO driver.

Jason