Re: [Xen-devel] [PATCH 6/6] xen: arm: use superpages in p2m when pages are suitably aligned

[Julien Grall <julien.grall@xxxxxxxxxx>]

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

[..]

> +    else
> +    {
> +        clear_page(p);
> +    }
> +

Spurious {}.

[..]

> +/*
> + * 0   == (P2M_ONE_DESCEND) continue to decend the tree

s/decend/descend/

[..]

> @@ -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 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.
        
Regards,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel