On Mon, Jun 08, 2026 at 03:44:29PM +0100, Matthew Wilcox wrote: > On Mon, Jun 08, 2026 at 04:37:03PM +0200, David Hildenbrand (Arm) wrote: > > On 6/8/26 16:31, Matthew Wilcox wrote: > > > On Mon, Jun 08, 2026 at 04:26:18PM +0200, David Hildenbrand (Arm) wrote: > > >> If that means that we would handle __GFP_ZERO consistently in the > > >> callers of > > >> alloc_frozen_pages(), that would also do I guess. We'd still have to > > >> pass the > > >> user address down to some degree, through folio interfaces only at least. > > > > > > What I don't understand is how the kernel page allocator needs to know > > > the user address in order to effectively zero it, but the hypervisor is > > > able to zero the page without knowing the user address. It feels like > > > somebody has x86-centric thinking where cache colouring doesn't matter. > > > > (not commenting on the icache dache mess we have to drag along) > > Well, that was kind of the point of this email ... I did ask the > question you're answering in a different email so let me respond > to that too. > > > The thing is that with free-page-reporting the memory is already zeroed by > > the > > hypervisor as part of discarding that memory previously (e.g., > > MADV_DONTNEED) > > and allocating fresh pages on re-access. > > > > So it's not a question of "why is the hypervisor zeroing less efficiently", > > as > > zeroing is just a side-product of reclaiming that memory in the first place. > > We definitely have users who don't want the guest to trust the > hypervisor. So how do they disable this optimisation?
What do you mean, how? This is done by: [PATCH v10 35/37] virtio_balloon: disable reporting zeroed optimization for confidential guests -- MST
