From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 6/6] xen: arm: use superpages in p2m when pages are suitably aligned Date: Tue, 10 Jun 2014 20:11:55 +0100 Message-ID: <5397587B.2050205@linaro.org> References: <1402394127.29980.52.camel@kazak.uk.xensource.com> <1402394278-9850-6-git-send-email-ian.campbell@citrix.com> <5396F5A7.1030001@linaro.org> <1402413798.7541.11.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1402413798.7541.11.camel@kazak.uk.xensource.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: Ian Campbell Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 10/06/14 16:23, Ian Campbell wrote: > On Tue, 2014-06-10 at 13:10 +0100, Julien Grall wrote: >> Hi Ian, >> >> This patch looks good in general. I've only few comments, see them below. >> >> On 06/10/2014 10:57 AM, Ian Campbell wrote: >>> +void p2m_dump_info(struct domain *d) >>> +{ >>> + struct p2m_domain *p2m = &d->arch.p2m; >>> + >>> + spin_lock(&p2m->lock); >>> + printk("p2m mappings for domain %d (vmid %d):\n", >>> + d->domain_id, p2m->vmid); >>> + BUG_ON(p2m->stats.mappings[0] || p2m->stats.shattered[0]); >>> + printk(" 1G mappings: %d (shattered %d)\n", >>> + p2m->stats.mappings[1], p2m->stats.shattered[1]); >>> + printk(" 2M mappings: %d (shattered %d)\n", >>> + p2m->stats.mappings[2], p2m->stats.shattered[2]); >>> + printk(" 4K mappings: %d\n", p2m->stats.mappings[3]); >> >> I wondering if we can have more than 2^32-1 4K mapping sometimes... > > That would be 16TB of memory, which isn't out of the question but we > don't currently support it. Still, not much harm in increase to a 64-bit > field. Sounds good. >> I think we should document how we pass the argument to apply_p2m_changes >> somewhere. Even better, use gmfn and nr_gfn, as x86 does, for >> apply_p2m_changes and handle internally the pfn_to_paddr stuff. This >> would avoid this kind of problem. > > Arianna is sorting that all out in her mmio mapping series. Oh right. Some of you will have to rebase his/her series on top of the other one :). Regards, -- Julien Grall