On Thu, 26 Aug 2010 09:28:42 +0100 "Daniel P. Berrange" <berra...@redhat.com> wrote:
> On Thu, Aug 26, 2010 at 01:47:50PM +0530, Amit Shah wrote: > > On (Thu) Aug 26 2010 [10:05:44], Paolo Bonzini wrote: > > > On 08/26/2010 08:05 AM, Amit Shah wrote: > > > >This is what I have currently. It would need some timer handling in > > > >the save/load case as well, right? > > > > > > When loading you won't have any pending "info balloon" command, so I > > > think the timer need not be preserved across migration. > > > > > > Also, 5 seconds for a stopped guest is actually a lot, > > > > That's the problem; it's policy. Where and how to specify it? > > It is unfortunate that this is policy, but we just have to accept > that the current query-balloon command is a flawed design. IMHO > we should just hardcode the timeout at 5 seconds as you do (plus > immediate return for paused guests). Then focus on adding new > monitor commands/events to deal with balloon query in a way > that doesn't require this kind of policy in QEMU, and deprecate > the existing query-balloon command. Agreed, but it's not just that: we've never correctly specified how commands that talk with the guest should behave. *brain dump warning* We were talking about making all commands work as synchronous and asynchronous. If we do that, then we'll need a 'global' timeout for all synchronous commands. We could have a default value and a command to set it. *brain dump warning ends* I really don't know what to do 0.13. Probably the hard-coded timer is the best solution we have, but I'm wondering if it's going to cause problems in the near future, when we get proper asynchronous command support.
