From: Kameron Carr <[email protected]> Sent: Tuesday, July 21, 2026 11:44 AM > > On Friday, June 26, 2026 8:04 AM, Michael Kelley wrote: > > 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. > > 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. >
OK, this is good information! So evidently the situation is just like with normal ARM64 VMs on Hyper-V today. The Hyper-V host must operate with a 4 KiB page size, but the guest can use a larger page size as long as it communicates with the host in 4 KiB chunks (which ARM64 guests on Hyper-V already do). As you point out, a guest page size of >= 4 KiB implicitly meets host 4 KiB size/alignment requirement. But any changing of the private/shared state of memory assigned to the guest is necessarily done in units of, and aligned to, the guest page size. When running with 16 or 64 KiB page size, Hyper-V specific code in the guest must be careful that it is not unwittingly decrypting a larger chunk of memory than it intends. Doing so would probably still work, but would create a security hole by exposing guest data to the host that should be kept private to the guest. I've done a quick look through all the places where Hyper-V code calls set_memory_decrypted(), and the only case I see where the size might not match the guest page size is in hv_common_cpu_init(), and you are fixing that case in this patch. So all appears to be good. Michael
