All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	"Yuan, Hang" <hang.yuan@intel.com>,
	"Lv, Zhiyuan" <zhiyuan.lv@intel.com>,
	intel-gvt-dev <intel-gvt-dev@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PULL] gvt-gt-next
Date: Thu, 21 Jan 2021 15:15:19 +0200	[thread overview]
Message-ID: <161123491821.9094.16627785208035798444@jlahtine-mobl.ger.corp.intel.com> (raw)
In-Reply-To: <20210121040825.GG15982@zhen-hp.sh.intel.com>

Quoting Zhenyu Wang (2021-01-21 06:08:25)
> On 2021.01.20 14:21:53 +0200, Joonas Lahtinen wrote:
> > Quoting Zhenyu Wang (2021-01-18 07:07:39)
> > > 
> > > Hi,
> > > 
> > > This is GVT next for 5.12 against drm-intel-gt-next which is mostly
> > > for cmd parser enhancement which adds extra check on register load
> > > depending on initial context and handles vGPU register state
> > > accordingly.
> > 
> > I think we were bit inconclusive on this last time.
> >
> 
> Sorry about that, I was thinking we might just follow your previous idea.
> 
> > Even if this does not have any dependency to drm-intel-gt-next I can
> > pull this to drm-intel-gt-next. The only caveat is that for any -fixes,
> > there needs to be a backmerge to drm-intel-next.
> > 
> > Not sure if this is a problem. Do we want to make it a recurring practice
> > to backmerge drm-intel-gt-next into drm-intel-next after it lands in
> > drm-next?
> >
> 
> So -gt-next won't do -gt-next-fixes, right? For -next-fixes, we always do
> drm-next backmerge, right?
> 
> > So to recap: Do we want to pull to drm-intel-next whenever there are no
> > dependencies to drm-intel-gt-next, to avoid a backmerge?
> 
> yeah, that's fine to me. But for this time gvt-next pull, it's really targeting
> for -gt-next which has some dependency, I can double check to confirm.

I've now pulled to drm-intel-gt-next.

Indeed any changes in i915/gt side that affect GVT would become
dependencies.

I think it would be good to continue on the plan to build GVT as a
completely separate module and have a clear definition of the interface
between the two.

Regards, Joonas

> Thanks.
> 
> > Or do we want
> > to always do a backmerge in anticipation of -fixes.
> > 
> > Regards, Joonas
> > 
> > > Thanks.
> > > --
> > > The following changes since commit fe7bcfaeb2b775f257348dc7b935f8e80eef3e7d:
> > > 
> > >   drm/i915/gt: Refactor heartbeat request construction and submission (2020-12-24 18:07:26 +0000)
> > > 
> > > are available in the Git repository at:
> > > 
> > >   https://github.com/intel/gvt-linux tags/gvt-gt-next-2021-01-18
> > > 
> > > for you to fetch changes up to 02dd2b12a685944c4d52c569d05f636372a7b6c7:
> > > 
> > >   drm/i915/gvt: unify lri cmd handler and mmio handlers (2020-12-25 11:16:32 +0800)
> > > 
> > > ----------------------------------------------------------------
> > > gvt-gt-next-2021-01-18
> > > 
> > > - GVT cmd parser enhancement against guest context (Yan)
> > > 
> > > ----------------------------------------------------------------
> > > Yan Zhao (11):
> > >       drm/i915/gvt: parse init context to update cmd accessible reg whitelist
> > >       drm/i915/gvt: scan VM ctx pages
> > >       drm/i915/gvt: filter cmds "srm" and "lrm" in cmd_handler
> > >       drm/i915/gvt: filter cmds "lrr-src" and "lrr-dst" in cmd_handler
> > >       drm/i915/gvt: filter cmd "pipe-ctrl" in cmd_handler
> > >       drm/i915/gvt: export find_mmio_info
> > >       drm/i915/gvt: make width of mmio_attribute bigger
> > >       drm/i915/gvt: introduce a new flag F_CMD_WRITE_PATCH
> > >       drm/i915/gvt: statically set F_CMD_WRITE_PATCH flag
> > >       drm/i915/gvt: update F_CMD_WRITE_PATCH flag when parsing init ctx
> > >       drm/i915/gvt: unify lri cmd handler and mmio handlers
> > > 
> > >  drivers/gpu/drm/i915/gvt/cmd_parser.c | 335 +++++++++++++++++++++++++++-------
> > >  drivers/gpu/drm/i915/gvt/cmd_parser.h |   4 +
> > >  drivers/gpu/drm/i915/gvt/gvt.h        |  37 +++-
> > >  drivers/gpu/drm/i915/gvt/handlers.c   |  15 +-
> > >  drivers/gpu/drm/i915/gvt/mmio.h       |   3 +
> > >  drivers/gpu/drm/i915/gvt/reg.h        |   2 +
> > >  drivers/gpu/drm/i915/gvt/scheduler.c  |  22 ++-
> > >  drivers/gpu/drm/i915/gvt/vgpu.c       |   4 +-
> > >  8 files changed, 339 insertions(+), 83 deletions(-)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-01-21 13:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18  5:07 [Intel-gfx] [PULL] gvt-gt-next Zhenyu Wang
2021-01-20 12:21 ` Joonas Lahtinen
2021-01-20 15:55   ` Vivi, Rodrigo
2021-01-21  4:08   ` Zhenyu Wang
2021-01-21 13:15     ` Joonas Lahtinen [this message]
2021-01-21 13:53       ` Joonas Lahtinen
2021-01-21 14:17         ` Jani Nikula
2021-02-05  7:30 Zhenyu Wang

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=161123491821.9094.16627785208035798444@jlahtine-mobl.ger.corp.intel.com \
    --to=joonas.lahtinen@linux.intel.com \
    --cc=hang.yuan@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-gvt-dev@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=zhenyuw@linux.intel.com \
    --cc=zhiyuan.lv@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.