Add drm_device argument to drm_prime_pages_to_sg(), so we can
call dma_max_mapping_size() to figure the segment size limit
and call into __sg_alloc_table_from_pages() with the correct
limit.
This fixes virtio-gpu with sev. Possibly it'll fix other bugs
too given that drm seems to totaly ignore segment size limits
so far ...
v2: place max_segment in drm driver not gem object.
v3: move max_segment next to the other gem fields.
v4: just use dma_max_mapping_size().
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20200907112425.15610-2-kraxel@redhat.com
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels without support for
ZONE_DEVICE Xen will fallback to use ballooned pages in order to
create foreign mappings.
The newly added helpers use the same parameters as the existing
{alloc/free}_xenballooned_pages functions, which allows for in-place
replacement of the callers. Once a memory region has been added to be
used as scratch mapping space it will no longer be released, and pages
returned are kept in a linked list. This allows to have a buffer of
pages and prevents resorting to frequent additions and removals of
regions.
If enabled (because ZONE_DEVICE is supported) the usage of the new
functionality untangles Xen balloon and RAM hotplug from the usage of
unpopulated physical memory ranges to map foreign pages, which is the
correct thing to do in order to avoid mappings of foreign pages depend
on memory hotplug.
Note the driver is currently not enabled on Arm platforms because it
would interfere with the identity mapping required on some platforms.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://lore.kernel.org/r/20200901083326.21264-4-roger.pau@citrix.com
Signed-off-by: Juergen Gross <jgross@suse.com>
While importing a dmabuf it is possible that the data of the buffer
is put with offset which is indicated by the SGT offset.
Respect the offset value and forward it to the backend.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV
display frontend" from Apr 3, 2018, leads to the following static
checker warning:
drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_gem_create()
warn: passing zero to 'ERR_CAST'
drivers/gpu/drm/xen/xen_drm_front_gem.c
133 struct drm_gem_object *xen_drm_front_gem_create(struct drm_device *dev,
134 size_t size)
135 {
136 struct xen_gem_object *xen_obj;
137
138 xen_obj = gem_create(dev, size);
139 if (IS_ERR_OR_NULL(xen_obj))
140 return ERR_CAST(xen_obj);
Fix this and the rest of misused places with IS_ERR_OR_NULL in the
driver.
Fixes: c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend"
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200813062113.11030-3-andr2000@gmail.com
Signed-off-by: Juergen Gross <jgross@suse.com>
When GEM backing storage is allocated those are normal pages,
so there is no point using pgprot_writecombine while mmaping.
This fixes mismatch of buffer pages' memory attributes between
the frontend and backend which may cause screen artifacts.
Fixes: c575b7eeb8 ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Suggested-by: Julien Grall <julien.grall@arm.com>
Acked-by: Julien Grall <julien.grall@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129150422.19867-1-andr2000@gmail.com
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal here I went through all
drivers. And indeed, all atomic drivers are now free of
drm_crtc_helper.h includes.
v2: Make it compile. There was so much compile fail on arm drivers
that I figured I'll better not include any of the acks on v1.
v3: Massive rebase because i915 has lost a lot of drmP.h includes, but
not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h
there was still one, which this patch largely removes. Which means
rolling out lots more includes all over.
This will also conflict with ongoing drmP.h cleanup by others I
expect.
v3: Rebase on top of atomic bochs.
v4: Review from Laurent for bridge/rcar/omap/shmob/core bits:
- (re)move some of the added includes, use the better include files in
other places (all suggested from Laurent adopted unchanged).
- sort alphabetically
v5: Actually try to sort them, and while at it, sort all the ones I
touch.
v6: Rebase onto i915 changes.
v7: Rebase once more.
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: virtualization@lists.linux-foundation.org
Cc: etnaviv@lists.freedesktop.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: spice-devel@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-tegra@vger.kernel.org
Cc: xen-devel@lists.xen.org
Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Dan Carpenter has reported that there is the following static checker
warning:
drivers/gpu/drm/drm_prime.c:317 drm_gem_map_dma_buf()
warn: 'sgt' can also be NULL
314 sgt = obj->dev->driver->gem_prime_get_sg_table(obj);
315
316 if (!IS_ERR(sgt)) {
317 if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
Problematic functions are xen_drm_front_gem_get_sg_table and
drm_gem_cma_prime_get_sg_table. Fix those by replacing NULL with error value.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719093713.3643-1-andr2000@gmail.com
It turns out this was only needed to paper over a bug in the CMA
helpers, which was addressed in
commit 998fb1a0f4
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date: Fri Nov 10 13:33:10 2017 +0000
drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1
Without this the following pipeline didn't work:
domU:
1. xen-front allocates a non-contig buffer
2. creates grants out of it
dom0:
3. converts the grants into a dma-buf. Since they're non-contig, the
scatter-list is huge.
4. imports it into rcar-du, which requires dma-contig memory for
scanout.
-> On this given platform there's an IOMMU, so in theory this should
work. But in practice this failed, because of the huge number of sg
entries, even though the IOMMU driver mapped it all into a dma-contig
range.
With a guest-contig buffer allocated in step 1, this problem doesn't
exist. But there's technically no reason to require guest-contig
memory for xen buffer sharing using grants.
Given all that, the xen-front cma support is not needed and should be
removed.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417074012.21311-1-andr2000@gmail.com
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
Xen guest domain configuration options [3].
Driver limitations:
1. Only primary plane without additional properties is supported.
2. Only one video mode supported which resolution is configured
via XenStore.
3. All CRTCs operate at fixed frequency of 60Hz.
1. Implement Xen bus state machine for the frontend driver according to
the state diagram and recovery flow from display para-virtualized
protocol: xen/interface/io/displif.h.
2. Read configuration values from Xen store according
to xen/interface/io/displif.h protocol:
- read connector(s) configuration
- read buffer allocation mode (backend/frontend)
3. Handle Xen event channels:
- create for all configured connectors and publish
corresponding ring references and event channels in Xen store,
so backend can connect
- implement event channels interrupt handlers
- create and destroy event channels with respect to Xen bus state
4. Implement shared buffer handling according to the
para-virtualized display device protocol at xen/interface/io/displif.h:
- handle page directories according to displif protocol:
- allocate and share page directories
- grant references to the required set of pages for the
page directory
- allocate xen balllooned pages via Xen balloon driver
with alloc_xenballooned_pages/free_xenballooned_pages
- grant references to the required set of pages for the
shared buffer itself
- implement pages map/unmap for the buffers allocated by the
backend (gnttab_map_refs/gnttab_unmap_refs)
5. Implement kernel modesetiing/connector handling using
DRM simple KMS helper pipeline:
- implement KMS part of the driver with the help of DRM
simple pipepline helper which is possible due to the fact
that the para-virtualized driver only supports a single
(primary) plane:
- initialize connectors according to XenStore configuration
- handle frame done events from the backend
- create and destroy frame buffers and propagate those
to the backend
- propagate set/reset mode configuration to the backend on display
enable/disable callbacks
- send page flip request to the backend and implement logic for
reporting backend IO errors on prepare fb callback
- implement virtual connector handling:
- support only pixel formats suitable for single plane modes
- make sure the connector is always connected
- support a single video mode as per para-virtualized driver
configuration
6. Implement GEM handling depending on driver mode of operation:
depending on the requirements for the para-virtualized environment,
namely requirements dictated by the accompanying DRM/(v)GPU drivers
running in both host and guest environments, number of operating
modes of para-virtualized display driver are supported:
- display buffers can be allocated by either
frontend driver or backend
- display buffers can be allocated to be contiguous
in memory or not
Note! Frontend driver itself has no dependency on contiguous memory for
its operation.
6.1. Buffers allocated by the frontend driver.
The below modes of operation are configured at compile-time via
frontend driver's kernel configuration.
6.1.1. Front driver configured to use GEM CMA helpers
This use-case is useful when used with accompanying DRM/vGPU driver
in guest domain which was designed to only work with contiguous
buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can
only import contiguous PRIME buffers, thus requiring frontend driver
to provide such. In order to implement this mode of operation
para-virtualized frontend driver can be configured to use
GEM CMA helpers.
6.1.2. Front driver doesn't use GEM CMA
If accompanying drivers can cope with non-contiguous memory then, to
lower pressure on CMA subsystem of the kernel, driver can allocate
buffers from system memory.
Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
may require IOMMU support on the platform, so accompanying DRM/vGPU
hardware can still reach display buffer memory while importing PRIME
buffers from the frontend driver.
6.2. Buffers allocated by the backend
This mode of operation is run-time configured via guest domain
configuration through XenStore entries.
For systems which do not provide IOMMU support, but having specific
requirements for display buffers it is possible to allocate such buffers
at backend side and share those with the frontend.
For example, if host domain is 1:1 mapped and has DRM/GPU hardware
expecting physically contiguous memory, this allows implementing
zero-copying use-cases.
Note, while using this scenario the following should be considered:
a) If guest domain dies then pages/grants received from the backend
cannot be claimed back
b) Misbehaving guest may send too many requests to the
backend exhausting its grant references and memory
(consider this from security POV).
Note! Configuration options 1.1 (contiguous display buffers) and 2
(backend allocated buffers) are not supported at the same time.
7. Handle communication with the backend:
- send requests and wait for the responses according
to the displif protocol
- serialize access to the communication channel
- time-out used for backend communication is set to 3000 ms
- manage display buffers shared with the backend
[1] https://github.com/xen-troops/displ_be
[2] https://github.com/xen-troops/libxenbe
[3] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403112317.28751-2-andr2000@gmail.com
Maxime Ripard