From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 6/6] xen: arm: use superpages in p2m when
 pages are suitably aligned
Date: Tue, 10 Jun 2014 16:23:18 +0100
Message-ID: <1402413798.7541.11.camel@kazak.uk.xensource.com>
References: <1402394127.29980.52.camel@kazak.uk.xensource.com>
	<1402394278-9850-6-git-send-email-ian.campbell@citrix.com>
	<5396F5A7.1030001@linaro.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <5396F5A7.1030001@linaro.org>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Julien Grall <julien.grall@linaro.org>
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
List-Id: xen-devel@lists.xenproject.org

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.

> [..]
> 
> > +    else
> > +    {
> > +        clear_page(p);
> > +    }
> > +
> 
> Spurious {}.

I prefer them when on both halves of an else when one of them needs
them, but I guess I'm in a minority so I'll remove.

> > @@ -574,7 +803,7 @@ int guest_physmap_add_entry(struct domain *d,
> >  {
> >      return apply_p2m_changes(d, INSERT,
> >                               pfn_to_paddr(gpfn),
> > -                             pfn_to_paddr(gpfn + (1 << page_order)),
> > +                             pfn_to_paddr(gpfn + (1 << page_order)) - 1,
> 
> > @@ -584,7 +813,7 @@ void guest_physmap_remove_page(struct domain *d,
> >  {
> >      apply_p2m_changes(d, REMOVE,
> >                        pfn_to_paddr(gpfn),
> > -                      pfn_to_paddr(gpfn + (1<<page_order)),
> > +                      pfn_to_paddr(gpfn + (1<<page_order)) - 1,
> 
> Why did you add -1 on both function? This is inconsistent with
> p2m_populate_ram which use the range [start, end[.

I thihk I thought the that the callers of apply_p2m_changes were
inconsistent about this, but then I changed my mind and somehow failed
to remove this change.

> 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.

Ian.