<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/vmwgfx, branch v5.17.9</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.17.9</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.17.9'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2022-05-18T08:28:22+00:00</updated>
<entry>
<title>drm/vmwgfx: Initialize drm_mode_fb_cmd2</title>
<updated>2022-05-18T08:28:22+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-03-02T15:24:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e199707bec9875e8fe30b171332c4bacd42823d4'/>
<id>urn:sha1:e199707bec9875e8fe30b171332c4bacd42823d4</id>
<content type='text'>
commit 3059d9b9f6aa433a55b9d0d21b566396d5497c33 upstream.

Transition to drm_mode_fb_cmd2 from drm_mode_fb_cmd left the structure
unitialized. drm_mode_fb_cmd2 adds a few additional members, e.g. flags
and modifiers which were never initialized. Garbage in those members
can cause random failures during the bringup of the fbcon.

Initializing the structure fixes random blank screens after bootup due
to flags/modifiers mismatches during the fbcon bring up.

Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.10+
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Reviewed-by: Maaz Mombasawala &lt;mombasawalam@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-7-zack@kde.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Disable command buffers on svga3 without gbobjects</title>
<updated>2022-05-18T08:28:21+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-03-18T17:43:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1e84d3adb689e978d2f546b76d62d616bf3aba7'/>
<id>urn:sha1:e1e84d3adb689e978d2f546b76d62d616bf3aba7</id>
<content type='text'>
commit 21d1d192890ced87f2f04f8f4dea92406e0b162a upstream.

With very limited vram on svga3 it's difficult to handle all the surface
migrations. Without gbobjects, i.e. the ability to store surfaces in
guest mobs, there's no reason to support intermediate svga2 features,
especially because we can fall back to fb traces and svga3 will never
support those in-between features.

