OASIS Virtual I/O Device (VIRTIO) TC

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). 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. Thoughts? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Amit Shah <amit.shah@redhat.com> writes: > 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. I see your point. I wonder how east it is define how much memory the guest has (from a guest perspective). Things like memory holes, device memory maps and I'm sure there is other platform-specific weirdness I'm sure I don't understand. I could be wrong though? Rusty.

On (Wed) 25 Sep 2013 [16:32:51], Rusty Russell wrote: > Amit Shah <amit.shah@redhat.com> writes: > > 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. > > I see your point. I wonder how east it is define how much memory the > guest has (from a guest perspective). Things like memory holes, device > memory maps and I'm sure there is other platform-specific weirdness I'm > sure I don't understand. Right now the driver directly grabs pages from the RAM area. It's a crude approach, but one that we use and works right now. We can continue doing the same... However, I see your point, too. So far, these questions you raise don't get asked by the host either, and the guests just comply with whatever the hosts have asked for (even if it means processes within the guest start to OOM). Amit