[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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). > 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |