From: Julien Grall <julien.grall@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Ian Campbell <Ian.Campbell@eu.citrix.com>,
xen-devel <xen-devel@lists.xenproject.org>,
Tiejun Chen <tiejun.chen@intel.com>,
MalcolmCrossley <malcolm.crossley@citrix.com>,
Keir Fraser <keir@xen.org>
Subject: Re: [PATCH 3/4 RFC] x86/p2m: use large pages for MMIO mappings
Date: Tue, 29 Sep 2015 13:16:49 +0100 [thread overview]
Message-ID: <560A8131.7040901@citrix.com> (raw)
In-Reply-To: <560A95AA02000078000A69A5@prv-mh.provo.novell.com>
On 29/09/15 12:44, Jan Beulich wrote:
>>>> On 29.09.15 at 13:33, <julien.grall@citrix.com> wrote:
>> On 15/09/15 08:34, Jan Beulich wrote:
>>> RFC reasons:
>>> - ARM side unimplemented (and hence libxc for now made cope with both
>>> models), the main issue (besides my inability to test any change
>>> there) being the many internal uses of map_mmio_regions())
>>
>> map_mmio_regions is used in ARM to map all the device memory in a guest.
>> We expect this function to map everything at once when called during
>> DOM0 build and/or when a guest is created (used to map the interrupt
>> controller).
>>
>> I would rather prefer to avoid introducing specific helpers with
>> slightly different behavior (i.e one is only mapping N page, the other
>> everything).
>>
>> What about extending map_mmio_regions to take a parameter telling if we
>> want to limit the number of mapping in a single invocation?
>
> Sure an option, albeit something that would be sufficient to be
> done in ARM specific code, albeit the only user using variable
> length is map_range_to_domain(). All the others, using fixed
> lengths up to 32 pages, would implicitly get everything done at
> once as long as the threshold is >= 32.
While this is the case today, we have different patch series coming up
using variable lenght in different place within the ARM code (vGIC,
ACPI...).
It won't be possible to use map_range_to_domain because it's very
specific to build DOM0.
So, I would extend map_mmio_region like that
map_mmio_regions(struct domain *d,
unsigned long start_gfn,
unsigned long nr,
unsigned long mfn,
unsigned long limit);
The limit parameter would be 0 if there is no limit otherwise the
maximum of iteration.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-09-29 12:18 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55F70C9A02000078000A2A58@prv-mh.provo.novell.com>
2015-09-15 7:13 ` [PATCH 0/4] x86/p2m: use large pages for MMIO mappings Jan Beulich
2015-09-15 7:30 ` [PATCH 1/4] x86/EPT: always return proper order value from ept_get_entry() Jan Beulich
2015-09-16 7:15 ` Tian, Kevin
2015-09-17 16:13 ` Andrew Cooper
2015-09-15 7:31 ` [PATCH 2/4] x86/NPT: always return proper order value from p2m_pt_get_entry() Jan Beulich
2015-09-15 7:35 ` Jan Beulich
2015-09-15 7:32 ` Jan Beulich
2015-09-17 16:14 ` Andrew Cooper
2015-09-15 7:34 ` [PATCH 3/4 RFC] x86/p2m: use large pages for MMIO mappings Jan Beulich
2015-09-16 10:02 ` Julien Grall
2015-09-17 16:37 ` Andrew Cooper
2015-09-17 17:59 ` Jan Beulich
2015-09-22 8:32 ` Jan Beulich
2015-09-29 11:33 ` Julien Grall
2015-09-29 11:44 ` Jan Beulich
2015-09-29 12:16 ` Julien Grall [this message]
2015-09-29 12:46 ` Jan Beulich
2015-09-29 12:52 ` Julien Grall
2015-09-29 13:00 ` Jan Beulich
2015-09-29 13:06 ` Julien Grall
2015-09-29 13:27 ` Jan Beulich
2015-09-30 10:15 ` Julien Grall
2015-09-15 7:37 ` [PATCH 4/4] x86/PoD: shorten certain operations on higher order ranges Jan Beulich
2015-09-23 17:10 ` George Dunlap
2015-09-23 17:16 ` George Dunlap
2015-09-24 8:42 ` Jan Beulich
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=560A8131.7040901@citrix.com \
--to=julien.grall@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Campbell@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=malcolm.crossley@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tiejun.chen@intel.com \
--cc=wei.liu2@citrix.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).