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 3ED7FC433E0 for ; Wed, 8 Jul 2020 03:51:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2361720720 for ; Wed, 8 Jul 2020 03:51:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729621AbgGHDvs (ORCPT ); Tue, 7 Jul 2020 23:51:48 -0400 Received: from mga03.intel.com ([134.134.136.65]:60761 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728441AbgGHDvs (ORCPT ); Tue, 7 Jul 2020 23:51:48 -0400 IronPort-SDR: wtDUDNTi2rpp+bdp/zUdvJcorSYc41MCtZbbQyefSIzZH62AOAcNKD+jMF04+B2Jg41qwrd9qX 9fbasx7L5fwg== X-IronPort-AV: E=McAfee;i="6000,8403,9675"; a="147740906" X-IronPort-AV: E=Sophos;i="5.75,326,1589266800"; d="scan'208";a="147740906" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2020 20:51:47 -0700 IronPort-SDR: ++OOhQv1gHr9jkoJJZShVKt4YOVbSBBVtP62ae7bFSdmns+p4AKOnv0QF9G0Bo2xq5nkLjYeyJ 30oK+Qr25wZA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,326,1589266800"; d="scan'208";a="483744223" Received: from joy-optiplex-7040.sh.intel.com (HELO joy-OptiPlex-7040) ([10.239.13.16]) by fmsmga005.fm.intel.com with ESMTP; 07 Jul 2020 20:51:46 -0700 Date: Wed, 8 Jul 2020 11:40:55 +0800 From: Yan Zhao To: Zhenyu Wang Cc: Alex Williamson , "intel-gvt-dev@lists.freedesktop.org" , "Tian, Kevin" , "kvm@vger.kernel.org" Subject: Re: [PATCH v3 0/2] VFIO mdev aggregated resources handling Message-ID: <20200708034055.GC20022@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> <20200708015419.GM27035@zhen-hp.sh.intel.com> <20200708033845.GB20022@joy-OptiPlex-7040> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200708033845.GB20022@joy-OptiPlex-7040> 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 Wed, Jul 08, 2020 at 11:38:46AM +0800, Yan Zhao wrote: > On Wed, Jul 08, 2020 at 09:54:19AM +0800, Zhenyu Wang wrote: > > On 2020.07.07 19:06:34 -0600, Alex Williamson wrote: > > > On Tue, 7 Jul 2020 23:28:39 +0000 > > > "Tian, Kevin" wrote: > > > > > > > Hi, Alex, > > > > > > > > Gentle ping... Please let us know whether this version looks good. > > > > > > I figured this is entangled with the versioning scheme. There are > > > unanswered questions about how something that assumes a device of a > > > given type is software compatible to another device of the same type > > > handles aggregation and how the type class would indicate compatibility > > > with an aggregated instance. Thanks, > > > > > > > +Yan > > > > Alex, If no concern on aggregated resources info for instance that would > > be vendor's behavior to determine what type of resources would be aggregated, > > then I'll check with Yan to see how to fulfill this during migration. > > > > Thanks > > > > hi zhenyu and Alex > currently in this series, it looks that aggregated instances are created > in this way: > echo ",aggregate=10" > create > > Is that possible that we change it like that: > 1. provide a separate attribute named "aggregator" under mdev type. > |- [parent physical device] > |--- Vendor-specific-attributes [optional] > |--- [mdev_supported_types] > | |--- [] > | | |--- create > + | | |--- aggregator > | | |--- name > | | |--- available_instances > | | |--- device_api > | | |--- description > | | |--- [devices] > > normally, the aggregator is read as 0. > correction: normally, the aggregator is read as "1" > 2. when we want to create an aggregated instance, we first echo the count > into the aggregator attribute. e.g. > echo 10 > aggregator > It will switch the mdev type to 10 x original_type. And then, > available_instances and description would be updated accordingly. > > 3. do the real mdev creation. > echo > create > > > In this way, before any instance is created, we can use the > migration_version attribute to test if two aggregation mdevs are > migration compatible. > > Thanks > Yan > >