Re: [Xen-devel] [XEN PATCH for-4.13 v7 05/11] libxl: Move shadow_memkb and iommu_memkb defaulting into libxl

[Jürgen Groß <jgross@xxxxxxxx>]

On 23.10.19 15:00, Ian Jackson wrote:
> Defaulting is supposed to be done by libxl.  So these calculations
> should be here in libxl.  libxl__domain_config_setdefault has all the
> necessary information including the values of max_memkb and max_vcpus.
>
> The overall functional effect depends on the caller:
>
> For xl, no change.  The code moves from xl to libxl.
>
> For callers who set one or both shadow_memkb and iommu_memkb (whether
> from libxl_get_required_shadow_memory or otherwise) before calling
> libxl_domain_need_memory (any version): the new code will leave their
> setting(s) unchanged.
>
> For callers who do not call libxl_domain_need_memory at all, and who
> fail to set one of these memory values: now they are both are properly
> set.  The shadow and iommu memory to be properly accounted for as
> intended.
>
> For callers which call libxl_domain_need_memory and request the
> current API (4.13) or which track libxl, the default values are also
> now right and everything works as intended.
>
> For callers which call libxl_domain_need_memory, and request an old
> pre-4.13 libxl API, and which leave one of these memkb settings unset,
> we take special measures to preserve the old behaviour.
>
> This means that they don't get the additional iommu memory and are at
> risk of the domain running out of memory as a result of f89f555827a6
> "remove late (on-demand) construction of IOMMU page tables".  But this
> is no worse than the state just after f89f555827a6, which already
> broke such callers in that way.  This is perhaps justifiable because
> of the API stability warning next to libxl_domain_need_memory.
>
> An alternative would be to drop the special-casing of these callers.
> That would cause a discrepancy between libxl_domain_need_memory and
> libxl_domain_create: the former would not include the iommu memory and
> the latter would.  That seems worse, but it's debateable.
>
> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Reviewed-by: Anthony PERARD <anthony.perard@xxxxxxxxxx>
Release-acked-by: Juergen Gross <jgross@xxxxxxxx>


Juergen


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