Those regs are added in order to slove the following complains:

 [70811.201818] gvt: vgpu(1) Invalid FORCE_NONPRIV write 2341 at offset 24d8
 [70811.201825] gvt: vgpu(1) Invalid FORCE_NONPRIV write 2351 at offset 24dc
 [70811.201831] gvt: vgpu(1) Invalid FORCE_NONPRIV write 10000d82 at offset 24e0
 [70811.201837] gvt: vgpu(1) Invalid FORCE_NONPRIV write 10064844 at offset 24e4

So solve them by adding the required regs to the whitelist.
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200302083130.17831-1-tina.zhang@intel.com

Teach gvt to use intel_gt directly as it currently assumes direct HW
access.

[Zhenyu: rebase, fix compiling]

Cc: Ding Zhuocheng <zhuocheng.ding@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200304032307.2983-3-zhenyuw@linux.intel.com

Stop trying to escape out of the gvt layer to find the engine that we
initially setup for use with gvt. Record the engines during initialisation
and use them henceforth.

add/remove: 1/4 grow/shrink: 22/28 up/down: 341/-1410 (-1069)

[Zhenyu: rebase, fix nonpriv register check fault, fix gvt engine
thread run failure.]

Cc: Ding Zhuocheng <zhuocheng.ding@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200304032307.2983-2-zhenyuw@linux.intel.com

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@@
identifier func, T;
@@
func(struct intel_vgpu *T,...) {
+struct drm_i915_private *i915 = T->gvt->dev_priv;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>

}
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-9-pankaj.laxminarayan.bharadiya@intel.com

drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.

The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.

@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}

@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-8-pankaj.laxminarayan.bharadiya@intel.com

Now start using parameterized DBUF_CTL instead
of hardcoded, this would allow shorter access
functions when reading or storing entire state.

Tried to implement it in a MMIO_PIPE manner, however
DBUF_CTL1 address is higher than DBUF_CTL2, which
implies that we have to now subtract from base
rather than add.

v2: - Removed unneeded DBUF_CTL_DIST and DBUF_CTL_ADDR
      macros. Started to use _PICK construct as suggested
      by Matt Roper.

v3: - _DBUF_CTL_S* to DBUF_CTL_S*, changed X to "slice"
      in macro(Ville Syrjälä)
    - Introduced enum for enumerating DBUF slices(Ville Syrjälä)
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202230630.8975-5-stanislav.lisovskiy@intel.com

Let's store the normal and IPS linetime watermarks individually,
and while at it we'll pimp the register definitions as well.

v2: Deal with gvt
Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-2-ville.syrjala@linux.intel.com

We are currently using a mix of platform name and acronym to name the
functions. Let's prefer the acronym as it should be clear what platform
it's about and it's shorter, so it doesn't go over 80 columns in a few
cases. This converts broadwell to bdw where appropriate.
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Acked-by: NJani Nikula <jani.nikula@linux.intel.com>
Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191224084012.24241-8-lucas.demarchi@intel.com

Simulate MIA core in reset status once GUC engine is reset.

v2: 1. use vgpu_vreg_t() function,
    2. clear MIA_IN_RESET after reading. (Zhenyu)
v3: add comments. (Zhenyu)
Signed-off-by: NGao Fred <fred.gao@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20191216160255.29499-1-fred.gao@intel.com

Host print below warning message when creating guest:
    "gvt: vgpu(1) Invalid FORCE_NONPRIV write 10002349".

Add register 0x2348 in force-to-nonpriv whitelist as required
by guest.
Signed-off-by: NGao, Fred <fred.gao@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The BitField of non privilege register address is only from bit 2 to 25.

v2: use REG_GENMASK instead. (Zhenyu)
Signed-off-by: NGao, Fred <fred.gao@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The region of pvinfo is reserved for communication between a VMM and
the GPU driver executing on a virtual machine. HW doesn't have any
backing mmio store support for the pvinfo region, thus accessing to
this range through MMIO read/write from host side is forbidden which
is regarded as unclaimed register access.

This patch leaves pvinfo range be initialized with zero.
Signed-off-by: NTina Zhang <tina.zhang@intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

We reference DP AUX registers via the DP_AUX_CH_CTL() and
DP_AUX_CH_DATA() macros that calculate all the register offsets for us
automatically; there's no need to explicitly define every offset in
i915_reg.h if they're never going to be used by the driver code.

