diff options
author | Diana Craciun <Diana.Craciun@freescale.com> | 2013-03-14 16:55:11 +0200 |
---|---|---|
committer | Scott Wood <scottwood@freescale.com> | 2014-01-10 17:34:04 -0600 |
commit | ed2ddc56e758d516c5699260ada4d68434dfe1dc (patch) | |
tree | 2dd135e9887680a3c34c88344da9319b5784676e /crypto | |
parent | 1149e8a73ffea953d8d6615ee37bce820a3eaeb8 (diff) | |
download | linux-stable-ed2ddc56e758d516c5699260ada4d68434dfe1dc.tar.gz linux-stable-ed2ddc56e758d516c5699260ada4d68434dfe1dc.tar.bz2 linux-stable-ed2ddc56e758d516c5699260ada4d68434dfe1dc.zip |
powerpc: Replaced tlbilx with tlbwe in the initialization code
On Freescale e6500 cores EPCR[DGTMI] controls whether guest supervisor
state can execute TLB management instructions. If EPCR[DGTMI]=0
tlbwe and tlbilx are allowed to execute normally in the guest state.
A hypervisor may choose to virtualize TLB1 and for this purpose it
may use IPROT to protect the entries for being invalidated by the
guest. However, because tlbwe and tlbilx execution in the guest state
are sharing the same bit, it is not possible to have a scenario where
tlbwe is allowed to be executed in guest state and tlbilx traps. When
guest TLB management instructions are allowed to be executed in guest
state the guest cannot use tlbilx to invalidate TLB1 guest entries.
Linux is using tlbilx in the boot code to invalidate the temporary
entries it creates when initializing the MMU. The patch is replacing
the usage of tlbilx in initialization code with tlbwe with VALID bit
cleared.
Linux is also using tlbilx in other contexts (like huge pages or
indirect entries) but removing the tlbilx from the initialization code
offers the possibility to have scenarios under hypervisor which are
not using huge pages or indirect entries.
Signed-off-by: Diana Craciun <Diana.Craciun@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Diffstat (limited to 'crypto')
0 files changed, 0 insertions, 0 deletions