From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 02EFBC433E0 for ; Thu, 9 Jul 2020 07:34:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DFC0820767 for ; Thu, 9 Jul 2020 07:34:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726215AbgGIHe2 (ORCPT ); Thu, 9 Jul 2020 03:34:28 -0400 Received: from mga02.intel.com ([134.134.136.20]:6929 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726183AbgGIHe2 (ORCPT ); Thu, 9 Jul 2020 03:34:28 -0400 IronPort-SDR: ingPK0Kpk/rgKwctWDZkJqfMeZ/SgxIN4xKja1dRVBX+AZ8+BmVuqekqj73ctpiOUj5ATL1jSA 9U4b8S8WhkdQ== X-IronPort-AV: E=McAfee;i="6000,8403,9676"; a="136180512" X-IronPort-AV: E=Sophos;i="5.75,331,1589266800"; d="scan'208";a="136180512" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2020 00:34:27 -0700 IronPort-SDR: f/eYnhavZCn1yjv9xOCAJdG710/TGGtn9AGr/1GgIHabbiv1OTckeOG6XwvFLd9Z1w+XpwSLFX 6zMECFhaP12g== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,331,1589266800"; d="scan'208";a="483699986" Received: from joy-optiplex-7040.sh.intel.com (HELO joy-OptiPlex-7040) ([10.239.13.16]) by fmsmga006.fm.intel.com with ESMTP; 09 Jul 2020 00:34:25 -0700 Date: Thu, 9 Jul 2020 15:23:34 +0800 From: Yan Zhao To: "Tian, Kevin" Cc: Alex Williamson , "intel-gvt-dev@lists.freedesktop.org" , "kvm@vger.kernel.org" , Zhenyu Wang Subject: Re: [PATCH v3 0/2] VFIO mdev aggregated resources handling Message-ID: <20200709072334.GA26155@joy-OptiPlex-7040> Reply-To: Yan Zhao References: <20200326054136.2543-1-zhenyuw@linux.intel.com> <20200408055824.2378-1-zhenyuw@linux.intel.com> <20200707190634.4d9055fe@x1.home> <20200708124806.058e33d9@x1.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Thu, Jul 09, 2020 at 02:53:05AM +0000, Tian, Kevin wrote: <...> > > We also can't even seem to agree that type is a necessary requirement > > for compatibility. Your discussion below of a type-A, which is > > equivalent to a type-B w/ aggregation set to some value is an example > > of this. We might also have physical devices with extensions to > > support migration. These could possibly be compatible with full mdev > > devices. We have no idea how an administrative tool would discover > > this other than an exhaustive search across every possible target. > > That's ugly but feasible when considering a single target host, but > > completely untenable when considering a datacenter. > > If exhaustive search can be done just one-off to build the compatibility > database for all assignable devices on each node, then it might be > still tenable in datacenter? yes, Alex, do you think below behavior to build compatibility database is acceptable? management stack could do the exhaustive search in one shot to build the compatibility database for all devices in every node. Meanwhile, it caches migration version strings for all tested devices. when there's a newly created/attached device, management stack could write every cached strings to migration version attribute of the newly created/attached device in order to update the migration compatibility database. Then it caches the migration version string of the newly created/attached device as well. once a device attribute is modified, e.g. after changing its aggregation count or updating its parent driver, update its cached migration version string and update the compatibility database by testing against migration version attribute of this device. Thanks Yan