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

[Eric Trudeau <etrudeau@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxxxxx]
> Sent: Monday, March 03, 2014 10:21 AM
> To: Dario Faggioli
> Cc: Arianna Avanzini; xen-devel@xxxxxxxxxxxxx; paolo.valente@xxxxxxxxxx;
> stefano.stabellini@xxxxxxxxxxxxx; julien.grall@xxxxxxxxxx; Eric Trudeau;
> viktor.kleinik@xxxxxxxxxxxxxxx; Ian Campbell; Tim Deegan
> Subject: Re: [Xen-devel] [RFC PATCH 2/3] arch, arm32: add the
> XEN_DOMCTL_memory_mapping hypercall
> 
> 
> 
> On 03/03/14 19:56, Dario Faggioli wrote:
> > 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?
> 
> Yes. Maybe a bit more smarter than permitting full I/0 caps for dom0.
> 

Our implementation does not require Dom0 access permission in order
for it to grant access permission to a DomU.  I suppose it wouldn't hurt
for iomem_permit_access because we allow iomem regions to be mapped
into multiple domains; however, I think the irqs_permit_access call keeps
multiple domains from "owning" the same IRQ.  I might be wrong about that.

> >> 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?
> 
> My term seems to be wrong for dom0 :).
> 
> On ARM, some device is used by Xen and therefore not exposed to dom0. By
> passthrough to dom0 I meant every device that are given to dom0, no
> matter if the platform has an IOMMU.
> 
> I think DOM0 should only be able to map theses devices to a guest. It
> seems stupid to allow dom0 mapping RAM or the UART used by Xen.
> 
> --
> Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel