RE: [PATCH v2 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms

["Kameron Carr" <kameroncarr@linux.microsoft.com>]

On Thursday, June 25, 2026 11:59 AM, Michael Kelley wrote:
> From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Thursday,
> June 25, 2026 10:35 AM
> > 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
> > 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.

> > @@ -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 can undo this change.

Regards,
Kameron