On Thu, Aug 19, 2021 at 01:33:09PM -0500, Tom Lendacky wrote:
I did it as inline originally because the presence of the function will be
decided based on the ARCH_HAS_PROTECTED_GUEST config. For now, that is
only selected by the AMD memory encryption support, so if I went out of
line I could put in mem_encrypt.c. But with TDX wanting to also use it, it
would have to be in an always built file with some #ifdefs or in its own
file that is conditionally built based on the ARCH_HAS_PROTECTED_GUEST
setting (they've already tried building with ARCH_HAS_PROTECTED_GUEST=y
and AMD_MEM_ENCRYPT not set).
To take it out of line, I'm leaning towards the latter, creating a new
file that is built based on the ARCH_HAS_PROTECTED_GUEST setting.
Yes. In general everytime architectures have to provide the prototype
and not just the implementation of something we end up with a giant mess
sooner or later. In a few cases that is still warranted due to
performance concerns, but i don't think that is the case here.
quoted
quoted
+/* 0x800 - 0x8ff reserved for AMD */
+#define PATTR_SME 0x800
+#define PATTR_SEV 0x801
+#define PATTR_SEV_ES 0x802
Why do we need reservations for a purely in-kernel namespace?
And why are you overoading a brand new generic API with weird details
of a specific implementation like this?
There was some talk about this on the mailing list where TDX and SEV may
need to be differentiated, so we wanted to reserve a range of values per
technology. I guess I can remove them until they are actually needed.
In that case add a flag for the differing behavior. And only add them
when actually needed. And either way there is absolutely no need to
reserve ranges.