Dave Hansen wrote:
On 4/17/25 12:11, Dan Williams wrote:
arch/x86/Kconfig | 4 ++++ arch/x86/mm/pat/memtype.c | 31 ++++--------------------------- drivers/char/mem.c | 27 +++++++++------------------ include/linux/io.h | 21 +++++++++++++++++++++ 4 files changed, 38 insertions(+), 45 deletions(-)
This looks like a good idea on multiple levels. We can take it through tip, but one things that makes me nervous is that neither of the "CHAR and MISC DRIVERS" supporters are even on cc.
Arnd Bergmann arnd@arndb.de (supporter:CHAR and MISC DRIVERS) Greg Kroah-Hartman gregkh@linuxfoundation.org (supporter:CHAR and MISC DRIVERS)
Good catch, just note that until this latest iteration the proposal was entirely contained to x86 specific support functions like devmem_is_allowed(). So yes, an oversight as this moved to a more general devmem mechanism.
I guess arm and powerpc have cc_platform_has() so it's not _completely_ x86 only, either. Acks from those folks would also be appreciated since it's going to affect them most immediately.
I have added Suzuki and Michael for their awareness, but I would not say acks are needed at this point since to date CC_ATTR_GUEST_MEM_ENCRYPT is strictly an x86-ism.
For example, the PowerPC implementation of cc_platform_has() has not been touched since Tom added it.
Suzuki, Michael, at a minimum the question this patch poses to ARM64 and PowerPC is whether they are going to allow CONFIG_STRICT_DEVMEM=n, or otherwise understand that CONFIG_STRICT_DEVMEM=y == LOCKDOWN with CC_ATTR_GUEST_MEM_ENCRYPT.
Also, just to confirm, patch 2 can go to stable@ without _any_ dependency on patch 1, right?
Correct. I will make them independent / unordered patches on the repost.
Next posting to fix the "select" instead of "depends on" dependency management, h/t Naveen, and clarify the "'crash' vs 'SEPT violation'" description.