All of lore.kernel.org
 help / color / mirror / Atom feed
From: George Dunlap <george.dunlap@citrix.com>
To: Julien Grall <julien.grall@linaro.org>, xen-devel@lists.xenproject.org
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>, Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	Ian Jackson <ian.jackson@citrix.com>
Subject: Re: [PATCH 06/16] SUPPORT.md: Add scalability features
Date: Tue, 21 Nov 2017 17:51:05 +0000	[thread overview]
Message-ID: <b3962a5d-e782-e261-4f87-8628c1839c00@citrix.com> (raw)
In-Reply-To: <41b48214-30b1-3396-2613-ffc48df27739@linaro.org>

On 11/21/2017 05:31 PM, Julien Grall wrote:
> Hi George,
> 
> On 11/21/2017 04:43 PM, George Dunlap wrote:
>> On 11/16/2017 03:19 PM, Julien Grall wrote:
>>> On 13/11/17 15:41, George Dunlap wrote:
>>>> Signed-off-by: George Dunlap <george.dunlap@citrix.com>
>>>> ---
>>>> CC: Ian Jackson <ian.jackson@citrix.com>
>>>> CC: Wei Liu <wei.liu2@citrix.com>
>>>> CC: Andrew Cooper <andrew.cooper3@citrix.com>
>>>> CC: Jan Beulich <jbeulich@suse.com>
>>>> CC: Stefano Stabellini <sstabellini@kernel.org>
>>>> CC: Konrad Wilk <konrad.wilk@oracle.com>
>>>> CC: Tim Deegan <tim@xen.org>
>>>> CC: Julien Grall <julien.grall@arm.com>
>>>> ---
>>>>    SUPPORT.md | 21 +++++++++++++++++++++
>>>>    1 file changed, 21 insertions(+)
>>>>
>>>> diff --git a/SUPPORT.md b/SUPPORT.md
>>>> index c884fac7f5..a8c56d13dd 100644
>>>> --- a/SUPPORT.md
>>>> +++ b/SUPPORT.md
>>>> @@ -195,6 +195,27 @@ on embedded platforms.
>>>>      Enables NUMA aware scheduling in Xen
>>>>    +## Scalability
>>>> +
>>>> +### 1GB/2MB super page support
>>>> +
>>>> +    Status, x86 HVM/PVH: : Supported
>>>> +    Status, ARM: Supported
>>>> +
>>>> +NB that this refers to the ability of guests
>>>> +to have higher-level page table entries point directly to memory,
>>>> +improving TLB performance.
>>>> +This is independent of the ARM "page granularity" feature (see below).
>>>
>>> I am not entirely sure about this paragraph for Arm. I understood this
>>> section as support for stage-2 page-table (aka EPT on x86) but the
>>> paragraph lead me to believe to it is for guest.
>>>
>>> The size of super pages of guests will depend on the page granularity
>>> used by itself and the format of the page-table (e.g LPAE vs short
>>> descriptor). We have no control on that.
>>>
>>> What we have control is the size of mapping used for stage-2 page-table.
>>
>> Stepping back from the document for a minute: would it make sense to use
>> "hardware assisted paging" (HAP) for Intel EPT, AMD RVI (previously
>> NPT), and ARM stage-2 pagetables?  HAP was already a general term used
>> to describe the two x86 technologies; and I think the description makes
>> sense, because if we didn't have hardware-assisted stage 2 pagetables
>> we'd need Xen-provided shadow pagetables.
> 
> I think using the term "hardware assisted paging" should be fine to
> refer the 3 technologies.

OK, great.

[snip]

> Short-descriptor is always using 4KB granularity supports 16MB, 1MB, 64KB
> 
> LPAE supports 4KB, 16KB, 64KB granularities. Each of them having
> different size of superpage.

Yes, that's why I started saying "L2 and L3 superpages", to mean
"Superpage entries in L2 or L3 pagetables", instead of 2MiB or 1GiB.
(Let me know if you can think of a better way to describe that.)

