Received: by 10.223.185.116 with SMTP id b49csp648762wrg; Wed, 21 Feb 2018 04:48:20 -0800 (PST) X-Google-Smtp-Source: AH8x224PWlV681+70LXCO4QDtrOm/EUFmrftCvlsO4D6RVP5HEX5ShxT9xU07TGV7vrLqDssiPXf X-Received: by 10.101.70.203 with SMTP id n11mr2543277pgr.377.1519217300191; Wed, 21 Feb 2018 04:48:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519217300; cv=none; d=google.com; s=arc-20160816; b=ExGEGCEcw/rDEeRDR3NjQTVuxDpacZ9dzCMdn/w5mQzJUZRhiu++ai/Ukqbm3wITb9 eae+cyRO8YH7e07WtD5aRRr9t2llAYXbzlDGxFS4eQXO2XAmOzYnmF5x6IGVJUfFDdbh LAfmEauPLsRkmE/elsxOx5O5js53mOfdlyCGIk+en43x0QQ4n43pIGfJjQt/mJd3+XbT Uk0nCB7Ikwb2sb9V6uGv1AndJRqFiHkWTKsygP6qSB+xjbp39YEpRMduhjSks/reueYn h/w7zK0NXq/Hz7vy/MUrhoiLV8t9++FfejXsuU9Bvrpb6SLejy0PmcKZvRV/a/u+4ky4 QxgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=WJQ/iDSN0Rpx/bRVhsRxWFyOKYDlXqxNYe3XZEmQBeI=; b=eyaOZYa+M8xLDndElq2kSwry10wgJt3thf0Prx4tcfi4he/3ByZsjXputSj9gHKouX jB/CITq12YZXBzK3X5oT6r8DyRrWMjR0FhefdHBy675jJzXSUDKBU6wC2NsqpsULKld5 Lgfxf3oYOtlRDex5bidfFDF22bL2MjJchaD5AmN1oE01Yskz5fLFFrMmdE9EtVGZbEIh Vf4QdV1i/zR7hINsXmjKJDGsF863ZdqGZPQFot+fHLldXBhYKvbISBV6wfqjEgWkuzxW eRMB+tkuJo9WSfSfvKOzaj8sayGrRRMgIccAI+6WlWueTmH9d+Rn6WpZL//tF6NyYSam yEBw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l4-v6si1580422pln.121.2018.02.21.04.48.06; Wed, 21 Feb 2018 04:48:20 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753079AbeBUJJy (ORCPT + 99 others); Wed, 21 Feb 2018 04:09:54 -0500 Received: from mx2.suse.de ([195.135.220.15]:52387 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753049AbeBUJJw (ORCPT ); Wed, 21 Feb 2018 04:09:52 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 20D96ABF3; Wed, 21 Feb 2018 09:09:51 +0000 (UTC) Subject: Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver To: Oleksandr Andrushchenko , xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, airlied@linux.ie, daniel.vetter@intel.com, seanpaul@chromium.org, gustavo@padovan.org, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Cc: Oleksandr Andrushchenko References: <1519200222-20623-1-git-send-email-andr2000@gmail.com> <1519200222-20623-2-git-send-email-andr2000@gmail.com> <91386840-c34a-31a4-2bb3-14a27ececa9c@gmail.com> From: Juergen Gross Message-ID: <4b20fcdd-2618-71a8-d94e-37c802973a02@suse.com> Date: Wed, 21 Feb 2018 10:09:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <91386840-c34a-31a4-2bb3-14a27ececa9c@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: de-DE Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/02/18 09:47, Oleksandr Andrushchenko wrote: > On 02/21/2018 10:19 AM, Juergen Gross wrote: >> On 21/02/18 09:03, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko >>> >>> Introduce skeleton of the para-virtualized Xen display >>> frontend driver. This patch only adds required >>> essential stubs. >>> >>> Signed-off-by: Oleksandr Andrushchenko >>> >>> --- >>>   drivers/gpu/drm/Kconfig             |  2 + >>>   drivers/gpu/drm/Makefile            |  1 + >>>   drivers/gpu/drm/xen/Kconfig         | 17 ++++++++ >>>   drivers/gpu/drm/xen/Makefile        |  5 +++ >>>   drivers/gpu/drm/xen/xen_drm_front.c | 83 >>> +++++++++++++++++++++++++++++++++++++ >>>   5 files changed, 108 insertions(+) >>>   create mode 100644 drivers/gpu/drm/xen/Kconfig >>>   create mode 100644 drivers/gpu/drm/xen/Makefile >>>   create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c >>> >>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig >>> index deeefa7a1773..757825ac60df 100644 >>> --- a/drivers/gpu/drm/Kconfig >>> +++ b/drivers/gpu/drm/Kconfig >>> @@ -289,6 +289,8 @@ source "drivers/gpu/drm/pl111/Kconfig" >>>     source "drivers/gpu/drm/tve200/Kconfig" >>>   +source "drivers/gpu/drm/xen/Kconfig" >>> + >>>   # Keep legacy drivers last >>>     menuconfig DRM_LEGACY >>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile >>> index 50093ff4479b..9d66657ea117 100644 >>> --- a/drivers/gpu/drm/Makefile >>> +++ b/drivers/gpu/drm/Makefile >>> @@ -103,3 +103,4 @@ obj-$(CONFIG_DRM_MXSFB)    += mxsfb/ >>>   obj-$(CONFIG_DRM_TINYDRM) += tinydrm/ >>>   obj-$(CONFIG_DRM_PL111) += pl111/ >>>   obj-$(CONFIG_DRM_TVE200) += tve200/ >>> +obj-$(CONFIG_DRM_XEN) += xen/ >>> diff --git a/drivers/gpu/drm/xen/Kconfig b/drivers/gpu/drm/xen/Kconfig >>> new file mode 100644 >>> index 000000000000..4cca160782ab >>> --- /dev/null >>> +++ b/drivers/gpu/drm/xen/Kconfig >>> @@ -0,0 +1,17 @@ >>> +config DRM_XEN >>> +    bool "DRM Support for Xen guest OS" >>> +    depends on XEN >>> +    help >>> +      Choose this option if you want to enable DRM support >>> +      for Xen. >>> + >>> +config DRM_XEN_FRONTEND >>> +    tristate "Para-virtualized frontend driver for Xen guest OS" >>> +    depends on DRM_XEN >>> +    depends on DRM >>> +    select DRM_KMS_HELPER >>> +    select VIDEOMODE_HELPERS >>> +    select XEN_XENBUS_FRONTEND >>> +    help >>> +      Choose this option if you want to enable a para-virtualized >>> +      frontend DRM/KMS driver for Xen guest OSes. >>> diff --git a/drivers/gpu/drm/xen/Makefile b/drivers/gpu/drm/xen/Makefile >>> new file mode 100644 >>> index 000000000000..967074d348f6 >>> --- /dev/null >>> +++ b/drivers/gpu/drm/xen/Makefile >>> @@ -0,0 +1,5 @@ >>> +# SPDX-License-Identifier: GPL-2.0 >>> + >>> +drm_xen_front-objs := xen_drm_front.o >>> + >>> +obj-$(CONFIG_DRM_XEN_FRONTEND) += drm_xen_front.o >>> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c >>> b/drivers/gpu/drm/xen/xen_drm_front.c >>> new file mode 100644 >>> index 000000000000..fd372fb464a1 >>> --- /dev/null >>> +++ b/drivers/gpu/drm/xen/xen_drm_front.c >>> @@ -0,0 +1,83 @@ >>> +/* >>> + *  Xen para-virtual DRM device >>> + * >>> + *   This program is free software; you can redistribute it and/or >>> modify >>> + *   it under the terms of the GNU General Public License as >>> published by >>> + *   the Free Software Foundation; either version 2 of the License, or >>> + *   (at your option) any later version. >>> + * >>> + *   This program is distributed in the hope that it will be useful, >>> + *   but WITHOUT ANY WARRANTY; without even the implied warranty of >>> + *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the >>> + *   GNU General Public License for more details. >> Use SPDX identifier instead (same applies for all other new >> sources): >> >> // SPDX-License-Identifier: GPL-2.0 > Will update, thank you >>> + * >>> + * Copyright (C) 2016-2018 EPAM Systems Inc. >>> + * >>> + * Author: Oleksandr Andrushchenko >>> + */ >>> + >>> +#include >>> + >>> +#include >>> +#include >>> +#include >>> + >>> +#include >>> + >>> +static void backend_on_changed(struct xenbus_device *xb_dev, >>> +        enum xenbus_state backend_state) >>> +{ >>> +} >>> + >>> +static int xen_drv_probe(struct xenbus_device *xb_dev, >>> +        const struct xenbus_device_id *id) >>> +{ >>> +    return 0; >>> +} >>> + >>> +static int xen_drv_remove(struct xenbus_device *dev) >>> +{ >>> +    return 0; >>> +} >>> + >>> +static const struct xenbus_device_id xen_drv_ids[] = { >>> +    { XENDISPL_DRIVER_NAME }, >>> +    { "" } >>> +}; >>> + >>> +static struct xenbus_driver xen_driver = { >>> +    .ids = xen_drv_ids, >>> +    .probe = xen_drv_probe, >>> +    .remove = xen_drv_remove, >>> +    .otherend_changed = backend_on_changed, >>> +}; >>> + >>> +static int __init xen_drv_init(void) >>> +{ >>> +    if (!xen_domain()) >>> +        return -ENODEV; >>> + >>> +    if (xen_initial_domain()) { >>> +        DRM_ERROR(XENDISPL_DRIVER_NAME " cannot run in initial >>> domain\n"); >>> +        return -ENODEV; >>> +    } >> Why not? Wouldn't that be possible in case of the backend living in a >> driver domain? > It is possible (and in my use-case backend indeed runs in > a driver domain). I was just not sure if it is really a > good idea to allow that. If you think this is ok, then > I'll remove this check I don't think the driver should decide that. This would be the job of Xen tools IMO. Juergen