cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

xen_drm_front.h (4417B)

      1/* SPDX-License-Identifier: GPL-2.0 OR MIT */
      2
      3/*
      4 *  Xen para-virtual DRM device
      5 *
      6 * Copyright (C) 2016-2018 EPAM Systems Inc.
      7 *
      8 * Author: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
      9 */
     10
     11#ifndef __XEN_DRM_FRONT_H_
     12#define __XEN_DRM_FRONT_H_
     13
     14#include <linux/scatterlist.h>
     15
     16#include <drm/drm_connector.h>
     17#include <drm/drm_simple_kms_helper.h>
     18
     19#include "xen_drm_front_cfg.h"
     20
     21struct drm_device;
     22struct drm_framebuffer;
     23struct drm_gem_object;
     24struct drm_pending_vblank_event;
     25
     26/**
     27 * DOC: Driver modes of operation in terms of display buffers used
     28 *
     29 * Depending on the requirements for the para-virtualized environment, namely
     30 * requirements dictated by the accompanying DRM/(v)GPU drivers running in both
     31 * host and guest environments, display buffers can be allocated by either
     32 * frontend driver or backend.
     33 */
     34
     35/**
     36 * DOC: Buffers allocated by the frontend driver
     37 *
     38 * In this mode of operation driver allocates buffers from system memory.
     39 *
     40 * Note! If used with accompanying DRM/(v)GPU drivers this mode of operation
     41 * may require IOMMU support on the platform, so accompanying DRM/vGPU
     42 * hardware can still reach display buffer memory while importing PRIME
     43 * buffers from the frontend driver.
     44 */
     45
     46/**
     47 * DOC: Buffers allocated by the backend
     48 *
     49 * This mode of operation is run-time configured via guest domain configuration
     50 * through XenStore entries.
     51 *
     52 * For systems which do not provide IOMMU support, but having specific
     53 * requirements for display buffers it is possible to allocate such buffers
     54 * at backend side and share those with the frontend.
     55 * For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting
     56 * physically contiguous memory, this allows implementing zero-copying
     57 * use-cases.
     58 *
     59 * Note, while using this scenario the following should be considered:
     60 *
     61 * #. If guest domain dies then pages/grants received from the backend
     62 *    cannot be claimed back
     63 *
     64 * #. Misbehaving guest may send too many requests to the
     65 *    backend exhausting its grant references and memory
     66 *    (consider this from security POV)
     67 */
     68
     69/**
     70 * DOC: Driver limitations
     71 *
     72 * #. Only primary plane without additional properties is supported.
     73 *
     74 * #. Only one video mode per connector supported which is configured
     75 *    via XenStore.
     76 *
     77 * #. All CRTCs operate at fixed frequency of 60Hz.
     78 */
     79
     80/* timeout in ms to wait for backend to respond */
     81#define XEN_DRM_FRONT_WAIT_BACK_MS	3000
     82
     83struct xen_drm_front_info {
     84	struct xenbus_device *xb_dev;
     85	struct xen_drm_front_drm_info *drm_info;
     86
     87	/* to protect data between backend IO code and interrupt handler */
     88	spinlock_t io_lock;
     89
     90	int num_evt_pairs;
     91	struct xen_drm_front_evtchnl_pair *evt_pairs;
     92	struct xen_drm_front_cfg cfg;
     93
     94	/* display buffers */
     95	struct list_head dbuf_list;
     96};
     97
     98struct xen_drm_front_drm_pipeline {
     99	struct xen_drm_front_drm_info *drm_info;
    100
    101	int index;
    102
    103	struct drm_simple_display_pipe pipe;
    104
    105	struct drm_connector conn;
    106	/* These are only for connector mode checking */
    107	int width, height;
    108
    109	struct drm_pending_vblank_event *pending_event;
    110
    111	struct delayed_work pflip_to_worker;
    112
    113	bool conn_connected;
    114};
    115
    116struct xen_drm_front_drm_info {
    117	struct xen_drm_front_info *front_info;
    118	struct drm_device *drm_dev;
    119
    120	struct xen_drm_front_drm_pipeline pipeline[XEN_DRM_FRONT_MAX_CRTCS];
    121};
    122
    123static inline u64 xen_drm_front_fb_to_cookie(struct drm_framebuffer *fb)
    124{
    125	return (uintptr_t)fb;
    126}
    127
    128static inline u64 xen_drm_front_dbuf_to_cookie(struct drm_gem_object *gem_obj)
    129{
    130	return (uintptr_t)gem_obj;
    131}
    132
    133int xen_drm_front_mode_set(struct xen_drm_front_drm_pipeline *pipeline,
    134			   u32 x, u32 y, u32 width, u32 height,
    135			   u32 bpp, u64 fb_cookie);
    136
    137int xen_drm_front_dbuf_create(struct xen_drm_front_info *front_info,
    138			      u64 dbuf_cookie, u32 width, u32 height,
    139			      u32 bpp, u64 size, u32 offset, struct page **pages);
    140
    141int xen_drm_front_fb_attach(struct xen_drm_front_info *front_info,
    142			    u64 dbuf_cookie, u64 fb_cookie, u32 width,
    143			    u32 height, u32 pixel_format);
    144
    145int xen_drm_front_fb_detach(struct xen_drm_front_info *front_info,
    146			    u64 fb_cookie);
    147
    148int xen_drm_front_page_flip(struct xen_drm_front_info *front_info,
    149			    int conn_idx, u64 fb_cookie);
    150
    151void xen_drm_front_on_frame_done(struct xen_drm_front_info *front_info,
    152				 int conn_idx, u64 fb_cookie);
    153
    154void xen_drm_front_gem_object_free(struct drm_gem_object *obj);
    155
    156#endif /* __XEN_DRM_FRONT_H_ */