Re: [Intel-gfx] [RFC PATCH 3/3] drm/i915: Enabling WD Transcoder

2022-04-27 Thread Kandpal, Suraj
++Laurent ,Dmitry, Abhinav and Rob > Adding support for writeback transcoder to start capturing frames using > interrupt mechanism > > Signed-off-by: Suraj Kandpal > --- > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_acpi.c | 1 + >

Re: [Intel-gfx] [RFC PATCH 2/3] drm/i915: Define WD trancoder for i915

2022-04-27 Thread Kandpal, Suraj
++Laurent ,Dmitry, Abhinav and Rob > -Original Message- > From: Kandpal, Suraj > Sent: Thursday, April 21, 2022 10:38 AM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Cc: Nikula, Jani ; ville.syrj...@linux.intel.com; > Murthy, Arun R ; Kandpal, Suraj > >

Re: [Intel-gfx] [PATCH 0/2] Initial GuC firmware release for DG2

2022-04-27 Thread Lucas De Marchi
On Wed, Apr 27, 2022 at 03:14:16PM -0700, John Harrison wrote: On 4/27/2022 11:24, Timo Aaltonen wrote: john.c.harri...@intel.com kirjoitti 27.4.2022 klo 19.55: From: John Harrison Add GuC firmware for DG2. Note that an older version of this patch exists in the CI topic branch. Hence this

Re: [Intel-gfx] [RFC PATCH 0/3] i915 writeback private framework

2022-04-27 Thread Kandpal, Suraj
++Laurent ,Dmitry, and Abhinav Hi, Can you have a look at the private implementation i915 is currently going with till we can figure out how to work with drm core . Regards, Suraj Kandpal > A patch series was floated in the drm mailing list which aimed to change the > drm_connector and

Re: [Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

2022-04-27 Thread Murthy, Arun R
> > > It's supported earlier than that. But IIRC there was some kind of > > > GTT alignment vs. async flip vs. FBC restriction that we weren't handling. > > > > > Should I enable it for earlier Gen also, or is it fine to keep it with > > starting > Gen 12. > > The only restriction that I see in

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Turn on compute engine support (rev4)

2022-04-27 Thread Patchwork
== Series Details == Series: i915: Turn on compute engine support (rev4) URL : https://patchwork.freedesktop.org/series/103011/ State : success == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103011v4 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Turn on compute engine support (rev4)

2022-04-27 Thread Patchwork
== Series Details == Series: i915: Turn on compute engine support (rev4) URL : https://patchwork.freedesktop.org/series/103011/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH v2 3/4] drm/i915/xehp: Add compute engine ABI

2022-04-27 Thread Matt Roper
We're now ready to start exposing compute engines to userspace. v2: - Move kerneldoc for other engine classes to a separate patch. (Andi) Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Vinay Belgaumkar Cc: Jordan Justen Cc: Szymon Morek UMD (mesa):

[Intel-gfx] [PATCH v2 1/4] drm/i915/uapi: Add kerneldoc for engine class enum

2022-04-27 Thread Matt Roper
We'll be adding a new type of engine soon. Let's document the existing engine classes first to help make it clear what each type of engine is used for. Cc: Andi Shyti Signed-off-by: Matt Roper --- include/uapi/drm/i915_drm.h | 53 - 1 file changed, 47

[Intel-gfx] [PATCH v2 4/4] drm/i915: Xe_HP SDV and DG2 have up to 4 CCS engines

2022-04-27 Thread Matt Roper
From: Daniele Ceraolo Spurio Cc: Vinay Belgaumkar Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Matt Roper Reviewed-by: Matt Roper Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/i915_pci.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v2 2/4] drm/i915/xehp: Add register for compute engine's MMIO-based TLB invalidation

2022-04-27 Thread Matt Roper
Compute engines have a separate register that the driver should use to perform MMIO-based TLB invalidation. Note that the term "context" in this register's bspec description is used to refer to the engine instance (in the same way "context" is used on bspec 46167). Bspec: 43930 Cc: Prathap Kumar

[Intel-gfx] [PATCH v2 0/4] i915: Turn on compute engine support

2022-04-27 Thread Matt Roper
Now that the necessary GuC-based hardware workarounds have landed, we're finally ready to actually enable compute engines for use by userspace. All of the "under-the-hood" heavy lifting already landed a while back in other series so all that remains now is to add I915_ENGINE_CLASS_COMPUTE to the

Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

2022-04-27 Thread Matt Roper
On Mon, Apr 25, 2022 at 11:41:36AM +0100, Tvrtko Ursulin wrote: > > On 22/04/2022 20:50, Matt Roper wrote: > > We're now ready to start exposing compute engines to userspace. > > > > While we're at it, let's extend the kerneldoc description for the other > > engine types as well. > > > > Cc:

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: SSEU handling updates (rev2)

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates (rev2) URL : https://patchwork.freedesktop.org/series/103244/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103244v2_full Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: SSEU handling updates (rev2)

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates (rev2) URL : https://patchwork.freedesktop.org/series/103244/ State : success == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103244v2 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: SSEU handling updates (rev2)

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates (rev2) URL : https://patchwork.freedesktop.org/series/103244/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates (rev2)

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates (rev2) URL : https://patchwork.freedesktop.org/series/103244/ State : warning == Summary == Error: dim checkpatch failed 721ef81dbce9 drm/i915/sseu: Don't try to store EU mask internally in UAPI format 91b82b1f6352 drm/i915/xehp: Drop

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Dixit, Ashutosh
On Wed, 27 Apr 2022 15:45:40 -0700, Patchwork wrote: > > Possible regressions > > * igt@kms_flip@flip-vs-suspend-interruptible@a-edp1: > > * shard-skl: PASS -> INCOMPLETE > > * igt@syncobj_timeline@wait-all-for-submit-snapshot: > > * shard-skl: PASS -> FAIL > > Warnings > > *

Re: [Intel-gfx] [PATCH 1/2] drm/i915/xehp: Add compute engine ABI

2022-04-27 Thread Kumar Valsan, Prathap
On Mon, Apr 25, 2022 at 11:41:36AM +0100, Tvrtko Ursulin wrote: > > On 22/04/2022 20:50, Matt Roper wrote: > > We're now ready to start exposing compute engines to userspace. > > > > While we're at it, let's extend the kerneldoc description for the other > > engine types as well. > > > > Cc:

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for i915: Upstream initial DG2 PCI IDs

2022-04-27 Thread Matt Roper
On Wed, Apr 27, 2022 at 04:53:12AM +, Patchwork wrote: > == Series Details == > > Series: i915: Upstream initial DG2 PCI IDs > URL : https://patchwork.freedesktop.org/series/103098/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_11550_full ->

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dg2: Define GuC firmware version for DG2

2022-04-27 Thread Ceraolo Spurio, Daniele
On 4/27/2022 9:55 AM, john.c.harri...@intel.com wrote: From: John Harrison First release of GuC for DG2. Reviewed-by: Daniele Ceraolo Spurio Daniele Signed-off-by: John Harrison CC: Tomasz Mistat CC: Ramalingam C CC: Daniele Ceraolo Spurio ---

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Initial GuC firmware release for DG2

2022-04-27 Thread John Harrison
On 4/27/2022 11:59, Patchwork wrote: Project List - Patchwork *Patch Details* *Series:* Initial GuC firmware release for DG2 *URL:* https://patchwork.freedesktop.org/series/103230/ *State:*failure *Details:* https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103230v1/index.html

