Re: [Xen-devel] Xen ballooning interface

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.08.18 at 16:20, <jgross@xxxxxxxx> wrote:
> On 13/08/18 15:54, Jan Beulich wrote:
>>>>> On 13.08.18 at 15:06, <jgross@xxxxxxxx> wrote:
>>> Suggested new interface
>>> -----------------------
>>> Hypercalls, memory map(s) and ACPI tables should stay the same (for
>>> compatibility reasons or because they are architectural interfaces).
>>>
>>> As the main confusion in the current interface is related to the
>>> specification of the target memory size this part of the interface
>>> should be changed: specifying the size of the ballooned area instead
>>> is much clearer and will be the same for all guest types (no firmware
>>> memory or magic additions involved).
>> 
>> But isn't this backwards? The balloon size is a piece of information
>> internal to the guest. Why should the outside world know or care?
> 
> Instead of specifying an absolute value to reach you'd specify how much
> memory the guest should stay below its maximum. I think this is a valid
> approach.

But with you vNUMA model there's no single such value, and nothing
like a "maximum" (which would need to be per virtual node afaics).

>>> Any further thoughts on this?
>> 
>> The other problem we've always had was that address information
>> could not be conveyed to the driver. The worst example in the past
>> was that 32-bit PV domains can't run on arbitrarily high underlying
>> physical addresses, but of course there are other cases where
>> memory below a certain boundary may be needed. The obvious
>> problem with directly exposing address information through the
>> interface is that for HVM guests machine addresses are meaningless.
>> Hence I wonder whether a dedicated "balloon out this page if you
>> can" mechanism would be something to consider.
> 
> Isn't this a problem orthogonal to the one we are discussing here?

Yes, but I think we shouldn't design a new interface without
considering all current shortcomings.

> I'd rather do a localhost guest migration to free specific pages a
> guest is owning and tell the Xen memory allocator not to hand them
> out to the new guest created by the migration.

There may not be enough memory to do a localhost migration.
Ballooning, after all, may be done just because of a memory
shortage.

Jan



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