Re: [Xen-devel] [PATCH 2/3] xen/p2m: Using INVALID_MFN instead of mfn_valid

["Hao, Xudong" <xudong.hao@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Wednesday, August 15, 2012 5:22 PM
> To: Hao, Xudong
> Cc: Zhang, Xiantao; xen-devel@xxxxxxxxxxxxx; tim@xxxxxxx
> Subject: Re: [Xen-devel] [PATCH 2/3] xen/p2m: Using INVALID_MFN instead of
> mfn_valid
> 
> >>> On 15.08.12 at 08:57, Xudong Hao <xudong.hao@xxxxxxxxx> wrote:
> > 64 bits big bar's MMIO address may out of the highest gfn, then mfn_valid
> > may return failure, so using INVALID_MFN to measure.
> 
> Hmm, that can be true for 32-bit BARs too (on systems with less
> than 4Gb).
> 

Exactly right, thanks comments.

> > Signed-off-by: Xiantao Zhang <xiantao.zhang@xxxxxxxxx>
> > Signed-off-by: Xudong Hao <xudong.hao@xxxxxxxxx>
> >
> > diff -r 663eb766cdde xen/arch/x86/mm/p2m-ept.c
> > --- a/xen/arch/x86/mm/p2m-ept.c     Tue Jul 24 17:02:04 2012 +0200
> > +++ b/xen/arch/x86/mm/p2m-ept.c     Thu Jul 26 15:40:01 2012 +0800
> > @@ -428,7 +428,7 @@ ept_set_entry(struct p2m_domain *p2m, un
> >      }
> >
> >      /* Track the highest gfn for which we have ever had a valid mapping */
> > -    if ( mfn_valid(mfn_x(mfn)) &&
> > +    if ( (mfn_x(mfn) != INVALID_MFN) &&
> >           (gfn + (1UL << order) - 1 > p2m->max_mapped_pfn) )
> >          p2m->max_mapped_pfn = gfn + (1UL << order) - 1;
> 
> Depending on how the above comment gets addressed (i.e.
> whether MMIO MFNs are to be considered here at all), this
> might need changing anyway, as this a huge max_mapped_pfn
> value likely wouldn't be very useful anymore.
> 

Jan,

Your viewpoint is similar with us. Here max_mapped_pfn value is for memory but 
not for MMIO. I think this is a simple changes, do you have another suggestion?

> Jan
> 


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