[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates URL : https://patchwork.freedesktop.org/series/103244/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103244v1 Summary --- **FAILURE**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: SSEU handling updates

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates URL : https://patchwork.freedesktop.org/series/103244/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: SSEU handling updates

2022-04-27 Thread Patchwork
== Series Details == Series: i915: SSEU handling updates URL : https://patchwork.freedesktop.org/series/103244/ State : warning == Summary == Error: dim checkpatch failed 55dde4d186fd drm/i915/sseu: Don't try to store EU mask internally in UAPI format 313094aca5e5 drm/i915/xehp: Drop GETPARAM

[Intel-gfx] [PATCH 2/5] drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK

2022-04-27 Thread Matt Roper
Slice/subslice/EU information should be obtained via the topology queries provided by the I915_QUERY interface; let's turn off support for the old GETPARAM lookups on Xe_HP and beyond where we can't return meaningful values. The slice mask lookup is meaningless since Xe_HP doesn't support

[Intel-gfx] [PATCH 5/5] drm/i915/sseu: Disassociate internal subslice mask representation from uapi

2022-04-27 Thread Matt Roper
Rather than storing subslice masks internally as u8[] (inside the sseu structure) and u32 (everywhere else), let's move over to using an intel_sseu_ss_mask_t typedef compatible with the operations in linux/bitmap.h. We're soon going to start adding code for a new platform where subslice masks are

[Intel-gfx] [PATCH 0/5] i915: SSEU handling updates

2022-04-27 Thread Matt Roper
This series makes a handful of updates to i915's internal handling of slice/subslice/EU (SSEU) data to handle recent platforms like Xe_HP in a more natural manner and to prepare for some additional upcoming platforms we have in the pipeline (the first of which I'll probably start sending patches

[Intel-gfx] [PATCH 1/5] drm/i915/sseu: Don't try to store EU mask internally in UAPI format

2022-04-27 Thread Matt Roper
Storing the EU mask internally in the same format the I915_QUERY topology queries use makes the final copy_to_user() a bit simpler, but makes the rest of the driver's SSEU more complicated. Given that modern platforms (gen11 and beyond) are architecturally guaranteed to have equivalent EU masks

[Intel-gfx] [PATCH 4/5] drm/i915/sseu: Simplify gen11+ SSEU handling

2022-04-27 Thread Matt Roper
Although gen11 and gen12 architectures supported the concept of multiple slices, in practice all the platforms that were actually designed only had a single slice (i.e., note the parameters to 'intel_sseu_set_info' that we pass for each platform). We can simplify the code slightly by dropping the

[Intel-gfx] [PATCH 3/5] drm/i915/xehp: Use separate sseu init function

2022-04-27 Thread Matt Roper
Xe_HP has enough fundamental differences from previous platforms that it makes sense to use a separate SSEU init function to keep things straightforward and easy to understand. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_sseu.c | 85 1 file changed,

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Patchwork
== Series Details == Series: drm/i915/gt: Fix memory leaks in per-gt sysfs URL : https://patchwork.freedesktop.org/series/103236/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103236v1_full Summary

Re: [Intel-gfx] [PATCH 0/2] Initial GuC firmware release for DG2

2022-04-27 Thread John Harrison
On 4/27/2022 11:24, Timo Aaltonen wrote: john.c.harri...@intel.com kirjoitti 27.4.2022 klo 19.55: From: John Harrison Add GuC firmware for DG2. Note that an older version of this patch exists in the CI topic branch. Hence this set includes a revert of that patch before applying the new

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gvt: Make intel_gvt_match_device() static

2022-04-27 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915/gvt: Make intel_gvt_match_device() static URL : https://patchwork.freedesktop.org/series/103237/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/103237/revisions/1/mbox/ not applied

[Intel-gfx] [PATCH 1/2] drm/i915/gvt: Make intel_gvt_match_device() static

2022-04-27 Thread Zhi Wang
After the refactor of GVT-g, the reference of intel_gvt_match_device() only happens in handlers.c. Make it static to let the compiler be happy. Cc: Jason Gunthorpe Cc: Jani Nikula Cc: Robert Beckett Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/gvt/handlers.c | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 2/2] drm/i915/gvt: Fix the compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n

2022-04-27 Thread Zhi Wang
A compiling error was reported when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n. Fix the problem by using the pre-defined macro. Cc: Jason Gunthorpe Cc: Jani Nikula Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/intel_gvt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Patchwork
== Series Details == Series: drm/i915/gt: Fix memory leaks in per-gt sysfs URL : https://patchwork.freedesktop.org/series/103236/ State : success == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103236v1 Summary ---

Re: [Intel-gfx] [PATCH 1/4] drm/i915/huc: check HW directly for HuC auth status

