[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 10/11] tools, libxl: handle the iomem parameter with the memory_mapping hcall



On Tue, 2014-04-22 at 21:03 +0100, Julien Grall wrote:
> Hi Arianna,
> 
> On 21/04/14 14:45, Arianna Avanzini wrote:
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index 6aa630e..cdf03cd 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -1113,6 +1113,19 @@ static void domcreate_launch_dm(libxl__egc *egc, 
> > libxl__multidev *multidev,
> >                    "failed give dom%d access to iomem range 
> > %"PRIx64"-%"PRIx64,
> >                    domid, io->start, io->start + io->number - 1);
> >               ret = ERROR_FAIL;
> > +            continue;
> > +        }
> > +        if (!libxl__arch_auto_translated_physmap(d_config))
> > +            continue;
> > +        ret = xc_domain_memory_mapping(CTX->xch, domid,
> > +                                       io->gfn, io->start,
> > +                                       io->number, 1);
> > +        if (ret < 0) {
> > +            LOGE(ERROR,
> > +                 "failed to map to dom%d iomem range %"PRIx64"-%"PRIx64
> > +                 " to guest address %"PRIx64,
> > +                 domid, io->start, io->start + io->number - 1, io->gfn);
> > +            ret = ERROR_FAIL;
> 
> I know I've asked you to create the small helper 
> "libxl__arch_auto_translated_physmap" in libxl. I'm wondering if we can 
> replace xc_domain_iomem_permission by xc_domain_memory_mapping.

The path we've decided to go down is to separate the granting/revoking
of permissions from the establishment of mappings, isn't it?

Doing as you suggest would be contrary to that plan I think.

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.