<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/vmwgfx, branch v5.6.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.6.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.6.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-01-15T13:34:49+00:00</updated>
<entry>
<title>drm/vmwgfx: Use VM_PFNMAP instead of VM_MIXEDMAP when possible</title>
<updated>2020-01-15T13:34:49+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2019-12-04T10:42:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b20414252068263c736d008e536658f9ce13d74a'/>
<id>urn:sha1:b20414252068263c736d008e536658f9ce13d74a</id>
<content type='text'>
For shared, and read-only private mappings of graphics memory, use
VM_PFNMAP instead of VM_MIXEDMAP. This means less accounting overhead
when inserting and removing page-table entries. TTM doesn't do this
by default, since there was a performance problem with book-keeping of
write-combined mappings. Since vmwgfx solely uses cached mappings, that's
not a problem and now that the TTM vm has largely been turned into
helpers, we can use VM_PFNMAP on a per-driver basis

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Roland Scheidegger &lt;sroland@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Bump driver minor version</title>
<updated>2020-01-15T10:55:03+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2020-01-14T10:38:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=61780dd7a45e72d697e35b675ca71e75b6ab08ce'/>
<id>urn:sha1:61780dd7a45e72d697e35b675ca71e75b6ab08ce</id>
<content type='text'>
Bump driver minor version to signal availability of the host messaging
ioctl.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Charmaine Lee &lt;charmainel@vmware.com&gt;
Reviewed-by: Roland Scheidegger &lt;sroland@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: add ioctl for messaging from/to guest userspace to/from host</title>
<updated>2020-01-15T10:54:16+00:00</updated>
<author>
<name>Roland Scheidegger</name>
<email>sroland@vmware.com</email>
</author>
<published>2019-11-21T16:44:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cb92a3235956442c5ff211291865e219dc4cf4a0'/>
<id>urn:sha1:cb92a3235956442c5ff211291865e219dc4cf4a0</id>
<content type='text'>
Up to now, guest userspace does logging directly to host using essentially
the same rather complex port assembly stuff as the kernel.
We'd rather use the same mechanism than duplicate it (it may also change in
the future), hence add a new ioctl for relaying guest/host messaging
(logging is just one application of it).

Signed-off-by: Roland Scheidegger &lt;sroland@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: prevent memory leak in vmw_cmdbuf_res_add</title>
<updated>2020-01-15T10:46:59+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-09-25T04:37:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=40efb09a7f53125719e49864da008495e39aaa1e'/>
<id>urn:sha1:40efb09a7f53125719e49864da008495e39aaa1e</id>
<content type='text'>
In vmw_cmdbuf_res_add if drm_ht_insert_item fails the allocated memory
for cres should be released.

Fixes: 18e4a4669c50 ("drm/vmwgfx: Fix compat shader namespace")
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: drop DRM_AUTH for render ioctls</title>
<updated>2020-01-15T10:46:59+00:00</updated>
<author>
<name>Emil Velikov</name>
<email>emil.velikov@collabora.com</email>
</author>
<published>2019-11-01T13:03:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0d4c19f93812c7b71c3a15f27fc4c5b2d990b2e6'/>
<id>urn:sha1:0d4c19f93812c7b71c3a15f27fc4c5b2d990b2e6</id>
<content type='text'>
With earlier commit 9c84aeba67cc ("drm/vmwgfx: Kill unneeded legacy
security features") we removed the no longer applicable validation, as
we now have isolation of primary clients from different master realms.

As of last commit, we're explicitly checking for authentication in the
only render ioctls which care about one.

With those in place, the DRM_AUTH token serves no real purpose. Let's
drop it.

Cc: VMware Graphics &lt;linux-graphics-maintainer@vmware.com&gt;
Cc: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Emil Velikov &lt;emil.velikov@collabora.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: check master authentication in surface_ref ioctls</title>
<updated>2020-01-15T10:46:58+00:00</updated>
<author>
<name>Emil Velikov</name>
<email>emil.velikov@collabora.com</email>
</author>
<published>2019-11-01T13:03:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4872e6aa217fbb475ffa0ad7bda0d9acff543f2c'/>
<id>urn:sha1:4872e6aa217fbb475ffa0ad7bda0d9acff543f2c</id>
<content type='text'>
With later commit we'll rework DRM authentication handling. Namely
DRM_AUTH will not be a requirement for DRM_RENDER_ALLOW ioctls.

Since vmwgfx does isolation for primary clients in different master
realms, the DRM_AUTH can be dropped.

The only place where authentication matters, is surface_reference ioctls
whenever a legacy (non-prime) handle is used. For those ioctls we call
vmw_surface_handle_reference(), where we explicitly check if the client
is both a) master and b) unauthenticated - bailing out as result.

