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:     Christoph Hellwig <hch@lst.de>, Max Gurtovoy <mgurtovoy@nvidia.com>
CC:     Jason Gunthorpe <jgg@ziepe.ca>, "Rao, Lei" <lei.rao@intel.com>,
        "kbusch@kernel.org" <kbusch@kernel.org>,
        "axboe@fb.com" <axboe@fb.com>, "kch@nvidia.com" <kch@nvidia.com>,
        "sagi@grimberg.me" <sagi@grimberg.me>,
        "alex.williamson@redhat.com" <alex.williamson@redhat.com>,
        "cohuck@redhat.com" <cohuck@redhat.com>,
        "yishaih@nvidia.com" <yishaih@nvidia.com>,
        "shameerali.kolothum.thodi@huawei.com" 
        <shameerali.kolothum.thodi@huawei.com>,
        "mjrosato@linux.ibm.com" <mjrosato@linux.ibm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "Dong, Eddie" <eddie.dong@intel.com>,
        "Li, Yadong" <yadong.li@intel.com>,
        "Liu, Yi L" <yi.l.liu@intel.com>,
        "Wilk, Konrad" <konrad.wilk@oracle.com>,
        "stephen@eideticom.com" <stephen@eideticom.com>,
        "Yuan, Hang" <hang.yuan@intel.com>
Subject: RE: [RFC PATCH 1/5] nvme-pci: add function nvme_submit_vf_cmd to
 issue admin commands for VF driver.
Thread-Topic: [RFC PATCH 1/5] nvme-pci: add function nvme_submit_vf_cmd to
 issue admin commands for VF driver.
Thread-Index: AQHZCTfLVudoTcTfbUW71RdNMUs3aK5gYwIAgAB8LwCAAAPrAIAAF5SAgAAEXoCAAAOwgIAAEcqAgAAnS4CAAHlwAIAAW7YAgALDKHA=
Date:   Fri, 9 Dec 2022 02:11:21 +0000
Message-ID: <BN9PR11MB52766AC1962858248B7030E28C1C9@BN9PR11MB5276.namprd11.prod.outlook.com>
References: <20221206055816.292304-2-lei.rao@intel.com>
 <20221206061940.GA6595@lst.de> <Y49HKHP9NrId39iH@ziepe.ca>
 <20221206135810.GA27689@lst.de> <Y49eObpI7QoSnugu@ziepe.ca>
 <20221206153811.GB2266@lst.de> <Y49k++D3i8DfLOLL@ziepe.ca>
 <20221206165503.GA8677@lst.de> <Y4+U3VR2LeEh2S7B@ziepe.ca>
 <2975e217-749b-6929-cd2d-4b6276ef33d1@nvidia.com>
 <20221207075834.GC2283@lst.de>
