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
Date: Wed, 9 Feb 2022 19:57:23 +0000 [thread overview]
Message-ID: <4e2faf7b-383e-58b3-8ae9-8f8d25c64420@intel.com> (raw)
In-Reply-To: <20220209072805.GA9050@lst.de>
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.
>
> I think we could actually kill them off entirely. They are used as
> arguments to the macros that setup the mmio table.
>
> 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.
>
> 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.
>
I agree that's the correct way for not exporting this to i915 by just organizing 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 direction, 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.
next prev parent reply other threads:[~2022-02-09 19:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 11:11 [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API Zhi Wang
2022-02-08 11:11 ` [PATCH v6 2/3] i915/gvt: Save the initial HW state snapshot in i915 Zhi Wang
2022-02-09 7:32 ` Christoph Hellwig
2022-02-09 19:50 ` Wang, Zhi A
2022-02-08 11:11 ` [PATCH v6 3/3] i915/gvt: Use the initial HW state snapshot saved " Zhi Wang
2022-02-09 7:32 ` Christoph Hellwig
2022-02-08 15:15 ` [PATCH v6 1/3] i915/gvt: Introduce the mmio table to support VFIO new mdev API Jani Nikula
2022-02-09 7:28 ` Christoph Hellwig
2022-02-09 9:04 ` Jani Nikula
2022-02-09 19:57 ` Wang, Zhi A
2022-02-09 19:57 ` Wang, Zhi A [this message]
2022-03-15 7:52 ` Christoph Hellwig
2022-03-15 8:46 ` Jani Nikula
2022-03-15 8:48 ` Christoph Hellwig
2022-03-15 8:59 ` Wang, Zhi A
2022-03-15 9:16 ` Jani Nikula
2022-02-09 7:36 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4e2faf7b-383e-58b3-8ae9-8f8d25c64420@intel.com \
--to=zhi.a.wang@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hch@lst.de \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jgg@nvidia.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=terrence.xu@intel.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.wang.linux@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).