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
