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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-06-10 at 20:11 +0100, Julien Grall wrote:
> 
> 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.

In the end I went with unsigned long which is the size of a pfn for
arm32 and arm64 and therefore not wasteful on arm32.

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

Yes.

Ian.


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