From: Julien Grall <julien.grall@arm.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.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,
xen-devel <xen-devel@lists.xenproject.org>,
"andrii_anisov@epam.com" <andrii_anisov@epam.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call
Date: Wed, 22 May 2019 17:03:14 +0100 [thread overview]
Message-ID: <e5141755-d677-184b-765a-2d67f80320cf@arm.com> (raw)
In-Reply-To: <16cea000-3b02-08f6-4b0e-2df1024ed245@arm.com>
Hi,
Answering to myself.
On 10/05/2019 15:34, Julien Grall wrote:
> On 10/05/2019 15:19, Jan Beulich wrote:
>>>>> On 10.05.19 at 16:04, <julien.grall@arm.com> wrote:
>>> On 10/05/2019 14:45, Jan Beulich wrote:
>>>>>>> On 10.05.19 at 15:41, <julien.grall@arm.com> wrote:
>>>>> The point here, we keep within the hypervisor the idea of what's valid or
>>>>> invalid. This allows us more flexibility on the value here (imagine we
>>>>> decide to
>>>>> change the value of GFN_INVALID in the future...).
>>>>
>>>> Exactly, and hence INVALID_GFN should not become visible to the
>>>> outside. Hence my request to use an all-ones value here.
>>> It is only visible if you put an exact value in the documentation. Your
>>> suggestion is to put a exactly value and I would rather not see that.
>>
>> I did specifically suggest to _not_ store INVALID_GFN here, but to
>> store 64-bit bits of ones. Note the difference between the two on
>> 32-bit Arm.
> Your point of having an exact value is only useful if you want to toolstack to
> silently ignore the missing frame and avoid a call.
>
> The former is pretty much wrong as if you were trying to read the frame then
> most likely you wanted to access it. So a message makes sense here.
>
> For the latter, avoiding the call is only going to save you a couple of cycles
> in a likely cold path.
>
> You really don't need to give an exact (including say all ones). You only need
> to say that the address return may not be mappable. The toolstack will try to
> map it and fail. That's not a big deal.
>
> Anyway, I will wait and see what's the view from the tools maintainer.
I had a discussion with Ian on IRC regarding the value here. After some debate
we agreed that specifying a single value would be best.
At the moment, Xen only supports 48-bits address that could be covered by 36-bit
MFN. Newer Arm revision supports up to 52-bit address, but that's only with 64KB
page granularity. Even if we were supporting 64-bit address, it would only cover
48-bit, so all ones should still be invalid. So I am happy with the all ones
version.
I will introduce a define so the tools can use it rather than an hardcoded value.
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: Jan Beulich <JBeulich@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.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,
xen-devel <xen-devel@lists.xenproject.org>,
"andrii_anisov@epam.com" <andrii_anisov@epam.com>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call
Date: Wed, 22 May 2019 17:03:14 +0100 [thread overview]
Message-ID: <e5141755-d677-184b-765a-2d67f80320cf@arm.com> (raw)
Message-ID: <20190522160314.33R2EyaH8AosX_veKDD03kRmvxDawd50Dp4NXx8OPLg@z> (raw)
In-Reply-To: <16cea000-3b02-08f6-4b0e-2df1024ed245@arm.com>
Hi,
Answering to myself.
On 10/05/2019 15:34, Julien Grall wrote:
> On 10/05/2019 15:19, Jan Beulich wrote:
>>>>> On 10.05.19 at 16:04, <julien.grall@arm.com> wrote:
>>> On 10/05/2019 14:45, Jan Beulich wrote:
>>>>>>> On 10.05.19 at 15:41, <julien.grall@arm.com> wrote:
>>>>> The point here, we keep within the hypervisor the idea of what's valid or
>>>>> invalid. This allows us more flexibility on the value here (imagine we
>>>>> decide to
>>>>> change the value of GFN_INVALID in the future...).
>>>>
>>>> Exactly, and hence INVALID_GFN should not become visible to the
>>>> outside. Hence my request to use an all-ones value here.
>>> It is only visible if you put an exact value in the documentation. Your
>>> suggestion is to put a exactly value and I would rather not see that.
>>
>> I did specifically suggest to _not_ store INVALID_GFN here, but to
>> store 64-bit bits of ones. Note the difference between the two on
>> 32-bit Arm.
> Your point of having an exact value is only useful if you want to toolstack to
> silently ignore the missing frame and avoid a call.
>
> The former is pretty much wrong as if you were trying to read the frame then
> most likely you wanted to access it. So a message makes sense here.
>
> For the latter, avoiding the call is only going to save you a couple of cycles
> in a likely cold path.
>
> You really don't need to give an exact (including say all ones). You only need
> to say that the address return may not be mappable. The toolstack will try to
> map it and fail. That's not a big deal.
>
> Anyway, I will wait and see what's the view from the tools maintainer.
I had a discussion with Ian on IRC regarding the value here. After some debate
we agreed that specifying a single value would be best.
At the moment, Xen only supports 48-bits address that could be covered by 36-bit
MFN. Newer Arm revision supports up to 52-bit address, but that's only with 64KB
page granularity. Even if we were supporting 64-bit address, it would only cover
48-bit, so all ones should still be invalid. So I am happy with the all ones
version.
I will introduce a define so the tools can use it rather than an hardcoded value.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-22 16:03 UTC|newest]
Thread overview: 154+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-07 15:14 [PATCH 00/14] xen/arm: Properly disable M2P on Arm Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 01/14] xen/arm: Use mfn_to_pdx instead of pfn_to_pdx when possible Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-09 17:50 ` Stefano Stabellini
2019-05-09 17:50 ` [Xen-devel] " Stefano Stabellini
2019-05-07 15:14 ` [PATCH 02/14] xen/x86: Constify the parameter "d" in mfn_to_gfn Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 03/14] xen/x86: Make mfn_to_gfn typesafe Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-10 11:35 ` Jan Beulich
2019-05-10 11:35 ` [Xen-devel] " Jan Beulich
2019-05-10 13:02 ` Julien Grall
2019-05-10 13:02 ` [Xen-devel] " Julien Grall
2019-05-10 13:24 ` Jan Beulich
2019-05-10 13:24 ` [Xen-devel] " Jan Beulich
2019-05-10 13:25 ` Julien Grall
2019-05-10 13:25 ` [Xen-devel] " Julien Grall
2019-05-20 15:13 ` Julien Grall
2019-05-20 15:13 ` [Xen-devel] " Julien Grall
2019-05-28 17:29 ` George Dunlap
2019-05-28 17:29 ` [Xen-devel] " George Dunlap
2019-05-29 11:39 ` Julien Grall
2019-05-29 11:39 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 04/14] xen/x86: Use mfn_to_gfn rather than mfn_to_gmfn Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-10 12:15 ` Jan Beulich
2019-05-10 12:15 ` [Xen-devel] " Jan Beulich
2019-05-10 13:07 ` Julien Grall
2019-05-10 13:07 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 05/14] xen/grant-table: Make arch specific macros typesafe Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-09 17:54 ` Stefano Stabellini
2019-05-09 17:54 ` [Xen-devel] " Stefano Stabellini
2019-05-07 15:14 ` [PATCH 06/14] xen: Convert hotplug page function to use typesafe MFN Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-09 18:01 ` Stefano Stabellini
2019-05-09 18:01 ` [Xen-devel] " Stefano Stabellini
2019-05-09 18:10 ` Julien Grall
2019-05-09 18:10 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 07/14] xen: Convert is_xen_fixed_mfn " Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-24 15:16 ` George Dunlap
2019-05-24 15:16 ` [Xen-devel] " George Dunlap
2019-05-07 15:14 ` [PATCH 08/14] xen: Convert is_xen_heap_mfn " Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-24 15:15 ` George Dunlap
2019-05-24 15:15 ` [Xen-devel] " George Dunlap
2019-05-07 15:14 ` [PATCH 09/14] xen: Introduce HAS_M2P config and use to protect mfn_to_gmfn call Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-09 18:06 ` Stefano Stabellini
2019-05-09 18:06 ` [Xen-devel] " Stefano Stabellini
2019-05-09 18:12 ` Julien Grall
2019-05-09 18:12 ` [Xen-devel] " Julien Grall
2019-05-09 18:16 ` Stefano Stabellini
2019-05-09 18:16 ` [Xen-devel] " Stefano Stabellini
2019-05-09 18:29 ` Julien Grall
2019-05-09 18:29 ` [Xen-devel] " Julien Grall
2019-05-09 19:49 ` Stefano Stabellini
2019-05-09 19:49 ` [Xen-devel] " Stefano Stabellini
2019-05-10 12:31 ` Jan Beulich
2019-05-10 12:31 ` [Xen-devel] " Jan Beulich
2019-05-10 13:22 ` Julien Grall
2019-05-10 13:22 ` [Xen-devel] " Julien Grall
2019-05-10 13:32 ` Jan Beulich
2019-05-10 13:32 ` [Xen-devel] " Jan Beulich
2019-05-10 13:41 ` Julien Grall
2019-05-10 13:41 ` [Xen-devel] " Julien Grall
2019-05-10 13:45 ` Jan Beulich
2019-05-10 13:45 ` [Xen-devel] " Jan Beulich
2019-05-10 14:04 ` Julien Grall
2019-05-10 14:04 ` [Xen-devel] " Julien Grall
2019-05-10 14:19 ` Jan Beulich
2019-05-10 14:19 ` [Xen-devel] " Jan Beulich
2019-05-10 14:34 ` Julien Grall
2019-05-10 14:34 ` [Xen-devel] " Julien Grall
2019-05-22 16:03 ` Julien Grall [this message]
2019-05-22 16:03 ` Julien Grall
2019-05-07 15:14 ` [PATCH 10/14] xen: Remove mfn_to_gmfn macro Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 11/14] xen/x86: mm: Re-implement set_gpfn_from_mfn() as a static inline function Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-10 12:43 ` Jan Beulich
2019-05-10 12:43 ` [Xen-devel] " Jan Beulich
2019-05-10 13:27 ` Julien Grall
2019-05-10 13:27 ` [Xen-devel] " Julien Grall
2019-05-10 13:35 ` Jan Beulich
2019-05-10 13:35 ` [Xen-devel] " Jan Beulich
2019-05-10 13:41 ` Julien Grall
2019-05-10 13:41 ` [Xen-devel] " Julien Grall
2019-05-10 13:48 ` Jan Beulich
2019-05-10 13:48 ` [Xen-devel] " Jan Beulich
2019-05-10 14:05 ` Julien Grall
2019-05-10 14:05 ` [Xen-devel] " Julien Grall
2019-05-10 14:21 ` Jan Beulich
2019-05-10 14:21 ` [Xen-devel] " Jan Beulich
2019-05-10 14:48 ` Julien Grall
2019-05-10 14:48 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 12/14] xen/x86: pv: Convert update_intpte() to use typesafe MFN Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-10 12:54 ` Jan Beulich
2019-05-10 12:54 ` [Xen-devel] " Jan Beulich
2019-05-10 13:28 ` Julien Grall
2019-05-10 13:28 ` [Xen-devel] " Julien Grall
2019-05-07 15:14 ` [PATCH 13/14] xen/mm: Convert {s, g}et_gpfn_from_mfn() " Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-07 20:27 ` Tamas K Lengyel
2019-05-07 20:27 ` [Xen-devel] " Tamas K Lengyel
2019-05-09 18:19 ` Stefano Stabellini
2019-05-09 18:19 ` [Xen-devel] " Stefano Stabellini
2019-05-10 13:21 ` Jan Beulich
2019-05-10 13:21 ` [Xen-devel] " Jan Beulich
2019-05-10 13:27 ` Andrew Cooper
2019-05-10 13:27 ` [Xen-devel] " Andrew Cooper
2019-05-10 13:34 ` Julien Grall
2019-05-10 13:34 ` [Xen-devel] " Julien Grall
2019-05-10 13:41 ` Jan Beulich
2019-05-10 13:41 ` [Xen-devel] " Jan Beulich
2019-05-10 13:46 ` Julien Grall
2019-05-10 13:46 ` [Xen-devel] " Julien Grall
2019-05-10 14:02 ` Jan Beulich
2019-05-10 14:02 ` [Xen-devel] " Jan Beulich
2019-05-10 14:05 ` Andrew Cooper
2019-05-10 14:05 ` [Xen-devel] " Andrew Cooper
2019-05-10 14:08 ` Julien Grall
2019-05-10 14:08 ` [Xen-devel] " Julien Grall
2019-05-10 14:09 ` Andrew Cooper
2019-05-10 14:09 ` [Xen-devel] " Andrew Cooper
2019-05-10 14:14 ` Jan Beulich
2019-05-10 14:14 ` [Xen-devel] " Jan Beulich
2019-05-10 14:27 ` Andrew Cooper
2019-05-10 14:27 ` [Xen-devel] " Andrew Cooper
2019-05-24 16:24 ` George Dunlap
2019-05-24 16:24 ` [Xen-devel] " George Dunlap
2019-05-29 16:27 ` Julien Grall
2019-05-29 16:27 ` [Xen-devel] " Julien Grall
2019-05-29 16:29 ` George Dunlap
2019-05-29 16:29 ` [Xen-devel] " George Dunlap
2019-05-24 16:35 ` George Dunlap
2019-05-24 16:35 ` [Xen-devel] " George Dunlap
2019-05-07 15:14 ` [PATCH 14/14] xen/mm: Provide dummy M2P-related helpers when !CONFIG_HAVE_M2P Julien Grall
2019-05-07 15:14 ` [Xen-devel] " Julien Grall
2019-05-09 18:20 ` Stefano Stabellini
2019-05-09 18:20 ` [Xen-devel] " Stefano Stabellini
2019-05-10 13:28 ` Jan Beulich
2019-05-10 13:28 ` [Xen-devel] " Jan Beulich
2019-05-10 13:29 ` Julien Grall
2019-05-10 13:29 ` [Xen-devel] " Julien Grall
2019-05-10 13:37 ` Jan Beulich
2019-05-10 13:37 ` [Xen-devel] " Jan Beulich
2019-05-10 13:38 ` Julien Grall
2019-05-10 13:38 ` [Xen-devel] " Julien Grall
2019-05-24 16:51 ` George Dunlap
2019-05-24 16:51 ` [Xen-devel] " George Dunlap
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=e5141755-d677-184b-765a-2d67f80320cf@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).