Re: [Xen-devel] [PATCH RFC v2 4/9] xen/arm: Implement get_maximum_gpfn hypercall for arm

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2013-07-03 at 12:29 +0100, Stefano Stabellini wrote:
> On Wed, 3 Jul 2013, Jaeyong Yoo wrote:
> > From: Alexey Sokolov <sokolov.a@xxxxxxxxxxx>
> > 
> > Since we do not know the maximum gpfn size for guest domain,
> > we walk the page table of guest in order to see the maximum size
> > of gpfn.
> > 
> > Singed-off-by: Alexey Sokolov <sokolov.a@xxxxxxxxxxx>
> > ---
> >  xen/arch/arm/mm.c             |  3 +-
> >  xen/arch/arm/p2m.c            | 69 
> > +++++++++++++++++++++++++++++++++++++++++++
> >  xen/include/asm-arm/p2m.h     |  3 ++
> >  xen/include/public/arch-arm.h |  6 ++++
> >  4 files changed, 80 insertions(+), 1 deletion(-)
> > 
> > diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
> > index d1290cd..650b1fc 100644
> > --- a/xen/arch/arm/mm.c
> > +++ b/xen/arch/arm/mm.c
> > @@ -762,7 +762,8 @@ int page_is_ram_type(unsigned long mfn, unsigned long 
> > mem_type)
> >  
> >  unsigned long domain_get_maximum_gpfn(struct domain *d)
> >  {
> > -    return -ENOSYS;
> > +    xen_pfn_t result = p2m_get_next_non_used_gpfn(d, GUEST_RAM_BASE >> 
> > PAGE_SHIFT);
> > +    return result;
> >  }
> 
> Rather than implementing p2m_get_next_non_used_gpfn, I think we should
> keep track of the maximum gpfn, like we do on x86, see:

ISTR Tim wanting to get rid of this concept on x86.

Anything which is walking the P2M should be doing so via iterator based
interfaces and not by looping on O...N where N is potentially guest
controlled. Not to mention 0...N might be quite sparse.

Ian.


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