From: Julien Grall <julien.grall@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Wei.Liu2@citrix.com, ian.campbell@citrix.com,
	Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org,
	Keir Fraser <keir@xen.org>
Subject: Re: [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number
Date: Wed, 12 Aug 2015 10:57:45 +0100	[thread overview]
Message-ID: <55CB1899.802@citrix.com> (raw)
In-Reply-To: <55CB0F000200007800099F11@prv-mh.provo.novell.com>
Hi Jan,
On 12/08/2015 08:16, Jan Beulich wrote:
>>>> On 05.08.15 at 15:18, <julien.grall@citrix.com> wrote:
>> On 05/08/15 13:46, Andrew Cooper wrote:
>>> On 05/08/15 13:36, Julien Grall wrote:
>>>> So we need to introduce the concept of in each definition. This patch
>>>> makes clear that MFN and GFN is always 4KB and PFN may vary.
>>>
>>> Is (or rather will) a 4K dom0 able to make 4K mappings of a 64K domU?
>>> How is a 64K dom0 expected to make mappings of a 4K domU?
>>
>> The Xen interface will stay 4K even with 64K guest. We have to support
>> 64K guest/dom0 on the current Xen because some distro may do the choice
>> to only ship 64K.
>
> Interesting. Does Linux on ARM not require any atomic page table
> entry updates? I ask because I can't see how you would emulate
> such when you need to deal with 16 of them at a time.
I'm not sure to understand this question.
ARM64 is able to support different page granularity (4KB, 16KB and 
64KB). You have to setup the page table registers during the boot in 
order to specify the granularity used for the whole page table.
In Linux, the page size is chosen at build time and therefore not 
possible to switch it automatically.
>
>> In my current implementation of Linux 64K support (see [1]), there is no
>> changes in Xen (hypervisor and tools). Linux is breaking the 64K page in
>> 4K chunk.
>>
>> When the backend is 64K, it will map the foreign 4K at the top of a 64K
>> page. It's a waste of memory, but it's easier to implement and it's
>> still and improvement compare to have Linux crashing at boot.
>
> Waste of memory? You're only mapping an existing chunk of memory.
> DYM waste of address space?
No, I really meant waste of memory. The current grant API in Linux is 
allocating one Linux Page per grant. Although the grant is always 4K, so 
we won't be able to make use of the 60K for anything as long as we use 
this page for a grant.
So if the grant is pre-allocated (such as for PV block), we won't be 
able use nr_grant * 60KB memory.
It's in my plan to improve the memory usage but we wanted something 
working given that today booting Linux with 64KB page granularity is 
crashing on Xen.
Regards,
-- 
Julien Grall
next prev parent reply	other threads:[~2015-08-12  9:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05 11:28 [RFC 0/2] xen: Clarify the page granularity for the hypercall Julien Grall
2015-08-05 11:28 ` [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number Julien Grall
2015-08-05 11:40   ` Andrew Cooper
2015-08-05 11:51     ` Ian Campbell
2015-08-05 12:36     ` Julien Grall
2015-08-05 12:46       ` Andrew Cooper
2015-08-05 13:18         ` Julien Grall
2015-08-12  7:16           ` Jan Beulich
2015-08-12  9:57             ` Julien Grall [this message]
2015-08-12 10:33               ` Jan Beulich
2015-08-12 11:13                 ` Julien Grall
2015-08-12 11:58                   ` Jan Beulich
2015-08-12 12:57                     ` Julien Grall
2015-08-12 13:25                       ` Jan Beulich
2015-08-05 11:28 ` [RFC 2/2] xen/public: grant-table: Specificy the size of the grant Julien Grall
2015-08-05 16:51   ` Stefano Stabellini
2015-08-12  7:21   ` Jan Beulich
2015-08-12 10:00     ` Julien Grall
2015-08-12 10:35       ` Jan Beulich
2015-08-12 11:08         ` Julien Grall
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=55CB1899.802@citrix.com \
    --to=julien.grall@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=Wei.Liu2@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=keir@xen.org \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --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).