Re: [Xen-devel] Xen ballooning interface

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
> Today's interface of Xen for memory ballooning is quite a mess. There
> are some shortcomings which should be addressed somehow. After a
> discussion on IRC there was consensus we should try to design a new
> interface addressing the current and probably future needs.
> 
> Current interface
> -----------------
> A guest has access to the following memory related information (all for
> x86):
> 
> - the memory map (E820 or EFI)
> - ACPI tables for HVM/PVH guests
> - actual maximum size via XENMEM_maximum_reservation hypercall (the
>   hypervisor will deny attempts of the guest to allocate more)
> - current size via XENMEM_current_reservation hypercall
> - Xenstore entry "memory/static-max" for the upper bound of memory size
>   (information for the guest which memory size might be reached without
>   hotplugging memory)
> - Xenstore entry "memory/target" for current target size (used for
>   ballooning: Xen tools set the size the guest should try to reach by
>   allocating or releasing memory)
> 
> The main problem with this interface is the guest doesn't know in all
> cases which memory is included in the values (e.g. memory allocated by
> Xen tools for the firmware of a HVM guest is included in the Xenstore
> and hypercall information, but not in the memory map).
> 

Somewhat related: who has the canonical source of all the information?
I think Xen should have that, but it is unclear to me how toolstack can
get such information from Xen. ISTR currently it is possible to get
current number of pages and maximum numbers of pages, both of which
contain pages for firmware which are visible to guests (E820 / EFI
reserved).

Without that fixed, the new interface won't be of much use because the
information toolstack put in the new nodes is still potentially wrong.
Currently toolstack applies some constant fudge numbers, which is a bit
unpleasant.

It would be at least useful to break down the accounting inside the
hypervisor a bit more:

* max_pages : maximum number of pages a domain can use for whatever
              purpose (ram + firmware + others)
* curr_pages : current number of pages a domain is using (ram + ...)
* max_ram_pages : maximum number of pages a domain can use for ram
* curr_ram_pages : ...
etc etc

IIRC there are current two schools of thought which disagrees with each
other what the "maximum number of pages" in hypervisor means.

This is not saying we can't design new interfaces, it is just that it
wouldn't be very useful IMHO.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel