Re: [PATCH v2 1/4] KVM: s390: Replace get_zeroed_page() with kzalloc() for the STHYI buffer

[Mike Rapoport]

On Mon, Sep 07, 2026 at 02:23:02PM +0200, Janosch Frank wrote:
> On 9/6/26 10:27 AM, Mike Rapoport (Microsoft) wrote:
> > handle_sthyi() allocates the buffer that receives the STHYI response
> > block before it is copied to the guest.
> > 
> > This buffer can be allocated with kmalloc() as there's nothing special
> > about it to go directly to the page allocator.
> > 
> > kmalloc() provides a better API that does not require ugly casts and
> > kfree() does not need to know the size of the freed object.
> > 
> > Performance difference between kmalloc() and __get_free_pages() is not
> > measurable as both allocators take an object/page from a per-CPU list for
> > fast path allocations.
> > 
> > For the slow path the performance is anyway determined by the amount of
> > reclaim involved rather than by what allocator is used.
> > 
> > The only goto in that function does not unwind anything, it merely skips
> > to the exit when the function code is invalid. Turn it into an early
> > return so that the buffer can be freed with __free(kfree).
> > 
> > Replace use of get_zeroed_page() with kzalloc() and free_page() with
> > kfree().
> > 
> > Assisted-by: copilot:claude-opus
> > Signed-off-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> Yup, there's no alignment requirement anyway.
> Reviewed-by: Janosch Frank <frankja@xxxxxxxxxxxxx>
> 
> 
> 
> Looking at the kernel's sthyi.c there are a couple more locations we could
> change:
> 
> I don't see a need for the syscall to allocate a page and the cache doesn't
> need page allocation either. We should even be able to have them byte

That's planned :)
I'm splitting this project into small chunks to ease both my review of what
LLM did and to avoid patch bombs that are hard to review for everyone.

> aligned since they are never the destination for one of the diagnose
> instructions, a kvzalloc should be fine if I didn't miss something...

For PAGE_SIZE allocations kvzalloc() will kzalloc() anyway, so I'd rather
use the latter explicitly. 
 
> Diag224 needs a 4k aligned 31-bit physical address for some reason so that
> needs GFP_DMA. diag204 is vmallocing anyway since subcode 7 uses logical
> addresses.

Actually __vmalloc_node() seems a bit odd there :)
Plain vmalloc() would do the same.

-- 
Sincerely yours,
Mike.