On Fri, Jan 10, 2025, Claudio Imbrenda wrote: > On Fri, 10 Jan 2025 08:22:12 -0800 > Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > AFAIK, that limitation exists purely because of dirty bitmaps. IIUC, these "fake" > > memslots are not intended to be visible to userspace, or at the very least don't > > *need* to be visible to userspace. > > > > Assuming that's true, they/it can/should be KVM-internal memslots, and those > > should never be dirty-logged. x86 allocates metadata based on slot size, so in > > practice creating a mega-slot will never succeed on x86, but the only size > > limitation I see in s390 is on arch.mem_limit, but for ucontrol that's set to -1ull, > > i.e. is a non-issue. > > > > I have a series (that I need to refresh) to provide a dedicated API for creating > > internal memslots, and to also enforce that flags == 0 for internal memslots, > > i.e. to enforce that dirty logging is never enabled (see Link below). With that > > I mind, I can't think of any reason to disallow a 0 => TASK_SIZE memslot so long > > as it's KVM-defined. > > > > Using a single memslot would hopefully allow s390 to unconditionally carve out a > > KVM-internal memslot, i.e. not have to condition the logic on the type of VM. E.g. > > yes, I would love that > > the reason why I did not use internal memslots is that I would have > potentially needed *all* the memslots for ucontrol, and instead of > reserving, say, half of all memslots, I decided to have them > user-visible, which is hack I honestly don't like. > > do you think you can refresh the series before the upcoming merge > window? Ya, I'll refresh it today, and then I can apply it early next week and provide an immutable topic branch/tag. My thought is to have you carry the below in the s390 series though, as I don't have a way to properly test it, and I'd prefer to avoid having to do a revert on the off chance removing the limit doesn't work for ucontrol.