2022-04-27 Thread Ceraolo Spurio, Daniele
On 4/26/2022 5:26 PM, Daniele Ceraolo Spurio wrote: The huc_is_authenticated function return is based on our SW tracking of the HuC auth status. However, around suspend/resume and reset this can go out of sync with the actual HW state, which is why we use huc_check_state() to look at the

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Patchwork
== Series Details == Series: drm/i915/gt: Fix memory leaks in per-gt sysfs URL : https://patchwork.freedesktop.org/series/103236/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Dixit, Ashutosh
On Wed, 27 Apr 2022 04:45:03 -0700, Andi Shyti wrote: > > Hi Ashutosh, Hi Andi, > > > > -static struct kobj_type kobj_gt_type = { > > > > - .release = kobj_gt_release, > > > > +static struct kobj_type kobj_gtn_type = { > > > > > > what does it mean GTN? Or is it GTn? Please use just GT,

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Dixit, Ashutosh
On Sun, 24 Apr 2022 15:36:23 -0700, Andi Shyti wrote: > > Hi Andrzej and Ashutosh, > > > > > > b/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > > > index 937b2e1a305e..4c72b4f983a6 100644 > > > > > --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h > > > > > +++

[Intel-gfx] [PATCH] drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Ashutosh Dixit
All kmalloc'd kobjects need a kobject_put() to free memory. For example in previous code, kobj_gt_release() never gets called. The requirement of kobject_put() now results in a slightly different code organization. v2: s/gtn/gt/ (Andi) Cc: Andi Shyti Cc: Andrzej Hajda Fixes: b770bcfae9ad

[Intel-gfx] ✗ Fi.CI.BUILD: failure for RFC: nested AVIC (rev2)

2022-04-27 Thread Patchwork
== Series Details == Series: RFC: nested AVIC (rev2) URL : https://patchwork.freedesktop.org/series/100904/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/100904/revisions/2/mbox/ not applied Applying: KVM: x86: document AVIC/APICv inhibit

[Intel-gfx] [RFC PATCH v3 19/19] KVM: x86: nSVM: expose the nested AVIC to the guest

2022-04-27 Thread Maxim Levitsky
This patch enables and exposes to the nested guest the support for the nested AVIC. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/svm/svm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 099329711ad13..431281ccc40ef 100644 ---

[Intel-gfx] [RFC PATCH v3 18/19] KVM: x86: SVM/nSVM: add optional non strict AVIC doorbell mode

2022-04-27 Thread Maxim Levitsky
By default, peers of a vCPU, can send it doorbell messages, only when that vCPU is assigned (loaded) a physical CPU. However when doorbell messages are not allowed, this causes all of the vCPU's peers to get VM exits, which is suboptimal when this vCPU is not halted, and therefore just temporary

[Intel-gfx] [RFC PATCH v3 17/19] KVM: x86: nSVM: implement nested AVIC doorbell emulation

2022-04-27 Thread Maxim Levitsky
This patch implements the doorbell msr emulation for nested AVIC. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/svm/avic.c | 49 + arch/x86/kvm/svm/svm.c | 2 ++ arch/x86/kvm/svm/svm.h | 1 + 3 files changed, 52 insertions(+) diff --git

[Intel-gfx] [RFC PATCH v3 16/19] KVM: x86: nSVM: implement support for nested AVIC vmexits

2022-04-27 Thread Maxim Levitsky
* SVM_EXIT_AVIC_UNACCELERATED_ACCESS is always forwarded to the L1 * SVM_EXIT_AVIC_INCOMPLETE_IPI is hidden from the guest if: - is_running was false in shadow physid page because L1's vCPU was scheduled out - in this case, the vCPU is waken up, and it will process nested AVIC on

[Intel-gfx] [RFC PATCH v3 15/19] KVM: x86: nSVM: add code to reload AVIC physid table when it is invalidated

2022-04-27 Thread Maxim Levitsky
An AVIC table invalidation is not supposed to happen often, and can only happen when the guest does something suspicious such as: - It places physid page in a memslot that is enabled/disabled and memslot flushing happens. - It tries to update apic backing page addresses - guest has no

[Intel-gfx] [RFC PATCH v3 14/19] KVM: x86: rename .set_apic_access_page_addr to reload_apic_access_page

2022-04-27 Thread Maxim Levitsky
This will be used on SVM to reload shadow page of the AVIC physid table No functional change intended Signed-off-by: Maxim Levitsky --- arch/x86/include/asm/kvm-x86-ops.h | 2 +- arch/x86/include/asm/kvm_host.h| 3 +-- arch/x86/kvm/vmx/vmx.c | 8 arch/x86/kvm/x86.c

[Intel-gfx] [RFC PATCH v3 13/19] KVM: x86: nSVM: wire nested AVIC to nested guest entry/exit

2022-04-27 Thread Maxim Levitsky
* Passthrough guest's avic pages that can be passed through - logical id table - avic backing page * Passthrough AVIC's mmio range - nested guest is responsible for marking it RW in its NPT tables. * Write track physical id page - all peer's avic backing pages

[Intel-gfx] [RFC PATCH v3 12/19] KVM: x86: nSVM: make nested AVIC physid write tracking be aware of the host scheduling

2022-04-27 Thread Maxim Levitsky
For each vCPU - store a linked list of all shadow physical id entries which address it. - Update those entries when this vCPU is scheduled in/out - update this list, when physid tables are modified by other means (guest write and/or table sync) To avoid races vs vcpu schedule,

[Intel-gfx] [RFC PATCH v3 11/19] KVM: x86: nSVM: implement shadowing of AVIC's physical id table

2022-04-27 Thread Maxim Levitsky
Implement the shadow physical id table and its write tracking code which will be soon used for the nested AVIC. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/svm/avic.c | 461 +++- arch/x86/kvm/svm/svm.h | 71 +++ 2 files changed, 524 insertions(+), 8

[Intel-gfx] [RFC PATCH v3 10/19] KVM: x86: nSVM: implement AVIC's physid/logid table access helpers

2022-04-27 Thread Maxim Levitsky
This implements a few helpers that help manipulate the AVIC's physical and logical id table entries. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/svm/svm.h | 45 ++ 1 file changed, 45 insertions(+) diff --git a/arch/x86/kvm/svm/svm.h

[Intel-gfx] [RFC PATCH v3 09/19] KVM: x86: nSVM: add nested AVIC tracepoints

2022-04-27 Thread Maxim Levitsky
This patch adds few tracepoints that will be used to debug/profile the nested AVIC. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/trace.h | 157 ++- arch/x86/kvm/x86.c | 13 2 files changed, 169 insertions(+), 1 deletion(-) diff --git

[Intel-gfx] [RFC PATCH v3 08/19] KVM: x86: SVM: move avic state to separate struct

2022-04-27 Thread Maxim Levitsky
This will make the code a bit easier to read when nested AVIC support is added. No functional change intended. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/svm/avic.c | 51 +++-- arch/x86/kvm/svm/svm.h | 14 ++- 2 files changed, 37 insertions(+),

[Intel-gfx] [RFC PATCH v3 07/19] KVM: x86: mmu: tweak fast path for emulation of access to nested NPT pages

2022-04-27 Thread Maxim Levitsky
If a non leaf mmu page is write tracked externally for some reason, which can in theory happen if it was used for nested avic physid page before, then this code will enter an endless loop of page faults because unprotecting the mmu page will not remove write tracking, nor will the write tracker

[Intel-gfx] [RFC PATCH v3 06/19] KVM: x86: mmu: add gfn_in_memslot helper

2022-04-27 Thread Maxim Levitsky
This is a tiny refactoring, and can be useful to check if a GPA/GFN is within a memslot a bit more cleanly. Signed-off-by: Maxim Levitsky --- include/linux/kvm_host.h | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/include/linux/kvm_host.h

[Intel-gfx] [RFC PATCH v3 05/19] x86: KVMGT: use kvm_page_track_write_tracking_enable

2022-04-27 Thread Maxim Levitsky
This allows to enable the write tracking only when KVMGT is actually used and doesn't carry any penalty otherwise. Tested by booting a VM with a kvmgt mdev device. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/Kconfig | 3 --- arch/x86/kvm/mmu/mmu.c | 2 +-

[Intel-gfx] [RFC PATCH v3 04/19] KVM: x86: mmu: allow to enable write tracking externally

2022-04-27 Thread Maxim Levitsky
This will be used to enable write tracking from nested AVIC code and can also be used to enable write tracking in GVT-g module when it actually uses it as opposed to always enabling it, when the module is compiled in the kernel. No functional change intended. Signed-off-by: Maxim Levitsky ---

[Intel-gfx] [RFC PATCH v3 03/19] KVM: x86: SVM: remove avic's broken code that updated APIC ID

2022-04-27 Thread Maxim Levitsky
AVIC is now inhibited if the guest changes apic id, thus remove that broken code. Signed-off-by: Maxim Levitsky --- arch/x86/kvm/svm/avic.c | 35 --- 1 file changed, 35 deletions(-) diff --git a/arch/x86/kvm/svm/avic.c b/arch/x86/kvm/svm/avic.c index

[Intel-gfx] [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.

2022-04-27 Thread Maxim Levitsky
Neither of these settings should be changed by the guest and it is a burden to support it in the acceleration code, so just inhibit it instead. Also add a boolean 'apic_id_changed' to indicate if apic id ever changed. Signed-off-by: Maxim Levitsky --- arch/x86/include/asm/kvm_host.h | 3 +++

[Intel-gfx] [RFC PATCH v3 01/19] KVM: x86: document AVIC/APICv inhibit reasons

2022-04-27 Thread Maxim Levitsky
These days there are too many AVIC/APICv inhibit reasons, and it doesn't hurt to have some documentation for them. Signed-off-by: Maxim Levitsky --- arch/x86/include/asm/kvm_host.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/x86/include/asm/kvm_host.h

[Intel-gfx] [RFC PATCH v3 00/19] RFC: nested AVIC

2022-04-27 Thread Maxim Levitsky
This is V3 of my nested AVIC patches. I fixed few more bugs, and I also split the cod insto smaller patches. Review is welcome! Best regards, Maxim Levitsky Maxim Levitsky (19): KVM: x86: document AVIC/APICv inhibit reasons KVM: x86: inhibit APICv/AVIC when the guest and/or host

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/gt: GEM_BUG_ON unexpected NULL at scatterlist walking

2022-04-27 Thread Matthew Auld
On 25/04/2022 17:24, Ramalingam C wrote: While locating the start of ccs scatterlist in smem scatterlist, that has to be the size of lmem obj size + corresponding ccs data size. Report bug if scatterlist terminate before that length. Signed-off-by: Ramalingam C ---

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: optimize the ccs_sz calculation per chunk

2022-04-27 Thread Matthew Auld
On 25/04/2022 17:24, Ramalingam C wrote: Calculate the ccs_sz that needs to be emitted based on the src and dst pages emitted per chunk. And handle the return value of emit_pte for the ccs pages. Signed-off-by: Ramalingam C --- drivers/gpu/drm/i915/gt/intel_migrate.c | 36

[Intel-gfx] ✗ Fi.CI.IGT: failure for Initial GuC firmware release for DG2

2022-04-27 Thread Patchwork
== Series Details == Series: Initial GuC firmware release for DG2 URL : https://patchwork.freedesktop.org/series/103230/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103230v1_full Summary ---

Re: [Intel-gfx] [PATCH v3] drm/i915: Don't show engine information in fdinfo with GuC submission

2022-04-27 Thread Dixit, Ashutosh
On Wed, 27 Apr 2022 10:16:03 -0700, Tvrtko Ursulin wrote: > > > On 27/04/2022 16:43, Dixit, Ashutosh wrote: > > On Wed, 27 Apr 2022 02:15:35 -0700, Tvrtko Ursulin wrote: > >> > >> On 15/04/2022 01:25, Ashutosh Dixit wrote: > >>> At present i915 does not fetch busyness information from GuC,

Re: [Intel-gfx] [PATCH 0/2] Initial GuC firmware release for DG2

2022-04-27 Thread Timo Aaltonen
john.c.harri...@intel.com kirjoitti 27.4.2022 klo 19.55: From: John Harrison Add GuC firmware for DG2. Note that an older version of this patch exists in the CI topic branch. Hence this set includes a revert of that patch before applying the new version. When merging, the revert would simply

[Intel-gfx] ✓ Fi.CI.BAT: success for Initial GuC firmware release for DG2

2022-04-27 Thread Patchwork
== Series Details == Series: Initial GuC firmware release for DG2 URL : https://patchwork.freedesktop.org/series/103230/ State : success == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103230v1 Summary ---

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

2022-04-27 Thread Matthew Auld
On 27/04/2022 09:36, Tvrtko Ursulin wrote: On 20/04/2022 18:13, Matthew Auld wrote: Add an entry for the new uapi needed for small BAR on DG2+. v2:    - Some spelling fixes and other small tweaks. (Akeem & Thomas)    - Rework error capture interactions, including no longer needing

Re: [Intel-gfx] [PATCH v3] drm/i915: Don't show engine information in fdinfo with GuC submission

2022-04-27 Thread Tvrtko Ursulin
On 27/04/2022 16:43, Dixit, Ashutosh wrote: On Wed, 27 Apr 2022 02:15:35 -0700, Tvrtko Ursulin wrote: On 15/04/2022 01:25, Ashutosh Dixit wrote: At present i915 does not fetch busyness information from GuC, resulting in incorrect busyness values in fdinfo. Because engine information is

Re: [Intel-gfx] [PATCH v2 4/4] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj

2022-04-27 Thread Matthew Auld
On 25/04/2022 17:24, Ramalingam C wrote: Capture the impact of memory region preference list of an object, on their memory residency and Flat-CCS capability of the objects. v2: Fix the Flat-CCS capability of an obj with {lmem, smem} preference list [Thomas] Signed-off-by: Ramalingam C

[Intel-gfx] [PATCH 2/2] drm/i915/dg2: Define GuC firmware version for DG2

2022-04-27 Thread John . C . Harrison
From: John Harrison First release of GuC for DG2. Signed-off-by: John Harrison CC: Tomasz Mistat CC: Ramalingam C CC: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c

[Intel-gfx] [PATCH 1/2] Revert "drm/i915/dg2: Define GuC firmware version for DG2"

2022-04-27 Thread John . C . Harrison
From: John Harrison This reverts commit 55c7f980e48e56861496526e02ed5bbfdac49ede. The CI topic branch within drm-top contains an old patch for supporting GuC on DG2. That needs to be dropped and an updated patch merged to drm-gt-next. Hence this patch reverts it so the new patch can be sent in

[Intel-gfx] [PATCH 0/2] Initial GuC firmware release for DG2

2022-04-27 Thread John . C . Harrison
From: John Harrison Add GuC firmware for DG2. Note that an older version of this patch exists in the CI topic branch. Hence this set includes a revert of that patch before applying the new version. When merging, the revert would simply be dropped and the corresponding patch in the topic branch

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/gt: Document the eviction of the Flat-CCS objects

2022-04-27 Thread Matthew Auld
On 25/04/2022 17:24, Ramalingam C wrote: Capture the eviction details for Flat-CCS capable, lmem objects. v2: Fix the Flat-ccs capbility of lmem obj with smem residency possibility [Thomas] Signed-off-by: Ramalingam C cc: Thomas Hellstrom cc: Matthew Auld ---

Re: [Intel-gfx] [PATCH v3] drm/i915: Don't show engine information in fdinfo with GuC submission

2022-04-27 Thread Dixit, Ashutosh
On Wed, 27 Apr 2022 02:15:35 -0700, Tvrtko Ursulin wrote: > > On 15/04/2022 01:25, Ashutosh Dixit wrote: > > At present i915 does not fetch busyness information from GuC, resulting in > > incorrect busyness values in fdinfo. Because engine information is coupled > > with busyness in fdinfo, skip

Re: [Intel-gfx] [RFC v2 1/2] drm/doc/rfc: VM_BIND feature design document

2022-04-27 Thread Niranjana Vishwanathapura
On Wed, Apr 20, 2022 at 03:45:25PM -0700, Niranjana Vishwanathapura wrote: On Thu, Mar 31, 2022 at 10:28:48AM +0200, Daniel Vetter wrote: Adding a pile of people who've expressed interest in vm_bind for their drivers. Also note to the intel folks: This is largely written with me having my

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

2022-04-27 Thread Lionel Landwerlin
On 27/04/2022 18:18, Matthew Auld wrote: On 27/04/2022 07:48, Lionel Landwerlin wrote: One question though, how do we detect that this flag (I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) is accepted on a given kernel? I assume older kernels are going to reject object creation if we use this

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

2022-04-27 Thread Matthew Auld
On 27/04/2022 07:48, Lionel Landwerlin wrote: One question though, how do we detect that this flag (I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) is accepted on a given kernel? I assume older kernels are going to reject object creation if we use this flag? From some offline discussion with

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

2022-04-27 Thread Daniel Vetter
On Wed, Apr 27, 2022 at 08:55:07AM +0200, Christian König wrote: > Well usually we increment the drm minor version when adding some new flags > on amdgpu. > > Additional to that just one comment from our experience with that: You don't > just need one flag, but two. The first one is a hint which

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

2022-04-27 Thread Matthew Auld
On 27/04/2022 07:55, Christian König wrote: Well usually we increment the drm minor version when adding some new flags on amdgpu. Additional to that just one comment from our experience with that: You don't just need one flag, but two. The first one is a hint which says "CPU access needed"

Re: [Intel-gfx] [PATCH] drm/i915/uc: use io memcpy functions for device memory copy

2022-04-27 Thread Siva Mullati
LGTM Acked-by: Siva Mullati On 06/04/22 14:48, Vivekanandan, Balasubramani wrote: > When copying RSA use io memcpy functions if the destination address > contains a GPU local memory address. Considering even the source > address can be on local memory, a bounce buffer is used to copy from io >

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8)

2022-04-27 Thread Patchwork
== Series Details == Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8) URL : https://patchwork.freedesktop.org/series/102213/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102213v8

Re: [Intel-gfx] [RFC v2 1/2] drm/doc/rfc: VM_BIND feature design document

2022-04-27 Thread Daniel Vetter
On Wed, Apr 20, 2022 at 03:50:00PM -0700, Niranjana Vishwanathapura wrote: > On Thu, Mar 31, 2022 at 01:37:08PM +0200, Daniel Vetter wrote: > > One thing I've forgotten, since it's only hinted at here: If/when we > > switch tlb flushing from the current dumb implementation > > we now have in i915

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8)

