drm/vmwgfx: Fix fencing on SVGAv3

Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with command buffers and extra registers.
The initial version of SV

drm/vmwgfx: Fix fencing on SVGAv3

Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with command buffers and extra registers.
The initial version of SVGAv3 lacked support for most advanced features
(e.g. 3D) which made fences unnecessary. That is no longer the case,
especially as 3D support is being turned on.

Switch from FIFO commands and capabilities to command buffers and extra
registers to enable fences on SVGAv3.

Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-5-zack@kde.org

show more ...

drm/vmwgfx: Add support for CursorMob and CursorBypass 4

* Add support for CursorMob
* Add support for CursorBypass 4
* Refactor vmw_du_cursor_plane_atomic_update to be kms-helper-atomic
-- move B

drm/vmwgfx: Add support for CursorMob and CursorBypass 4

* Add support for CursorMob
* Add support for CursorBypass 4
* Refactor vmw_du_cursor_plane_atomic_update to be kms-helper-atomic
-- move BO mappings to vmw_du_cursor_plane_prepare_fb
-- move BO unmappings to vmw_du_cursor_plane_cleanup_fb

Cursor mobs are a new svga feature which enables support for large
cursors, e.g. large accessibility cursor on platforms with vmwgfx. It
also cleans up the cursor code and makes it more uniform with the rest
of modern guest backed objects support.

Signed-off-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-2-zack@kde.org

show more ...

drm/vmwgfx: Fix stale file descriptors on failed usercopy

A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This

drm/vmwgfx: Fix stale file descriptors on failed usercopy

A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.

Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.

Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support")
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

show more ...

drm/vmwgfx: Remove unused compile options

Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since

drm/vmwgfx: Remove unused compile options

Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since the implementation of screen targets landed there hasn't been a
reason to explicitly disable it and the options were never used.
Remove of all that unused code.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org
(cherry picked from commit 11343099d5ae6c7411da1425b6b162c89fb5bf10)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

show more ...

drm/vmwgfx: Remove explicit transparent hugepages support

Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only v

drm/vmwgfx: Remove explicit transparent hugepages support

Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only very
old devices (OpenGL 2.1 support and earlier) used this code and at this
point performance differences are negligible.

Because the code requires very old hardware versions to run it has
been largely untested and unused for a long time.

Furthermore removal of the ttm hugepages support in:
commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
broke the coherency mode in vmwgfx when running with hugepages.

Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
(cherry picked from commit 49d535d64d52945e2c874f380705675e20a02b6a)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

show more ...

drm/vmwgfx: Remove unused compile options

Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since

drm/vmwgfx: Remove unused compile options

Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since the implementation of screen targets landed there hasn't been a
reason to explicitly disable it and the options were never used.
Remove of all that unused code.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org

show more ...

drm/vmwgfx: Remove explicit transparent hugepages support

Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only v

drm/vmwgfx: Remove explicit transparent hugepages support

Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only very
old devices (OpenGL 2.1 support and earlier) used this code and at this
point performance differences are negligible.

Because the code requires very old hardware versions to run it has
been largely untested and unused for a long time.

Furthermore removal of the ttm hugepages support in:
commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
broke the coherency mode in vmwgfx when running with hugepages.

Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org

show more ...

drm/vmwgfx: Bump the minor version

v2: Old userspace doesn't like 3.x.x and we'd like to keep it working,
so lets just bump the minor version until we have no choice.

With GEM, GL4.3, stats and rem

drm/vmwgfx: Bump the minor version

v2: Old userspace doesn't like 3.x.x and we'd like to keep it working,
so lets just bump the minor version until we have no choice.

With GEM, GL4.3, stats and removal of a lot of old code it's time to bump
the minor version of the driver.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211209024924.3298137-1-zack@kde.org

show more ...

drm/vmwgfx: Remove usage of MOBFMT_RANGE

Using MOBFMT_RANGE in the early days of guest backed objects was a major
performance win but that has changed a lot since. There's no more
a performance reas

drm/vmwgfx: Remove usage of MOBFMT_RANGE

Using MOBFMT_RANGE in the early days of guest backed objects was a major
performance win but that has changed a lot since. There's no more
a performance reason to use MOBFMT_RANGE. The device can/will still
profit from the pages being contiguous but marking them as MOBFMT_RANGE
no longer matters.
Benchmarks (e.g. heaven, valley) show that creating page tables
for mob memory is actually faster than using mobfmt ranges.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-12-zack@kde.org

show more ...

drm/vmwgfx: support 64 UAVs

If the host supports SVGA3D_DEVCAP_GL43, we can handle 64 instead of
just 8 UAVs.
Based on a patch from Roland Scheidegger <sroland@vmware.com>.

Signed-off-by: Roland Sc

drm/vmwgfx: support 64 UAVs

If the host supports SVGA3D_DEVCAP_GL43, we can handle 64 instead of
just 8 UAVs.
Based on a patch from Roland Scheidegger <sroland@vmware.com>.

Signed-off-by: Roland Scheidegger <sroland@vmware.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-9-zack@kde.org

show more ...

drm/vmwgfx: Implement DRIVER_GEM

This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx
was written before GEM and has always used TTM. Over the years the
TTM buffers started inherti

drm/vmwgfx: Implement DRIVER_GEM

This is initial change adding support for DRIVER_GEM to vmwgfx. vmwgfx
was written before GEM and has always used TTM. Over the years the
TTM buffers started inherting from GEM objects but vmwgfx never
implemented GEM making it quite awkward. We were directly setting
variables in GEM objects to not make DRM crash.

This change brings vmwgfx inline with other DRM drivers and allows us
to use a lot of DRM helpers which have depended on drivers with GEM
support.

Due to historical reasons vmwgfx splits the idea of a buffer and surface
which makes it a littly tricky since either one can be used in most
of our ioctl's which take user space handles. For now our BO's are
GEM objects and our surfaces are opaque objects which are backed by
GEM objects. In the future I'd like to combine those into a single
BO but we don't want to break any of our existing ioctl's so it will
take time to do it in a non-destructive way.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-5-zack@kde.org

show more ...

drm/vmwgfx: Remove the dedicated memory accounting

vmwgfx shared very elaborate memory accounting with ttm. It was moved
from ttm to vmwgfx in change
f07069da6b4c ("drm/ttm: move memory accounting i

drm/vmwgfx: Remove the dedicated memory accounting

vmwgfx shared very elaborate memory accounting with ttm. It was moved
from ttm to vmwgfx in change
f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4")
but because of complexity it was hard to maintain. Some parts of the code
weren't freeing memory correctly and some were missing accounting all
together. While those would be fairly easy to fix the fundamental reason
for memory accounting in the driver was the ability to invoke shrinker
which is part of TTM code as well (with support for unified memory
hopefully coming soon).

That meant that vmwgfx had a lot of code that was either unused or
duplicating code from TTM. Removing this code also prevents excessive
calls to global swapout which were common during memory pressure
because both vmwgfx and TTM would invoke the shrinker when memory
usage reached half of RAM.

Fixes: f07069da6b4c ("drm/ttm: move memory accounting into vmwgfx v4")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206172620.3139754-2-zack@kde.org

show more ...

drm/vmwgfx: Introduce a new placement for MOB page tables

For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tabl

drm/vmwgfx: Introduce a new placement for MOB page tables

For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and we have to fence those bo's because we don't want
to destroy the page tables while the host is still executing
the command buffers which might be accessing them.

To solve it we introduce a new placement VMW_PL_SYSTEM which
is very similar to TTM_PL_SYSTEM except that it allows
fencing. This fixes kernel oops'es during unloading of the driver
(and pci hot remove/add) which were caused by busy BO's in
TTM_PL_SYSTEM being present in the delayed deletion list in
TTM (TTM_PL_SYSTEM manager is destroyed before the delayed
deletions are executed)

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211105193845.258816-5-zackr@vmware.com

show more ...

drm/vmwgfx: Copy DRM hash-table code into driver

Besides some legacy code, vmwgfx is the only user of DRM's hash-
table implementation. Copy the code into the driver, so that the
core code can be re

drm/vmwgfx: Copy DRM hash-table code into driver

Besides some legacy code, vmwgfx is the only user of DRM's hash-
table implementation. Copy the code into the driver, so that the
core code can be retired.

No functional changes. However, the real solution for vmwgfx is to
use Linux' generic hash-table functions.

v2:
* add TODO item for updating vmwgfx (Sam)

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211129094841.22499-3-tzimmermann@suse.de

show more ...

drm/ttm: remove ttm_bo_vm_insert_huge()

The huge page functionality in TTM does not work safely because PUD and
PMD entries do not have a special bit.

get_user_pages_fast() considers any page that

drm/ttm: remove ttm_bo_vm_insert_huge()

The huge page functionality in TTM does not work safely because PUD and
PMD entries do not have a special bit.

get_user_pages_fast() considers any page that passed pmd_huge() as
usable:

if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {

And vmf_insert_pfn_pmd_prot() unconditionally sets

entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));

eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE.

As such gup_huge_pmd() will try to deref a struct page:

head = try_grab_compound_head(pmd_page(orig), refs, flags);

and thus crash.

Thomas further notices that the drivers are not expecting the struct page
to be used by anything - in particular the refcount incr above will cause
them to malfunction.

Thus everything about this is not able to fully work correctly considering
GUP_fast. Delete it entirely. It can return someday along with a proper
PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast.

Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Thomas Hellström <thomas.helllstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
[danvet: Update subject per Thomas' &Christian's review]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/0-v2-a44694790652+4ac-ttm_pmd_jgg@nvidia.com

show more ...

drm/vmwgfx: Fix fencing on SVGAv3

[ Upstream commit 1d6595b4cd47acfd824550f48f10b54a6f0e93ee ]

Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with

drm/vmwgfx: Fix fencing on SVGAv3

[ Upstream commit 1d6595b4cd47acfd824550f48f10b54a6f0e93ee ]

Port of the vmwgfx to SVGAv3 lacked support for fencing. SVGAv3 removed
FIFO's and replaced them with command buffers and extra registers.
The initial version of SVGAv3 lacked support for most advanced features
(e.g. 3D) which made fences unnecessary. That is no longer the case,
especially as 3D support is being turned on.

Switch from FIFO commands and capabilities to command buffers and extra
registers to enable fences on SVGAv3.

Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-5-zack@kde.org
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/vmwgfx: Fix stale file descriptors on failed usercopy

commit a0f90c8815706981c483a652a6aefca51a5e191c upstream.

A failing usercopy of the fence_rep object will lead to a stale entry in
the file

drm/vmwgfx: Fix stale file descriptors on failed usercopy

commit a0f90c8815706981c483a652a6aefca51a5e191c upstream.

A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.

Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.

Fixes: c906965dee22 ("drm/vmwgfx: Add export fence to file descriptor support")
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

drm/vmwgfx: Remove unused compile options

commit 50ca8cc7c0fdd9ab16b8b66ffb301fface101fac upstream.

Before the driver had screen targets support we had to disable explicit
bringup of its infrastruc

drm/vmwgfx: Remove unused compile options

commit 50ca8cc7c0fdd9ab16b8b66ffb301fface101fac upstream.

Before the driver had screen targets support we had to disable explicit
bringup of its infrastructure because it was breaking screen objects
support.
Since the implementation of screen targets landed there hasn't been a
reason to explicitly disable it and the options were never used.
Remove of all that unused code.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org
(cherry picked from commit 11343099d5ae6c7411da1425b6b162c89fb5bf10)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

drm/vmwgfx: Remove explicit transparent hugepages support

commit bc701a28c74e78d7b5aa2b8628cb3608d4785d14 upstream.

Old versions of the svga device used to export virtual vram, handling of
which wa

drm/vmwgfx: Remove explicit transparent hugepages support

commit bc701a28c74e78d7b5aa2b8628cb3608d4785d14 upstream.

Old versions of the svga device used to export virtual vram, handling of
which was optimized on top of transparent hugepages support. Only very
old devices (OpenGL 2.1 support and earlier) used this code and at this
point performance differences are negligible.

Because the code requires very old hardware versions to run it has
been largely untested and unused for a long time.

Furthermore removal of the ttm hugepages support in:
commit 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
broke the coherency mode in vmwgfx when running with hugepages.

Fixes: 0d979509539e ("drm/ttm: remove ttm_bo_vm_insert_huge()")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Maaz Mombasawala <mombasawalam@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
(cherry picked from commit 49d535d64d52945e2c874f380705675e20a02b6a)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

drm/vmwgfx: Introduce a new placement for MOB page tables

[ Upstream commit f6be23264bbac88d1e2bb39658e1b8a397e3f46d ]

For larger (bigger than a page) and noncontiguous mobs we have
to create page

drm/vmwgfx: Introduce a new placement for MOB page tables

[ Upstream commit f6be23264bbac88d1e2bb39658e1b8a397e3f46d ]

