Re: [PATCH v4 16/18] KVM: guest_memfd: Explicitly pass number of pages to kvm_arch_gmem_prepare()

[Ackerley Tng <ackerleytng@google.com>]

Sean Christopherson <seanjc@google.com> writes:

> Tweak the guest_memfd prepare() hook to explicitly pass the number of pages
> to "prepare", so that the prepare() and invalidate() hooks can be combined
> into a single convert() hook, and because the existing code is outright
> broken if a guest_memfd folio is comprised of more than one page (which
> can't happen, yet).  guest_memfd aligns the pfn down, and the SNP code
> *tries* to create a corresponding huge entry, but if the RMP must use 4KiB
> entries for whatever reason, KVM will only "prepare" the first pfn, and not
> the actual pfn that needs to be converted/prepared.
>
> Alternatively, @max_order could simply be repurposed as _the_ @order, but
> that will fall apart when in-place conversion comes along, at which point
> KVM will need to deal with conversions that aren't strictly bound to a one
> folio.
>
> Note, kvm_gmem_prepare_folio() still mishandles hugepages, as it aligns
> only the pfn, i.e. would pass the wrong gfn+pfn pair.  This will be fixed
> shortly.
>
> WARN in the SNP code if the number of pages to prepare is anything other
> than '1', i.e. if guest_memfd is trying to prepare/convert more than a
> single 4KiB page, as sev_gmem_prepare() doesn't actually handle conversion
> greater than order-0 folios.
>
> Opportunistically convert the existing WARN in the prepare flow to a only
> fire once, e.g. so that a guest_memfd bug doesn't unintentionally Dos the
> kernel by spamming the log.
>
> Fixes: b85524314a3d ("KVM: guest_memfd: delay kvm_gmem_prepare_folio() until the memory is passed to the guest")
> Signed-off-by: Sean Christopherson <seanjc@google.com>
>
> [...snip...]
>

Reviewed-by: Ackerley Tng <ackerleytng@google.com>