OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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

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 */
> 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.  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]