Re: [virtio-dev] Re: Straw linux/lguest implementation of new "memballoon"

[Rusty Russell <rusty@au1.ibm.com>]

Amit Shah <amit.shah@redhat.com> writes:
> On (Wed) 28 May 2014 [17:09:16], Rusty Russell wrote:
>> You're right.  I've deleted that sentence; we need to have a discussion
>> on whether stats are actually valuable as they are today.
>
> What would a guest admin allow a host admin to know?
> 1. How much memory the guest was started with
> 2. Did the guest ask for extra pages (negative balloon)
> 3. What is the size of the current balloon

Well, the host knows all these things.

> In addition, a host admin would like to know (well, it'd like to know
> a lot more, but being realistic):
> 4. Did the guest refuse to give it memory when asked?  How many times?
> 5. Did the guest voluntarily give up memory when not asked for (min
>    going beyond the min balloon)

It knows this, too.

The legacy ballon stats interface published stats about the guest VM,
such as:

#define VIRTIO_BALLOON_S_SWAP_IN  0   /* Amount of memory swapped in */
#define VIRTIO_BALLOON_S_SWAP_OUT 1   /* Amount of memory swapped out */
#define VIRTIO_BALLOON_S_MAJFLT   2   /* Number of major faults */
#define VIRTIO_BALLOON_S_MINFLT   3   /* Number of minor faults */
#define VIRTIO_BALLOON_S_MEMFREE  4   /* Total amount of free memory */
#define VIRTIO_BALLOON_S_MEMTOT   5   /* Total amount of memory */

With the guest controlling the balloon, it's not clear these are needed.

>> > Also, if a device gives control of 2 out of 5 requested pages, which
>> > pages were the ones the device gave back?
>> 
>> The first two.
>
> Should this be explicit?  I think so.

Yes:

diff --git a/content.tex b/content.tex
index e7c64b2..745a29e 100644
--- a/content.tex
+++ b/content.tex
@@ -5179,10 +5179,24 @@ it didn't put in).
 \item The driver constructs a buffer of le64 values.  The first is
   device-readable VIRTIO_MEMBALLOON_GCMD_GET_PAGES, followed by one
   or more device-readable 64-bit page addresses of pages it wants,
-  followed by a final device-writabe 64-bit value.
+  followed by a final device-writable 64-bit value.
+\begin{note}
+  For example, if the driver were to ask for 3 pages back, at
+  addresses 0x1000, 0x2000 and 0x3000, the request would contain 5 64-bit
+  values (4 device-readable followed by 1 device-writable):
+  \begin{lstlisting}
+    0 0x1000 0x2000 0x3000 0
+  \end{lstlisting}
+\end{note}
 \item The driver places the buffer into the todevq and notifies the device.
-\item When the device has finished with the buffer, the final 64-bit value
-  indicates the number of pages which were successfully obtained.
+\item When the device has finished with the buffer, the final 64-bit
+  value indicates the number of pages (in requested order) which were
+  successfully obtained.
+\begin{note}
+  To continue the previous example, if the device could only return 2
+  pages, it would return the pages 0x1000 and 0x2000 and write ``2''
+  in the final field.
+\end{note}
 \end{enumerate}
 
 \subsubsection{Exchanging Pages With The Balloon}\label{sec:Device Types / Memory Balloon Device / Device Operation / Exchanging Pages With The Balloon}

Cheers,
Rusty.