1. 24 9月, 2015 1 次提交
  2. 17 9月, 2015 1 次提交
  3. 14 9月, 2015 2 次提交
    • T
      drm/vmwgfx: Map the fifo as cached · 2e586a7e
      Thomas Hellstrom 提交于
      On the guest kernel side, previously the FIFO has been mapped write-
      combined. This has worked since VMs up to now has not honored the mapping
      type and mapped the FIFO cached anyway. Since the FIFO is accessed cached
      by the CPU on the virtual device side, this leads to inconsistent
      mappings once the guest starts to honor the mapping types.
      
      So ask for cached mappings when we map the FIFO. We do this by
      using ioremap_cache() instead of ioremap_wc(), and remove the MTRR setup.
      On the TTM side, MOBs, GMRs and VRAM buffers are already requesting
      cached mappings for kernel- and user-space.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NSinclair Yeh <syeh@vmware.com>
      2e586a7e
    • T
      drm/vmwgfx: Fix up user_dmabuf refcounting · 54c12bc3
      Thomas Hellstrom 提交于
      If user space calls unreference on a user_dmabuf it will typically
      kill the struct ttm_base_object member which is responsible for the
      user-space visibility. However the dmabuf part may still be alive and
      refcounted. In some situations, like for shared guest-backed surface
      referencing/opening, the driver may try to reference the
      struct ttm_base_object member again, causing an immediate kernel warning
      and a later kernel NULL pointer dereference.
      
      Fix this by always maintaining a reference on the struct
      ttm_base_object member, in situations where it might subsequently be
      referenced.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NBrian Paul <brianp@vmware.com>
      Reviewed-by: NSinclair Yeh <syeh@vmware.com>
      54c12bc3
  4. 01 9月, 2015 1 次提交
  5. 21 8月, 2015 2 次提交
  6. 14 8月, 2015 1 次提交
    • T
      drm/vmwgfx: Fix execbuf locking issues · 3e04e2fe
      Thomas Hellstrom 提交于
      This addresses two issues that cause problems with viewperf maya-03 in
      situation with memory pressure.
      
      The first issue causes attempts to unreserve buffers if batched
      reservation fails due to, for example, a signal pending. While previously
      the ttm_eu api was resistant against this type of error, it is no longer
      and the lockdep code will complain about attempting to unreserve buffers
      that are not reserved. The issue is resolved by avoid calling
      ttm_eu_backoff_reservation in the buffer reserve error path.
      
      The second issue is that the binding_mutex may be held when user-space
      fence objects are created and hence during memory reclaims. This may cause
      recursive attempts to grab the binding mutex. The issue is resolved by not
      holding the binding mutex across fence creation and submission.
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NSinclair Yeh <syeh@vmware.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3e04e2fe
  7. 13 8月, 2015 9 次提交
  8. 06 8月, 2015 1 次提交
  9. 05 8月, 2015 22 次提交