All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@arm.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	"andrii_anisov@epam.com" <andrii_anisov@epam.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	oleksandr_tyshchenko@epam.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH for-next 8/9] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call
Date: Thu, 18 Apr 2019 16:09:21 +0100	[thread overview]
Message-ID: <20539440-8014-cd4d-3c95-e88b53bcce32@arm.com> (raw)
In-Reply-To: <20190418114627.GC30543@zion.uk.xensource.com>

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@arm.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	"andrii_anisov@epam.com" <andrii_anisov@epam.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	oleksandr_tyshchenko@epam.com, Jan Beulich <JBeulich@suse.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH for-next 8/9] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call
Date: Thu, 18 Apr 2019 16:09:21 +0100	[thread overview]
Message-ID: <20539440-8014-cd4d-3c95-e88b53bcce32@arm.com> (raw)
Message-ID: <20190418150921.2_NHJp80lPt3uqjF_tNc68vhuxAOHwcC-EAgHM-HdnM@z> (raw)
In-Reply-To: <20190418114627.GC30543@zion.uk.xensource.com>

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2019-04-18 15:09 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-18 11:35 [PATCH for-next 0/9] xen/arm: Properly disable M2P on Arm Julien Grall
2019-02-18 11:35 ` [PATCH for-next 1/9] xen/arm: Use mfn_to_pdx instead of pfn_to_pdx when possible Julien Grall
2019-04-15 21:55   ` Stefano Stabellini
2019-04-15 21:55     ` [Xen-devel] " Stefano Stabellini
2019-04-15 22:03     ` Julien Grall
2019-04-15 22:03       ` [Xen-devel] " Julien Grall
2019-04-15 22:25       ` Stefano Stabellini
2019-04-15 22:25         ` [Xen-devel] " Stefano Stabellini
2019-04-15 22:42         ` Julien Grall
2019-04-15 22:42           ` [Xen-devel] " Julien Grall
2019-04-17 17:07           ` Julien Grall
2019-04-17 17:07             ` [Xen-devel] " Julien Grall
2019-04-25 11:20             ` Jan Beulich
2019-04-25 11:20               ` [Xen-devel] " Jan Beulich
2019-04-29 16:30               ` Julien Grall
2019-04-29 16:30                 ` [Xen-devel] " Julien Grall
2019-02-18 11:35 ` [PATCH for-next 2/9] xen/x86: Constify the parameter "d" in mfn_to_mfn Julien Grall
2019-03-13 14:40   ` Jan Beulich
2019-02-18 11:35 ` [PATCH for-next 3/9] xen/x86: Use mfn_to_gfn rather than mfn_to_gmfn Julien Grall
2019-03-13 14:45   ` Jan Beulich
2019-03-13 15:13     ` Julien Grall
2019-02-18 11:35 ` [PATCH for-next 4/9] xen/grant-table: Make arch specific macros typesafe Julien Grall
2019-03-13 14:51   ` Jan Beulich
2019-04-15 22:03   ` Stefano Stabellini
2019-04-15 22:03     ` [Xen-devel] " Stefano Stabellini
2019-04-15 22:07     ` Julien Grall
2019-04-15 22:07       ` [Xen-devel] " Julien Grall
2019-02-18 11:35 ` [PATCH for-next 5/9] xen: Convert hotplug page function to use typesafe MFN Julien Grall
2019-03-13 14:57   ` Jan Beulich
2019-03-13 16:26     ` Julien Grall
2019-02-18 11:35 ` [PATCH for-next 6/9] xen: Convert is_xen_fixed_mfn " Julien Grall
2019-03-13 14:58   ` Jan Beulich
2019-04-15 22:05   ` Stefano Stabellini
2019-04-15 22:05     ` [Xen-devel] " Stefano Stabellini
2019-02-18 11:35 ` [PATCH for-next 7/9] xen: Convert is_xen_heap_mfn " Julien Grall
2019-03-13 15:04   ` Jan Beulich
2019-03-13 17:24     ` Julien Grall
2019-03-14  7:52       ` Jan Beulich
2019-03-14 10:12         ` Julien Grall
2019-03-14 10:14           ` Andrew Cooper
2019-03-14 10:19             ` Julien Grall
2019-03-14 11:47             ` Jan Beulich
2019-03-14 12:18               ` Andrew Cooper
2019-04-15 22:08   ` Stefano Stabellini
2019-04-15 22:08     ` [Xen-devel] " Stefano Stabellini
2019-02-18 11:35 ` [PATCH for-next 8/9] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call Julien Grall
2019-03-13 15:20   ` Jan Beulich
2019-03-13 17:30     ` Julien Grall
2019-03-14  7:55       ` Jan Beulich
2019-04-17 17:42         ` Julien Grall
2019-04-17 17:42           ` [Xen-devel] " Julien Grall
2019-04-18 11:46           ` Wei Liu
2019-04-18 11:46             ` [Xen-devel] " Wei Liu
2019-04-18 15:09             ` Julien Grall [this message]
2019-04-18 15:09               ` Julien Grall
2019-04-24 15:28               ` Julien Grall
2019-04-24 15:28                 ` [Xen-devel] " Julien Grall
2019-04-25 10:03               ` Wei Liu
2019-04-25 10:03                 ` [Xen-devel] " Wei Liu
2019-04-15 22:17     ` Stefano Stabellini
2019-04-15 22:17       ` [Xen-devel] " Stefano Stabellini
2019-04-25 10:06       ` Jan Beulich
2019-04-25 10:06         ` [Xen-devel] " Jan Beulich
2019-02-18 11:36 ` [PATCH for-next 9/9] xen: Remove mfn_to_gmfn macro Julien Grall
2019-03-13 15:22   ` Jan Beulich
2019-03-13 15:24     ` Julien Grall
2019-03-13 15:40       ` Jan Beulich
2019-03-13 15:48         ` Julien Grall
2019-03-13 15:59           ` Jan Beulich
2019-03-13 17:34             ` Andrew Cooper
2019-03-13 17:42               ` Julien Grall
2019-03-13 18:41                 ` Andrew Cooper
2019-03-14  8:05                   ` Jan Beulich
2019-03-14  7:59               ` Jan Beulich
2019-05-07 14:35     ` Julien Grall
2019-05-07 14:35       ` [Xen-devel] " Julien Grall
2019-04-15 22:19   ` Stefano Stabellini
2019-04-15 22:19     ` [Xen-devel] " Stefano Stabellini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20539440-8014-cd4d-3c95-e88b53bcce32@arm.com \
    --to=julien.grall@arm.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=andrii_anisov@epam.com \
    --cc=konrad.wilk@oracle.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.