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

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



On Thu, Apr 18, 2019 at 04:09:21PM +0100, Julien Grall wrote:
> 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.

OK. That seems to be a sensible way forward.

Wei.

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

 


Rackspace

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