From: Kameron Carr <redacted> Sent: Friday, June 26, 2026 4:09 AM

On Thursday, June 25, 2026 11:59 AM, Michael Kelley wrote:

quoted

From: Kameron Carr <redacted> Sent: Thursday,
June 25, 2026 10:35 AM

quoted

We need to round up the memory allocated for the input/output pages to
the nearest PAGE_SIZE, since set_memory_decrypted() requires the size to
be a multiple of PAGE_SIZE. This only has an effect on ARM VMs that are
using PAGE_SIZE larger than 4K.

I think this change resulted from a Sashiko comment. My understanding is
that the ARM CCA architecture only supports CCA guests with 4 KiB page
size. Is that still the case, or has that restriction been lifted in a later version
of the architecture? I'm in favor of handling the larger page sizes, if only for
future proofing. But I wondered whether your intent is to always support

quoted

4 KiB page sizes even if CCA doesn't support them now. Another way to

put it: In reviewing code, should I flag issues related to page sizes > 4 KiB?

I think you might be right. I'm looking at RMM spec 2.0 beta 2, and the RMI
can have granule size 4KB, 16KB, 64KB, but the RSI is restricted to granule size
4KB.

I'm open to suggestion on best way to move forward.

The best approach probably depends on whether the 4 KiB restriction is
likely to be lifted in a future version of the CCA architecture, and I don't have
any insight into that.

If it is likely to be lifted, then doing the initial implementation to support
larger page sizes probably makes sense (which is what you've done here).
It's less work than going back and adding later. But the commit message
and/or code comments should indicate that the larger page size support
is future-proofing work, so that someone doesn't get the wrong idea that
it should work with larger page sizes now.

The alternate approach is to not do any larger page size support now,
and to explicitly state that the code is assuming the current restriction
of 4 KiB page size only.

Whichever approach is chosen should be used consistently so there's
not a mishmash.

quoted

quoted

@@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu)
 		}

 		if (!ms_hyperv.paravisor_present &&
-		    (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
-			ret = set_memory_decrypted((unsigned long)mem, pgcount);
+		    (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
+		     hv_isolation_type_cca())) {
+			ret = set_memory_decrypted((unsigned long)kasan_reset_tag(mem),
+				alloc_size >> PAGE_SHIFT);

I don't know enough about KASAN or the tag situation on ARM64
to comment on this change. But this same sequence of allocating
memory and then decrypting it occurs in other places in Hyper-V
code. It seems like those places would also need the same
kasan_reset_tag() call.

I'm not sure of the exact behavior of PAGE_END when there are
KASAN tags, but it looks like tags could mess with the address
comparison.

I do see that __virt_to_phys_nodebug() and virt_addr_valid() in
arch/arm64/include/asm/memory.h both reset tags before calling
__is_lm_address().

If there are many calls that follow this pattern, it may be better to
add the tag reset in __set_memory_enc_dec().

I had the same thought.

I can undo this change.

Unfortunately, I don't know whether undoing it is right or not. I
haven't taken the time to go learn about the whole scheme and its
implications.

Michael