Re: [Xen-devel] [XenARM] XEN tools for ARM with Virtualization Extensions

["Eric Trudeau" <etrudeau@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Julien Grall [mailto:julien.grall@xxxxxxxxxx]
> Sent: Thursday, June 27, 2013 6:41 PM
> To: Eric Trudeau
> Cc: xen-devel; Ian Campbell
> Subject: Re: [Xen-devel] [XenARM] XEN tools for ARM with Virtualization
> Extensions
> 
> On 06/27/2013 09:19 PM, Eric Trudeau wrote:
> 
> >> -----Original Message-----
> >> From: Julien Grall [mailto:julien.grall@xxxxxxxxxx]
> >> Sent: Thursday, June 27, 2013 3:34 PM
> >> To: Eric Trudeau
> >> Cc: Ian Campbell; xen-devel
> >> Subject: Re: [Xen-devel] [XenARM] XEN tools for ARM with Virtualization
> >> Extensions
> >>
> >> On 06/27/2013 08:01 PM, Eric Trudeau wrote:
> >>
> >>>> -----Original Message-----
> >>>> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> >>>> Sent: Thursday, June 27, 2013 12:34 PM
> >>>> To: Eric Trudeau
> >>>> Cc: xen-devel
> >>>> Subject: Re: [XenARM] XEN tools for ARM with Virtualization Extensions
> >>>>
> >>>> On Thu, 2013-06-27 at 16:21 +0000, Eric Trudeau wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> >>>>>> Sent: Wednesday, June 26, 2013 12:45 PM
> >>>>>> To: Eric Trudeau
> >>>>>> Cc: xen-devel
> >>>>>> Subject: Re: [XenARM] XEN tools for ARM with Virtualization Extensions
> >>>>>>
> >>>>
> >>>
> >>>>> I rebased to the XSA-55 commit and now I can create the guest.  I am
> >>>>> able to debug a kernel init panic.
> >>>>
> >>>
> >>> My panic seems related to memory regions in device tree.  I am appended
> >>> my DTB to the kernel zImage.
> >>> How does the memory assigned by XEN for the guest domain get inserted
> >>> into the device tree?
> >>> Does Hypervisor or the toolchain manipulate the appended DTB and modify
> >>> the hypervisor node's reg and irq properties? What about the memory
> node?
> >>
> >>
> >> For the moment, the toolstack isn't not able to parse/modify the guest
> >> DTB. Memory and IRQ properties are hardcoded in the hypervisor and the
> >> toolstack. The different values need to match the following constraints:
> >>   - The memory region start from 0x80000000. The size needs to be the
> >> same in the configuration file and the DTS, otherwise the domain will
> >> crash. I believe the default size is 128MB.
> >>   - IRQ properties are:
> >>       * event channel: 31, except if you have modified the IRQ number in
> >> Xen for dom0;
> >>       * timer: same IRQs number as the dom0 DTS;
> >>   - GIC range: same range as the dom0 DTS.
> >>
> >
> > I changed my DTS to hard code memory at 0x80000000 with size 0x800000.
> > Now, I hit my first I/O access fault.  I tried using iomem attribute in my
> dom1.cfg.
> > Is iomem attribute supported yet on ARM?
> > I see the rangeset iomem_caps being set correctly, but I don't know if it is
> being
> > added to the VTTBR for my guest dom.
> 
> Are you trying to assign a device to your guest? If so, Xen doesn't
> yet support it.
> 
> To map physical memory range in a guest you need to use/implement
> xc_domain_memory_mapping/XEN_DOMCTL_memory_mapping
> which is missing on ARM. To help you, you can read this thread:
> http://lists.xen.org/archives/html/xen-devel/2013-06/msg00870.html
> 

I added support for XEN_DOMCTL_memory_mapping in xen/arch/arm/domctl.c
using xen/arch/x86/domctl.c as a model.  I only implemented add functionality.
I then modified domcreate_launch_dm() to call xc_domain_memory_mapping()
instead of xc_domain_iomem_permission for the iomem regions in the domain
cfg file.

This allowed my kernel which unfortunately has some hard-coded accesses to
device memory to boot up in a DomU guest machine without crashing.
Now, I am looking into how to enable IRQs in my guest domains.
Would I implement xc_domain_bind_pt_irq/XEN_DOMCTL_bind_pt_irq in a similar
way as xc_domain_memory_mapping?  Or will the existing xc_domain_irq_permission
calls work?

What functions should I call to implement  XEN_DOMCTL_bind_pt_irq on ARM?

Thanks,
Eric

------------------------------------------------------------------

diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 0c32d0b..4196c0c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -970,8 +970,9 @@ static void domcreate_launch_dm(libxl__egc *egc, 
libxl__multidev *multidev,
         LOG(DEBUG, "dom%d iomem %"PRIx64"-%"PRIx64,
             domid, io->start, io->start + io->number - 1);

-        ret = xc_domain_iomem_permission(CTX->xch, domid,
-                                          io->start, io->number, 1);
+        ret = xc_domain_memory_mapping(CTX->xch, domid,
+                                       io->start, io->start,
+                                       io->number, 1);
         if (ret < 0) {
             LOGE(ERROR,
                  "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64,
diff --git a/xen/arch/arm/domctl.c b/xen/arch/arm/domctl.c
index 851ee40..222aac9 100644
--- a/xen/arch/arm/domctl.c
+++ b/xen/arch/arm/domctl.c
@@ -10,11 +10,83 @@
 #include <xen/errno.h>
 #include <xen/sched.h>
 #include <public/domctl.h>
+#include <xen/iocap.h>
+#include <xsm/xsm.h>
+#include <xen/paging.h>
+#include <xen/guest_access.h>

 long arch_do_domctl(struct xen_domctl *domctl, struct domain *d,
                     XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
 {
-    return -ENOSYS;
+    long ret = 0;
+    bool_t copyback = 0;
+
+    switch ( domctl->cmd )
+    {
+    case XEN_DOMCTL_memory_mapping:
+    {
+        unsigned long gfn = domctl->u.memory_mapping.first_gfn;
+        unsigned long mfn = domctl->u.memory_mapping.first_mfn;
+        unsigned long nr_mfns = domctl->u.memory_mapping.nr_mfns;
+        int add = domctl->u.memory_mapping.add_mapping;
+
+        /* removing i/o memory is not implemented yet */
+        if (!add) {
+            ret = -ENOSYS;
+            break;
+        }
+        ret = -EINVAL;
+        if ( (mfn + nr_mfns - 1) < mfn || /* wrap? */
+             /* x86 checks wrap based on paddr_bits which is not implemented 
on ARM? */
+             /* ((mfn | (mfn + nr_mfns - 1)) >> (paddr_bits - PAGE_SHIFT)) || 
*/
+             (gfn + nr_mfns - 1) < gfn ) /* wrap? */
+            break;
+
+        ret = -EPERM;
+        if ( current->domain->domain_id != 0 )
+            break;
+
+        ret = xsm_iomem_mapping(XSM_HOOK, d, mfn, mfn + nr_mfns - 1, add);
+        if ( ret )
+            break;
+
+        if ( add )
+        {
+            printk(XENLOG_G_INFO
+                   "memory_map:add: dom%d gfn=%lx mfn=%lx nr=%lx\n",
+                   d->domain_id, gfn, mfn, nr_mfns);
+
+            ret = iomem_permit_access(d, mfn, mfn + nr_mfns - 1);
+            if ( !ret && paging_mode_translate(d) )
+            {
+                ret = map_mmio_regions(d, gfn << PAGE_SHIFT,
+                                       (gfn + nr_mfns - 1) << PAGE_SHIFT,
+                                       mfn << PAGE_SHIFT);
+                if ( ret )
+                {
+                    printk(XENLOG_G_WARNING
+                           "memory_map:fail: dom%d gfn=%lx mfn=%lx nr=%lx\n",
+                           d->domain_id, gfn, mfn, nr_mfns);
+                    if ( iomem_deny_access(d, mfn, mfn + nr_mfns - 1) &&
+                         is_hardware_domain(current->domain) )
+                        printk(XENLOG_ERR
+                               "memory_map: failed to deny dom%d access to 
[%lx,%lx]\n",
+                               d->domain_id, mfn, mfn + nr_mfns - 1);
+                }
+            }
+        }
+    }
+    break;
+
+    default:
+        ret = -ENOSYS;
+        break;
+    }
+
+    if ( copyback && __copy_to_guest(u_domctl, domctl, 1) )
+        ret = -EFAULT;
+
+    return ret;
 }

 void arch_get_info_guest(struct vcpu *v, vcpu_guest_context_u c)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel