From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: xen-devel <xen-devel@lists.xenproject.org>
Subject: gnttab_map_refs and contiguous buffer
Date: Thu, 23 Mar 2017 17:40:49 +0200 [thread overview]
Message-ID: <a081c4ba-8aef-02ed-4740-11d08a5e440d@gmail.com> (raw)
Hi, all!
I am trying to implement a zero-copy scenario for DRM front/back,
e.g. buffers allocated by DomU in the DRM frontend used as is
by Dom0. The requirement I have is that the buffer is contiguous.
So, what I currently have is:
1. DomU is 1:1 mapped and is able to allocate physically contiguous
buffer, e.g. PFNs and MFNs are sequential.
2. On Dom0 side I allocate ballooned pages (because I need reservation)
and am able to map those (gnttab_map_refs with grefs from DomU):
pfn 52a35 dev_bus_addr 6c100000
pfn 52a34 dev_bus_addr 6c101000
...
pfn 52a2c dev_bus_addr 6c109000
3. Then I have to create an SG table from these, so I can pass the buffer
to real HW DRM driver: as you can see from the above PFNs they are not
sequential as those were allocated from the balloon. Thus, sg_table
is also has number of segments != 1 which is not ok for my use-case.
Still, if I do __pfn_to_mfn(page_to_pfn(balloon_page[i])) I get the
correct MFN, which is expected because p2m translation happens.
4. If I try to do a hack:
dev_bus_pages[i] = pfn_to_page(MFN[i]) and then create an SG table from
these pages then of course the sg table is configuous and
I can share the SG with HW DRM driver.
What is naturally happens next is:
"Unable to handle kernel paging request at virtual address ffff80002c100000"
[ 86.263197] PC is at __clean_dcache_area_poc+0x20/0x40
[ 86.268377] LR is at __swiotlb_map_page+0x80/0x98
for the very first maddr == 6c100000, because my dev_bus_addr[i] and
dev_bus_pages[i] have no translation set up.
So, the question: is there any way I can make those ballooned pages
to convert into contiguous scatter-gather? So, sg table consists
of a single entry?
I was thinking of:
1. Is it possible to update translation manually so dev_bus_addr[i]
has corresponding continuous pages, e.g. so I can do
dev_bus_pages[i] = pfn_to_page(MFN[i]) and CPU can access those?
2. I can of course allocate contiguous buffer in Dom0 and
manually (unfortunately there is no API to do that) increase/decrease
reservation for the pages as balloon driver does and use those for mapping.
This way MFN will follow PFN (we are in Dom0 which is 1:1).
But this is going to be clumsy, as I'll have to copy-paste part
of the balloon driver into mine (decrease_reservation/increase_reservation)
3. Any other neat solution?
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next reply other threads:[~2017-03-23 15:40 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-23 15:40 Oleksandr Andrushchenko [this message]
2017-03-27 10:16 ` arm64: dma_to_phys/phys_to_dma need to be properly implemented Oleksandr Andrushchenko
2017-03-27 20:23 ` Stefano Stabellini
2017-03-28 6:42 ` Oleksandr Andrushchenko
2017-03-28 12:40 ` Andrii Anisov
2017-03-28 13:04 ` Oleksandr Andrushchenko
2017-03-28 19:20 ` Stefano Stabellini
2017-03-29 6:17 ` Oleksandr Andrushchenko
2017-03-29 22:36 ` Stefano Stabellini
2017-03-29 22:48 ` Julien Grall
2017-03-31 8:15 ` Oleksandr Andrushchenko
2017-03-31 17:56 ` 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=a081c4ba-8aef-02ed-4740-11d08a5e440d@gmail.com \
--to=andr2000@gmail.com \
--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).