Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
From:   "Wang, Zhi A" <zhi.a.wang@intel.com>
To:     Christoph Hellwig <hch@lst.de>,
        Jani Nikula <jani.nikula@linux.intel.com>
CC:     Zhi Wang <zhi.wang.linux@gmail.com>,
        "jgg@nvidia.com" <jgg@nvidia.com>,
        "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>,
        "intel-gvt-dev@lists.freedesktop.org" 
        <intel-gvt-dev@lists.freedesktop.org>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
        "Vivi, Rodrigo" <rodrigo.vivi@intel.com>,
        Zhenyu Wang <zhenyuw@linux.intel.com>,
        "Xu, Terrence" <terrence.xu@intel.com>
Subject: Re: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO
 new mdev API
Thread-Topic: [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support
 VFIO new mdev API
Thread-Index: AQHYHNy+WB6hSk3In0CMw3y1iZvDnKyJw40AgAEP4YCAANFZAA==
Date:   Wed, 9 Feb 2022 19:57:23 +0000
Message-ID: <4e2faf7b-383e-58b3-8ae9-8f8d25c64420@intel.com>
References: <20220208111151.13115-1-zhi.a.wang@intel.com>
 <871r0dqtjf.fsf@intel.com> <20220209072805.GA9050@lst.de>
In-Reply-To: <20220209072805.GA9050@lst.de>
Accept-Language: en-FI, en-US
Content-Language: aa
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.14.0
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?MLAPRjzTkfEpOC9TyMZrOjNI0hxYv1pINttcRuicnthyZIFjJ3sya8Ai?=
 =?Windows-1252?Q?NZnUiH5AIRM3uGicZAGJTZWi+Tptq0nujQ/9tI41ZREwyop9CdgJ7py4?=
 =?Windows-1252?Q?qnCzV+DHdpD17iyEUwNwzVusJIMWhffvu9We3mUlEGk4nEIO+A1FciIT?=
 =?Windows-1252?Q?kBY1Aef+OTYCOp5Sp2a9FQj1cBrTCVmfbnLSDImC0E7B9GuCG8y0cGPM?=
 =?Windows-1252?Q?KzetSBOOuJADA5eIdOgr6uroBwKQde5lbVLwfm2RtivxIYDj1fobL2H5?=
 =?Windows-1252?Q?lIv0fyG+XKyJOheacw2ffPaAnKpy+RnFchxp6kbvhZSXyKHlPt0KETT7?=
 =?Windows-1252?Q?oU+UFRPJg9ycDos28s6ib51rgw0dXxeGAHgF/z61BUEVIRqBgivV6078?=
 =?Windows-1252?Q?VaDHpqXva7M21rHJfwQYQHFMW7ntSrEZL0+nxZ/omXvAbDQ/zZrNA+3U?=
 =?Windows-1252?Q?zRr2nyh4BmBKIu4kj3KJ2d//4S0sNZFv5D/uUvDTubOKU0OdJ7THZfZt?=
 =?Windows-1252?Q?asDqATOaAtNQBzNC6tVsteETR7920fHZvGiCt5f2htz5Ecwry8YRIR25?=
 =?Windows-1252?Q?dWD+REJqIFofqMFNBN8FrTWC/3ERuwnCXxDfxzyc6r7JYgtWYvDcKDH8?=
 =?Windows-1252?Q?m4ToDZiXPlPlOWhJNYJXacMZ4ejO/aH2AG552ckDyBoBKyPMr5RwSCEg?=
 =?Windows-1252?Q?DnEFAZU654IPx2jxHFrYrdJqlrzIpWN3k/5ZxCSge12KhWHURgk/ze6L?=
 =?Windows-1252?Q?aLnLfpRy7D6JE+JcJxxY/zHd1Pp8RXalQ7vV0yVPFJeYJVSuuoNia5dt?=
 =?Windows-1252?Q?b4y/9ltNkQtvVipWoaz87/UXjqpT45JSBbDqML9E6KTpHjTzsXtKObI+?=
 =?Windows-1252?Q?B5Pef6fI1UCuyEZhriHkA9un5v7VhNT7g+jNb63D4M8njlm1/mGx1e/X?=
 =?Windows-1252?Q?otnnagMZDEpeud3P0ASiYrw2C1Kq26LGvUpaxk92xMiSvC1tRFkL1HaQ?=
 =?Windows-1252?Q?0i1YJE19Vk447IhUGLz79OxlHRPff+90lCvwW6zOV2c3H/U12C5Mq7YG?=
 =?Windows-1252?Q?ENf5KuDT15TcS+wcJTI1SQpGQ6Eu9MwfS3jlvSm1/oSI4rgAcaAQvb5C?=
 =?Windows-1252?Q?GscJmA53viRlWZZL3OYmfOYGSkJnrK4yvXcvoYzLekzLe4QpKBpcH8mV?=
 =?Windows-1252?Q?ZgqF2AdRy250roeN9EgTNaGq/OKTQ4VNOFg2qN/VOhFN63uZ6Y/Hz3S+?=
 =?Windows-1252?Q?qnkYEHWz3sJHEFRRt+TtKwk9I4NNbiFz491KWj3OyMkQLnPBgw4PlUA0?=
 =?Windows-1252?Q?jygfppf/b81MLYM1zNvGSJ9Bt91Hu8EaDX8bCYdrQpVkKkRxTryQ8mr3?=
 =?Windows-1252?Q?X7Tfy1UHqcFZuIJWkHUUg3sIJNxb4Pp37Cn1eqBxjyOwa7O40NUa39+f?=
 =?Windows-1252?Q?K7MPuJk0zSBGgvcaR3tZW6b7i9nOm9H13mgZgD55f3FH81afPwoDsb6H?=
 =?Windows-1252?Q?eA+NaxWKc2ph2W4YcfiRiNYdOmcWrdvAsmSfrSJiRJkVNeot5c1wM1Qp?=
 =?Windows-1252?Q?PkYjKzSEBSsdhyGbbRrh0Yq0Rp+GKlf4u9PF2ERH95xfo8dWfgyd9fR0?=
 =?Windows-1252?Q?y6hAPgA/clEEC7/n+tUjs1K0YmQUxAQ21fd7AYoPqvOMdCmELO8g7k3N?=
 =?Windows-1252?Q?HFsbm9CZYUWEH4GcWhzwWmXiGL/m2oNrgpmQP1YryP7LpNS4rns+6xox?=
 =?Windows-1252?Q?efrVAJTPR0mpC93n3P8=3D?=
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <75D52C3B1C0F9C49BD26FEA202295FEF@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5549.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bddf839d-7052-43d7-b745-08d9ec066384
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2022 19:57:23.2455
 (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: wmjRDnsfr17iM899sbIFY7lFQ3y8JoiUchgwx6t+PRsJqFn31hjYBfHGNw5jxc9RLe10hvSKtdqQ6451SZ6EdA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR11MB5691
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=no 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

On 2/9/22 7:28 AM, Christoph Hellwig wrote:
> On Tue, Feb 08, 2022 at 05:15:00PM +0200, Jani Nikula wrote:
>>>  #ifdef CONFIG_DRM_I915_GVT
>>> +
>>> +#define D_BDW   (1 << 0)
>>> +#define D_SKL	(1 << 1)
>>> +#define D_KBL	(1 << 2)
>>> +#define D_BXT	(1 << 3)
>>> +#define D_CFL	(1 << 4)
>>> +
>>> +#define D_GEN9PLUS	(D_SKL | D_KBL | D_BXT | D_CFL)
>>> +#define D_GEN8PLUS	(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>>> +
>>> +#define D_SKL_PLUS	(D_SKL | D_KBL | D_BXT | D_CFL)
>>> +#define D_BDW_PLUS	(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>>> +
>>> +#define D_PRE_SKL	(D_BDW)
>>> +#define D_ALL		(D_BDW | D_SKL | D_KBL | D_BXT | D_CFL)
>>
>> If these really need to be in a header in i915/, I think they need to be
>> longer with some namespacing or something. I do wish these could be
>> hidden though.
>=20
> I think we could actually kill them off entirely.  They are used as
> arguments to the macros that setup the mmio table.
>=20
> Thefunctions to build these tabls are already organized by families,
> so we'd need relatively few conditions to just build them the right
> way.  There also are some runtime checks in the callbacks, but they
> seem entirely superflous as far as I can tell.
>=20
> Only the cmd parser is a bit messy.  So maybe we could keep these
> constants just for the cmd parser inside of gvt for now (and clean
> that up later) and remove them entirely from the mmio table.
>=20
I agree that's the correct way for not exporting this to i915 by just organ=
izing them in the functions, like what you said.
But I guess it's also matter of time and schedule as well. If we go that di=
rection, it might take longer time for coding as
this is a big re-factor. Also, we need our QA to do another full test run. =
That needs to be considered. (If we are ok with that)

Besides, we have to have a methodology to make sure everything is the same =
as before.
Currently I am comparing the numbers of tracked mmio and the mmio snapshot.=
 It would be nice to have more insight. :)

Thanks,
Zhi.