[Intel-gfx] [PULL] gvt-gt-next

[Intel-gfx] [PULL] gvt-gt-next

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 2022 bytes --]


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.

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(-)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-gt-next

[Joonas Lahtinen]

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.

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 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? 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

Re: [Intel-gfx] [PULL] gvt-gt-next

[Vivi, Rodrigo]

On Wed, 2021-01-20 at 14:21 +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.
> 
> 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 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?

It looks better indeed...

but how to proceed when we have dependencies? merge on both sides like
the topic branches?

>  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

Re: [Intel-gfx] [PULL] gvt-gt-next

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 3383 bytes --]

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.

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(-)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] gvt-gt-next

[Joonas Lahtinen]

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

Re: [Intel-gfx] [PULL] gvt-gt-next

[Joonas Lahtinen]

Quoting Joonas Lahtinen (2021-01-21 15:15:19)
> 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.

There was a header test build failure noticed by Chris:

drivers/gpu/drm/i915/gvt/cmd_parser.h:53:44: error: ‘struct intel_vgpu’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
   53 | void intel_gvt_update_reg_whitelist(struct intel_vgpu *vgpu);

It's now fixed in drm-intel-gt-next, you may want to backmerge after
drm-next lands the drm-intel-gt-next PR.

Regards, Joonas

> 
> 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

Re: [Intel-gfx] [PULL] gvt-gt-next

[Jani Nikula]

On Thu, 21 Jan 2021, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> Quoting Joonas Lahtinen (2021-01-21 15:15:19)
>> 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.
>
> There was a header test build failure noticed by Chris:
>
> drivers/gpu/drm/i915/gvt/cmd_parser.h:53:44: error: ‘struct intel_vgpu’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
>    53 | void intel_gvt_update_reg_whitelist(struct intel_vgpu *vgpu);

Please use CONFIG_DRM_I915_WERROR=y during development.

BR,
Jani.


>
> It's now fixed in drm-intel-gt-next, you may want to backmerge after
> drm-next lands the drm-intel-gt-next PR.
>
> Regards, Joonas
>
>> 
>> 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(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] gvt-gt-next

[Zhenyu Wang]

[-- Attachment #1.1: Type: text/plain, Size: 1607 bytes --]


Hi,

Here's more gvt next changes including ww locking fix from Zhi, and
replace to use i915 engine default state for GVT cmd parser init.
Those have all been verified without regression. Details below.

Thanks.
--
The following changes since commit 69b4b99842201bc24c98ba66b922d8879e190483:

  drm/i915/gvt: Add missing forward decl of intel_vgpu for HDRTEST (2021-01-21 15:51:21 +0200)

are available in the Git repository at:

  https://github.com/intel/gvt-linux tags/gvt-gt-next-2020-02-05

for you to fetch changes up to e156285b120feaac6207e6bd3fa31d9ae8ffd80d:

  drm/i915/gvt: Purge dev_priv->gt (2021-02-05 15:28:36 +0800)

----------------------------------------------------------------
gvt-gt-next-2020-02-05

- GVT object ww locking fix (Zhi)
- One smatch fix for uninitialized return value (Dan)
- Use i915 engine's default state for GVT cmd parser init (Chris)
- Purge dev_priv->gt (Chris)

----------------------------------------------------------------
Chris Wilson (2):
      drm/i915/gvt: Parse default state to update reg whitelist
      drm/i915/gvt: Purge dev_priv->gt

Dan Carpenter (1):
      drm/i915/gvt: fix uninitialized return in intel_gvt_update_reg_whitelist()

Zhenyu Wang (1):
      Merge tag 'drm-intel-gt-next-2021-01-21-1' into gvt-gt-next

Zhi Wang (1):
      drm/i915/gvt: Introduce per object locking in GVT scheduler.

 drivers/gpu/drm/i915/gvt/cmd_parser.c | 92 ++++++++---------------------------
 drivers/gpu/drm/i915/gvt/execlist.c   |  8 ++-
 drivers/gpu/drm/i915/gvt/scheduler.c  | 52 +++++++++++++++-----
 3 files changed, 64 insertions(+), 88 deletions(-)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx