Re: [Xen-devel] [v4][PATCH 1/2] xen:x86:mm:p2m: introduce set_rmrr_p2m_entry

["Chen, Tiejun" <tiejun.chen@xxxxxxxxx>]

On 2014/7/28 20:07, Jan Beulich wrote:
> > > > On 28.07.14 at 13:42, <tiejun.chen@xxxxxxxxx> wrote:
> > --- a/xen/arch/x86/mm/p2m.c
> > +++ b/xen/arch/x86/mm/p2m.c
> > @@ -858,6 +858,32 @@ int set_mmio_p2m_entry(struct domain *d, unsigned long 
> > gfn, mfn_t mfn)
> >       return set_typed_p2m_entry(d, gfn, mfn, p2m_mmio_direct);
> >   }
> >
> > +int set_rmrr_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn)
> Leaving aside all the previously raised points making me hesitate to
> accept the pair of patches on their own, let's please try to avoid
Do you mean we should fix such RMRR problem completely? Looks we need to 
reserve the RMRR range for each VM. So I'm considering to force 
reserving this range when we go that XENMEM_machine_memory_map for each 
VM. But I'm not sure if this is good. So maybe we can do this after this 
thread since I guess myself need some time to investigate this problem. 
Or you know this is ongoing by some guys, I'd like to refine my patches 
to follow that.
> having Intel specific function names in non-Intel-specific code unless
> that's really the best choice. In the case here, you could
> s/rmrr/identity/ and at once drop the redundant mfn argument (the
> function can construct this for the call to p2m_set_entry(), and the
> function name will make it obvious why this gets derived from gfn).
Okay.

Thanks
Tiejun

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