v2: Apparently GVT was directly using these raw definitions in a couple
    places.  Switch GVT code over to using our preferred macros.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>  #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20191026051226.30807-1-matthew.d.roper@intel.com

PSR registers are a mess, some have the full address while others just
have the additional offset from psr_mmio_base.

For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
0x800 and using it makes more difficult for people with an PSR
register address or PSR register name from from BSpec as i915 also
don't match the BSpec names.
For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers are
only available in DDIA.

Other reason to make relative to transcoder is that since BDW every
transcoder have PSR registers, so in theory it should be possible to
have PSR enabled in a non-eDP transcoder.

So for BDW+ we can use _TRANS2() to get the register offset of any
PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ
that will calculate the register offset for the single PSR instance,
noting that we are already guarded about trying to enable PSR in other
port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)' in
intel_psr_compute_config(), this check should only be valid for HSW
and will be changed in future.
PSR2 registers and PSR_EVENT was added after Haswell so that is why
_PSR_ADJ() is not used in some macros.

The only registers that can not be relative to transcoder are
PSR_IMR and PSR_IIR that are not relative to anything, so keeping it
hardcoded. That changed for TGL but it will be handled in another
patch.

Also removing BDW_EDP_PSR_BASE from GVT because it is not used as it
is the only PSR register that GVT have.

v5:
- Macros changed to be more explicit about HSW (Dhinakaran)
- Squashed with the patch that added the tran parameter to the
macros (Dhinakaran)

v6:
- Checking for interruption errors after module reload in the
transcoder that will be used (Dhinakaran)
- Using lowercase to the registers offsets

v7:
- Removing IS_HASWELL() from registers macros(Jani)

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190820223325.27490-1-jose.souza@intel.com

There is pvinfo writing come from vgpu might be unexpected, like
writing to one unknown address, GVT-g should do as reserved register
to discard any invalid write. Now GVT-g lets it write to the vreg
without prompt error message, should ignore the unexpected pvinfo
write access and leave the vreg as the default value.

For possible guest query GVT-g host feature, this returned proper
value instead of wrong guest setting.

v2: ignore unexpected pvinfo write instead of return predefined value

Fixes: e39c5add ("drm/i915/gvt: vGPU MMIO virtualization")
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Instead of updating by MMIO write, all of the wa regs are initialized by
wa_ctx. From host side, it should make this behavior as expected, add
'F_CMD_ACCESS' flag to these regs and allow access by commands.

[  123.557608] gvt: vgpu 2: srm access to non-render register (b11c)
[  123.563728] gvt: vgpu 2: MI_STORE_REGISTER_MEM handler error
[  123.569409] gvt: vgpu 2: cmd parser error
[  123.573424] 0x0
[  123.573425] 0x24

[  123.578686] gvt: vgpu 2: scan workload error
[  123.582958] GVT Internal error  for the guest
[  123.587317] Now vgpu 2 will enter failsafe mode.
[  123.591938] gvt: vgpu 2: failed to submit desc 0
[  123.596557] gvt: vgpu 2: fail submit workload on ring 0
[  123.601786] gvt: vgpu 2: fail to emulate MMIO write 00002230 len 4
Acked-by: NYan Zhao <yan.y.zhao@intel.com>
Signed-off-by: NWeinan Li <weinan.z.li@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Enter failsafe if vgpu tries to change CSFE_CHICKEN1_REG setting
which is controlled by host.
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Enter failsafe if vgpu tries to change GFX_MODE controlled by host.
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Host prints below warning message when guest running some application:
"gvt: vgpu(1) Invalid FORCE_NONPRIV write 2754 at 24f0".
"gvt: vgpu(1) Invalid FORCE_NONPRIV write 28a0 at 24f0".

Registers 0x2754 and 0x28a0 are required by guest so add to whitelist.
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

the vGPU write on TRTTE and 0x4dfc is now write to vreg first. their
values all be restored hardware when context switching.

Fixes: e39c5add ("drm/i915/gvt: vGPU MMIO virtualization")
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NYan Zhao <yan.y.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Revert "drm/i915/gvt: Refine the snapshort range of I915 MCHBAR to optimize gvt-g boot time"