Otherwise the usual isolation path kicks in and we're all good.

v2: Reword commit message, since the isolation work has landed.

Cc: VMware Graphics &lt;linux-graphics-maintainer@vmware.com&gt;
Cc: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Emil Velikov &lt;emil.velikov@collabora.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: move the require_exist handling together</title>
<updated>2020-01-15T10:46:58+00:00</updated>
<author>
<name>Emil Velikov</name>
<email>emil.velikov@collabora.com</email>
</author>
<published>2019-11-01T13:03:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8815a94f27d2f30fe1216ce10c7da0f6ae69ca0f'/>
<id>urn:sha1:8815a94f27d2f30fe1216ce10c7da0f6ae69ca0f</id>
<content type='text'>
Move the render_client hunk for require_exist alongside the rest.
Keeping all the reasons why an existing object is needed, in a single
place makes it easier to follow.

Cc: VMware Graphics &lt;linux-graphics-maintainer@vmware.com&gt;
Cc: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Emil Velikov &lt;emil.velikov@collabora.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Replace deprecated PTR_RET</title>
<updated>2020-01-15T10:46:58+00:00</updated>
<author>
<name>Lukas Bulwahn</name>
<email>lukas.bulwahn@gmail.com</email>
</author>
<published>2019-12-08T10:53:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a26ca967c240c628085142d6569fff69539b44e6'/>
<id>urn:sha1:a26ca967c240c628085142d6569fff69539b44e6</id>
<content type='text'>
Commit 508108ea2747 ("drm/vmwgfx: Don't refcount command-buffer managed
resource lookups during command buffer validation") slips in use of
deprecated PTR_RET. Use PTR_ERR_OR_ZERO instead.

As the PTR_ERR_OR_ZERO is a bit longer than PTR_RET, we introduce
local variable ret for proper indentation and line-length limits.

Signed-off-by: Lukas Bulwahn &lt;lukas.bulwahn@gmail.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Call vmw_driver_{load,unload}() before registering device</title>
<updated>2020-01-15T10:46:58+00:00</updated>
<author>
<name>Thomas Zimmermann</name>
<email>tzimmermann@suse.de</email>
</author>
<published>2019-12-10T12:43:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=36891da8de9822a62d79b64f99e73442efbf3f1d'/>
<id>urn:sha1:36891da8de9822a62d79b64f99e73442efbf3f1d</id>
<content type='text'>
The load/unload callbacks in struct drm_driver are deprecated. Remove
them and call functions explicitly.

Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
</content>
</entry>
<entry>
<title>drm/vmwgfx: Don't use the HB port if memory encryption is active</title>
<updated>2020-01-15T10:46:57+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2019-11-14T13:03:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=af4eaf10978e5b14660020f39e619059489cc694'/>
<id>urn:sha1:af4eaf10978e5b14660020f39e619059489cc694</id>
<content type='text'>
With memory encryption active, the hypervisor typically can't read the
guest memory using the HB port, since it is encrypted using a key known
only to the guest. In that case fall back to processing 4 bytes at a time
using the ordinary backdoor port.
The other option would be to use unencrypted bounce buffers for the
hypervisor to read out from or write into, but given the limited message
sizes it appears more efficient to just fall back to the ordinary backdoor
port.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Roland Scheidegger &lt;sroland@vmware.com&gt;
</content>
</entry>
</feed>
