Skip to content

L
linux
Switch branch/tag
  1. 27 Sep, 2018 3 commits
  3. 20 Sep, 2018 13 commits
  5. 19 Sep, 2018 1 commit
  7. 18 Sep, 2018 6 commits
    • Rodrigo Vivi's avatar
      Merge tag 'gvt-fixes-2018-09-18' of https://github.com/intel/gvt-linux into drm-intel-fixes · a530bf94
      Rodrigo Vivi authored 
      gvt-fixes-2018-09-18

- Fix initial DPIO PHY register state for BXT (Colin)
- BXT untracked GEN9_CLKGATE_DIS_4 warning fix (Colin)
- Fix srcu lock for GFN valid check (Weinan)
- Should clear GGTT entry value after vGPU destroy (Zhipeng)
Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180918073349.GQ20737@zhen-hp.sh.intel.com
      a530bf94
    • Dave Airlie's avatar
      drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers. · 57078338
      Dave Airlie authored 
      vgem seems to oops on the intel CI due to the vgem debugfs init
hitting this path now.

Check if we have mode_config funcs before checking one.
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180918062018.24942-1-airlied@gmail.com
      57078338
    • Zhipeng Gong's avatar
      drm/i915/gvt: clear ggtt entries when destroy vgpu · 7759ca3a
      Zhipeng Gong authored 
      When one vgpu is destroyed, its ggtt entries are not cleared.
This patch clears ggtt entries to avoid information leak.

v2: add 'Fixes' tag (Zhenyu)

Fixes: 2707e444 ("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: default avatarZhipeng Gong <zhipeng.gong@intel.com>
Reviewed-by: default avatarHang Yuan <hang.yuan@intel.com>
Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      7759ca3a
    • Weinan Li's avatar
      drm/i915/gvt: request srcu_read_lock before checking if one gfn is valid · a1ac5f09
      Weinan Li authored 
      Fix the suspicious RCU usage issue in intel_vgpu_emulate_mmio_write.
Here need to request the srcu read lock of kvm->srcu before doing
gfn_to_memslot(). The detailed log is as below:
[  218.710688] =============================
[  218.710690] WARNING: suspicious RCU usage
[  218.710693] 4.14.15-dd+ #314 Tainted: G     U
[  218.710695] -----------------------------
[  218.710697] ./include/linux/kvm_host.h:575 suspicious rcu_dereference_check() usage!
[  218.710699]
               other info that might help us debug this:

[  218.710702]
               rcu_scheduler_active = 2, debug_locks = 1
[  218.710704] 1 lock held by qemu-system-x86/2144:
[  218.710706]  #0:  (&gvt->lock){+.+.}, at: [<ffffffff816a1eea>] intel_vgpu_emulate_mmio_write+0x5a/0x2d0
[  218.710721]
               stack backtrace:
[  218.710724] CPU: 0 PID: 2144 Comm: qemu-system-x86 Tainted: G     U 4.14.15-dd+ #314
[  218.710727] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015
[  218.710729] Call Trace:
[  218.710734]  dump_stack+0x7c/0xb3
[  218.710739]  gfn_to_memslot+0x15f/0x170
[  218.710743]  kvm_is_visible_gfn+0xa/0x30
[  218.710746]  intel_vgpu_emulate_gtt_mmio_write+0x267/0x3c0
[  218.710751]  ? __mutex_unlock_slowpath+0x3b/0x260
[  218.710754]  intel_vgpu_emulate_mmio_write+0x182/0x2d0
[  218.710759]  intel_vgpu_rw+0xba/0x170 [kvmgt]
[  218.710763]  intel_vgpu_write+0x14d/0x1a0 [kvmgt]
[  218.710767]  __vfs_write+0x23/0x130
[  218.710770]  vfs_write+0xb0/0x1b0
[  218.710774]  SyS_pwrite64+0x73/0x90
[  218.710777]  entry_SYSCALL_64_fastpath+0x25/0x9c
[  218.710780] RIP: 0033:0x7f33e8a91da3
[  218.710783] RSP: 002b:00007f33dddc8700 EFLAGS: 00000293

v2: add 'Fixes' tag, refine log format.(Zhenyu)
Fixes: cc753fbe ("drm/i915/gvt: validate gfn before set shadow page")
Reviewed-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: default avatarWeinan Li <weinan.z.li@intel.com>
Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      a1ac5f09
    • Colin Xu's avatar
      drm/i915/gvt: Add GEN9_CLKGATE_DIS_4 to default BXT mmio handler · d817de3b
      Colin Xu authored 
      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: default avatarHe, Min <min.he@intel.com>
Signed-off-by: default avatarColin Xu <colin.xu@intel.com>
Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      d817de3b
    • Colin Xu's avatar
      drm/i915/gvt: Init PHY related registers for BXT · db7c8f1e
      Colin Xu authored 
      Recent patch fixed the call trace
"ERROR Port B enabled but PHY powered down? (PHY_CTL 00000000)".
but introduced another similar call trace shown as:
"ERROR Port C enabled but PHY powered down? (PHY_CTL 00000200)".
The call trace will appear when host and guest enabled different ports,
i.e. host using PORT C or neither PORT is enabled, while guest is always
using PORT B as simulated by gvt. The issue is actually covered previously
before the commit and reverals now when the commit do the right thing.

On BXT, some PHY registers are initialized by vbios, before i915 loaded.
Later i915 will re-program some, or skip some based on the implementation.
The initialized mmio for guest i915 is done by gvt, based on the snapshot
taken from host. If host and guest have different PORT enabled, some
DPIO PHY mmios that gvt initialized for guest i915 will not match the
simualted monitor for guest, which leads to guest i915 print the calltrace
when it's trying to enable PHY and PORT.

The solution is to init these DPIO PHY registers to default value, then
guest i915 will program them to reasonable value based on the default
powerwell table and enabled PORT. Together with the old patch, all similar
call trace in guest kernel on BXT can be resolved.

v2: Move PHY register init to intel_vgpu_reset_mmio (Min)
v3: Do not delete empty line in issue fix patch. (zhenyu)

Fixes: c8ab5ac3 ("drm/i915/gvt: Make correct handling to vreg
BXT_PHY_CTL_FAMILY")
Reviewed-by: default avatarHe, Min <min.he@intel.com>
Signed-off-by: default avatarColin Xu <colin.xu@intel.com>
Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      db7c8f1e
  9. 17 Sep, 2018 1 commit
  11. 16 Sep, 2018 2 commits
  13. 15 Sep, 2018 8 commits
  15. 14 Sep, 2018 6 commits
    • Linus Torvalds's avatar
      Merge tag 'devicetree-fixes-for-4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux · 090b75bc
      Linus Torvalds authored 
      Pull DeviceTree fix from Rob Herring:
 "One regression for a 20 year old PowerMac:

   - Fix a regression on systems having a DT without any phandles which
     happens on a PowerMac G3"

* tag 'devicetree-fixes-for-4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux:
  of: fix phandle cache creation for DTs with no phandles
      090b75bc
    • Linus Torvalds's avatar
      Merge tag 'for-linus-4.19c-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip · d7c02680
      Linus Torvalds authored 
      Pull xen fixes from Juergen Gross:
 "This contains some minor cleanups and fixes:

   - a new knob for controlling scrubbing of pages returned by the Xen
     balloon driver to the Xen hypervisor to address a boot performance
     issue seen in large guests booted pre-ballooned

   - a fix of a regression in the gntdev driver which made it impossible
     to use fully virtualized guests (HVM guests) with a 4.19 based dom0

   - a fix in Xen cpu hotplug functionality which could be triggered by
     wrong admin commands (setting number of active vcpus to 0)

  One further note: the patches have all been under test for several
  days in another branch. This branch has been rebased in order to avoid
  merge conflicts"

* tag 'for-linus-4.19c-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/gntdev: fix up blockable calls to mn_invl_range_start
  xen: fix GCC warning and remove duplicate EVTCHN_ROW/EVTCHN_COL usage
  xen: avoid crash in disable_hotplug_cpu
  xen/balloon: add runtime control for scrubbing ballooned out pages
  xen/manage: don't complain about an empty value in control/sysrq node
      d7c02680
    • Linus Torvalds's avatar
      Merge tag 'xtensa-20180914' of git://github.com/jcmvbkbc/linux-xtensa · eae4f885
      Linus Torvalds authored 
      Pull Xtensa fixes and cleanups from Max Filippov:

 - don't allocate memory in platform_setup as the memory allocator is
   not initialized at that point yet;

 - remove unnecessary ifeq KBUILD_SRC from arch/xtensa/Makefile;

 - enable SG chaining in arch/xtensa/Kconfig.

* tag 'xtensa-20180914' of git://github.com/jcmvbkbc/linux-xtensa:
  xtensa: enable SG chaining in Kconfig
  xtensa: remove unnecessary KBUILD_SRC ifeq conditional
  xtensa: ISS: don't allocate memory in platform_setup
      eae4f885
    • Linus Torvalds's avatar
      Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux · 3e153256
      Linus Torvalds authored 
      Pull arm64 fixes from Will Deacon:
 "The trickle of arm64 fixes continues to come in.

  Nothing that's the end of the world, but we've got a fix for PCI IO
  port accesses, an accidental naked "asm goto" and a fix to the
  vmcoreinfo PT_NOTE merged this time around which we'd like to get
  sorted before it becomes ABI.

   - Fix ioport_map() mapping the wrong physical address for some I/O
     BARs

   - Remove direct use of "asm goto", since some compilers don't like
     that

   - Ensure kimage_voffset is always present in vmcoreinfo PT_NOTE"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  asm-generic: io: Fix ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO
  arm64: kernel: arch_crash_save_vmcoreinfo() should depend on CONFIG_CRASH_CORE
  arm64: jump_label.h: use asm_volatile_goto macro instead of "asm goto"
      3e153256
    • Trond Myklebust's avatar
      NFS: Don't open code clearing of delegation state · 9f0c5124
      Trond Myklebust authored 
      Add a helper for the case when the nfs4 open state has been set to use
a delegation stateid, and we want to revert to using the open stateid.
Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      9f0c5124
    • Trond Myklebust's avatar
      NFSv4.1 fix infinite loop on I/O. · 994b15b9
      Trond Myklebust authored 
      The previous fix broke recovery of delegated stateids because it assumes
that if we did not mark the delegation as suspect, then the delegation has
effectively been revoked, and so it removes that delegation irrespectively
of whether or not it is valid and still in use. While this is "mostly
harmless" for ordinary I/O, we've seen pNFS fail with LAYOUTGET spinning
in an infinite loop while complaining that we're using an invalid stateid
(in this case the all-zero stateid).

What we rather want to do here is ensure that the delegation is always
correctly marked as needing testing when that is the case. So we want
to close the loophole offered by nfs4_schedule_stateid_recovery(),
which marks the state as needing to be reclaimed, but not the
delegation that may be backing it.

Fixes: 0e3d3e5d ("NFSv4.1 fix infinite loop on IO BAD_STATEID error")
Signed-off-by: default avatarTrond Myklebust <trond.myklebust@hammerspace.com>
Cc: stable@vger.kernel.org # v4.11+
Signed-off-by: default avatarAnna Schumaker <Anna.Schumaker@Netapp.com>
      994b15b9
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7