This reverts commit f74a6d9a.

BXT needs to access 0x141000-0x1417ff register to obtain the dram info.
But after the snapshot range of I915_MCHBAR is refined in f74a6d9a,
it only initializes the range of 0x144000-0x147fff for VGPU and then
causes that the guest GPU can't get the initialized value for dram
detection on BXT.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Typedef is not recommended in the Linux kernel.The klocwork static code
analyzer takes the enumeration as the full range of intel_gvt_gtt_type_t.
But the intel_gvt_gtt_type_t will never be used in full range. For
example, the GTT_TYPE_INVALID will never be used as an index of an array.
Remove the typedef and let the enumeration starts from zero to pass
klocwork analysis.

This patch fixed the critial issues #483, #551, #665 reported by
klockwork.

v3:
- Remove the typedef and let the enumeration starts from zero.
Signed-off-by: NAleksei Gimbitskii <aleksei.gimbitskii@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
CC: Colin Xu <colin.xu@intel.com>
Reviewed-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

We want to use intel_engine_mask_t inside i915_request.h, which means
extracting it from the general header file mess and placing it inside a
types.h. A knock on effect is that the compiler wants to warn about
type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
for the worst.

v2: Use intel_engine_mask_t consistently
v3: Move I915_NUM_ENGINES to its natural home at the end of the enum
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190401162641.10963-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

According to Intel GFX PRM on 01.org, plane surface address can be updated
synchronously or asynchronously. Synchronous flip will hold plane surface
address update to start of next vsync, which is current implementation.
Asynchronous flip will update the address as soon as possible. Without
async flip, some 3D application could not reach better performance and
the maximum performance is no higher than vsync frequency.

The patch enables the async flip on plane surface address mmio update,
and increment flip count correctly.

With async flip enabled, some 3D applications have significant performance
improvement. i.e. 3DMark Ice Storm has a 300%~400% increment on score.

v2:
Use bit operation definition for flip mode. (zhenyu)
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

in init_skil_mmio_info, replaced register address with the known
name from i915_reg.h definition to improve code readbility.
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

A few advantages:

- Prepares us for the planned split of display uncore from GT uncore

- Improves our engine-centric view of the world in the engine code
  and allows us to avoid jumping back to dev_priv.

- Allows us to wrap accesses to engine register in nice macros that
  automatically pick the right mmio base.
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-10-daniele.ceraolospurio@intel.com

code cleanup. sreg is not used now. remove it for code cleanness.

v3: remove unnecessary array_size in vreg's memory allocation (min he)
v2: do not allocate memory for sreg. (min he)
Reviewed-by: NHe, Min <min.he@intel.com>
Signed-off-by: NYan Zhao <yan.y.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

In the next patch, we are introducing a broad virtual engine to encompass
multiple physical engines, losing the 1:1 nature of BIT(engine->id). To
reflect the broader set of engines implied by the virtual instance, lets
store the full bitmask.

v2: Use intel_engine_mask_t (s/ring_mask/engine_mask/)
v3: Tvrtko voted for moah churn so teach everyone to not mention ring
and use $class$instance throughout.
v4: Comment upon the disparity in bspec for using VCS1,VCS2 in gen8 and
VCS[0-4] in later gen. We opt to keep the code consistent and use
0-index naming throughout.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190305180332.30900-1-chris@chris-wilson.co.uk

Currently it will take the snapshot of the MCHBAR registers for gvt-g
initialization so that it can be used for guest vgpu. And it will cover
from 0x140000 to 0x17ffff. In fact based on the HW spec most of them are
meanlingless and some time is wasted to read these register.
Only the range of 0x144000 to 0x147fff contains the valid definition.
So the range of capturing I915 MCHBAR register is refined, which helps
to optimize the gvt-g boot time.

V1->V2: Move the register definition into reg.h
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Mixed C99 and kernel types use is getting ugly. Prefer kernel types.

sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Acked-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

The newly updated guest driver could program 0x21f0 via lri and srm,
without F_CMD_ACCESS flag cmd parser will stop parser reset cmd.
0x21f0 applies to BDW, SKL, KBL, BXT and CFL.
Reviewed-by: NYan Zhao <yan.y.zhao@intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Use INTEL_GEN to simplify the code for SKL+ platforms.

v2:
- split the enabling code into final one to identify any regression.

Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NFei Jiang <fei.jiang@intel.com>
Signed-off-by: Nfred gao <fred.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Add registers of 0x4ab8 and 0x2248 into MMIO handler.
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NFei Jiang <fei.jiang@intel.com>
Signed-off-by: Nfred gao <fred.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Add D_CFL for CFL platform.
Reviewed-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NFei Jiang <fei.jiang@intel.com>
Signed-off-by: Nfred gao <fred.gao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Host print below warning message when creating guest:
"gvt: vgpu(2) Invalid FORCE_NONPRIV write 83a8".

Register 0x83a8 should be in force-to-nonpriv whitelist as required by
guest

v2: update commit message to describe purpose of this patch in detail
(zhenyu wang)
Signed-off-by: NZhao Yan <yan.y.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

GVT-g only simulates DP port for guest and leaves EDP_PSR_IMR
and EDP_PSR_IIR registers as default MMIO read/write.
So guest won't get expected initial values of these registers when
initializing the gpu driver, which results in following warning and logs.

--------
Interrupt register 0x64838 is not zero: 0xffffffff
WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/i915/i915_irq.c:177
gen3_assert_iir_is_zero+0x38/0xa0

Call Trace:
gen8_de_irq_postinstall+0xa7/0x400
gen8_irq_postinstall+0x27/0x80
drm_irq_install+0xbc/0x140
i915_driver_load+0xa9d/0xd50
--------
Because GVT-g does not handle EDP(embedded DP) simulation for guests,
always set EDP_PSR_IMR and EDP_PSR_IIR to value 0.
Signed-off-by: NLonghe Zheng <longhe.zheng@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Host prints lots of untracked MMIO at 0x4653c when creating linux guest.
"gvt: vgpu 2: untracked MMIO 0004653c len 4"

GEN9_CLKGATE_DIS_4 (0x4653c) is accessed by i915 for gmbus clockgating.
However vgpu doesn't support any clockgating powergating operations
on related mmio access trap so need add it to default handler.
GEN9_CLKGATE_DIS_4 is accessed in bxt_gmbus_clock_gating() which only
applies to GEN9_LP so doens't show the warning on other platforms.

The solution is to add it to default handler init_bxt_mmio_info().
Reviewed-by: NHe, Min <min.he@intel.com>
Signed-off-by: NColin Xu <colin.xu@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Recent patch introduce strict check on scanning cmd:
Commit 8d458ea0 ("drm/i915/gvt: return error on cmd access")

Before 8d458ea0, if cmd_reg_handler() checks that a cmd access a mmio
that not marked as F_CMD_ACCESS, it simply returns 0 and log an error.
Now it will return -EBADRQC which will cause the workload fail to submit.

On BXT, i915 applies WaClearHIZ_WM_CHICKEN3 which will program
GEN9_WM_CHICKEN3 by LRI when init wa ctx. If it has no F_CMD_ACCESS flag,
vgpu will fail to start. Also add F_MODE_MASK since it's mode mask reg.

v2: Refresh commit message to elaborate issue symptom in detail.
v3: Make SKL_PLUS share same handling since GEN9_WM_CHICKEN3 should be
    F_CMD_ACCESS from HW aspect. (yan, zhenyu)
Signed-off-by: NColin Xu <colin.xu@intel.com>
Acked-by: NZhao Yan <yan.y.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

Guest kernel will write to BXT_PHY_CTL_FAMILY to reset DDI PHY
and pull BXT_PHY_CTL to check PHY status. Previous handling will
set/reset BXT_PHY_CTL of all PHYs at same time on receiving vreg
write to some BXT_PHY_CTL_FAMILY. If some BXT_PHY_CTL is already
enabled, following reset to another BXT_PHY_CTL_FAMILY will clear
the enabled BXT_PHY_CTL, which result in guest kernel print:

-----------------------------------
[drm:intel_ddi_get_hw_state [i915]]
*ERROR* Port B enabled but PHY powered down? (PHY_CTL 00000000)
-----------------------------------

The correct handling should operate BXT_PHY_CTL_FAMILY and
BXT_PHY_CTL on the same DDI.

