xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Juergen Gross <jgross@suse.com>,
	ian.campbell@citrix.com, ian.jackson@eu.citrix.com,
	jbeulich@suse.com, keir@xen.org, tim@xen.org,
	xen-devel@lists.xen.org
Subject: Re: [PATCH V3 1/1] expand x86 arch_shared_info to support >3 level p2m tree
Date: Mon, 15 Sep 2014 09:29:45 +0100	[thread overview]
Message-ID: <5416A379.5@citrix.com> (raw)
In-Reply-To: <5412CB80.9030208@suse.com>


On 12/09/2014 11:31, Juergen Gross wrote:
> On 09/09/2014 12:49 PM, Juergen Gross wrote:
>> On 09/09/2014 12:27 PM, Andrew Cooper wrote:
>>> On 09/09/14 10:58, Juergen Gross wrote:
>>>> The x86 struct arch_shared_info field pfn_to_mfn_frame_list_list
>>>> currently contains the mfn of the top level page frame of the 3 level
>>>> p2m tree, which is used by the Xen tools during saving and restoring
>>>> (and live migration) of pv domains. With three levels of the p2m tree
>>>> it is possible to support up to 512 GB of RAM for a 64 bit pv domain.
>>>> A 32 bit pv domain can support more, as each memory page can hold 1024
>>>> instead of 512 entries, leading to a limit of 4 TB. To be able to
>>>> support more RAM on x86-64 an additional level is to be added.
>>>>
>>>> This patch expands struct arch_shared_info with a new p2m tree root
>>>> and the number of levels of the p2m tree. The new information is
>>>> indicated by the domain to be valid by storing ~0UL into
>>>> pfn_to_mfn_frame_list_list (this should be done only if more than
>>>> three levels are needed, of course).
>>>
>>> A small domain feeling a little tight on space could easily opt for a 2
>>> or even 1 level p2m.  (After all, one advantage of virt is to cram many
>>> small VMs into a server).
>>>
>>> How is xen and toolstack support for n-level p2ms going to be 
>>> advertised
>>> to guests?  Simply assuming the toolstack is capable of dealing with
>>> this new scheme wont work with a new pv guest running on an older Xen.
>>
>> Is it really worth doing such an optimization? This would save only very
>> few pages.
>>
>> If you think it should be done we can add another SIF_* flag to
>> start_info->flags. In this case a domain using this feature could not be
>> migrated to a server with old tools, however. So we would probably end
>> with the need to be able to suppress that flag on a per-domain base.
>
> Any further comments?
>
> Which way should I go?
>

There are two approaches, with different up/downsides

1) continue to use the old method, and use the new method only when 
absolutely required.  This will function, but on old toolstacks, suffer 
migration/suspend failures when the toolstack fails to find the p2m.

2) Provide a Xen feature flag indicating the presence of N-level p2m 
support.  Guests which can see this flag are free to use N-level, and 
guests which can't are not.

Ultimately, giving more than 512GB to a current 64bit PV domain is not 
going to work, and the choice above depends on which failure mode you 
wish a new/old mix to have.

~Andrew

  reply	other threads:[~2014-09-15  8:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-09  9:58 [PATCH V3 0/1] support >3 level p2m tree Juergen Gross
2014-09-09  9:58 ` [PATCH V3 1/1] expand x86 arch_shared_info to " Juergen Gross
2014-09-09 10:27   ` Andrew Cooper
2014-09-09 10:49     ` Juergen Gross
2014-09-12 10:31       ` Juergen Gross
2014-09-15  8:29         ` Andrew Cooper [this message]
2014-09-15  8:52           ` Juergen Gross
2014-09-15  9:42             ` Jan Beulich
2014-09-15  9:48               ` Juergen Gross
2014-09-15  9:44             ` David Vrabel
2014-09-15  9:52               ` Juergen Gross
2014-09-15 10:30                 ` David Vrabel
2014-09-15 10:46                   ` Juergen Gross
2014-09-15 11:29                     ` Jan Beulich
2014-09-15 14:30                     ` David Vrabel
2014-09-16  3:52                       ` Juergen Gross
2014-09-16 10:14                         ` David Vrabel
2014-09-16 10:38                           ` Juergen Gross
2014-09-16 11:56                             ` David Vrabel
2014-09-16 12:44                               ` Juergen Gross
2014-09-17  4:25                                 ` Juergen Gross
2014-09-30  8:53   ` Jan Beulich
     [not found]   ` <542A8B93020000780003AE7B@suse.com>
2014-09-30  8:59     ` Juergen Gross

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=5416A379.5@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=keir@xen.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xen.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).