Re: [PATCH v3 1/4] public: Add page related definitions for accessing guests memory

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.08.2021 19:02, Costin Lupu wrote:
> These changes introduce the page related definitions needed for mapping and
> accessing guests memory. These values are intended to be used by any toolstack
> component that needs to map guests memory. Until now, the values were defined
> by the xenctrl.h header, therefore whenever a component had to use them it 
> also
> had to add a dependency for the xenctrl library.
> 
> This patch also introduces xen_mk_long() macrodefinition for defining long
> constants both for C and assembler code.
> 
> Signed-off-by: Costin Lupu <costin.lupu@xxxxxxxxx>

x86 part:
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

This extends to the common parts only if the Arm side gets an ack,
since - as said before - there you're treating use of one unstable
interface (libxc) for another (the ABI) in supposedly stable
libraries, or - if the ABI is to be stable despite being exposed
to the tool stack only - you make it impossible to make the page
size variable down the road.

Just yesterday we've been (internally) talking about the similar
"maximum vCPU-s" aspect: This shouldn't be taken directly from the
ABI by tool stacks, as imo we ought to allow the upper bounds to
be configurable in the hypervisor (with the present limits merely
becoming limits of what can be configured). This would similarly
require a library function (or two, as HVM and PV limits are
likely different). I wonder whether we shouldn't have a stable
library providing functions to retrieve such limits. Initially the
library would return constants, short of the hypervisor providing
the needed data.

Jan