v2: Use correct reg define. The naming looks confusing, however
    current i915_reg.h bind DPIO_PHY0 to _PHY_CTL_FAMILY_DDI and
    bind DPIO_PHY1 to _PHY_CTL_FAMILY_EDP, pairing to
    _BXT_PHY_CTL_DDI_A and _BXT_PHY_CTL_DDI_B respectively.
v3: v2 incorrectly map _PHY_CTL_FAMILY_EDP to _BXT_PHY_CTL_DDI_A.
    BXT_PHY_CTL() looks up DDI using PORTx but not PHYx. Based on
    DPIO_PHY to DDI mapping, make correct vreg handle to BXT_PHY_CTL
    on receiving vreg write to BXT_PHY_CTL_FAMILY. (He, Min)

Current mapping according to bxt_power_wells:
dpio-common-a:
    >>> DPIO_PHY1
    >>> BXT_DPIO_CMN_A_POWER_DOMAINS
    >>> POWER_DOMAIN_PORT_DDI_A_LANES
    >>> PORT_A

dpio-common-bc:
    >>> DPIO_PHY0
    >>> BXT_DPIO_CMN_BC_POWER_DOMAINS
    >>> POWER_DOMAIN_PORT_DDI_B_LANES | POWER_DOMAIN_PORT_DDI_C_LANES
    >>> PORT_B or PORT_C
Signed-off-by: NColin Xu <colin.xu@intel.com>
Reviewed-by: NHe, Min <min.he@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>

there is below call track at boot time when booting guest
with kabylake vgpu with specifal configuration and this try to fix it.

[drm:gen9_dbuf_enable [i915]] *ERROR* DBuf power enable timeout
------------[ cut here ]------------
WARNING: gen9_dc_off_power_well_enable+0x224/0x230 [i915]
Unexpected DBuf power power state (0x8000000a)
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
 [<ffffffff99d24408>] dump_stack+0x19/0x1b
 [<ffffffff996926d8>] __warn+0xd8/0x100
 [<ffffffff9969275f>] warn_slowpath_fmt+0x5f/0x80
 [<ffffffffc07bbae4>] gen9_dc_off_power_well_enable+0x224/0x230 [i915]
 [<ffffffffc07ba9d2>] intel_power_well_enable+0x42/0x50 [i915]
 [<ffffffffc07baa6a>] __intel_display_power_get_domain+0x8a/0xb0 [i915]
 [<ffffffffc07bdb93>] intel_display_power_get+0x33/0x50 [i915]
 [<ffffffffc07bdf95>] intel_display_set_init_power+0x45/0x50 [i915]
 [<ffffffffc07be003>] intel_power_domains_init_hw+0x63/0x8a0 [i915]
 [<ffffffffc07995c3>] i915_driver_load+0xae3/0x1760 [i915]
 [<ffffffff99bd6580>] ? nvmem_register+0x500/0x500
 [<ffffffffc07a476c>] i915_pci_probe+0x2c/0x50 [i915]
 [<ffffffff9999cfea>] local_pci_probe+0x4a/0xb0
 [<ffffffff9999e729>] pci_device_probe+0x109/0x160
 [<ffffffff99a79aa5>] driver_probe_device+0xc5/0x3e0
 [<ffffffff99a79ea3>] __driver_attach+0x93/0xa0
 [<ffffffff99a79e10>] ? __device_attach+0x50/0x50
 [<ffffffff99a77645>] bus_for_each_dev+0x75/0xc0
 [<ffffffff99a7941e>] driver_attach+0x1e/0x20
 [<ffffffff99a78ec0>] bus_add_driver+0x200/0x2d0
 [<ffffffff99a7a534>] driver_register+0x64/0xf0
 [<ffffffff9999df65>] __pci_register_driver+0xa5/0xc0
 [<ffffffffc0929000>] ? 0xffffffffc0928fff
 [<ffffffffc0929059>] i915_init+0x59/0x5c [i915]
 [<ffffffff9960210a>] do_one_initcall+0xba/0x240
 [<ffffffff9971108c>] load_module+0x272c/0x2bc0
 [<ffffffff9997b990>] ? ddebug_proc_write+0xf0/0xf0
 [<ffffffff997115e5>] SyS_init_module+0xc5/0x110
 [<ffffffff99d36795>] system_call_fastpath+0x1c/0x21
Signed-off-by: NXiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>