Re: [Xen-devel] [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On dom, 2014-03-02 at 17:56 +0800, Julien Grall wrote:
> On 02/03/14 08:49, Arianna Avanzini wrote:

> > +
> > +        ret = -EPERM;
> > +   /*
> > +    * NOTE: dom0 seems to have empty iomem_caps but to be however able to
> > +    *       access I/O memory ranges. The following check takes for granted
> > +    *       that any iomem range can be mapped to a domU if the current
> > +    *       domain is dom0.
> > +    */
> > +        if ( current->domain->domain_id != 0 &&
> > +             !iomem_access_permitted(current->domain, mfn, mfn + nr_mfns - 
> > 1) )
> > +            return ret;
> 
> This check can be removed by adding in construct_dom0 
> (arch/arm/domain_build.c) something like that:
>    /* DOM0 is permitted full I/O capabilities */
>    rc = iomem_permit_access(d, 0UL, ~OUL);
> 
Right. FTR, xen/arch/x86/domain_build.c, has this (also in
construct_dom0):

    /* DOM0 is permitted full I/O capabilities. */
    rc |= ioports_permit_access(dom0, 0, 0xFFFF);
    rc |= iomem_permit_access(dom0, 0UL, ~0UL);
    rc |= irqs_permit_access(dom0, 1, nr_irqs_gsi - 1);

Do you want a patch to that/similar effect?

> I'm wondering if we can even restrict dom0 I/0 access by only permit 
> access on devices passthrough to it. Because dom0 should not be allowed 
> to map I/O ranges which belong to device used by Xen e.g : GIC, RAM,...
> 
So, this is probably me messing up with the terminology, but what
'devices passthrough to it [dom0]' would mean, for example in cases
where we don't have an IOMMU (like cubie* boards), and hence where
proper passtrhogh will never be, I think, supported? Or do we plan to
have it working there too?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

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