From: Ian Campbell <ian.campbell@citrix.com>
To: Oleksandr Dmytryshyn <oleksandr.dmytryshyn@globallogic.com>
Cc: Keir Fraser <keir@xen.org>,
Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
xen-devel@lists.xen.org,
Stefano Stabellini <stefano.stabellini@citrix.com>,
Jan Beulich <jbeulich@suse.com>
Subject: Re: Question about mapping between domains
Date: Mon, 13 Jul 2015 10:04:35 +0100 [thread overview]
Message-ID: <1436778275.7019.32.camel@citrix.com> (raw)
In-Reply-To: <1436448706-2687-1-git-send-email-oleksandr.dmytryshyn@globallogic.com>
On Thu, 2015-07-09 at 16:31 +0300, Oleksandr Dmytryshyn wrote:
> I have some questions:
> 1. Is this a correct solution?
> 2. Could this solution be considered as a normal (not hack)?
> 3. If not then could anybody help me to implement this in the right way?
The way we deal with this elsewhere in the kernel is that we only ever
do grant mappings over ballooned out pages, which are allocated via
gnttab_alloc_pages. That way when they are unmapped the page is expected
to be entry and no backing mfn is lost. The page can then subsequently
be ballooned back in as normal.
There is an additional quirk for a 1:1 mapped dom0 which is that we
don't actually decrease reservation when ballooning, but keep the 1:1
mfn in anticipation of ballooning it back in later.
If you can't arrange to use already ballooned buffers for your DMA
buffer then you will need to manually balloon it out before and balloon
it back in later.
You may also want to extend the dom0 1:1 quirk described above to your
1:1 mapped domD.
If you have sufficient control over/knowledge of the domD IPA space then
you could also try and arrange that the region used for these mappings
does not correspond to any real RAM in the guest (i.e. stick it in an
MMIO hole). That depends on you never needing to find an associated
struct page though, which will depend on your use case.
Ian.
next prev parent reply other threads:[~2015-07-13 9:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-09 13:31 Question about mapping between domains Oleksandr Dmytryshyn
2015-07-13 9:04 ` Ian Campbell [this message]
2015-07-14 15:31 ` Oleksandr Dmytryshyn
2015-07-14 15:41 ` Oleksandr Dmytryshyn
2015-07-14 15:50 ` Ian Campbell
2015-07-15 8:28 ` Oleksandr Dmytryshyn
2015-07-15 11:51 ` Stefano Stabellini
2015-07-15 12:00 ` Ian Campbell
2015-07-14 15:49 ` Ian Campbell
2015-07-17 7:43 ` Oleksandr Dmytryshyn
2015-07-17 8:59 ` Ian Campbell
2015-07-22 12:07 ` Oleksandr Dmytryshyn
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=1436778275.7019.32.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@suse.com \
--cc=keir@xen.org \
--cc=oleksandr.dmytryshyn@globallogic.com \
--cc=stefano.stabellini@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.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).