For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and we have to fence those bo's because we don't want
to destroy the page tables while the host is still executing
the command buffers which might be accessing them.

To solve it we introduce a new placement VMW_PL_SYSTEM which
is very similar to TTM_PL_SYSTEM except that it allows
fencing. This fixes kernel oops'es during unloading of the driver
(and pci hot remove/add) which were caused by busy BO's in
TTM_PL_SYSTEM being present in the delayed deletion list in
TTM (TTM_PL_SYSTEM manager is destroyed before the delayed
deletions are executed)

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211105193845.258816-5-zackr@vmware.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/ttm: remove ttm_bo_vm_insert_huge()

[ Upstream commit 0d979509539ed1df883a30d442177ca7be609565 ]

The huge page functionality in TTM does not work safely because PUD and
PMD entries do not have

drm/ttm: remove ttm_bo_vm_insert_huge()

[ Upstream commit 0d979509539ed1df883a30d442177ca7be609565 ]

The huge page functionality in TTM does not work safely because PUD and
PMD entries do not have a special bit.

get_user_pages_fast() considers any page that passed pmd_huge() as
usable:

if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {

And vmf_insert_pfn_pmd_prot() unconditionally sets

entry = pmd_mkhuge(pfn_t_pmd(pfn, prot));

eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE.

As such gup_huge_pmd() will try to deref a struct page:

head = try_grab_compound_head(pmd_page(orig), refs, flags);

and thus crash.

Thomas further notices that the drivers are not expecting the struct page
to be used by anything - in particular the refcount incr above will cause
them to malfunction.

Thus everything about this is not able to fully work correctly considering
GUP_fast. Delete it entirely. It can return someday along with a proper
PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast.

Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults")
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Thomas Hellström <thomas.helllstrom@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
[danvet: Update subject per Thomas' &Christian's review]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/0-v2-a44694790652+4ac-ttm_pmd_jgg@nvidia.com
Signed-off-by: Sasha Levin <sashal@kernel.org>

show more ...

drm/vmwgfx: Remove the repeated declaration

Function 'vmw_context_binding_list' is declared twice, remove the
repeated declaration.

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Ro

drm/vmwgfx: Remove the repeated declaration

Function 'vmw_context_binding_list' is declared twice, remove the
repeated declaration.

Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Roland Scheidegger <sroland@vmware.com>
Cc: Zack Rusin <zackr@vmware.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1621930170-54923-1-git-send-email-zhangshaokun@hisilicon.com

show more ...

drm/vmwgfx: Fix a 64bit regression on svga3

Register accesses are always 4bytes, accidently this was changed to
a void pointer whwqich badly breaks 64bit archs when running on top
of svga3.

Fixes:

drm/vmwgfx: Fix a 64bit regression on svga3

Register accesses are always 4bytes, accidently this was changed to
a void pointer whwqich badly breaks 64bit archs when running on top
of svga3.

Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-3-zackr@vmware.com
(cherry picked from commit 87360168759879d68550b0c052bbcc2a0339ff74)
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>

show more ...

drm/vmwgfx: Use 2.19 version number to recognize mks-stats ioctls

To let the userspace recognize that it's running on top of a vmwgfx
that supports mks-stat ioctls we need to bump the version number

drm/vmwgfx: Use 2.19 version number to recognize mks-stats ioctls

To let the userspace recognize that it's running on top of a vmwgfx
that supports mks-stat ioctls we need to bump the version number.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Reviewed-by: Neha Bhende <bhenden@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-4-zackr@vmware.com

show more ...

drm/vmwgfx: Cleanup logging

The code was using the old DRM logging functions, which made it
hard to figure out what was coming from vmwgfx. The newer logging
helpers include the driver name in the l

drm/vmwgfx: Cleanup logging

The code was using the old DRM logging functions, which made it
hard to figure out what was coming from vmwgfx. The newer logging
helpers include the driver name in the logs and make it explicit
which driver they're coming from. This allows us to standardize
our logging a bit and clean it up in the process.

vmwgfx is a little special because technically the hardware it's
running on can be anything from the last 12 years or so which is
why we need to include capabilities in the logs in the first
place or otherwise we'd have no way of knowing what were
the capabilities of the platform the guest was running in.

Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Martin Krastev <krastevm@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210723165153.113198-2-zackr@vmware.com

show more ...