In-Reply-To: <20221207075834.GC2283@lst.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?HkL+6phhVIOajWpBhnVzShcEaQJDQKFqfHrtM+xv92paKdNifYn8fiDRHi1X?=
 =?us-ascii?Q?PWE1/Iqr+g1Iw4vT7m9mY+osonBr7NCeBQ3U+K/T/QBk4dDJDUMr5JjG5Her?=
 =?us-ascii?Q?1028E3g4n5vpAG02vAAwo9oRipsMvvDHBbHkLyaIQeoJARpwvUCq3mrGEVG/?=
 =?us-ascii?Q?al+zt2pT7hixACmP7XWKYuA5x+4GIj9s8nzzXruxgcu8Eorqvu15bWgM5jH8?=
 =?us-ascii?Q?aZjLVflijttI6GSo+r6fbucfV1arxOFzx8dV8QxJoF21vg/3072tN2KyWoKp?=
 =?us-ascii?Q?2KqhjC9TK9dwNX59TZG+c/IQ8UndisQSB+idn+vbJAVw4NeFGepTIz9kyrel?=
 =?us-ascii?Q?/7/EuTf2Um+SCr/dduRfsuhS8dCsX/ClZoCd44XrtCPY9woDPJbipAHmtZNG?=
 =?us-ascii?Q?h2lG1Td6nwYujrwbsITjiHJEjnxddkQi9b+kCpPFihpZxz+BvJvhAz+X/65m?=
 =?us-ascii?Q?FhOvA30/h3KndCRgCVhgA3xu3qSPPBxOrk3WLxk48o8cPCjLg8Kcd+UGszwv?=
 =?us-ascii?Q?9/alxQ8+tkDB3+3qH7iqkicwxahrJqXaImnN2c2znWIM1bvS7pNnFjRr8GsJ?=
 =?us-ascii?Q?YEFqV6u+mPpnAjj5BJrTHSpRTL5WeQjnMPwYo0iYqLa/LO/CVopOlq2cs2jS?=
 =?us-ascii?Q?+rKXH9G9ZOSyXWBcn8woOsewTsJSNbwYladjhw+DamQR86RQqZIUxTZXZqJ/?=
 =?us-ascii?Q?C0B54cmS+qAIMvqeWNSuD0tOHb3vRaw3O3RBHIWDOK+t1eMXoyLYgirN8LhN?=
 =?us-ascii?Q?zH+zSB9U9u5rUzM/6izHMG9/Vi+FOKoVmc0RhEVs3nDjj441T3rRIPgummtL?=
 =?us-ascii?Q?c1G+/TZrdEmzmyW7w8ZR1kzGjITh3pwJDqw18Cz8anQ06jRJ4mwFs75IPNuf?=
 =?us-ascii?Q?+xOyzW29WxLUJe6UHy5ulJJLG05v7f+4rUbJfn8drQYXHNtOjshJlGDfGUlL?=
 =?us-ascii?Q?GTHPnHZh0dJzwLKG/IKcvrMeLwKnZP8y+3ZHVDqOxvuD5eSDpQng4e13u+ZH?=
 =?us-ascii?Q?66DfGxDiJ4Vl4V3VARa8lzQw60maDvsintKHL1J2gQdfiTdBhXtv3yLRHJKS?=
 =?us-ascii?Q?uXBakzNzJzspsURGe8x4JsRIs1ic03AwFVA1obKyYzb/Wcf8Do4xam2Cq3dL?=
 =?us-ascii?Q?mk8MXS2JEdpjdI26UGtTcU6+sy59e7rCK3XAfzxwMqblsU6phrhxbOob+Imc?=
 =?us-ascii?Q?Pgcs68UkWFIHEH9VsI4LF/vKluTU/9J9izH2Tf+a8McUbYOSYQJ1NAFqIuiS?=
 =?us-ascii?Q?yNJrZyV/sHo71H08BiqeiCifthamIY97itqi0Byran60CaQw/Vny9PhOQDDs?=
 =?us-ascii?Q?HFc3cDxNX/yURpiOklFlaUAjMibRacKJGUXHOfgVLzzOWmFAXFw6CK8Qi0fs?=
 =?us-ascii?Q?o2bA3c3KNIDWv4kc2um+178DPpl2T7XK/SXNUgPRdcSzcMP+hhnoBItmK1Vp?=
 =?us-ascii?Q?u+2zzM2+3SZK+wGLhoAIS7uXyhn8Bx/5HFhark3aa8XEB+JTW6M3b9fJAbBa?=
 =?us-ascii?Q?ss8Bx6cYNe1ZfuPJZvLz10ECI0W6TCWFKSgovxLQon99BVl2z+sv89oDIuRj?=
 =?us-ascii?Q?spFeQii2e8r1Dapx8rDXEVYn2GbgfMdUO4xCEGDK?=
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: fe54fa1b-e8b8-4cd6-2056-08dad98aaa7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2022 02:11:21.4631
 (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: hrm7/Lkvu0a1jGPZikUIs76nirozCxDiPvgDvVui9T/53j2oSKpvA2U0vHR/KMcxWEUJKTW7ZCq+taypuPu6gw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6010
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE 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: Christoph Hellwig <hch@lst.de>
> Sent: Wednesday, December 7, 2022 3:59 PM
>=20
> On Wed, Dec 07, 2022 at 04:30:20AM +0200, Max Gurtovoy wrote:
> > I'm not sure how awkward is for migration driver to ask the controlling
> > device driver to operate a migration action.
>=20
> It can't.  That's the whole point.  The controlled function that is
> being migrate must be absolutely unaware of that (except for things
> like quiescing access or FLRs that could happen anyway), because
> otherwise your have a fundamental information leak.
>=20

Can you elaborate which information is leaked?

No matter who provides the uAPI (controlling or controlled), end of
the day it's the same cmd invoked on the controlling device to save/
restore the state of the controlled device itself.