From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
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:47:19 +0000 [thread overview]
Message-ID: <54EC80E7.5000905@linaro.org> (raw)
In-Reply-To: <1424783622.27930.340.camel@citrix.com>
On 24/02/15 13:13, Ian Campbell wrote:
>>>>> #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.
That was a misunderstanding of the define. Without Jan's explanation I
would not have understand the purpose of this define.
> 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.
lpae_t is an uint64_t and flags an unsigned int, so we will have to
check that any bits we have to modified is effectively living on the
less significant word.
Also, a smaller change would allow us to backport the patch to Xen 4.5.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-02-24 13:47 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
2015-02-24 13:47 ` Julien Grall [this message]
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=54EC80E7.5000905@linaro.org \
--to=julien.grall@linaro.org \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=ian.campbell@citrix.com \
--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.