[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] New virtio balloon...
Daniel Kiper <daniel.kiper@oracle.com> writes: > On Wed, Feb 05, 2014 at 01:45:38PM +1030, Rusty Russell wrote: >> self-ballooning? It seems like they'll just fight over target values >> if they both try to act. > > Sadly, yep. I know about that issue. Do you mean that we would like to avoid > such situation in new VIRTIO balloon driver? Any other reasons? To step back a moment: I feel that you, Luiz and I are engaged in a search for enlightenment, and we are slowly making progress! The specification needs to be cover how to implement both device and driver. Simple enough to implement correctly, complex enough to be useful. I see Luiz, with his self-ballooning patch (which was basically a "gimme more mem please!" from the guest) heading in the same direction that Xen's self-balloon ended up. Does this mean that the current (legacy) virtio ballon is completely backwards, and that experience shows that the guest must drive? Or does it really mean that there are cases for both, and the we need a balloon driver which does both? If both, it needs to be specified what side wins. A feature bit would be the classic method. If we really don't know, we should leave the balloon device out of the standard entirely for v1.0 rather than rushing it (except to reserve id 13 for the future virtio balloon). >> -struct gcmd_stats { >> - __le64 type; /* VIRTIO_BALLOON_GCMD_STATS */ >> +struct gcmd_update { >> + __le64 type; /* VIRTIO_BALLOON_GCMD_UPDATE */ > > Hmmm... Update what? Maybe VIRTIO_BALLOON_GCMD_UPDATE_STATS > or VIRTIO_BALLOON_GCMD_UPDATE_STATE? Both are not perfect > but are better then simple update... Yes, it's vague :( >> __le64 need_more; > > I do not think that it is needed if we have a target here. I hope that > host is smart and can make simple comparison with current target. > >> struct virtio_balloon_statistic stats[VIRTIO_BALLOON_S_NR]; >> + __le64 target; Ah, in my proposal this was written by host, not initialized by guest. > Nice but: > - what to do if guest puts here target below current target; > I think that a host should do what is asked for (if it is possible) > - just lower target; Otherwise host should reject target us usual, > - 0 (zero) should be a special value; it should mean that guest > asks for nothing or does not have any preference. We could use it as two way comms like this, in which case your proposal makes sense. Cheers, Rusty.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]