linux-kernel - Re: [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table format definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1288007977.14756.41.camel@e102109-lin.cambridge.arm.com>
Date:	Mon, 25 Oct 2010 12:59:37 +0100
From:	Catalin Marinas <catalin.marinas@....com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 06/18] ARM: LPAE: Introduce the 3-level page table
 format definitions

On Mon, 2010-10-25 at 12:15 +0100, Arnd Bergmann wrote:
> On Monday 25 October 2010, Catalin Marinas wrote:
> > +/*
> > + * With LPAE, there are 3 levels of page tables. Each level has 512 entries of
> > + * 8 bytes each, occupying a 4K page. The first level table covers a range of
> > + * 512GB, each entry representing 1GB. Since we are limited to 4GB input
> > + * address range, only 4 entries in the PGD are used.
> > + *
> > + * There are enough spare bits in a page table entry for the kernel specific
> > + * state.
> > + */
> > +#define PTRS_PER_PTE           512
> > +#define PTRS_PER_PMD           512
> > +#define PTRS_PER_PGD           4
> 
> Since the PGD is so extremely small, would it be possible to fold it
> into the mm_context_t in order to save an allocation?
> Or does the PGD still require page alignment?

There are alignment restrictions, though not to a page size. Given the
TTBR0 access range of the full 4GB (TTBCR.T0SZ = 0), the alignment
required is 64 (2^6). We get this for the slab allocator anyway when the
L1_CACHE_SHIFT is 6 but I could make this requirement explicit by
creating a kmem_cache with the required alignment.

> Do you also have patches to allow 40-bit virtual space? I suppose we
> will need that for KVM support in the future.

I'm not sure how these would look like since the architecture is 32-bit
(and I'm not familiar with KVM). With the MMU disabled, you can't access
beyond the 4GB space anyway. KVM could use something like the pfn but in
the virtual space.

Cortex-A15 comes with both LPAE and Virtualisation Extensions, so the
latter could be used for something like KVM. There is another stage of
page table translations, so the one set up by Linux actually generates
an intermediate physical address (IPA) which gets translated to the real
PA in the second stage. The IPA is 40-bit wide.

Catalin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/