[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: XENMAPSPACE_grant_table vs. GNTTABOP_setup_table
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. ~Andrew
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |