[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



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

 


Rackspace

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