From: Juergen Gross <jgross@suse.com>
To: Stefano Stabellini <stefano@aporeto.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
Wei Liu <wei.liu2@citrix.com>,
"George.Dunlap@eu.citrix.com" <George.Dunlap@eu.citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: Future support of 5-level paging in Xen:wq
Date: Mon, 12 Dec 2016 08:10:46 +0100 [thread overview]
Message-ID: <034a64a6-db3f-a173-f751-eeaac01d7fb6@suse.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1612091121020.22778@sstabellini-ThinkPad-X260>
On 09/12/16 20:31, Stefano Stabellini wrote:
> On Fri, 9 Dec 2016, Juergen Gross wrote:
>> On 09/12/16 00:50, Stefano Stabellini wrote:
>>> On Thu, 8 Dec 2016, Andrew Cooper wrote:
>>>> On 08/12/2016 19:18, Stefano Stabellini wrote:
>>>>> On Thu, 8 Dec 2016, Andrew Cooper wrote:
>>>>>> On 08/12/16 16:46, Juergen Gross wrote:
>>>>>>> The first round of (very preliminary) patches for supporting the new
>>>>>>> 5-level paging of future Intel x86 processors [1] has been posted to
>>>>>>> lkml:
>>>>>>>
>>>>>>> https://lkml.org/lkml/2016/12/8/378
>>>>>>>
>>>>>>> An explicit note has been added: "CONFIG_XEN is broken." and
>>>>>>> "I would appreciate help with the code."
>>>>>>>
>>>>>>> I think we should start a discussion what we want to do in future:
>>>>>>>
>>>>>>> - are we going to support 5-level paging for PV guests?
>>>>>>> - do we limit 5-level paging to PVH and HVM?
>>>>>> The 64bit PV ABI has 16TB of virtual address space just above the upper
>>>>>> 48-canonical boundary.
>>>>>>
>>>>>> Were Xen to support 5-level PV guests, we'd either leave the PV guest
>>>>>> kernel with exactly the same amount of higher half space as it currently
>>>>>> has, or we'd have to recompile Xen as properly position-independent and
>>>>>> use a different virtual range in different paging mode.
>>>>>>
>>>>>> Another pain point is the quantity of virtual address space handed away
>>>>>> in the ABI. We currently had 97% of the virtual address space away to
>>>>>> 64bit PV guests, and frankly this is too much. This is the wrong way
>>>>>> around when Xen has more management to do than the guest. If we were to
>>>>>> go along the 5-level PV guests route, I will insist that there is a
>>>>>> rather more even split of virtual address space baked into the ABI.
>>>>>>
>>>>>> However, a big question is whether any of this effort is worth doing, in
>>>>>> the light of PVH.
>>>>> With my Aporeto hat on, I'll say that given the overwhelming amount of
>>>>> hardware available out there without virtualization support, this work
>>>>> is worth doing. I am referring to all the public cloud virtual machines,
>>>>> which can support Xen PV guests but cannot support PVH guests.
>>>>
>>>> Why is Xen supporting 5-level guests useful for running in a PV cloud
>>>> VM? Xen doesn't run PV.
>>>>
>>>> I am not suggesting that we avoid adding 5-level support to Xen. We
>>>> should absolutely do that. The question is only whether we extend the
>>>> PV ABI to support 5-level PV guests. Conceptually, its very easy to
>>>> have a 5-level Xen but only supporting 4-level PV guests.
>>>>
>>>> VT-x and SVM date from 2005/2006 and are now 10 years old. I would be
>>>> surprised if you would find much hardware of this age in any cloud; you
>>>> can't by anything that old, and support contracts have probably run out
>>>> if you have owned that hardware for 10 years.
>>>
>>> I am thinking that in a couple of years, we might already find VMs so
>>> large that to use all the memory in a nested virt scenario, we need
>>> 5-level PV abi support.
>>>
>>
>> No, I don't think so. I believe there will be no hardware capable of
>> 5-level paging but without VMX/SVM support. Support of PVH/HVM for such
>> large guests should be enough. We don't need to extend PV which we want
>> to get rid of in Linux anyway, no?
>
> I am talking about nested virtualization when the L1 virtual machine
> does not support nested VMX or SVM. No Amazon AWS virtual machines
> support nested VMX, but it is possible to run Xen PV virtual machines on
> top of any Amazon HVM instance.
>
> When 5-level pagetable hardware will become available on Amazon AWS, it
> might be possible to get virtual machines so large that in order to use
> all the memory, you need to use 5-level pagetables in L1 Xen. In this
> scenario, if we want to create a L2 virtual machine as large as possible
> we will need support for 5-level page tables in the PV ABI.
>
> Please correct me if I am wrong.
So basically you are telling us that due to nested virt on AWS we will
never be able to drop PV support, right? Why are we pushing PVH then?
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-12-12 7:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-08 16:46 Future support of 5-level paging in Xen Juergen Gross
2016-12-08 17:22 ` Andrew Cooper
2016-12-08 19:18 ` Stefano Stabellini
2016-12-08 22:21 ` Andrew Cooper
2016-12-08 23:40 ` Boris Ostrovsky
2016-12-09 0:20 ` Andrew Cooper
2016-12-09 0:41 ` Boris Ostrovsky
2016-12-09 9:49 ` Jan Beulich
2017-01-03 17:32 ` anshul makkar
2017-01-03 22:38 ` Boris Ostrovsky
2016-12-08 23:50 ` Future support of 5-level paging in Xen:wq Stefano Stabellini
2016-12-09 5:01 ` Juergen Gross
2016-12-09 19:31 ` Stefano Stabellini
2016-12-09 19:53 ` Andrew Cooper
2016-12-12 7:10 ` Juergen Gross [this message]
2016-12-12 19:13 ` Stefano Stabellini
2016-12-12 19:32 ` Konrad Rzeszutek Wilk
2016-12-13 3:57 ` Li, Liang Z
2016-12-13 4:16 ` Tian, Kevin
2016-12-13 4:32 ` Zhang, Xiong Y
2016-12-13 5:44 ` Li, Liang Z
2016-12-13 17:21 ` Andrew Cooper
2016-12-14 1:04 ` George Dunlap
2016-12-13 8:14 ` Jan Beulich
2016-12-09 9:59 ` Future support of 5-level paging in Xen Jan Beulich
[not found] ` <584A8E7B020000780012727D@suse.com>
2016-12-09 10:07 ` Juergen Gross
2016-12-09 10:54 ` 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=034a64a6-db3f-a173-f751-eeaac01d7fb6@suse.com \
--to=jgross@suse.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=sstabellini@kernel.org \
--cc=stefano@aporeto.com \
--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).