2022-04-27 Thread Patchwork
== Series Details == Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8) URL : https://patchwork.freedesktop.org/series/102213/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8)

2022-04-27 Thread Patchwork
== Series Details == Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching (rev8) URL : https://patchwork.freedesktop.org/series/102213/ State : warning == Summary == Error: dim checkpatch failed e059b3ad1acf drm/i915/bios: Reorder panel DTD parsing 0daf03385bab

Re: [Intel-gfx] [PATCH 4/4] drm/i915/huc: Don't fail the probe if HuC init fails

2022-04-27 Thread Rodrigo Vivi
On Tue, Apr 26, 2022 at 05:26:17PM -0700, Daniele Ceraolo Spurio wrote: > The previous patch introduced new failure cases in the HuC init flow > that can be hit by simply changing the config, so we want to avoid > failing the probe in those scenarios. HuC load failure is already > considered a

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

2022-04-27 Thread Andi Shyti
[...] > + if (!dmc_mmio_addr_sanity_check(dmc, mmioaddr, mmio_count, > dmc_header->header_ver, dmc_id)) > + drm_err(>drm, "DMC firmware has Wrong MMIO Addresses\n"); > + return 0; > + mh? :)

Re: [Intel-gfx] [PATCH 1/4] drm/i915/huc: check HW directly for HuC auth status

2022-04-27 Thread Rodrigo Vivi
On Tue, Apr 26, 2022 at 05:26:14PM -0700, Daniele Ceraolo Spurio wrote: > The huc_is_authenticated function return is based on our SW tracking of > the HuC auth status. However, around suspend/resume and reset this can > go out of sync with the actual HW state, which is why we use >

Re: [Intel-gfx] [PATCH] drm/i915: Support Async Flip on Linear buffers

2022-04-27 Thread Ville Syrjälä
On Wed, Apr 27, 2022 at 02:58:09AM +, Murthy, Arun R wrote: > > On Tue, Apr 26, 2022 at 05:34:07PM +0530, Arun R Murthy wrote: > > > Starting from Gen12 Async Flip is supported on linear buffers. > > > > It's supported earlier than that. But IIRC there was some kind of GTT > > alignment vs.

Re: [Intel-gfx] [PATCH v12] drm/amdgpu: add drm buddy support to amdgpu

2022-04-27 Thread Mike Lothian
On Tue, 26 Apr 2022 at 17:36, Christian König wrote: > > Hi Mike, > > sounds like somehow stitching together the SG table for PRIME doesn't > work any more with this patch. > > Can you try with P2P DMA disabled? -CONFIG_PCI_P2PDMA=y +# CONFIG_PCI_P2PDMA is not set If that's what you're meaning,

Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs

2022-04-27 Thread Andi Shyti
Hi Ashutosh, > > > -static struct kobj_type kobj_gt_type = { > > > - .release = kobj_gt_release, > > > +static struct kobj_type kobj_gtn_type = { > > > > what does it mean GTN? Or is it GTn? Please use just GT, gtn is > > confusing. > > > > Same for all the rest of the gtn's you have used below.

[Intel-gfx] [PULL] drm-intel-gt-next

2022-04-27 Thread Tvrtko Ursulin
Hi Dave, Daniel, Here goes the first drm-intel-gt-next PR towards 5.19. A lot of stuff here across the board in terms of new features, new platform support and bug fixes. For bug fixes the most interesting are: * a fix for out of bounds kernel access in mmap ops due incorrect object bound

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: ttm backend dont provide mmap_offset for kernel buffers

2022-04-27 Thread Thomas Hellström
Sorry for late reply, On Thu, 2022-04-14 at 17:13 +0100, Robert Beckett wrote: > > > On 14/04/2022 15:05, Thomas Hellström wrote: > > On Tue, 2022-04-12 at 15:18 +, Robert Beckett wrote: > > > stolen/kernel buffers should not be mmapable by userland. > > > do not provide callbacks to

Re: [Intel-gfx] [PATCH v3] drm/i915: Don't show engine information in fdinfo with GuC submission

2022-04-27 Thread Tvrtko Ursulin
On 15/04/2022 01:25, Ashutosh Dixit wrote: At present i915 does not fetch busyness information from GuC, resulting in incorrect busyness values in fdinfo. Because engine information is coupled with busyness in fdinfo, skip showing client engine information in fdinfo with GuC submission till

Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi

2022-04-27 Thread Tvrtko Ursulin
On 20/04/2022 18:13, Matthew Auld wrote: Add an entry for the new uapi needed for small BAR on DG2+. v2: - Some spelling fixes and other small tweaks. (Akeem & Thomas) - Rework error capture interactions, including no longer needing NEEDS_CPU_ACCESS for objects marked for capture.

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Use existing uncore helper to read gpm_timestamp

2022-04-27 Thread Tvrtko Ursulin
On 27/04/2022 01:35, Umesh Nerlige Ramappa wrote: Use intel_uncore_read64_2x32 to read upper and lower fields of the GPM timestamp. v2: Fix compile error Signed-off-by: Umesh Nerlige Ramappa --- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 ++--- 1 file changed, 2

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Add MMIO range restrictions

2022-04-27 Thread kernel test robot
, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/intel-lab-lkp/linux/commits/Anusha-Srivatsa/drm-i915-dmc-Add-MMIO-range-restrictions/20220427-084021 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Add first set of DG2 PCI IDs

2022-04-27 Thread Lucas De Marchi
On Mon, Apr 25, 2022 at 02:12:50PM -0700, Matt Roper wrote: The IDs added here are the subset reserved for 'motherboard down' designs of DG2. We have all the necessary support upstream to enable these now (although they'll continue to require force_probe until the usual requirements are met).

  1   2   >