PV drivers upstream backport for Yocto 3.7 migration #39
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 3df9604.
This reverts commit 477b748.
This reverts commit 64176df.
This reverts commit 0c908fa.
This reverts commit 5b4d2c2.
This reverts commit de90dc8.
This reverts commit f1b7904.
…ctive CRTC" This reverts commit 6b7b71d.
[ Upstream commit cd6e992 ] This is the sync up with the canonical definition of the sound protocol in Xen: 1. Protocol version was referenced in the protocol description, but missed its definition. Fixed by adding a constant for current protocol version. 2. Some of the request descriptions have "reserved" fields missed: fixed by adding corresponding entries. 3. Extend the size of the requests and responses to 64 octets. Bump protocol version to 2. 4. Add explicit back and front synchronization In order to provide explicit synchronization between backend and frontend the following changes are introduced in the protocol: - add new ring buffer for sending asynchronous events from backend to frontend to report number of bytes played by the frontend (XENSND_EVT_CUR_POS) - introduce trigger events for playback control: start/stop/pause/resume - add "req-" prefix to event-channel and ring-ref to unify naming of the Xen event channels for requests and events 5. Add explicit back and front parameter negotiation In order to provide explicit stream parameter negotiation between backend and frontend the following changes are introduced in the protocol: add XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameters given: request passes desired parameter's intervals/masks and the response to this request returns allowed min/max intervals/masks to be used. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Oleksandr Grytsov <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Cc: Konrad Rzeszutek Wilk <[email protected]> Cc: Takashi Iwai <[email protected]> Signed-off-by: Boris Ostrovsky <[email protected]>
[ Upstream commit ce63b2c ] This is the sync up with the canonical definitions of the input, sound and display protocols in Xen. Changes to kbdif: 1. Add missing string constants for {feature|request}-raw-pointer to align with the rest of the interface file. 2. Add new XenStore feature fields, so it is possible to individually control set of exposed virtual devices for each guest OS: - set feature-disable-keyboard to 1 if no keyboard device needs to be created - set feature-disable-pointer to 1 if no pointer device needs to be created 3. Move multi-touch device parameters to backend nodes: these are described as a part of frontend's XenBus configuration nodes while they belong to backend's configuration. Fix this by moving the parameters to the proper section. Unique-id field: 1. Add unique-id XenBus entry for virtual input and display. 2. Change type of unique-id field to string for sndif to align with display and input protocols. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
[ Upstream commit cc3196a ] Introduce skeleton of the para-virtualized Xen sound frontend driver. Initial handling for Xen bus states: implement Xen bus state machine for the frontend driver according to the state diagram and recovery flow from sound para-virtualized protocol: xen/interface/io/sndif.h. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit fd3b360 ] Read configuration values from Xen store according to xen/interface/io/sndif.h protocol: - introduce configuration structures for different components, e.g. sound card, device, stream - read PCM HW parameters, e.g rate, format etc. - detect stream type (capture/playback) - read device and card parameters Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 788ef64 ] Handle Xen event channels: - create for all configured streams 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 Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit d6e0fbb ] Implement shared buffer handling according to the para-virtualized sound device protocol at xen/interface/io/sndif.h: - manage buffer memory - handle granted references - handle page directories [ Fixed missing linux/kernel.h inclusion -- tiwai ] Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 1cee559 ] Implement essential initialization of the sound driver: - introduce required data structures - handle driver registration - handle sound card registration - register sound driver on backend connection - remove sound driver on backend disconnect Initialize virtual sound card with streams according to the Xen store configuration. Implement ALSA driver operations including: - manage frontend/backend shared buffers - manage Xen bus event channel states Implement requests from front to back for ALSA PCM operations. - report ALSA period elapsed event: handle XENSND_EVT_CUR_POS notifications from the backend when stream position advances during playback/capture. The event carries a value of how many octets were played/captured at the time of the event. - implement explicit stream parameter negotiation between backend and frontend: handle XENSND_OP_HW_PARAM_QUERY request to read/update configuration space for the parameter given: request passes desired parameter interval and the response to this request returns min/max interval for the parameter to be used. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 190a5f2 ] Add myself as sound/xen maintainer. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 3d62461 ] The error for a -ve value in ret is redundant as all previous assignments to ret have an associated -ve check and hence it is impossible for ret to be less that zero at the point of the check. Remove this redundant error check. Detected by CoveritScan, CID#1469407 ("Logically Dead code") Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Takashi Sakamoto <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 014cea5 ] The negative error return from the call to to_sndif_format is being assigned to an unsigned 8 bit integer and hence the check for a negative value is always going to be false. Fix this by using ret as the error return and hence the negative error can be detected and assign the u8 sndif_format to ret if there is no error. Detected by CoverityScan, CID#1469385 ("Unsigned compared against 0") Signed-off-by: Colin Ian King <[email protected]> Reviewed-by: Takashi Sakamoto <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 4c0eaac ] gcc-8 warns that pcm_instance->name is not necessarily terminated correctly if the input is more than 80 characters long or lacks a termination byte itself: In function 'strncpy', inlined from 'cfg_device' at sound/xen/xen_snd_front_cfg.c:399:3, inlined from 'xen_snd_front_cfg_card' at sound/xen/xen_snd_front_cfg.c:509:9: include/linux/string.h:254:9: error: '__builtin_strncpy' specified bound 80 equals destination size [-Werror=stringop-truncation] return __builtin_strncpy(p, q, size); Using strlcpy() instead of strncpy() makes this a bit safer. Fixes: fd3b360 ("ALSA: xen-front: Read sound driver configuration from Xen store") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit e46dcbb ] kfree() doesn't accept error pointers so I've set "str" to NULL on these paths. Fixes: fd3b360 ("ALSA: xen-front: Read sound driver configuration from Xen store") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit 0d5bcfc ] We want the loop to exit when "to" is set to zero, but in the current code it's set to -1. Also I tweaked the indenting so it doesn't look like we're passing "--to" to xenbus_read_unsigned(). Fixes: cc3196a ("ALSA: xen-front: Introduce Xen para-virtualized sound frontend driver") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
[ Upstream commit ce6f7d0 ] kbdif protocol describes multi-touch device parameters as a part of frontend's XenBus configuration nodes while they belong to backend's configuration. Fix this by reading the parameters as defined by the protocol. Fixes: 49aac82 ("Input: xen-kbdfront - add multi-touch support") Signed-off-by: Oleksandr Andrushchenko <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
[ Upstream commit 3ef8a2e ] It is now only possible to control if multi-touch virtual device is created or not (via the corresponding XenStore entries), but keyboard and pointer devices are always created. In some cases this is not desirable. For example, if virtual keyboard device is exposed to Android then the latter won't automatically show on-screen keyboard as it expects that a physical keyboard device can be used for typing. Utilize keyboard and pointer device XenStore feature fields to configure which virtual devices are created: - set "feature-disable-keyboard" to 1 if no keyboard device needs to be created - set "feature-disable-pointer" to 1 if no pointer device needs to be created Keep old behavior by default. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Suggested-by: Andrii Chepurnyi <[email protected]> Tested-by: Andrii Chepurnyi <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
[ Upstream commit 0c908fa ] We do not want the common dma_configure() pathway to apply indiscriminately to all devices, since there are plenty of buses which do not have DMA capability, and if their child devices were used for DMA API calls it would only be indicative of a driver bug. However, there are a number of buses for which DMA is implicitly expected even when not described by firmware - those we whitelist with an automatic opt-in to dma_configure(), assuming that the DMA address space and the physical address space are equivalent if not otherwise specified. Commit 7232888 ("of: restrict DMA configuration") introduced a short-term fix by comparing explicit bus types, but this approach is far from pretty, doesn't scale well, and fails to cope at all with bus drivers which may be built as modules, like host1x. Let's refine things by making that opt-in a property of the bus type, which neatly addresses those problems and lets the decision of whether firmware description of DMA capability should be optional or mandatory stay internal to the bus drivers themselves. Signed-off-by: Robin Murphy <[email protected]> Acked-by: Rob Herring <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Acked-by: Thierry Reding <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
… clip rectangle [ Upstream commit bb4dd71 ] Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. Note that this replaces crtc_state->adjusted_mode usage with crtc_state->mode. The latter is the correct choice since that's the mode the user provided and it matches the plane crtc coordinates the user also provided. Once everyone agrees on this we can move the clip handling into drm_atomic_helper_check_plane_state(). Cc: Laurent Pinchart <[email protected]> Cc: Noralf Trønnes <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Thierry Reding <[email protected]>
[ Upstream commit 40275dc ] The PL111 needs to filter valid modes based on memory bandwidth. I guess it is a pretty simple operation, so we can still claim the DRM KMS helper pipeline is simple after adding this (optional) vtable callback. Reviewed-by: Eric Anholt <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit 4751cf7 ] It is possible that drm_simple_kms_plane_atomic_check called with no CRTC set, e.g. when user-space application sets CRTC_ID/FB_ID to 0 before doing any actual drawing. This leads to NULL pointer dereference because in this case new CRTC state is NULL and must be checked before accessing. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit ac86cba ] If simple_kms_helper based driver needs to work with vblanks, then it has to provide drm_driver.{enable|disable}_vblank callbacks, because drm_simple_kms_helper.drm_crtc_funcs does not provide any. At the same time drm_driver.{enable|disable}_vblank callbacks are marked as deprecated and shouldn't be used by new drivers. Fix this by extending drm_simple_kms_helper.drm_crtc_funcs to provide the missing callbacks. Signed-off-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit bee330f ] Use srcu to protect drm_device.unplugged in a race free manner. Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark sections preventing access to device resources that are not available after the device is gone. Suggested-by: Daniel Vetter <[email protected]> Signed-off-by: Noralf Trønnes <[email protected]> Signed-off-by: Oleksandr Andrushchenko <[email protected]> [ ported to 4.14 ] Reviewed-by: Oleksandr Andrushchenko <[email protected]> Tested-by: Oleksandr Andrushchenko <[email protected]> Cc: [email protected] Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit 0c9c7fd ] tinydrm enable hook wants to play around with the new fb in .atomic_enable(), thus we'll need access to the plane state. Performed with coccinelle: @r1@ identifier F =~ ".*enable$"; identifier P, CS; @@ F( struct drm_simple_display_pipe *P ,struct drm_crtc_state *CS + ,struct drm_plane_state *plane_state ) { ... } @@ struct drm_simple_display_pipe *P; expression E; @@ { + struct drm_plane *plane; ... + plane = &P->plane; P->funcs->enable(P ,E + ,plane->state ); ... } @@ identifier P, CS; @@ struct drm_simple_display_pipe_funcs { ... void (*enable)(struct drm_simple_display_pipe *P ,struct drm_crtc_state *CS + ,struct drm_plane_state *plane_state ); ... }; v2: Pimp the commit message (David) Cc: Marek Vasut <[email protected]> Cc: Eric Anholt <[email protected]> Cc: David Lechner <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Linus Walleij <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Noralf Trønnes <[email protected]> Signed-off-by: Oleksandr Andrushchenko <[email protected]> [ port to 4.14 ]
[ Upstream commit c575b7e ] 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 <[email protected]> [port to 4.14 kernel] Reviewed-by: Boris Ostrovsky <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit 4394e96 ] It turns out this was only needed to paper over a bug in the CMA helpers, which was addressed in commit 998fb1a Author: Liviu Dudau <[email protected]> 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 <[email protected]> Suggested-by: Daniel Vetter <[email protected]> Acked-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit ccc3b2b ] There's nothing tinydrm specific to this, and there's a few more copies of the same in various other drivers. Signed-off-by: Daniel Vetter <[email protected]> Cc: Gustavo Padovan <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Sean Paul <[email protected]> Cc: David Airlie <[email protected]> Cc: David Lechner <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Neil Armstrong <[email protected]> Cc: Daniel Stone <[email protected]> Cc: Haneen Mohammed <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: "Ville Syrjälä" <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Acked-by: David Lechner <[email protected]> Reviewed-by: Noralf Trønnes <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Oleksandr Andrushchenko <[email protected]> [ port to 4.14 ]
[ Upstream commit dd388ee ] I missed this one because on an older tree. Signed-off-by: Daniel Vetter <[email protected]> Cc: Oleksandr Andrushchenko <[email protected]> Cc: [email protected] Reviewed-by: Oleksandr Andrushchenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
[ Upstream commit e30ca4b ] drm_dev_alloc() returns error pointers, it never returns NULL. Fixes: c575b7e ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Oleksandr Andrushchenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20180508092650.GA661@mwanda
[ Upstream commit 18f20bc ] The xen_drm_front_shbuf_alloc() function was returning a mix of error pointers and NULL and the the caller wasn't checking correctly. I've changed it to always return error pointer consistently. Fixes: c575b7e ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Oleksandr Andrushchenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20180508092739.GB661@mwanda
[ Upstream commit f45140d ] If the loop times out then we want to exit with "to" set to zero, but in the current code it's set to -1. Fixes: c575b7e ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Oleksandr Andrushchenko <[email protected]> Signed-off-by: Oleksandr Andrushchenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20180508092829.GC661@mwanda
Introduce Xen zero-copy helper DRM driver, add user-space API
of the driver:
1. DRM_IOCTL_XEN_ZCOPY_DUMB_FROM_REFS
This will create a DRM dumb buffer from grant references provided
by the frontend. The intended usage is:
- Frontend
- creates a dumb/display buffer and allocates memory
- grants foreign access to the buffer pages
- passes granted references to the backend
- Backend
- issues DRM_XEN_ZCOPY_DUMB_FROM_REFS ioctl to map
granted references and create a dumb buffer
- requests handle to fd conversion via DRM_IOCTL_PRIME_HANDLE_TO_FD
- requests real HW driver/consumer to import the PRIME buffer with
DRM_IOCTL_PRIME_FD_TO_HANDLE
- uses handle returned by the real HW driver
- at the end:
o closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
o closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
o closes file descriptor of the exported buffer
2. DRM_IOCTL_XEN_ZCOPY_DUMB_TO_REFS
This will grant references to a dumb/display buffer's memory provided
by the backend. The intended usage is:
- Frontend
- requests backend to allocate dumb/display buffer and grant
references to its pages
- Backend
- requests real HW driver to create a dumb with
DRM_IOCTL_MODE_CREATE_DUMB
- requests handle to fd conversion via
DRM_IOCTL_PRIME_HANDLE_TO_FD
- requests zero-copy driver to import the PRIME buffer with
DRM_IOCTL_PRIME_FD_TO_HANDLE
- issues DRM_XEN_ZCOPY_DUMB_TO_REFS ioctl to
grant references to the buffer's memory.
- passes grant references to the frontend
- at the end:
- closes zero-copy driver's handle with DRM_IOCTL_GEM_CLOSE
- closes real HW driver's handle with DRM_IOCTL_GEM_CLOSE
- closes file descriptor of the imported buffer
Implement GEM/IOCTL handling depending on driver mode of operation:
- if GEM is created from grant references, then prepare to create
a dumb from mapped pages
- if GEM grant references are about to be provided for the
imported PRIME buffer, then prepare for granting references
and providing those to user-space
Implement handling of display buffers from backend to/from front
interaction point ov view:
- when importing a buffer from the frontend:
- allocate/free xen ballooned pages via Xen balloon driver
or by manually allocating a DMA buffer
- if DMA buffer is used, then increase/decrease its pages
reservation accordingly
- map/unmap foreign pages to the ballooned pages
- when exporting a buffer to the frontend:
- grant references for the pages of the imported PRIME buffer
- pass the grants back to user-space, so those can be shared
with the frontend
Add an option to allocate DMA buffers as backing storage while
importing a frontend's buffer into host's memory:
for those use-cases when exported PRIME buffer will be used by
a device expecting CMA buffers only, it is possible to map
frontend's pages onto contiguous buffer, e.g. allocated via
DMA API.
Implement synchronous buffer deletion: for buffers, created from front's
grant references, synchronization between backend and frontend is needed
on buffer deletion as front expects us to unmap these references after
XENDISPL_OP_DBUF_DESTROY response.
For that reason introduce DRM_IOCTL_XEN_ZCOPY_DUMB_WAIT_FREE IOCTL:
this will block until dumb buffer, with the wait handle provided,
be freed.
The rationale behind implementing own wait handle:
- dumb buffer handle cannot be used as when the PRIME buffer
gets exported there are at least 2 handles: one is for the
backend and another one for the importing application,
so when backend closes its handle and the other application still
holds the buffer then there is no way for the backend to tell
which buffer we want to wait for while calling xen_ioctl_wait_free
- flink cannot be used as well as it is gone when DRM core
calls .gem_free_object_unlocked
Signed-off-by: Oleksandr Andrushchenko <[email protected]>
andr2000
changed the title
[ Upstream commit 069035c ] When unplugging a hotpluggable DRM device we first unregister it with drm_dev_unregister and then set drm_device.unplugged flag which is used to mark device critical sections with drm_dev_enter()/ drm_dev_exit() preventing access to device resources that are not available after the device is gone. But drm_dev_unregister may lead to hotplug uevent(s) fired to user-space on card and/or connector removal, thus making it possible for user-space to try accessing a disconnected device. Fix this by first making sure device is properly marked as disconnected and only then unregister it. Fixes: bee330f ("drm: Use srcu to protect drm_device.unplugged") Signed-off-by: Oleksandr Andrushchenko <[email protected]> Reported-by: Andrii Chepurnyi <[email protected]> Cc: "Noralf Trønnes" <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
andr2000
force-pushed
the
pr_pv_drv_upstream_for_yocto_3_7_migration
branch
from
a5a4aba to
eab3797
Compare
andr2000
pushed a commit
to andr2000/linux
that referenced
this pull request
Nov 27, 2018
Increase kasan instrumented kernel stack size from 32k to 64k. Other architectures seems to get away with just doubling kernel stack size under kasan, but on s390 this appears to be not enough due to bigger frame size. The particular pain point is kasan inlined checks (CONFIG_KASAN_INLINE vs CONFIG_KASAN_OUTLINE). With inlined checks one particular case hitting stack overflow is fs sync on xfs filesystem: #0 [9a0681e8] 704 bytes check_usage at 34b1fc #1 [9a0684a8] 432 bytes check_usage at 34c710 #2 [9a068658] 1048 bytes validate_chain at 35044a #3 [9a068a70] 312 bytes __lock_acquire at 3559fe xen-troops#4 [9a068ba8] 440 bytes lock_acquire at 3576ee xen-troops#5 [9a068d60] 104 bytes _raw_spin_lock at 21b44e0 xen-troops#6 [9a068dc8] 1992 bytes enqueue_entity at 2dbf72 xen-troops#7 [9a069590] 1496 bytes enqueue_task_fair at 2df5f0 xen-troops#8 [9a069b68] 64 bytes ttwu_do_activate at 28f438 xen-troops#9 [9a069ba8] 552 bytes try_to_wake_up at 298c4c xen-troops#10 [9a069dd0] 168 bytes wake_up_worker at 23f97c xen-troops#11 [9a069e78] 200 bytes insert_work at 23fc2e xen-troops#12 [9a069f40] 648 bytes __queue_work at 2487c0 xen-troops#13 [9a06a1c8] 200 bytes __queue_delayed_work at 24db28 xen-troops#14 [9a06a290] 248 bytes mod_delayed_work_on at 24de84 xen-troops#15 [9a06a388] 24 bytes kblockd_mod_delayed_work_on at 153e2a0 xen-troops#16 [9a06a3a0] 288 bytes __blk_mq_delay_run_hw_queue at 158168c xen-troops#17 [9a06a4c0] 192 bytes blk_mq_run_hw_queue at 1581a3c xen-troops#18 [9a06a580] 184 bytes blk_mq_sched_insert_requests at 15a2192 xen-troops#19 [9a06a638] 1024 bytes blk_mq_flush_plug_list at 1590f3a xen-troops#20 [9a06aa38] 704 bytes blk_flush_plug_list at 1555028 xen-troops#21 [9a06acf8] 320 bytes schedule at 219e476 xen-troops#22 [9a06ae38] 760 bytes schedule_timeout at 21b0aac xen-troops#23 [9a06b130] 408 bytes wait_for_common at 21a1706 xen-troops#24 [9a06b2c8] 360 bytes xfs_buf_iowait at fa1540 xen-troops#25 [9a06b430] 256 bytes __xfs_buf_submit at fadae6 xen-troops#26 [9a06b530] 264 bytes xfs_buf_read_map at fae3f6 xen-troops#27 [9a06b638] 656 bytes xfs_trans_read_buf_map at 10ac9a8 xen-troops#28 [9a06b8c8] 304 bytes xfs_btree_kill_root at e72426 xen-troops#29 [9a06b9f8] 288 bytes xfs_btree_lookup_get_block at e7bc5e xen-troops#30 [9a06bb18] 624 bytes xfs_btree_lookup at e7e1a6 xen-troops#31 [9a06bd88] 2664 bytes xfs_alloc_ag_vextent_near at dfa070 xen-troops#32 [9a06c7f0] 144 bytes xfs_alloc_ag_vextent at dff3ca xen-troops#33 [9a06c880] 1128 bytes xfs_alloc_vextent at e05fce xen-troops#34 [9a06cce8] 584 bytes xfs_bmap_btalloc at e58342 xen-troops#35 [9a06cf30] 1336 bytes xfs_bmapi_write at e618de xen-troops#36 [9a06d468] 776 bytes xfs_iomap_write_allocate at ff678e xen-troops#37 [9a06d770] 720 bytes xfs_map_blocks at f82af8 xen-troops#38 [9a06da40] 928 bytes xfs_writepage_map at f83cd6 xen-troops#39 [9a06dde0] 320 bytes xfs_do_writepage at f85872 xen-troops#40 [9a06df20] 1320 bytes write_cache_pages at 73dfe8 xen-troops#41 [9a06e448] 208 bytes xfs_vm_writepages at f7f892 xen-troops#42 [9a06e518] 88 bytes do_writepages at 73fe6a xen-troops#43 [9a06e570] 872 bytes __writeback_single_inode at a20cb6 xen-troops#44 [9a06e8d8] 664 bytes writeback_sb_inodes at a23be2 xen-troops#45 [9a06eb70] 296 bytes __writeback_inodes_wb at a242e0 xen-troops#46 [9a06ec98] 928 bytes wb_writeback at a2500e xen-troops#47 [9a06f038] 848 bytes wb_do_writeback at a260ae xen-troops#48 [9a06f388] 536 bytes wb_workfn at a28228 xen-troops#49 [9a06f5a0] 1088 bytes process_one_work at 24a234 xen-troops#50 [9a06f9e0] 1120 bytes worker_thread at 24ba26 xen-troops#51 [9a06fe40] 104 bytes kthread at 26545a xen-troops#52 [9a06fea8] kernel_thread_starter at 21b6b62 To be able to increase the stack size to 64k reuse LLILL instruction in __switch_to function to load 64k - STACK_FRAME_OVERHEAD - __PT_SIZE (65192) value as unsigned. Reported-by: Benjamin Block <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Vasily Gorbik <[email protected]> Signed-off-by: Martin Schwidefsky <[email protected]>
arminn
pushed a commit
that referenced
this pull request
Nov 28, 2019
generic/417 reported as blow: ------------[ cut here ]------------ kernel BUG at /home/yuchao/git/devf2fs/inode.c:695! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 21697 Comm: umount Tainted: G W O 4.18.0-rc2+ #39 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 EIP: f2fs_evict_inode+0x556/0x580 [f2fs] Call Trace: ? _raw_spin_unlock+0x2c/0x50 evict+0xa8/0x170 dispose_list+0x34/0x40 evict_inodes+0x118/0x120 generic_shutdown_super+0x41/0x100 ? rcu_read_lock_sched_held+0x97/0xa0 kill_block_super+0x22/0x50 kill_f2fs_super+0x6f/0x80 [f2fs] deactivate_locked_super+0x3d/0x70 deactivate_super+0x40/0x60 cleanup_mnt+0x39/0x70 __cleanup_mnt+0x10/0x20 task_work_run+0x81/0xa0 exit_to_usermode_loop+0x59/0xa7 do_fast_syscall_32+0x1f5/0x22c entry_SYSENTER_32+0x53/0x86 EIP: f2fs_evict_inode+0x556/0x580 [f2fs] It can simply reproduced with scripts: Enable quota feature during mkfs. Testcase1: 1. mkfs.f2fs /dev/zram0 2. mount -t f2fs /dev/zram0 /mnt/f2fs 3. xfs_io -f /mnt/f2fs/file -c "pwrite 0 4k" -c "fsync" 4. godown /mnt/f2fs 5. umount /mnt/f2fs 6. mount -t f2fs -o ro /dev/zram0 /mnt/f2fs 7. umount /mnt/f2fs Testcase2: 1. mkfs.f2fs /dev/zram0 2. mount -t f2fs /dev/zram0 /mnt/f2fs 3. touch /mnt/f2fs/file 4. create process[pid = x] do: a) open /mnt/f2fs/file; b) unlink /mnt/f2fs/file 5. godown -f /mnt/f2fs 6. kill process[pid = x] 7. umount /mnt/f2fs 8. mount -t f2fs -o ro /dev/zram0 /mnt/f2fs 9. umount /mnt/f2fs The reason is: during recovery, i_{c,m}time of inode will be updated, then the inode can be set dirty w/o being tracked in sbi->inode_list[DIRTY_META] global list, so later write_checkpoint will not flush such dirty inode into node page. Once umount is called, sync_filesystem() in generic_shutdown_super() will skip syncng dirty inodes due to sb_rdonly check, leaving dirty inodes there. To solve this issue, during umount, add remove SB_RDONLY flag in sb->s_flags, to make sure sync_filesystem() will not be skipped. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
arminn
pushed a commit
that referenced
this pull request
Nov 28, 2019
https://bugzilla.kernel.org/show_bug.cgi?id=200219 Reproduction way: - mount image - run poc code - umount image F2FS-fs (loop1): Bitmap was wrongly set, blk:15364 ------------[ cut here ]------------ kernel BUG at /home/yuchao/git/devf2fs/segment.c:2061! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 2 PID: 17686 Comm: umount Tainted: G W O 4.18.0-rc2+ #39 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 EIP: update_sit_entry+0x459/0x4e0 [f2fs] Code: e8 1c b5 fd ff 0f 0b 0f 0b 8b 45 e4 c7 44 24 08 9c 7a 6c f8 c7 44 24 04 bc 4a 6c f8 89 44 24 0c 8b 06 89 04 24 e8 f7 b4 fd ff <0f> 0b 8b 45 e4 0f b6 d2 89 54 24 10 c7 44 24 08 60 7a 6c f8 c7 44 EAX: 00000032 EBX: 000000f8 ECX: 00000002 EDX: 00000001 ESI: d7177000 EDI: f520fe68 EBP: d6477c6c ESP: d6477c34 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282 CR0: 80050033 CR2: b7fbe000 CR3: 2a99b3c0 CR4: 000406f0 Call Trace: f2fs_allocate_data_block+0x124/0x580 [f2fs] do_write_page+0x78/0x150 [f2fs] f2fs_do_write_node_page+0x25/0xa0 [f2fs] __write_node_page+0x2bf/0x550 [f2fs] f2fs_sync_node_pages+0x60e/0x6d0 [f2fs] ? sync_inode_metadata+0x2f/0x40 ? f2fs_write_checkpoint+0x28f/0x7d0 [f2fs] ? up_write+0x1e/0x80 f2fs_write_checkpoint+0x2a9/0x7d0 [f2fs] ? mark_held_locks+0x5d/0x80 ? _raw_spin_unlock_irq+0x27/0x50 kill_f2fs_super+0x68/0x90 [f2fs] deactivate_locked_super+0x3d/0x70 deactivate_super+0x40/0x60 cleanup_mnt+0x39/0x70 __cleanup_mnt+0x10/0x20 task_work_run+0x81/0xa0 exit_to_usermode_loop+0x59/0xa7 do_fast_syscall_32+0x1f5/0x22c entry_SYSENTER_32+0x53/0x86 EIP: 0xb7f95c51 Code: c1 1e f7 ff ff 89 e5 8b 55 08 85 d2 8b 81 64 cd ff ff 74 02 89 02 5d c3 8b 0c 24 c3 8b 1c 24 c3 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90 8d 76 EAX: 00000000 EBX: 0871ab90 ECX: bfb2cd00 EDX: 00000000 ESI: 00000000 EDI: 0871ab90 EBP: 0871ab90 ESP: bfb2cd7c DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246 Modules linked in: f2fs(O) crc32_generic bnep rfcomm bluetooth ecdh_generic snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq pcbc joydev aesni_intel snd_seq_device aes_i586 snd_timer crypto_simd snd cryptd soundcore mac_hid serio_raw video i2c_piix4 parport_pc ppdev lp parport hid_generic psmouse usbhid hid e1000 [last unloaded: f2fs] ---[ end trace d423f83982cfcdc5 ]--- The reason is, different log headers using the same segment, once one log's next block address is used by another log, it will cause panic as above. Main area: 24 segs, 24 secs 24 zones - COLD data: 0, 0, 0 - WARM data: 1, 1, 1 - HOT data: 20, 20, 20 - Dir dnode: 22, 22, 22 - File dnode: 22, 22, 22 - Indir nodes: 21, 21, 21 So this patch adds sanity check to detect such condition to avoid this issue. Signed-off-by: Chao Yu <[email protected]> Signed-off-by: Jaegeuk Kim <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.