On 14/08/18 09:34, Jan Beulich wrote: >>>> On 14.08.18 at 09:19, <jgr...@suse.com> wrote: >> On 14/08/18 09:02, Jan Beulich wrote: >>>>>> On 13.08.18 at 17:44, <jgr...@suse.com> wrote: >>>> On 13/08/18 17:29, Jan Beulich wrote: >>>>>>>> On 13.08.18 at 16:20, <jgr...@suse.com> wrote: >>>>>> On 13/08/18 15:54, Jan Beulich wrote: >>>>>>>>>> On 13.08.18 at 15:06, <jgr...@suse.com> 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). >>>> >>>> With vNUMA there is a current value of memory per node supplied by the >>>> tools and a maximum per node can be caclulated the same way. >>> >>> Can it? If so, I must be overlooking some accounting done >>> somewhere. I'm only aware of a global maximum. >> >> The tools set the vnuma information for the guest. How do they do this >> without knowing the memory size per vnuma node? > > That's the current (initial) size, not the maximum.
Which is the same in the current implementation: libxl__vnuma_config_check() will fail if the memory of all vnuma nodes won't sum up to the max memory of the domain. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
