From: Kameron Carr <[email protected]> Sent: Friday, June 26,
2026 4:09 AM
>
> On Thursday, June 25, 2026 11:59 AM, Michael Kelley wrote:
> > From: Kameron Carr <[email protected]> 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.
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.
>
> > > @@ -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
