Michael Ellerman [off-list ref] writes:

Ram Pai [off-list ref] writes:

quoted

On Thu, Aug 17, 2017 at 05:30:27PM -0300, Thiago Jung Bauermann wrote:

quoted

Ram Pai [off-list ref] writes:

quoted

On Thu, Aug 10, 2017 at 06:27:34PM -0300, Thiago Jung Bauermann wrote:

quoted

Ram Pai [off-list ref] writes:

quoted

@@ -227,6 +229,24 @@ static inline void pkey_mm_init(struct mm_struct *mm)
 	mm->context.execute_only_pkey = -1;
 }

+static inline void pkey_mmu_values(int total_data, int total_execute)
+{
+	/*
+	 * since any pkey can be used for data or execute, we
+	 * will  just  treat all keys as equal and track them
+	 * as one entity.
+	 */
+	pkeys_total = total_data + total_execute;
+}

Right now this works because the firmware reports 0 execute keys in the
device tree, but if (when?) it is fixed to report 32 execute keys as
well as 32 data keys (which are the same keys), any place using
pkeys_total expecting it to mean the number of keys that are available
will be broken. This includes pkey_initialize and mm_pkey_is_allocated.

Good point. we should just ignore total_execute. It should
be the same value as total_data on the latest platforms.
On older platforms it will continue to be zero.

Indeed. There should just be a special case to disable execute
protection for P7.

Ok. we should disable execute protection for P7 and earlier generations of CPU.

You should do what the device tree says you can do.

If it says there are no execute keys then you shouldn't touch the IAMR.

The downside of that approach is that the device tree in P8 LPARs
currently says there are no execute keys even though there are. We'd
have to require customers to upgrade their firmware to a fixed version
if they want to use execute keys.

-- 
Thiago Jung Bauermann
IBM Linux Technology Center