On 12/19/2022 9:57 AM, Zheng Wang wrote:
> Hi Zhi,
>
> Thanks again for your reply and clear explaination about the function.
> I still have some doubt about the fix. Here is a invoke chain :
> ppgtt_populate_spt
>->ppgtt_populate_shadow_entry
> ->split_2MB_gtt_entry
> As far as I'm
On 12/15/2022 12:47 PM, Joonas Lahtinen wrote:
> (+ Tvrtko as FYI)
>
> Zhenyu, can you take a look at the patch ASAP.
>
> Regards, Joonas
Thanks so much for the reminding and patch.
Actually I don't think it is proper fix as:
split_2MB_gtt_entry() is going to allocate a new spt structure,
On 10/6/22 18:31, Alex Williamson wrote:
> On Thu, 6 Oct 2022 08:37:09 -0300
> Jason Gunthorpe wrote:
>
>> On Wed, Oct 05, 2022 at 04:03:56PM -0600, Alex Williamson wrote:
>>> We can't have a .remove callback that does nothing, this breaks
>>> removing the device while it's in use. Once we have
On 5/6/22 12:08 AM, Jason Gunthorpe wrote:
> Use the existing vfio_device versions of vfio_(un)pin_pages(). There is no
> reason to use a group interface here, kvmgt has easy access to a
> vfio_device.
>
> Delete kvmgt_vdev::vfio_group since these calls were the last users.
>
> Reviewed-by:
Hi folks:
Here is the pull of gvt-next which fixes the compilation error and warnings
for the the GVT-g refactor patches:
- Fix a compiling warning of non-static function only having one caller.
- Fix a potential NULL pointer reference in the code re-factor.
- Fix a compiling error when
On 4/26/22 3:53 PM, Jason Gunthorpe wrote:
> On Tue, Apr 26, 2022 at 07:58:59AM +0000, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thank
On 4/26/22 8:37 AM, Jani Nikula wrote:
> On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thanks so m
On 4/26/22 8:37 AM, Jani Nikula wrote:
> On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thanks so m
Hi folks:
I updated the branch again. Please use this pull. Here is the pull of
gvt-next which fixes the compilation error when i915 debug is open after
the GVT-g refactor patches.
Thanks so much for the efforts.
Thanks,
Zhi.
The following changes since commit
Hi folks:
Here is the pull of gvt-next which fixs the compilation error when i915 debug
is open after the GVT-g refactor patches.
Thanks so much for the efforts.
Thanks,
Zhi.
The following changes since commit 2917f53113be3b7a0f374e02cebe6d6b749366b5:
vfio/mdev: Remove mdev drvdata
On 4/25/22 12:33 PM, Jani Nikula wrote:
> On Mon, 25 Apr 2022, Jani Nikula wrote:
>> On Thu, 21 Apr 2022, "Wang, Zhi A" wrote:
>>> Hi folks:
>>>
>>> Here is the PR of gvt-next. Thanks so much for the patience.
>>
>> Thanks, pull
Hi folks:
Here is the PR of gvt-next. Thanks so much for the patience.
Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the
GVT-g with the
new MDEV interfaces:
- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup.
On 4/21/22 1:14 PM, Jason Gunthorpe wrote:
> On Thu, Apr 21, 2022 at 09:41:30AM +0300, Joonas Lahtinen wrote:
>> + Tvrtko
>>
>> Quoting Christoph Hellwig (2022-04-21 08:47:38)
>>> On Thu, Apr 21, 2022 at 04:57:34AM +, Wang, Zhi A wrote:
>>>> Is it p
gt;> On Wed, Apr 20, 2022 at 04:34:47PM +, Wang, Zhi A wrote:
>>>>> Hi folks:
>>>>>
>>>>> Here is the PR of gvt-next. Thanks so much for the patience.
>>>>>
>>>>> Mostly it includes the patch bundle of GVT-g re-factor p
Hi folks:
Here is the PR of gvt-next. Thanks so much for the patience.
Mostly it includes the patch bundle of GVT-g re-factor patches for adapting the
GVT-g with the
new MDEV interfaces:
- Separating the MMIO table from GVT-g. (Zhi)
- GVT-g re-factor. (Christoph)
- GVT-g mdev API cleanup.
On 4/20/22 7:08 AM, Christoph Hellwig wrote:
> On Thu, Apr 14, 2022 at 11:38:59AM -0300, Jason Gunthorpe wrote:
>> pull requests can flow through more than one tree concurrently. The
>> purpose of the topic branch is to allow all the commits to be in all
>> the trees they need to be in at once.
>>
On 4/14/22 1:43 PM, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 04:40:11PM +0300, Jani Nikula wrote:
>
>> git clone https://github.com/intel/gvt-linux -b for-christoph
>
> There are alot of extra commits on there - is it possible to base this
> straight on rc1 not on some
On 4/14/22 1:34 PM, Jason Gunthorpe wrote:
> On Thu, Apr 14, 2022 at 12:20:42PM +0000, Wang, Zhi A wrote:
>> On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
>>> On Wed, Apr 13, 2022 at 11:13:06PM +, Wang, Zhi A wrote:
>>>> Hi folks:
>>>>
>>>&g
On 4/13/22 11:20 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 11:13:06PM +0000, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Thanks so much for the efforts. I prepared a branch which contains all our
>> patches.The aim of the branch is for the VFIO maintainers to pull
022, Christoph Hellwig wrote:
>> On Wed, Apr 13, 2022 at 01:47:05PM +0000, Wang, Zhi A wrote:
>>>> the GVT code in the i915 is a bit of a mess right now due to strange
>>>> abstractions and lots of indirect calls. This series refactors various
>>>> bits to
On 4/13/22 8:04 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 07:17:52PM +0000, Wang, Zhi A wrote:
>> On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
>>> On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
>>>> On Wed, Apr 13, 2022 at 01:18:14P
On 4/13/22 5:37 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 06:29:46PM +0200, Christoph Hellwig wrote:
>> On Wed, Apr 13, 2022 at 01:18:14PM -0300, Jason Gunthorpe wrote:
>>> Yeah, I was thinking about that too, but on the other hand I think it
>>> is completely wrong that gvt requires
On 4/13/22 1:43 PM, Jason Gunthorpe wrote:
> On Wed, Apr 13, 2022 at 01:39:35PM +0000, Wang, Zhi A wrote:
>
>> It seems Jani's makefile clean patch has already included this one, I can
>> just simply drop this one so that Christoph won't need to re-send everything.
>>
&
On 4/11/22 2:13 PM, Christoph Hellwig wrote:
> Hi all,
>
> the GVT code in the i915 is a bit of a mess right now due to strange
> abstractions and lots of indirect calls. This series refactors various
> bits to clean that up. The main user visible change is that almost all
> of the GVT code
On 4/13/22 12:33 PM, Jani Nikula wrote:
> On Mon, 11 Apr 2022, Christoph Hellwig wrote:
>> On Mon, Apr 11, 2022 at 07:11:03PM +0300, Jani Nikula wrote:
Up to you but I usually sort these lists
>>>
>>> Yeah, please do. Otherwise matches what I sent, so ack.
>>
>> Let's just merge your 2 patch
my pull request not based on a tag in drm-intel-next, just the
latest drm-intel-next?
Thanks,
Zhi.
On 4/13/22 9:31 AM, Jani Nikula wrote:
> On Fri, 08 Apr 2022, "Wang, Zhi A" wrote:
>> Hi Jani:
>>
>> Thanks so much for the help. Can you generate a new tag
Ping. :)
On 4/8/22 2:07 PM, Zhi Wang wrote:
> Hi Jani:
>
> Thanks so much for the help. Can you generate a new tag on drm-intel-next? I
> noticed that there was one patch moving the DMC related registers into
> display/intel_dmc_regs.h, which is not included in the latest tag on
>
Hi Jani:
Thanks so much for the help. Can you generate a new tag on drm-intel-next? I
noticed that there was one patch moving the DMC related registers into
display/intel_dmc_regs.h, which is not included in the latest tag on
drm-intel-next.
Guess it would be better that I can change this
Thanks so much!
Jani and Joonas, it would be better to have one rb from i915 maintainers as
this patches also modify i915 code.
Thanks,
Zhi.
On 4/7/22 8:06 AM, Christoph Hellwig wrote:
> The whole series looks good and works fine on by Kaby Lake Thinkpad:
>
> Reviewed-by: Christoph Hellwig
>
Hi Jani:
Thanks so much for the guidance. :) I included it in the v8 patch. :)
Thanks,
Zhi.
On 3/31/22 8:25 AM, Jani Nikula wrote:
> On Thu, 31 Mar 2022, "Wang, Zhi A" wrote:
>> Hi Jani and Joonas:
>>
>> Are you OK with these patches? I noticed I need to change
Hi Chris:
Thanks for the testing. Can you attach the dmesg? I tested mostly on my skylake
desktop with some 3D workload.
Thanks,
Zhi.
On 3/31/22 7:42 AM, Christoph Hellwig wrote:
> On Thu, Mar 31, 2022 at 07:11:07AM +0000, Wang, Zhi A wrote:
>> Hi Jani and Joonas:
>>
Hi Jani and Joonas:
Are you OK with these patches? I noticed I need to change the license of the
new file. Will do that when check-in if you are OK with these.
Thanks,
Zhi.
On 3/28/22 6:50 AM, Christoph Hellwig wrote:
> On Fri, Mar 25, 2022 at 01:52:49PM -0400, Zhi Wang wrote:
>>
>> v7:
>>
>>
Thanks for the contribution, Colin. Queued.
On 3/15/22 8:24 PM, Colin Ian King wrote:
> There is a spelling mistake in a gvt_vgpu_err error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
I was actually testing it for almost two weeks, but still I met some hang and I
was trying to figure where the problem is as this is quite a big change. Let's
see if I can figure it out this week.
Thanks,
Zhi.
On 3/15/22 8:48 AM, Christoph Hellwig wrote:
> On Tue, Mar 15, 2022 at 10:46:53AM
On 2/9/22 9:04 AM, Jani Nikula wrote:
> On Wed, 09 Feb 2022, 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)
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
On 2/9/22 7:32 AM, Christoph Hellwig wrote:
> On Tue, Feb 08, 2022 at 06:11:50AM -0500, Zhi Wang wrote:
>> +struct drm_i915_private *dev_priv = iter->i915;
>> +u32 *mmio, i;
>> +
>> +for (i = offset; i < offset + size; i += 4) {
>> +mmio = iter->data + i;
>> +
On 11/30/2021 6:46 PM, Christoph Hellwig wrote:
> I still think this goes into the wrong direction.
>
> Something closer to your first version that also saves away the
> gvt->mmio.mmio_attribute flags in the core i915 module, and which
> splits the MMIO table into one that contains just the
On 12/12/2021 3:25 PM, Rikard Falkeborn worte:
> On Fri, Dec 10, 2021 at 09:00:56AM +0000, Wang, Zhi A wrote:
>> On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
>>> Constify a number of static structs that are never modified to allow the
>>> compiler to put them in read-
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> Constify a number of static structs that are never modified to allow the
> compiler to put them in read-only memory. In order to do this, constify a
> number of local variables and pointers in structs.
>
> This is most important for structs that
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 4 ++--
> drivers/gpu/drm/i915/gvt/gtt.h | 2 +-
> 2 files
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory. While at it, make name a const char*.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/vgpu.c | 4 ++--
> 1 file changed, 2
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory. WHile at it, make the description const
> char* since it is never modified.
>
> Signed-off-by: Rikard Falkeborn
> ---
>
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> It is never modified, so make it const to allow the compiler to put it
> in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put it in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gvt.h | 2 +-
> drivers/gpu/drm/i915/gvt/handlers.c | 12 ++--
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/sched_policy.c | 2 +-
> drivers/gpu/drm/i915/gvt/scheduler.h| 2 +-
>
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/interrupt.c | 10 +-
> drivers/gpu/drm/i915/gvt/interrupt.h | 2
On 12/4/2021 12:55 PM, Rikard Falkeborn wrote:
> These are never modified, so make them const to allow the compiler to
> put them in read-only memory.
>
> Signed-off-by: Rikard Falkeborn
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 62 +-
>
On 11/9/2021 12:58 PM, h...@lst.de wrote:
> On Tue, Nov 09, 2021 at 10:51:27AM +0000, Wang, Zhi A wrote:
>> Can you elaborate more about this? We need the hash query from the table
>> ASAP when the hypervisor trapped a mmio access. It's a critical path and
>> we tried dif
in the re-factor patches wouldn’t block the process of
mdev API improvement?
Thanks,
Zhi.
-Original Message-
From: Joonas Lahtinen
Sent: Thursday, November 4, 2021 2:59 PM
To: Christoph Hellwig ; Jani Nikula ;
Vivi, Rodrigo ; Zhenyu Wang ;
Wang, Zhi A
Cc: Jason Gunthorpe ; intel
On 10/3/21 5:23 AM, Randy Dunlap wrote:
> Fix kernel-doc warnings in gtt.c:
>
> gtt.c:1152: warning: This comment starts with '/**', but isn't a kernel-doc
> comment. Refer Documentation/doc-guide/kernel-doc.rst
> * Check if can do 2M page
> gtt.c:1152: warning: missing initial short
On 10/8/21 9:17 AM, Nirmoy Das wrote:
> Return early if dri minor root dentry is NULL.
>
> CC: Zhenyu Wang
> CC: Zhi Wang
> CC: Jani Nikula
> CC: Joonas Lahtinen
> CC: Rodrigo Vivi
> CC: David Airlie
> CC: Daniel Vetter
> Signed-off-by: Nirmoy Das
> ---
>
continue our development and pull-request to upstream. Thanks so much
for the patch and the discussion.
Thanks,
Zhi.
On 10/1/21 1:01 PM, Wang, Zhi A wrote:
> On 9/29/21 6:55 PM, Jason Gunthorpe wrote:
>> On Wed, Sep 29, 2021 at 06:27:16PM +0000, Wang, Zhi A wrote:
>>> On 9/28
On 9/29/21 6:55 PM, Jason Gunthorpe wrote:
> On Wed, Sep 29, 2021 at 06:27:16PM +0000, Wang, Zhi A wrote:
>> On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
>>> On Tue, Sep 28, 2021 at 02:35:06PM +, Wang, Zhi A wrote:
>>>
>>>> Yes. I was thinking of the possib
On 9/28/21 3:05 PM, Jason Gunthorpe wrote:
> On Tue, Sep 28, 2021 at 02:35:06PM +0000, Wang, Zhi A wrote:
>
>> Yes. I was thinking of the possibility of putting off some work later so
>> that we don't need to make a lot of changes. GVT-g needs to take a
>> snapshot of GPU
On 9/28/21 2:00 PM, Luis Chamberlain wrote:
> On Tue, Sep 28, 2021 at 07:41:00AM +0000, Wang, Zhi A wrote:
>> Hey guys:
>>
>> After some investigation, I found the root cause this problem ("i915"
>> module loading will be stuck with Christoph's refactor
Hey guys:
After some investigation, I found the root cause this problem ("i915"
module loading will be stuck with Christoph's refactor patches), which
can be reproduced by building both i915 and kvmgt as kernel module and
the loading i915.
The root cause is: in Linux kernel loading, before a
On 7/28/2021 8:59 PM, Jason Gunthorpe wrote:
> On Wed, Jul 28, 2021 at 01:38:58PM +0000, Wang, Zhi A wrote:
>
>> I guess those APIs you were talking about are KVM-only. For other
>> hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not
>> sure if you have a
e MPT module.
Thanks so much for the comments.
Thanks,
Zhi.
-Original Message-
From: Jason Gunthorpe
Sent: Tuesday, July 27, 2021 3:12 PM
To: Gerd Hoffmann
Cc: Wang, Zhi A ; Christoph Hellwig ; Jani
Nikula ; Joonas Lahtinen
; Vivi, Rodrigo ;
Zhenyu Wang ; intel-...@lis
to put a document about the
background and more description in the MPT headers. So it won't confuse more
people.
Feel free to drop more comments.
Thanks,
Zhi.
-Original Message-
From: Christoph Hellwig
Sent: Wednesday, July 21, 2021 6:54 PM
To: Jani Nikula ; Joonas Lahtinen
;
rg>; Maarten
Lankhorst <maarten.lankho...@linux.intel.com>; dri-devel@lists.freedesktop.org;
intel-...@lists.freedesktop.org; dim-to...@lists.freedesktop.org; Wang, Zhi A
<zhi.a.w...@intel.com>; Zhenyu Wang <zhen...@linux.intel.com>; Srinivas, Vidya
<vidya.srini...@intel.com>
, November 27, 2017 1:59 PM
To: zhen...@linux.intel.com; Wang, Zhi A <zhi.a.w...@intel.com>;
jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com; Vivi, Rodrigo
<rodrigo.v...@intel.com>; airl...@linux.ie;
intel-gvt-...@lists.freedesktop.org; intel-...@lists.freedesktop.org
.@intel.com>;
Zhenyu Wang <zhen...@linux.intel.com>; Wang, Zhi A <zhi.a.w...@intel.com>
Cc: LKML <linux-ker...@vger.kernel.org>; kernel-janit...@vger.kernel.org
Subject: [PATCH] drm/i915/gvt: Use common error handling code in
shadow_workload_ring_buffer()
From: Markus Elfring
AM
To: Gao, Fred <fred@intel.com>; Zhenyu Wang <zhen...@linux.intel.com>;
Wang, Zhi A <zhi.a.w...@intel.com>; Jani Nikula <jani.nik...@linux.intel.com>;
Joonas Lahtinen <joonas.lahti...@linux.intel.com>; Vivi, Rodrigo
<rodrigo.v...@intel.com>; David A
, September 22, 2017 2:11 PM
To: Wang, Zhi A <zhi.a.w...@intel.com>; Zhenyu Wang <zhen...@linux.intel.com>;
Joe Perches <j...@perches.com>
Cc: Gao, Fred <fred@intel.com>; David Airlie <airl...@linux.ie>;
intel-...@lists.freedesktop.org; kernel-janit.
66 matches
Mail list logo
