5641f19b - drm/xen-front: Use Xen common shared buffer implementation

Fri, 30 Nov 2018 07:42:04 +0000

drm/xen-front: Use Xen common shared buffer implementationUse page directory based shared buffer implementationnow available as common code for Xen frontend drivers.Remove flushing of shared buffer on page flip as thisworkaround needs a proper fix.Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Noralf Trønnes Signed-off-by: Boris Ostrovsky List of files: /linux-6.15/drivers/gpu/drm/xen/Makefile

4394e964 - drm/xen-front: Remove CMA support

Tue, 17 Apr 2018 07:40:12 +0000

drm/xen-front: Remove CMA supportIt turns out this was only needed to paper over a bug in the CMAhelpers, which was addressed incommit 998fb1a0f478b83492220ff79583bf9ad538bdd8Author: Liviu Dudau Date: Fri Nov 10 13:33:10 2017 +0000 drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1Without this the following pipeline didn't work:domU:1. xen-front allocates a non-contig buffer2. creates grants out of itdom0:3. converts the grants into a dma-buf. Since they're non-contig, thescatter-list is huge.4. imports it into rcar-du, which requires dma-contig memory forscanout.-> On this given platform there's an IOMMU, so in theory this shouldwork. But in practice this failed, because of the huge number of sgentries, even though the IOMMU driver mapped it all into a dma-contigrange.With a guest-contig buffer allocated in step 1, this problem doesn'texist. But there's technically no reason to require guest-contigmemory for xen buffer sharing using grants.Given all that, the xen-front cma support is not needed and should beremoved.Signed-off-by: Oleksandr Andrushchenko Suggested-by: Daniel Vetter Acked-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180417074012.21311-1-andr2000@gmail.com List of files: /linux-6.15/drivers/gpu/drm/xen/Makefile

c575b7ee - drm/xen-front: Add support for Xen PV display frontend

Tue, 03 Apr 2018 11:23:17 +0000

drm/xen-front: Add support for Xen PV display frontendAdd support for Xen para-virtualized frontend display driver.Accompanying backend [1] is implemented as a user-space applicationand its helper library [2], capable of running as a Weston clientor DRM master.Configuration of both backend and frontend is done viaXen 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 tothe state diagram and recovery flow from display para-virtualizedprotocol: xen/interface/io/displif.h.2. Read configuration values from Xen store accordingto 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 state4. Implement shared buffer handling according to thepara-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 usingDRM 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 configuration6. 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 driversrunning in both host and guest environments, number of operatingmodes 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 notNote! Frontend driver itself has no dependency on contiguous memory forits operation.6.1. Buffers allocated by the frontend driver.The below modes of operation are configured at compile-time viafrontend 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 operationmay require IOMMU support on the platform, so accompanying DRM/vGPUhardware can still reach display buffer memory while importing PRIMEbuffers from the frontend driver.6.2. Buffers allocated by the backendThis mode of operation is run-time configured via guest domainconfiguration through XenStore entries.For systems which do not provide IOMMU support, but having specificrequirements for display buffers it is possible to allocate such buffersat backend side and share those with the frontend.For example, if host domain is 1:1 mapped and has DRM/GPU hardwareexpecting physically contiguous memory, this allows implementingzero-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#l1257Signed-off-by: Oleksandr Andrushchenko Reviewed-by: Boris Ostrovsky Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20180403112317.28751-2-andr2000@gmail.com List of files: /linux-6.15/drivers/gpu/drm/xen/Makefile

Changes in Makefile

5641f19b - drm/xen-front: Use Xen common shared buffer implementation

4394e964 - drm/xen-front: Remove CMA support

c575b7ee - drm/xen-front: Add support for Xen PV display frontend