[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

On 24/08/2021 07:11, Jan Beulich wrote:
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,

For Arm:

Acked-by: Julien Grall <jgrall@xxxxxxxxxx>

Cheers,

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


--
Julien Grall



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.