Re: [virtio] [OASIS Issue Tracker] Created: (VIRTIO-28) Implement new balloon device (ID 13)

[Amit Shah <amit.shah@redhat.com>]

On (Wed) 11 Sep 2013 [04:51:39], OASIS Issues Tracker wrote:
> Implement new balloon device (ID 13)
> ------------------------------------
> 
>                  Key: VIRTIO-28
>                  URL: http://tools.oasis-open.org/issues/browse/VIRTIO-28
>              Project: OASIS Virtual I/O Device (VIRTIO) TC
>           Issue Type: New Feature
>             Reporter: Rusty Russell
> 
> 
> The current virtio balloon device is bad enough that fixing it yields something completely incompatible:
> 1) The page size is 4096, always, rather than some configurable page size.
> 2) Page numbers are 32 bits.
> 3) The deflate queue is not actually used by any device implementation (see issue virtio-25).
> 4) The "actual" number is kind of useless, and (along with the deflate queue) requires the guest to track pages, rather than just faulting them in.
> 5) The config is little-endian by mistake (may not matter).

The current design is weird: the host tells the guest the offset by
which to inflate or deflate the balloon.  Instead, the host should let
the guest know how much in absolute terms the memory should be
adjusted to, and the guest will take the decision on whether to
inflate, or deflate, or not take any action at all.

For example, with the current scenario, if a guest is started with 4G
memory, but the guest kernel is started with 'mem=2G', the guest is
only going to use 2G of memory.  ballooning to 3G from the host will
try to inflate the balloon by 1G on the guest, when really no action
is needed.

This also happens with > 4G RAM and 32-bit guests.

> We could just move the entire thing to legacy, and have a new balloon device, like:
> 1) An incoming queue for balloon size updates or stats request.
> 2) An outgoing queue for giving 64 bit address/length pairs to balloon, answering stats.
> 3) No config space, no features.

ACK

		Amit