From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: Rob Clark <robdclark@gmail.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: Re: GEM allocation for para-virtualized DRM driver
Date: Sat, 18 Mar 2017 15:25:16 +0200 [thread overview]
Message-ID: <5a4e572f-d694-86de-5e8d-ecbebf9905cf@gmail.com> (raw)
In-Reply-To: <CAF6AEGvNUK+b2r=0HSSULXN1L3mmrTqzkFUJH8o=GxS1MiZBcw@mail.gmail.com>
Hi, Rob
On 03/18/2017 02:22 PM, Rob Clark wrote:
> On Fri, Mar 17, 2017 at 1:39 PM, Oleksandr Andrushchenko
> <andr2000@gmail.com> wrote:
>> Hello,
>> I am writing a para-virtualized DRM driver for Xen hypervisor
>> and it now works with DRM CMA helpers, but I would also like
>> to make it work with non-contigous memory: virtual machine
>> that the driver runs in can't guarantee that CMA is actually
>> physically contigous (that is not a problem because of IPMMU
>> and other means, the only constraint I have is that I cannot mmap
>> with pgprot == noncached). So, I am planning to use *drm_gem_get_pages* +
>> *shmem_read_mapping_page_gfp* to allocate memory for GEM objects
>> (scanout buffers + dma-bufs shared with virtual GPU)
>>
>> Do you think this is the right approach to take?
> I guess if you had some case where you needed to "migrate" buffers
> between host and guest memory,
yes, this is the case. but, I can "map" buffers between host and guests
> then TTM might be useful.
I was looking into it, but it seems to be an overkill in my case
And isn't it that GEM should be used for new drivers, not TTM?
> Otherwise
> this sounds like the right approach.
Thank you. Actually, I am playing with alloc_pages + remap_pfn_range now,
but what DRM provides (_get_pages + shmem_read) seem to be more portable
and generic. So, I'll probably stick to it
> BR,
> -R
Thank you for helping,
Oleksandr Andrushchenko
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-03-18 13:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-17 17:39 GEM allocation for para-virtualized DRM driver Oleksandr Andrushchenko
2017-03-18 12:22 ` Rob Clark
2017-03-18 13:25 ` Oleksandr Andrushchenko [this message]
2017-03-18 14:06 ` Rob Clark
2017-03-18 14:44 ` Oleksandr Andrushchenko
2017-03-18 14:50 ` Rob Clark
2017-03-18 14:56 ` Oleksandr Andrushchenko
2017-03-20 17:18 ` Oleksandr Andrushchenko
2017-03-20 17:38 ` Rob Clark
2017-03-20 18:01 ` Oleksandr Andrushchenko
2017-03-20 18:17 ` Rob Clark
2017-03-20 18:25 ` Oleksandr Andrushchenko
2017-03-20 18:52 ` Rob Clark
2017-03-20 19:05 ` Oleksandr Andrushchenko
2017-03-21 15:12 ` Oleksandr Andrushchenko
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=5a4e572f-d694-86de-5e8d-ecbebf9905cf@gmail.com \
--to=andr2000@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=robdclark@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.