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

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

On Friday, June 26, 2026 8:04 AM, Michael Kelley wrote:
> From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Friday, June
> 26, 2026 4:09 AM
> >
> > 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.
> 
> 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.

I talked with some people from ARM. My current understanding is that the
4KB granule size for the RSI does not mean the guest is restricted to 4KB
page size. The granule size is just the alignment requirement and larger
page sizes will always be 4KB aligned.

I tested 64KB page size on CCA Realm and it booted successfully.

I will be treating large page sizes as a valid scenario. Please flag any
issues you spot related to page size > 4KB.

Regards,
Kameron