From: Juergen Gross <jgross@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.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: Tue, 09 Sep 2014 12:49:51 +0200 [thread overview]
Message-ID: <540EDB4F.30402@suse.com> (raw)
In-Reply-To: <540ED600.3060102@citrix.com>
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.
Juergen
>
> ~Andrew
>
>>
>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> ---
>> xen/include/public/arch-x86/xen.h | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/include/public/arch-x86/xen.h b/xen/include/public/arch-x86/xen.h
>> index f35804b..2ca996c 100644
>> --- a/xen/include/public/arch-x86/xen.h
>> +++ b/xen/include/public/arch-x86/xen.h
>> @@ -224,7 +224,12 @@ struct arch_shared_info {
>> /* Frame containing list of mfns containing list of mfns containing p2m. */
>> xen_pfn_t pfn_to_mfn_frame_list_list;
>> unsigned long nmi_reason;
>> - uint64_t pad[32];
>> + /*
>> + * Following two fields are valid if pfn_to_mfn_frame_list_list contains
>> + * ~0UL.
>> + */
>> + unsigned long p2m_levels; /* number of levels of p2m tree */
>> + xen_pfn_t p2m_root; /* p2m tree top level mfn */
>> };
>> typedef struct arch_shared_info arch_shared_info_t;
>>
>
>
>
next prev parent reply other threads:[~2014-09-09 10:49 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 [this message]
2014-09-12 10:31 ` Juergen Gross
2014-09-15 8:29 ` Andrew Cooper
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=540EDB4F.30402@suse.com \
--to=jgross@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jbeulich@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).