linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 05/11] ARM: LPAE: provide an IPA capable pmd_addr_end
Date: Thu, 6 Feb 2014 20:04:56 -0800	[thread overview]
Message-ID: <20140207040456.GN9157@cbox> (raw)
In-Reply-To: <20140206104328.GB29446@arm.com>

On Thu, Feb 06, 2014 at 10:43:28AM +0000, Catalin Marinas wrote:
> On Wed, Feb 05, 2014 at 07:55:45PM +0000, Marc Zyngier wrote:
> > The default pmd_addr_end macro uses an unsigned long to represent
> > the VA. When used with KVM and stage-2 translation, the VA is
> > actually an IPA, which is up to 40 bits. This also affect the
> > SMMU driver, which also deals with stage-2 translation.
> > 
> > Instead, provide an implementation that can cope with larger VAs
> > by using a u64 instead. This version will overload the default
> > one provided in include/asm-generic/pgtable.h.
> > 
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> >  arch/arm/include/asm/pgtable-3level.h | 5 +++++
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
> > index 03243f7..594867b 100644
> > --- a/arch/arm/include/asm/pgtable-3level.h
> > +++ b/arch/arm/include/asm/pgtable-3level.h
> > @@ -262,6 +262,11 @@ static inline int has_transparent_hugepage(void)
> >  	return 1;
> >  }
> >  
> > +#define pmd_addr_end(addr, end)						\
> > +({	u64 __boundary = ((addr) + PMD_SIZE) & PMD_MASK;		\
> > +	(__boundary - 1 < (end) - 1)? __boundary: (end);		\
> > +})
> 
> I see why you need this but it affects all the other uses of
> pmd_addr_end() with 32-bit VA. It would be slight performance, I don't
> think it's noticeable.
> 
> A different approach could be something like (untested):
> 
> #define pmd_addr_end(addr, end)					\
> ({	__typeof__(addr) __boundary = ...
> 	...
> })
> 
> What about the pgd_addr_end(), do we need this or it's not used by KVM?
> 

What about pud_addr_end(), is that defined as a noop on LPAE, or?

I would be in favor of introducing them all using your approach to avoid
somebody being inspired by the KVM code when dealing with IPAs and
breaking things unknowingly.

-Christoffer

  reply	other threads:[~2014-02-07  4:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05 19:55 [PATCH v3 00/11] arm/arm64: KVM: host cache maintenance when guest caches are off Marc Zyngier
2014-02-05 19:55 ` [PATCH v3 01/11] arm64: KVM: force cache clean on page fault when " Marc Zyngier
2014-02-05 19:55 ` [PATCH v3 02/11] arm64: KVM: allows discrimination of AArch32 sysreg access Marc Zyngier
2014-02-05 19:55 ` [PATCH v3 03/11] arm64: KVM: trap VM system registers until MMU and caches are ON Marc Zyngier
2014-02-05 19:55 ` [PATCH v3 04/11] arm64: KVM: flush VM pages before letting the guest enable caches Marc Zyngier
2014-02-07  4:08   ` Christoffer Dall
2014-02-05 19:55 ` [PATCH v3 05/11] ARM: LPAE: provide an IPA capable pmd_addr_end Marc Zyngier
2014-02-06 10:43   ` Catalin Marinas
2014-02-07  4:04     ` Christoffer Dall [this message]
2014-02-07 15:44       ` Catalin Marinas
2014-02-07 17:10         ` Christoffer Dall
2014-02-11  9:07           ` Marc Zyngier
2014-02-05 19:55 ` [PATCH v3 06/11] ARM: KVM: force cache clean on page fault when caches are off Marc Zyngier
2014-02-06 10:49   ` Catalin Marinas
2014-02-05 19:55 ` [PATCH v3 07/11] ARM: KVM: fix handling of trapped 64bit coprocessor accesses Marc Zyngier
2014-02-06 10:49   ` Catalin Marinas
2014-02-05 19:55 ` [PATCH v3 08/11] ARM: KVM: fix ordering of " Marc Zyngier
2014-02-06 10:50   ` Catalin Marinas
2014-02-05 19:55 ` [PATCH v3 09/11] ARM: KVM: introduce per-vcpu HYP Configuration Register Marc Zyngier
2014-02-06 11:01   ` Catalin Marinas
2014-02-05 19:55 ` [PATCH v3 10/11] ARM: KVM: add world-switch for AMAIR{0,1} Marc Zyngier
2014-02-06 11:02   ` Catalin Marinas
2014-02-05 19:55 ` [PATCH v3 11/11] ARM: KVM: trap VM system registers until MMU and caches are ON Marc Zyngier
2014-02-06 11:03   ` Catalin Marinas
2014-02-07  4:08   ` Christoffer Dall

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=20140207040456.GN9157@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.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).