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

Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table

  • To: Martin Lucina <martin@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Tue, 9 Jun 2020 11:22:51 +0100
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Delivery-date: Tue, 09 Jun 2020 10:23:08 +0000
  • Ironport-sdr: EOsWrPTebEbtU0to4SChpf/HjOT3LEn6GUXRBVPWbATRtwthm1Jt+84v/uQlmtmaZHspttUBER x2HfHuNr9hwhzcJ6S4r8BRrVeaUvLp6wnec+vOGcaY4TBSgK3ZfHO7vUEyTILH78v1W3PpAsi8 vEgrf7EcBi0Xz73UzIXX/pEjQYmLRu55vS6Po5Z4diTeeOiaoxjMnxtbxyVHjgGLxurArb6hrG JNTjlhYxWCbIWlpZF6wZb0NSrphk0I/191MJtP65ugcQwOr6BxbAgKSk77/ZxQucDVgQ0/hy6t VQw=
  • List-id: Developer list for MirageOS <mirageos-devel.lists.xenproject.org>

On 09/06/2020 10:44, Martin Lucina wrote:
> Hi,
> I've been making progress on bootstrapping a new, PVHv2 only, Xen platform
> stack for MirageOS [1]. The basics are now functional and I have started to
> re-implement the grant table code.
> After studying both the Mini-OS and Linux implementations some, I don't
> understand the difference between using XENMAPSPACE_grant_table vs.
> GNTTABOP_setup_table to set up the initial grant table mapping for the
> guest.
> Are these calls just newer and older ways of accomplishing the same thing?
> The Linux driver seems to use both in various conditions, whereas Mini-OS
> uses the former on ARM and the latter on x86.
> If these are functionally equivalent, then for my purposes I'd rather use
> XENMAPSPACE_setup_table, since IIUC this lets me map the grant table at an
> address of my choosing rather than GNTTABOP_setup_table which at least on
> x86_64 appears to be returning PFNs at the top of the address space.
> Any advice much appreciated,

There is a little bit of history here...

GNTTABOP_setup_table was the original PV way of doing things (specify
size as an input, get a list of frames as an output to map), and
XENMAPSPACE_grant_table was the original HVM way of doing things (as
mapping is the other way around - I specify a GFN which I'd like to turn
into a grant table mapping).

When grant v2 came along, it was only XENMAPSPACE_grant_table updated to
be compatible.  i.e. you have to use XENMAPSPACE_grant_table to map the
status frames even if you used GNTTABOP_setup_table previously.

It is a mistake that GNTTABOP_setup_table was usable in HVM guests to
being with.  Returning -1 is necessary to avoid an information leak (the
physical address of the frames making up the grant table) which an HVM
guest shouldn't, and has no use knowing.

An with that note, ARM is extra special because the grant API is
specified to use host physical addresses rather than guest physical (at
least for dom0, for reasons of there generally not being an IOMMU),
which is why it does use the old PV way.

It is all a bit of a mess.




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