Re: [PATCH v3 1/4] KVM: Dynamic sized kvm memslots array

[Peter Xu <peterx@redhat.com>]

On Mon, Sep 16, 2024 at 02:52:04PM -0300, Fabiano Rosas wrote:
> >>  
> >> +    /*
> >> +     * A VM will at least require a few memslots to work, or it can even
> >> +     * fail to boot.  Make sure the supported value is always at least
> >> +     * larger than what we will initially allocate.
> >
> > The commit message says 16 was chosen to cover basic usage, which is
> > fine. But here we're disallowing anything smaller. Shouldn't QEMU always
> > respect what KVM decided? Of course, setting aside bugs or other
> > scenarios that could result in the ioctl returning 0. Could some kernel
> > implementation at some point want to reduce the max number of memslots
> > and then get effectively denied because QEMU thinks otherwise?

I'd say it's unlikely to happen, but indeed failing it here might be based
too much over the artificial KVM_MEMSLOTS_NR_ALLOC_DEFAULT I came up with.

If this check is removed, I suppose we're still fine.  So it means later
when qemu initializes kvm memslots here:

    kvm_slots_grow(kml, KVM_MEMSLOTS_NR_ALLOC_DEFAULT);

It'll be throttled by whatever kvm specified lower than 16. Then if
memslots are not enough, we'll fail at memslot allocation whenever
requested more than what kvm offers:

    fprintf(stderr, "%s: no free slot available\n", __func__);
    abort();

Yeah, maybe it is better to fail here.. Even though I think we'll never use
it, but still good to remove some lines if they're not needed.  Let me
remove this check in my next post.

Thanks,

-- 
Peter Xu