On svga3 we wither want to use fb traces or screen targets
(i.e. gbobjects), nothing in between. This fixes presentation on a lot
of fusion/esxi tech previews where the exposed svga3 caps haven't been
finalized yet.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Fixes: 2cd80dbd3551 ("drm/vmwgfx: Add basic support for SVGA3")
Cc: &lt;stable@vger.kernel.org&gt; # v5.14+
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-5-zack@kde.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix fencing on SVGAv3</title>
<updated>2022-05-18T08:28:16+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-03-02T15:24:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4d962c47f2c495da2c60141acacb74388c0487af'/>
<id>urn:sha1:4d962c47f2c495da2c60141acacb74388c0487af</id>
<content type='text'>
[ 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 &lt;zackr@vmware.com&gt;
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Reviewed-by: Maaz Mombasawala &lt;mombasawalam@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220302152426.885214-5-zack@kde.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix gem refcounting and memory evictions</title>
<updated>2022-04-27T12:41:15+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2022-04-20T04:03:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cff5f3b583674567e60127e86822e4ea762e9c02'/>
<id>urn:sha1:cff5f3b583674567e60127e86822e4ea762e9c02</id>
<content type='text'>
commit 298799a28264ce400d9ff95c51b7adcb123d866e upstream.

v2: Add the last part of the ref count fix which was spotted by
Philipp Sieweck where the ref count of cpu writers is off due to
ERESTARTSYS or EBUSY during bo waits.

The initial GEM port broke refcounting on shareable (prime) surfaces and
memory evictions. The prime surfaces broke because the parent surfaces
weren't increasing the ref count on GEM surfaces, which meant that
the memory backing textures could have been deleted while the texture
was still accessible. The evictions broke due to a typo, the code was
supposed to exit if the passed buffers were not vmw_buffer_object
not if they were. They're tied because the evictions depend on having
memory to actually evict.

This fixes crashes with XA state tracker which is used for xrender
acceleration on xf86-video-vmware, apps/tests which use a lot of
memory (a good test being the piglit's streaming-texture-leak) and
desktops.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM")
Reported-by: Philipp Sieweck &lt;psi@informatik.uni-kiel.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.17+
Reviewed-by: Maaz Mombasawala &lt;mombasawalam@vmware.com&gt;
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20220420040328.1007409-1-zack@kde.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix stale file descriptors on failed usercopy</title>
<updated>2022-01-27T15:55:20+00:00</updated>
<author>
<name>Mathias Krause</name>
<email>minipli@grsecurity.net</email>
</author>
<published>2022-01-27T08:34:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a0f90c8815706981c483a652a6aefca51a5e191c'/>
<id>urn:sha1:a0f90c8815706981c483a652a6aefca51a5e191c</id>
<content type='text'>
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 &lt;minipli@grsecurity.net&gt;
Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix possible usage of an uninitialized variable</title>
<updated>2021-12-17T15:35:30+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2021-12-15T20:02:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=58fa0d90eddeda37b32597eda139e888ebe5af04'/>
<id>urn:sha1:58fa0d90eddeda37b32597eda139e888ebe5af04</id>
<content type='text'>
vmw_user_bo_lookup can fail to lookup user buffers, especially because
the buffer handles come from the userspace. The return value has
to be checked before the buffers are put back.

This was spotted by Dan's Smatch statick checker:
    drivers/gpu/drm/vmwgfx/vmwgfx_bo.c:574 vmw_user_bo_synccpu_release()
	error: uninitialized symbol 'vmw_bo'.

Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211215200224.3693345-1-zack@kde.org
(cherry picked from commit 60c9ecd705be3a28f79d70ea21c3939db668bf46)
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Remove unused compile options</title>
<updated>2021-12-17T15:35:02+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2021-12-15T18:41:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=50ca8cc7c0fdd9ab16b8b66ffb301fface101fac'/>
<id>urn:sha1:50ca8cc7c0fdd9ab16b8b66ffb301fface101fac</id>
<content type='text'>
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 &lt;zackr@vmware.com&gt;
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-3-zack@kde.org
(cherry picked from commit 11343099d5ae6c7411da1425b6b162c89fb5bf10)
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Remove explicit transparent hugepages support</title>
<updated>2021-12-17T15:34:27+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2021-12-15T18:41:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc701a28c74e78d7b5aa2b8628cb3608d4785d14'/>
<id>urn:sha1:bc701a28c74e78d7b5aa2b8628cb3608d4785d14</id>
<content type='text'>
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 &lt;zackr@vmware.com&gt;
Cc: Jason Gunthorpe &lt;jgg@nvidia.com&gt;
Cc: Thomas Hellström &lt;thomas.hellstrom@linux.intel.com&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Reviewed-by: Maaz Mombasawala &lt;mombasawalam@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-2-zack@kde.org
(cherry picked from commit 49d535d64d52945e2c874f380705675e20a02b6a)
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix a size_t/long int format specifier mismatch</title>
<updated>2021-12-17T15:34:02+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2021-12-15T18:41:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4e07d71c0d667ebf1e36be90b962081d2b778909'/>
<id>urn:sha1:4e07d71c0d667ebf1e36be90b962081d2b778909</id>
<content type='text'>
On i386 size_t is of course 32bits and using long int throws warnings,
trivially fix it by using the dedicated size_t format.

This is enough to fix the following warning found by the kernel test
robot:
   drivers/gpu/drm/vmwgfx/vmwgfx_gem.c: In function 'vmw_bo_print_info':
&gt;&gt; drivers/gpu/drm/vmwgfx/vmwgfx_gem.c:230:33: warning: format '%ld'
expects argument of type 'long int', but argument 4 has type 'size_t'
{aka 'unsigned int'} [-Wformat=]
     230 |  seq_printf(m, "\t\t0x%08x: %12ld bytes %s, type = %s",
         |                             ~~~~^
         |                                 |
         |                                 long int
         |                             %12d
     231 |      id, bo-&gt;base.base.size, placement, type);
         |          ~~~~~~~~~~~~~~~~~~
         |                       |

Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Zack Rusin &lt;zackr@vmware.com&gt;
Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM")
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Reviewed-by: Maaz Mombasawala &lt;mombasawalam@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211215184147.3688785-1-zack@kde.org
(cherry picked from commit 72345114c96b8211ec693b1ce59f95a83a613f1d)
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Bump the minor version</title>
<updated>2021-12-09T18:16:35+00:00</updated>
<author>
<name>Zack Rusin</name>
<email>zackr@vmware.com</email>
</author>
<published>2021-12-09T02:49:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=94eb7de6f4bec1c8bb99371c21df42cac0de6ee9'/>
<id>urn:sha1:94eb7de6f4bec1c8bb99371c21df42cac0de6ee9</id>
<content type='text'>
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 &lt;zackr@vmware.com&gt;
Reviewed-by: Martin Krastev &lt;krastevm@vmware.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20211209024924.3298137-1-zack@kde.org
</content>
</entry>
</feed>
