Re: [Xen-devel] [v7][RFC][PATCH 08/13] xen/x86/p2m: set p2m_access_n for reserved device memory mapping

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

On 2014/11/4 19:41, Jan Beulich wrote:
> > > > On 04.11.14 at 11:41, <tiejun.chen@xxxxxxxxx> wrote:
> > On 2014/11/4 16:02, Jan Beulich wrote:
> > > > > > On 04.11.14 at 02:35, <tiejun.chen@xxxxxxxxx> wrote:
> > > > @@ -686,8 +686,25 @@ guest_physmap_add_entry(struct domain *d, unsigned long 
> > > > gfn,
> > > >         /* Now, actually do the two-way mapping */
> > > >         if ( mfn_valid(_mfn(mfn)) )
> > > >         {
> > > > -        rc = p2m_set_entry(p2m, gfn, _mfn(mfn), page_order, t,
> > > > -                           p2m->default_access);
> > > > +        rc = 0;
> > > > +        a =  p2m->default_access;
> > > > +        if ( !is_hardware_domain(d) )
> > > > +        {
> > > > +            rc = 
> > > > iommu_get_reserved_device_memory(p2m_check_reserved_device_memory,
> > > > +                                                  &gfn);
> > > > +            /* We always avoid populating reserved device memory. */
> > > > +            if ( rc == 1 )
> > > > +                goto out;
> > > But you'll need to make sure that you don't return 1 to the callers:
> > You're right.
> >
> > > They expect 0 or negative error codes. But with the model of
> > > not even populating these regions (or relocating the memory
> > > before [at boot time] assigning a device associated with an RMRR)
> > > I think this needs to become an error anyway.
> > Looks -EINVAL might be used.
> Hmm, -EINVAL is being used way too frequently already. -EBUSY
> would make it at least a little bit more distinct.
Yeah, this also makes sense.

Thanks
Tiejun

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