From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 1/2] xen/mm: Clarify the granularity for each Frame Number Date: Wed, 12 Aug 2015 10:57:45 +0100 Message-ID: <55CB1899.802@citrix.com> References: <1438774133-1564-1-git-send-email-julien.grall@citrix.com> <1438774133-1564-2-git-send-email-julien.grall@citrix.com> <55C1F617.8090208@citrix.com> <55C2034F.9070508@citrix.com> <55C20595.8030502@citrix.com> <55C20D2D.1050806@citrix.com> <55CB0F000200007800099F11@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZPSn9-0001NA-FH for xen-devel@lists.xenproject.org; Wed, 12 Aug 2015 09:57:51 +0000 In-Reply-To: <55CB0F000200007800099F11@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Wei.Liu2@citrix.com, ian.campbell@citrix.com, Stefano Stabellini , Andrew Cooper , Ian Jackson , Tim Deegan , stefano.stabellini@citrix.com, xen-devel@lists.xenproject.org, Keir Fraser List-Id: xen-devel@lists.xenproject.org Hi Jan, On 12/08/2015 08:16, Jan Beulich wrote: >>>> On 05.08.15 at 15:18, 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