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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: Thursday, July 31, 2014 11:42 PM
> 
> >>> On 01.08.14 at 00:29, <kevin.tian@xxxxxxxxx> wrote:
> >>  From: Chen, Tiejun
> >> Sent: Tuesday, July 29, 2014 6:36 PM
> >>
> >> Its used conveniently to create RMRR mapping in shared EPT case.
> >>
> >> Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx>
> >> ---
> >>  xen/arch/x86/mm/p2m.c     | 29 +++++++++++++++++++++++++++++
> >>  xen/include/asm-x86/p2m.h |  3 +++
> >>  2 files changed, 32 insertions(+)
> >>
> >> v6:
> >>
> >> * Refactor set_identity_p2m_entry to make sense
> >>
> >> v5:
> >>
> >> * Rename this function as set_identity_p2m_entry()
> >> * Get mfn directly inside set_identity_p2m_entry()
> >>
> >> v4:
> >>
> >> * new patch to combine get and set together to create RMRR mapping.
> >>
> >> diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
> >> index 642ec28..06bed7a 100644
> >> --- a/xen/arch/x86/mm/p2m.c
> >> +++ b/xen/arch/x86/mm/p2m.c
> >> @@ -858,6 +858,35 @@ 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_identity_p2m_entry(struct domain *d, unsigned long gfn)
> >> +{
> >> +    p2m_type_t p2mt;
> >> +    p2m_access_t a;
> >> +    mfn_t mfn;
> >> +    struct p2m_domain *p2m = p2m_get_hostp2m(d);
> >> +    int ret = -EBUSY;
> >> +
> >> +    gfn_lock(p2m, gfn, 0);
> >> +
> >> +    mfn = p2m->get_entry(p2m, gfn, &p2mt, &a, 0, NULL);
> >> +
> >> +    if ( !mfn_valid(mfn) )
> >> +        ret = p2m_set_entry(p2m, gfn, _mfn(gfn), PAGE_ORDER_4K,
> >> p2m_mmio_direct,
> >> +                            p2m_access_rw);
> >> +    else if ( mfn_x(mfn) == gfn &&
> >> +              p2mt == p2m_mmio_direct &&
> >> +              a == p2m_access_rw )
> >> +        ret = 0;
> >> +    else
> >> +        printk(XENLOG_G_WARNING
> >> +               "Cannot identity map d%d:%lx, already mapped
> to %lx.\n",
> >> +               d->domain_id, gfn, mfn_x(mfn));
> >
> > what about !mfn_valid but the GFN has been used for emulated MMIOs?
> w/o
> > a guest e820 view you can't avoid overlapping by just looking at mfn...
> 
> What good would looking at the guest's E820 table do here? Both
> emulated MMIO ranges and the (supposed) exclusion ranges needed
> for the RMRR would just be holes.
> 

You are right. E820 is memory oriented so we don't know whether the hole
has been used for emulated MMIO ranges...

Thanks
Kevin

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