Re: [Xen-devel] [PATCH for-next 8/9] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call

[Julien Grall <julien.grall@xxxxxxx>]

Hi,

On 18/04/2019 12:46, Wei Liu wrote:
> On Wed, Apr 17, 2019 at 06:42:47PM +0100, Julien Grall wrote:
> > Hi,
> >
> > @Wei, @Ian: Do you have any input?
> Sorry I haven't been following this closely, but shouldn't we fix the
> interface to return gfn instead? And then the mapping of it should
> interpret the value properly per guest type.
We already return a GFN today. The problem is we only hold an MFN at that time.

At the moment, we rely on the M2P to find the corresponding GFN. As we don't 
have an M2P on Arm, we would have to store the associated GFN.
But all this logic is a bit broken. It relies on the toolstack (or the guest) to 
have mapped the shared info frame in the P2M using the physmap hypervisor with 
XENMAPSPACE_shared_info beforehand. This is also racy as you may return a GFN 
that was unmapped/remapped to something else before the toolstack has a chance 
to map in its address space the page.
The correct solution would be to phase out the field shared_info_frame and use 
XENMEM_acquire_resource instead. However, this requires the associated ioctl to 
be implemented in Linux.
> I don't see immediately how user space program will need to access this
> page for autotranslated guests though.
If there are no use, then I am not convinced it is worth trying to make 
shared_info_frame working on Arm.
Cheers,

--
Julien Grall

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