Re: [PATCH v4 2/3] swiotlb: dma: its: Enforce host page-size alignment for shared buffers

[Marc Zyngier <maz@kernel.org>]

On Tue, 28 Apr 2026 13:20:53 +0100,
Aneesh Kumar K.V <aneesh.kumar@kernel.org> wrote:
> 
> Marc Zyngier <maz@kernel.org> writes:
> 
> > On Mon, 27 Apr 2026 07:31:07 +0100,
> > "Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> wrote:
> >> 
> >> When running private-memory guests, the guest kernel must apply additional
> >> constraints when allocating buffers that are shared with the hypervisor.
> >> 
> >> These shared buffers are also accessed by the host kernel and therefore
> >> must be aligned to the host’s page size, and have a size that is a multiple
> >> of the host page size.
> >> 
> >> On non-secure hosts, set_guest_memory_attributes() tracks memory at the
> >> host PAGE_SIZE granularity. This creates a mismatch when the guest applies
> >> attributes at 4K boundaries while the host uses 64K pages. In such cases,
> >> set_guest_memory_attributes() call returns -EINVAL, preventing the
> >> conversion of memory regions from private to shared.
> >> 
> >> Architectures such as Arm can tolerate realm physical address space
> >> (protected memory) PFNs being mapped as shared memory, as incorrect
> >> accesses are detected and reported as GPC faults. However, relying on this
> >> mechanism is unsafe and can still lead to kernel crashes.
> >> 
> >> This is particularly likely when guest_memfd allocations are mmapped and
> >> accessed from userspace. Once exposed to userspace, we cannot guarantee
> >> that applications will only access the intended 4K shared region rather
> >> than the full 64K page mapped into their address space. Such userspace
> >> addresses may also be passed back into the kernel and accessed via the
> >> linear map, resulting in a GPC fault and a kernel crash.
> >> 
> >> With CCA, although Stage-2 mappings managed by the RMM still operate at a
> >> 4K granularity, shared pages must nonetheless be aligned to the
> >> host-managed page size and sized as whole host pages to avoid the issues
> >> described above.
> >
> > I thought that was being fixed, and that there was now a strong
> > guarantee that RMM and host are aligned on the page size. Even more,
> > S2 is totally irrelevant here. The only thing that matters is the host
> > page size vs the guest page size. Nothing else.
> >
> 
> Yes, the latest RMM update includes the ability to change the granule
> size.
> 
> The section above in the commit message was intended to explain that the
> S2 mapping size is irrelevant. I agree it is not clear as written, so I
> will reword it to improve clarity.

Even better, remove it. Nothing CCA-specific should be in this patch.

[...]

> >>  static struct gen_pool *itt_pool;
> >> @@ -268,11 +272,13 @@ static void *itt_alloc_pool(int node, int size)
> >>  		if (addr)
> >>  			break;
> >>  
> >> -		page = its_alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO, 0);
> >> +		page = its_alloc_pages_node(node, GFP_KERNEL | __GFP_ZERO,
> >> +					    get_order(mem_decrypt_granule_size()));
> >
> > You already taught its_alloc_pages_node() about the decrypt granule
> > size stuff. I don't think we need to see more of it (and you don't
> > mess with the call that is just above it).
> >
> >>  		if (!page)
> >>  			break;
> >>  
> >> -		gen_pool_add(itt_pool, (unsigned long)page_address(page), PAGE_SIZE, node);
> >> +		gen_pool_add(itt_pool, (unsigned long)page_address(page),
> >> +			     mem_decrypt_granule_size(), node);
> >
> > I'd rather see something like mem_decrypt_align(PAGE_SIZE), which
> > keeps the intent clear.
> >
> 
> The helper was added based on feedback from a previous version. I assume
> you are suggesting that only this caller should switch?

I don't know what you mean by 'this'. What I'd like to see is this
last hunk be changed to:

	gen_pool_add(itt_pool, (unsigned long)page_address(page),
		     mem_decrypt_align(PAGE_SIZE), node);

and the previous hunk simply dropped.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.