Thread (13 messages) 13 messages, 4 authors, 2017-10-11
STALE3155d
Revisions (24)
  1. v1 [diff vs current]
  2. v1 [diff vs current]
  3. v1 current
  4. v1 [diff vs current]
  5. v1 [diff vs current]
  6. v1 [diff vs current]
  7. v1 [diff vs current]
  8. v1 [diff vs current]
  9. v2 [diff vs current]
  10. v2 [diff vs current]
  11. v2 [diff vs current]
  12. v2 [diff vs current]
  13. v3 [diff vs current]
  14. v4 [diff vs current]
  15. v4 [diff vs current]
  16. v5 [diff vs current]
  17. v5 [diff vs current]
  18. v5 [diff vs current]
  19. v5 [diff vs current]
  20. v5 [diff vs current]
  21. v5 [diff vs current]
  22. v5 [diff vs current]
  23. v6 [diff vs current]
  24. v6 [diff vs current]

[PATCH 1/3] arm64: mm: Support Common Not Private translations

From: james.morse@arm.com (James Morse)
Date: 2017-10-09 16:48:36

Hi Catalin, Vladimir,

On 09/10/17 16:23, Catalin Marinas wrote:
On Mon, Oct 09, 2017 at 01:55:32PM +0100, Vladimir Murzin wrote:
quoted
This patch adds support for Common Not Private translations on
different exceptions levels:
quoted
(2) For EL1 we postpone setting CNP till all cpus are up and rely on
    cpufeature framework to 1) patch the code which is sensitive to
    CNP and 2) update TTBR1_EL1 with CNP bit set. The only case where
    TTBR1_EL1 can be reprogrammed is hibirnation, so the code there is
    changed to save raw TTBR1_EL1 and blindly restore it on resume.
Even if you do this when all the CPUs are up, that's not always true.
Starting with maxcpus=1 allows something like systemd to bring up new
CPUs once user space starts.
For secondary CPUs cpu_enable_cnp() will be called to set CNP on TTBR1_EL1. But
what about cpuidle? This also resets the TTBR1_EL1 value.

The problem we have is that we don't know
what the firmware is doing, whether it's setting CnP or not. Maybe we
should add some statement in Documentation/arm64/booting.txt that
firmware must not use CnP at all.
quoted
diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
index 095d3c1..1d056f3 100644
--- a/arch/arm64/kernel/hibernate.c
+++ b/arch/arm64/kernel/hibernate.c
@@ -124,7 +124,7 @@ int arch_hibernation_header_save(void *addr, unsigned int max_size)
 		return -EOVERFLOW;
 
 	arch_hdr_invariants(&hdr->invariants);
-	hdr->ttbr1_el1		= __pa_symbol(swapper_pg_dir);
+	hdr->ttbr1_el1		= read_sysreg(ttbr1_el1);
 	hdr->reenter_kernel	= _cpu_resume;
 
 	/* We can't use __hyp_get_vectors() because kvm may still be loaded */
Are all the CPUs up when coming out of hibernation and restoring
ttbr1_el1?
'nonboot' CPUs are powered off around hibernate, so this only runs on one CPU.

Restoring with the CNP set like this will share all the TTBR1 mappings using the
reserved ASID out of TTBR0. Hibernate then calls cpu_uninstall_idmap() via
__cpu_suspend_exit(), which will restore the original ttbr0 value and CNP bit.


Thanks,

James
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help