linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Ram Pai <linuxram@us.ibm.com>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Cc: dave.hansen@intel.com, paulus@samba.org, aneesh.kumar@linux.vnet.ibm.com
Subject: Re: [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K backed hpte pages.
Date: Tue, 20 Jun 2017 16:21:45 +0530	[thread overview]
Message-ID: <ff6fe458-6539-e237-4556-41872385815a@linux.vnet.ibm.com> (raw)
In-Reply-To: <1497671564-20030-3-git-send-email-linuxram@us.ibm.com>

On 06/17/2017 09:22 AM, Ram Pai wrote:
> Rearrange 64K PTE bits to  free  up  bits 3, 4, 5  and  6
> in the 64K backed hpte pages. This along with the earlier
> patch will entirely free up the four bits from 64K PTE.
> 
> This patch does the following change to 64K PTE that is
> backed by 64K hpte.
> 
> H_PAGE_F_SECOND which occupied bit 4 moves to the second part
>         of the pte.
> H_PAGE_F_GIX which  occupied bit 5, 6 and 7 also moves to the
>         second part of the pte.
> 
> since bit 7 is now freed up, we move H_PAGE_BUSY from bit 9
> to bit 7. Trying to minimize gaps so that contiguous bits
> can be allocated if needed in the future.
> 
> The second part of the PTE will hold
> (H_PAGE_F_SECOND|H_PAGE_F_GIX) at bit 60,61,62,63.

I still dont understand how we freed up the 5th bit which is
used in the 5th patch. Was that bit never used for any thing
on 64K page size (64K and 4K mappings) ?

+#define _RPAGE_RSV5		0x00040UL

+#define H_PAGE_PKEY_BIT0	_RPAGE_RSV1
+#define H_PAGE_PKEY_BIT1	_RPAGE_RSV2
+#define H_PAGE_PKEY_BIT2	_RPAGE_RSV3
+#define H_PAGE_PKEY_BIT3	_RPAGE_RSV4
+#define H_PAGE_PKEY_BIT4	_RPAGE_RSV5

  reply	other threads:[~2017-06-20 10:52 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-17  3:52 [RFC v2 00/12] powerpc: Memory Protection Keys Ram Pai
2017-06-17  3:52 ` [RFC v2 01/12] powerpc: Free up four 64K PTE bits in 4K backed hpte pages Ram Pai
2017-06-20 10:20   ` Anshuman Khandual
2017-06-20 23:23     ` Ram Pai
2017-06-21  5:35       ` Anshuman Khandual
2017-06-21  6:34         ` Ram Pai
2017-06-21  6:41   ` Aneesh Kumar K.V
2017-06-21  9:30     ` Ram Pai
2017-06-22  9:07   ` Anshuman Khandual
2017-06-22 16:20     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 02/12] powerpc: Free up four 64K PTE bits in 64K " Ram Pai
2017-06-20 10:51   ` Anshuman Khandual [this message]
2017-06-20 23:25     ` Ram Pai
2017-06-21  6:50   ` Aneesh Kumar K.V
2017-06-21  6:54   ` Aneesh Kumar K.V
2017-06-21 20:14     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 03/12] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call Ram Pai
2017-06-19 12:18   ` Michael Ellerman
2017-06-20 22:45     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 04/12] powerpc: store and restore the pkey state across context switches Ram Pai
2017-06-17  3:52 ` [RFC v2 05/12] powerpc: Implementation for sys_mprotect_pkey() system call Ram Pai
2017-06-21  7:16   ` Aneesh Kumar K.V
2017-06-17  3:52 ` [RFC v2 06/12] powerpc: Program HPTE key protection bits Ram Pai
2017-06-20  8:21   ` Anshuman Khandual
2017-06-20 23:26     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 07/12] powerpc: Macro the mask used for checking DSI exception Ram Pai
2017-06-20  8:14   ` Anshuman Khandual
2017-06-20 23:28     ` Ram Pai
2017-06-21  7:25   ` Aneesh Kumar K.V
2017-06-21  9:17     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 08/12] powerpc: Handle exceptions caused by violation of pkey protection Ram Pai
2017-06-20  7:24   ` Anshuman Khandual
2017-06-20 23:43     ` Ram Pai
2017-06-21  3:54       ` Anshuman Khandual
2017-06-21  6:26         ` Ram Pai
2017-06-17  3:52 ` [RFC v2 09/12] powerpc: Deliver SEGV signal on pkey violation Ram Pai
2017-06-20  6:54   ` Anshuman Khandual
2017-06-20 23:56     ` Ram Pai
2017-06-21  3:18       ` Anshuman Khandual
2017-06-21  6:10         ` Ram Pai
2017-06-17  3:52 ` [RFC v2 10/12] powerpc: Read AMR only if pkey-violation caused the exception Ram Pai
2017-06-19 11:06   ` Michael Ellerman
2017-06-19 17:59     ` Ram Pai
2017-06-20  6:46       ` Anshuman Khandual
2017-06-20 23:58         ` Ram Pai
2017-06-20 23:56     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 11/12]Documentation: Documentation updates Ram Pai
2017-06-20  6:18   ` Anshuman Khandual
2017-06-21  0:04     ` Ram Pai
2017-06-17  3:52 ` [RFC v2 12/12]selftest: Updated protection key selftest Ram Pai
2017-06-19 11:04   ` Michael Ellerman
2017-06-20  6:26   ` Anshuman Khandual
2017-06-21  0:10     ` Ram Pai
2017-06-20  5:10 ` [RFC v2 00/12] powerpc: Memory Protection Keys Balbir Singh
2017-06-20  6:05   ` Anshuman Khandual
2017-06-20  9:56   ` Benjamin Herrenschmidt

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=ff6fe458-6539-e237-4556-41872385815a@linux.vnet.ibm.com \
    --to=khandual@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=linuxram@us.ibm.com \
    --cc=paulus@samba.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).