From: Ian Campbell <ian.campbell@citrix.com>
To: Julien Grall <julien.grall@linaro.org>
Cc: vijay.kilari@gmail.com, stefano.stabellini@eu.citrix.com,
Prasun.Kapoor@caviumnetworks.com,
vijaya.kumar@caviumnetworks.com, tim@xen.org,
xen-devel@lists.xen.org, stefano.stabellini@citrix.com,
manish.jaggi@caviumnetworks.com
Subject: Re: [PATCH v1] xen/arm: Do not allocate pte entries for MAP_SMALL_PAGES
Date: Tue, 24 Feb 2015 13:13:42 +0000 [thread overview]
Message-ID: <1424783622.27930.340.camel@citrix.com> (raw)
In-Reply-To: <54EC75C7.7040209@linaro.org>
On Tue, 2015-02-24 at 12:59 +0000, Julien Grall wrote:
> On 24/02/15 10:26, Ian Campbell wrote:
> > On Tue, 2015-02-24 at 09:38 +0000, Julien Grall wrote:
> >> Hi Ian,
> >>
> >> On 24/02/2015 09:31, Ian Campbell wrote:
> >>> On Wed, 2015-02-18 at 13:03 +0000, Julien Grall wrote:
> >>>>> + {
> >>>>> + pte = mfn_to_xen_entry(mfn, (ai & 0xffff));
> >>>>
> >>>> Please introduce a new macro for the mask.
> >>>
> >>> Better would be a pte_foo accessor, similar (if not identical) to x86's
> >>> pte_get_flags. So pte_get_flags(ai) or so.
> >>
> >> I'm not able to find a such function in x86. Did you intend to mean
> >> pte_flags_to_cacheattr?
> >
> > It's actually get_pte_flags.
> >
> >> In another side, using PTE_PRESENT would require to introduce a
> >> PAGE_AVAIL0 (or smth similar).
> >
> > Why?
>
> If we have only a bit PTE_PRESENT, how do you define MAP_SMALL_PAGES?
Oh right, yes, I was thinking that would use some other bit, either an
avail bit or reusing the table bit or something.
> Anyway, I guess introduce a separate helper would help here.
>
> >>> #define PTE_PRESENT ((struct lpae_t){ .pt.present = 1 }).bits
> >>>
> >>> probably doesn't work, I'm not even sure if this sort of thing is
> >>> possible. If not then "#define PTE_PRESET (1ULL<<0)".
> >>
> >> The attribute index (write-alloc, buferrable...) is using the less
> >> significant 3 bits. So I was suggesting to use the top of the word.
> >
> > I was suggesting to use bits 2..4 as in the real PTE, to be more similar
> > to the x86 interpretation of this argument.
>
> I don't think we have to follow how x86 interpret this argument. This is
> just a series of flags and may or may not match a bit in the PTE.
Not matching x86 here has already led to one set of confusion.
I'm not saying with have to match x86, but we should strongly consider
it and not just run with what we have now because it is a smaller
change.
Ian.
next prev parent reply other threads:[~2015-02-24 13:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-18 12:56 [PATCH v1] xen/arm: Do not allocate pte entries for MAP_SMALL_PAGES vijay.kilari
2015-02-18 13:03 ` Julien Grall
2015-02-24 9:31 ` Ian Campbell
2015-02-24 9:38 ` Julien Grall
2015-02-24 10:17 ` Jan Beulich
2015-02-24 10:26 ` Ian Campbell
2015-02-24 12:59 ` Julien Grall
2015-02-24 13:13 ` Ian Campbell [this message]
2015-02-24 13:47 ` Julien Grall
2015-02-24 13:54 ` Jan Beulich
2015-03-03 7:58 ` Vijay Kilari
2015-03-03 10:27 ` Ian Campbell
2015-03-03 11:17 ` Julien Grall
2015-03-03 11:47 ` Ian Campbell
2015-03-03 11:51 ` Julien Grall
2015-03-03 11:57 ` Ian Campbell
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=1424783622.27930.340.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=julien.grall@linaro.org \
--cc=manish.jaggi@caviumnetworks.com \
--cc=stefano.stabellini@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--cc=vijay.kilari@gmail.com \
--cc=vijaya.kumar@caviumnetworks.com \
--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 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.