On Wed, 22 Aug 2018 13:01:39 -0600 Alex Williamson <alex.william...@redhat.com> wrote:
> So apparently I assumed too much about the existing balloon inhibitor > use case, it's clearly not as general as the interface would lead one > to believe. The immediate solution is probably to make a postcopy > specific wrapper around qemu_balloon_inhibit() that keeps a static > internal state to avoid over incrementing or decrementing. That should > resolve this and then we can move on to whether we want to change the > overall internal interface or fixup some of the other cases noted > above. Thanks, > > Alex > My gut feeling is that an interface that allows code to add yet-another-inhibitor and to remove it again (IOW, what this patch implemented) is the way to go and that we should push out any checking whether a inhibitor actually can be removed to the callers. So, I think it actually makes a lot of sense for the postcopy code to keep track whether it actually submitted 'its' inhibit and only call into the generic inhibitor code to release it if that's the case.
