From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v1] xen/arm: Do not allocate pte entries for MAP_SMALL_PAGES Date: Tue, 24 Feb 2015 13:47:19 +0000 Message-ID: <54EC80E7.5000905@linaro.org> References: <1424264213-30614-1-git-send-email-vijay.kilari@gmail.com> <54E48DAB.5030307@linaro.org> <1424770282.27930.259.camel@citrix.com> <54EC4699.8050905@linaro.org> <1424773562.27930.301.camel@citrix.com> <54EC75C7.7040209@linaro.org> <1424783622.27930.340.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1424783622.27930.340.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell 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 List-Id: xen-devel@lists.xenproject.org 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