From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall Date: Mon, 03 Mar 2014 23:20:58 +0800 Message-ID: <53149DDA.2030706@linaro.org> References: <1393721365-22458-1-git-send-email-avanzini.arianna@gmail.com> <1393721365-22458-3-git-send-email-avanzini.arianna@gmail.com> <53130053.9050801@linaro.org> <1393847789.4058.62.camel@Solace> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1393847789.4058.62.camel@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: paolo.valente@unimore.it, Ian Campbell , stefano.stabellini@eu.citrix.com, Tim Deegan , xen-devel@lists.xen.org, julien.grall@citrix.com, etrudeau@broadcom.com, Arianna Avanzini , viktor.kleinik@globallogic.com List-Id: xen-devel@lists.xenproject.org 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. >> 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