From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Oleksandr Andrushchenko <Oleksandr_Andrushchenko@epam.com>,
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, jgross@suse.com, konrad.wilk@oracle.com
Subject: Re: [PATCH 8/9] drm/xen-front: Implement GEM operations
Date: Wed, 28 Feb 2018 21:52:56 +0200 [thread overview]
Message-ID: <a93367d2-f058-94f4-6e7d-a16eeded9c52@gmail.com> (raw)
In-Reply-To: <81d77b4c-db75-8830-06c9-6774c15a4c25@oracle.com>
On 02/28/2018 09:46 PM, Boris Ostrovsky wrote:
> On 02/27/2018 01:52 AM, Oleksandr Andrushchenko wrote:
>> On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
>>> On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
>>>> On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
>>>>> On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
>>>>>> + ret = gem_alloc_pages_array(xen_obj, size);
>>>>>> + if (ret < 0) {
>>>>>> + gem_free_pages_array(xen_obj);
>>>>>> + goto fail;
>>>>>> + }
>>>>>> +
>>>>>> + ret = alloc_xenballooned_pages(xen_obj->num_pages,
>>>>>> + xen_obj->pages);
>>>>> Why are you allocating balloon pages?
>>>> in this use-case we map pages provided by the backend
>>>> (yes, I know this can be a problem from both security
>>>> POV and that DomU can die holding pages of Dom0 forever:
>>>> but still it is a configuration option, so user decides
>>>> if her use-case needs this and takes responsibility for
>>>> such a decision).
>>> Perhaps I am missing something here but when you say "I know this can be
>>> a problem from both security POV ..." then there is something wrong with
>>> your solution.
>> well, in this scenario there are actually 2 concerns:
>> 1. If DomU dies the pages/grants from Dom0/DomD cannot be
>> reclaimed back
>> 2. Misbehaving guest may send too many requests to the
>> backend exhausting grant references and memory of Dom0/DomD
>> (this is the only concern from security POV). Please see [1]
>>
>> But, we are focusing on embedded use-cases,
>> so those systems we use are not that "dynamic" with respect to 2).
>> Namely: we have fixed number of domains and their functionality
>> is well known, so we can do rather precise assumption on resource
>> usage. This is why I try to warn on such a use-case and rely on
>> the end user who understands the caveats
>
> How will dom0/backend know whether or not to trust the front end (and
> thus whether or not to provide provide pages to it)? Will there be
> something in xenstore, for example, to indicate such trusted frontends?
Exactly, there is a dedicated xl configuration option available [1] for
vdispl:
"be-alloc=BOOLEAN
Indicates if backend can be a buffer provider/allocator for this domain.
See display protocol for details."
Thus, one can configure this per domain for trusted ones in corresponding
xl configuration files
> -boris
>
>
>> I'll probably add more precise description of this use-case
>> clarifying what is that security POV, so there is no confusion
>>
>> Hope this explanation answers your questions
>>> -boris
>>>
>>>> Please see description of the buffering modes in xen_drm_front.h
>>>> specifically for backend allocated buffers:
>>>>
>>>> *******************************************************************************
>>>>
>>>> * 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.
>>>>
>>>>> -boris
>>>>>
>>>>>> + if (ret < 0) {
>>>>>> + DRM_ERROR("Cannot allocate %zu ballooned pages: %d\n",
>>>>>> + xen_obj->num_pages, ret);
>>>>>> + goto fail;
>>>>>> + }
>>>>>> +
>>>>>> + return xen_obj;
>>>>>> + }
>>>>>> + /*
>>>>>> + * need to allocate backing pages now, so we can share those
>>>>>> + * with the backend
>>>>>> + */
>>>>>> + xen_obj->num_pages = DIV_ROUND_UP(size, PAGE_SIZE);
>>>>>> + xen_obj->pages = drm_gem_get_pages(&xen_obj->base);
>>>>>> + if (IS_ERR_OR_NULL(xen_obj->pages)) {
>>>>>> + ret = PTR_ERR(xen_obj->pages);
>>>>>> + xen_obj->pages = NULL;
>>>>>> + goto fail;
>>>>>> + }
>>>>>> +
>>>>>> + return xen_obj;
>>>>>> +
>>>>>> +fail:
>>>>>> + DRM_ERROR("Failed to allocate buffer with size %zu\n", size);
>>>>>> + return ERR_PTR(ret);
>>>>>> +}
>>>>>> +
>>>>>>
>> Thank you,
>> Oleksandr
>>
>> [1]
>> https://lists.xenproject.org/archives/html/xen-devel/2017-07/msg03100.html
>>
[1] https://xenbits.xen.org/docs/4.10-testing/man/xl.cfg.5.html
Indicates if backend can be a buffer provider/allocator for this
domain. See display protocol for details.
next prev parent reply other threads:[~2018-02-28 19:53 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-21 8:03 [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver Oleksandr Andrushchenko
2018-02-21 8:19 ` Juergen Gross
2018-02-21 8:47 ` Oleksandr Andrushchenko
2018-02-21 9:09 ` Juergen Gross
2018-02-21 9:11 ` Oleksandr Andrushchenko
2018-02-21 9:17 ` [Xen-devel] " Roger Pau Monné
2018-02-21 9:42 ` Oleksandr Andrushchenko
2018-02-21 10:19 ` Roger Pau Monné
2018-02-21 10:25 ` Oleksandr Andrushchenko
2018-02-22 22:23 ` Boris Ostrovsky
2018-02-23 6:37 ` Oleksandr Andrushchenko
2018-02-23 14:39 ` Boris Ostrovsky
2018-02-23 14:51 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 2/9] drm/xen-front: Implement Xen bus state handling Oleksandr Andrushchenko
2018-02-21 8:23 ` Juergen Gross
2018-02-21 8:50 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 3/9] drm/xen-front: Read driver configuration from Xen store Oleksandr Andrushchenko
2018-02-22 23:20 ` Boris Ostrovsky
2018-02-23 6:46 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 4/9] drm/xen-front: Implement Xen event channel handling Oleksandr Andrushchenko
2018-02-22 23:50 ` Boris Ostrovsky
2018-02-23 7:00 ` Oleksandr Andrushchenko
2018-02-23 14:44 ` Boris Ostrovsky
2018-02-23 14:49 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 5/9] drm/xen-front: Implement handling of shared display buffers Oleksandr Andrushchenko
2018-02-23 0:25 ` Boris Ostrovsky
2018-02-23 7:53 ` Oleksandr Andrushchenko
2018-02-23 14:36 ` Boris Ostrovsky
2018-02-23 14:45 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 6/9] drm/xen-front: Introduce DRM/KMS virtual display driver Oleksandr Andrushchenko
2018-02-23 15:12 ` Boris Ostrovsky
2018-02-23 15:19 ` Oleksandr Andrushchenko
2018-03-05 9:13 ` Daniel Vetter
2018-03-05 9:19 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 7/9] drm/xen-front: Implement KMS/connector handling Oleksandr Andrushchenko
2018-03-05 9:23 ` Daniel Vetter
2018-03-05 12:59 ` Oleksandr Andrushchenko
2018-03-06 7:22 ` Daniel Vetter
2018-03-06 7:29 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 8/9] drm/xen-front: Implement GEM operations Oleksandr Andrushchenko
2018-02-23 15:26 ` Boris Ostrovsky
2018-02-23 15:35 ` Oleksandr Andrushchenko
2018-02-26 23:47 ` Boris Ostrovsky
2018-02-27 6:52 ` Oleksandr Andrushchenko
2018-02-28 19:46 ` Boris Ostrovsky
2018-02-28 19:52 ` Oleksandr Andrushchenko [this message]
2018-03-05 9:32 ` Daniel Vetter
2018-03-05 13:46 ` Oleksandr Andrushchenko
2018-03-06 7:26 ` Daniel Vetter
2018-03-06 7:43 ` Oleksandr Andrushchenko
2018-02-21 8:03 ` [PATCH 9/9] drm/xen-front: Implement communication with backend Oleksandr Andrushchenko
2018-03-05 9:25 ` Daniel Vetter
2018-03-05 9:30 ` Oleksandr Andrushchenko
2018-03-06 9:26 ` Daniel Vetter
2018-03-06 9:45 ` Oleksandr Andrushchenko
2018-02-26 8:21 ` [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend Oleksandr Andrushchenko
2018-02-27 12:40 ` Oleksandr Andrushchenko
2018-02-28 14:08 ` [Xen-devel] " Julien Grall
2018-03-01 1:42 ` Stefano Stabellini
2018-03-01 8:26 ` Gerd Hoffmann
2018-03-01 8:49 ` Oleksandr Andrushchenko
2018-03-01 1:14 ` Stefano Stabellini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a93367d2-f058-94f4-6e7d-a16eeded9c52@gmail.com \
--to=andr2000@gmail.com \
--cc=Oleksandr_Andrushchenko@epam.com \
--cc=airlied@linux.ie \
--cc=boris.ostrovsky@oracle.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavo@padovan.org \
--cc=jgross@suse.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=seanpaul@chromium.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).