>> 3. Whether Xen provides the *interface* for a guest to use L2 or L3
>> superpages (for 4k page granularity, 2MiB or 1GiB respectively) in its
>> own pagetables.  I *think* HAP on x86 provides the interface whenever
>> the underlying hardware does.  I assume it's the same for ARM?  In the
>> case of shadow mode, we only provide the interface for 2MiB pagetables.
> 
> See above. We have no way to control that in the guest.

We don't control whether the guest uses *any* features.  Should we not
mention PV disks or SMMUv2 or whatever because we don't know if the
guest will use them?

Of course not.  This document describes whether the guest *has the
features available to use*, either provided by the hardware or emulated
by Xen.

It sounds like you may not have ever thought about whether an ARM guest
has L2 or L3 superpages available, because it's always had all of them;
but it's different on x86.

[snip]

>> 2. Whether Xen uses superpage mappings for HAP.  Xen uses this on x86
>> when hardware support is -- I take it Xen does this on ARM as well?
>
> The size of superpages supported will depend on the page-table format
> (short-descriptor vs LPAE) and the granularity used.
>
> Supersection (16MB) for short-descriptor is optional but mandatory when
> the processor support LPAE. LPAE is mandatory with virtualization. So
> all size of superpages are supported.
>
> Note that stage-2 page-tables can only use LPAE page-table.
>
> I would also rather avoid to mention any superpage size for Arm in
> SUPPORT.MD as there are a lot.

So it sounds like basically everything supported on native was supported
in virtualization (and under Xen) from the start, so it's probably less
important to mention.  But since we *will* need to do that for x86, we
probably need to say *something* in case people want to know.

Let me see what I can come up with.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

  reply	other threads:[~2017-11-21 17:51 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-13 15:41 [PATCH 01/16] Introduce skeleton SUPPORT.md George Dunlap
2017-11-13 15:41 ` [PATCH 02/16] SUPPORT.md: Add core functionality George Dunlap
2017-11-21  8:03   ` Jan Beulich
2017-11-21 10:36     ` George Dunlap
2017-11-21 11:34       ` Jan Beulich
2017-11-13 15:41 ` [PATCH 03/16] SUPPORT.md: Add some x86 features George Dunlap
2017-11-21  8:09   ` Jan Beulich
2017-11-21 10:42     ` George Dunlap
2017-11-21 11:35       ` Jan Beulich
2017-11-21 12:24         ` George Dunlap
2017-11-21 13:00           ` Jan Beulich
2017-11-21 12:32         ` Ian Jackson
2017-11-13 15:41 ` [PATCH 04/16] SUPPORT.md: Add core ARM features George Dunlap
2017-11-21  8:11   ` Jan Beulich
2017-11-21 10:45     ` George Dunlap
2017-11-21 10:59       ` Julien Grall
2017-11-21 11:37       ` Jan Beulich
2017-11-21 12:39         ` George Dunlap
2017-11-21 13:01           ` Jan Beulich
2017-11-13 15:41 ` [PATCH 05/16] SUPPORT.md: Toolstack core George Dunlap
2017-11-13 15:41 ` [PATCH 06/16] SUPPORT.md: Add scalability features George Dunlap
2017-11-16 15:19   ` Julien Grall
2017-11-16 15:30     ` George Dunlap
2017-11-21 16:43     ` George Dunlap
2017-11-21 17:31       ` Julien Grall
2017-11-21 17:51         ` George Dunlap [this message]
2017-11-21  8:16   ` Jan Beulich
2017-11-13 15:41 ` [PATCH 07/16] SUPPORT.md: Add virtual devices common to ARM and x86 George Dunlap
2017-11-21  8:29   ` Jan Beulich
2017-11-21  9:19     ` Paul Durrant
2017-11-21 10:56     ` George Dunlap
2017-11-21 11:41       ` Jan Beulich
2017-11-21 17:20         ` George Dunlap
2017-11-22 11:05           ` Jan Beulich
2017-11-22 16:16             ` George Dunlap
2017-11-21 17:35     ` George Dunlap
2017-11-22 11:07       ` Jan Beulich
2017-11-13 15:41 ` [PATCH 08/16] SUPPORT.md: Add x86-specific virtual hardware George Dunlap
2017-11-21  8:39   ` Jan Beulich
2017-11-21 18:02     ` George Dunlap
2017-11-22 11:11       ` Jan Beulich
2017-11-22 11:21         ` George Dunlap
2017-11-22 11:45         ` George Dunlap
2017-11-22 16:30         ` George Dunlap
2017-11-13 15:41 ` [PATCH 09/16] SUPPORT.md: Add ARM-specific " George Dunlap
2017-11-16 15:41   ` Julien Grall
2017-11-22 16:32     ` George Dunlap
2017-11-16 15:41   ` Julien Grall
2017-11-13 15:41 ` [PATCH 10/16] SUPPORT.md: Add Debugging, analysis, crash post-portem George Dunlap
2017-11-21  8:48   ` Jan Beulich
2017-11-21 18:19     ` George Dunlap
2017-11-21 19:05       ` Ian Jackson
2017-11-21 19:21         ` Andrew Cooper
2017-11-22 10:51           ` George Dunlap
2017-11-22 11:15       ` Jan Beulich
2017-11-22 17:06         ` George Dunlap
2017-11-13 15:41 ` [PATCH 11/16] SUPPORT.md: Add 'easy' HA / FT features George Dunlap
2017-11-21  8:49   ` Jan Beulich
2017-11-13 15:41 ` [PATCH 12/16] SUPPORT.md: Add Security-releated features George Dunlap
2017-11-16 16:23   ` Konrad Rzeszutek Wilk
2017-11-21  8:52   ` Jan Beulich
2017-11-22 17:13     ` George Dunlap
2017-11-23 10:13       ` Jan Beulich
2017-11-13 15:41 ` [PATCH 13/16] SUPPORT.md: Add secondary memory management features George Dunlap
2017-11-21  8:54   ` Jan Beulich
2017-11-21 19:55   ` Andrew Cooper
2017-11-22 17:15     ` George Dunlap
2017-11-23 10:35       ` Jan Beulich
2017-11-23 10:42         ` Olaf Hering
2017-11-23 11:55           ` Olaf Hering
2017-11-23 12:00             ` George Dunlap
2017-11-23 12:17               ` Andrew Cooper
2017-11-23 12:45                 ` Olaf Hering
2017-11-23 12:58                   ` Andrew Cooper
2017-11-23 17:58                     ` George Dunlap
2017-11-13 15:41 ` [PATCH 14/16] SUPPORT.md: Add statement on PCI passthrough George Dunlap
2017-11-14 13:25   ` Marek Marczykowski-Górecki
2017-11-22 17:18     ` George Dunlap
2017-11-16 15:43   ` Julien Grall
2017-11-22 18:58     ` George Dunlap
2017-11-22 19:05       ` Rich Persaud
2017-11-21  8:59   ` Jan Beulich
2017-11-22 17:20     ` George Dunlap
2017-11-13 15:41 ` [PATCH 15/16] SUPPORT.md: Add statement on migration RFC George Dunlap
2017-11-13 15:41 ` [PATCH 16/16] SUPPORT.md: Add limits RFC George Dunlap
2017-11-21  9:26   ` Jan Beulich
2017-11-22 18:01     ` George Dunlap
2017-11-23 10:33       ` Jan Beulich
2017-11-13 15:43 ` [PATCH 01/16] Introduce skeleton SUPPORT.md George Dunlap
2017-11-20 17:01 ` Jan Beulich

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=b3962a5d-e782-e261-4f87-8628c1839c00@citrix.com \
    --to=george.dunlap@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=julien.grall@linaro.org \
    --cc=konrad.wilk@oracle.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.