[Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c

[Wei Liu]

From: Ian Jackson 

We are going to want to use some but not all of the machinery
previously in xc_minios.c.  Split the privcmd and gnttab code into its
own file.  This part is pure code motion.

But we also have to:

 - Alter the Makefile to build and link xc_minios_privcmd.c too.

 - Rename some of the minios_*_ops symbols to have proper namespaceing
   and make them have external linkage, so that the init code (which
   remains in xc_minios.c) can reference them.

 - Call these *_ops symbols xc_*_ops so that we can mix and match in
   the future.  This does not impede the existing mechanisms for
   run-time overriding.  (But leave a comment next to the new
   declarations in xc_private.h saying not to use these.)

 - Change map_frames_ex to minios_map_frames_ex if compiling on rump
   kernel.

Signed-off-by: Ian Jackson 

[ wei: wrap long lines, use __RUMPRUN__ and define macro for map_frames_ex ]

Signed-off-by: Wei Liu 
---
 tools/libxc/Makefile|   2 +-
 tools/libxc/xc_minios.c | 243 +
 tools/libxc/xc_minios_privcmd.c | 291 
 tools/libxc/xc_private.h|   3 +
 4 files changed, 299 insertions(+), 240 deletions(-)
 create mode 100644 tools/libxc/xc_minios_privcmd.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 6fa88c7..4ace2b6 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
 CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
 CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
 CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
-CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
+CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
index e703684..90e3363 100644
--- a/tools/libxc/xc_minios.c
+++ b/tools/libxc/xc_minios.c
@@ -41,164 +41,10 @@
 
 #include "xc_private.h"
 
-void minios_interface_close_fd(int fd);
 void minios_evtchn_close_fd(int fd);
-void minios_gnttab_close_fd(int fd);
-
-extern void minios_interface_close_fd(int fd);
-extern void minios_evtchn_close_fd(int fd);
 
 extern struct wait_queue_head event_queue;
 
-static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
-{
-int fd = alloc_fd(FTYPE_XC);
-
-if ( fd == -1)
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-void minios_interface_close_fd(int fd)
-{
-files[fd].type = FTYPE_NONE;
-}
-
-static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch, 
xc_osdep_handle h, int npages)
-{
-return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
-}
-
-static void minios_privcmd_free_hypercall_buffer(xc_interface *xch, 
xc_osdep_handle h, void *ptr, int npages)
-{
-free(ptr);
-}
-
-static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h, 
privcmd_hypercall_t *hypercall)
-{
-multicall_entry_t call;
-int i, ret;
-
-call.op = hypercall->op;
-for (i = 0; i < ARRAY_SIZE(hypercall->arg); i++)
-   call.args[i] = hypercall->arg[i];
-
-ret = HYPERVISOR_multicall(&call, 1);
-
-if (ret < 0) {
-   errno = -ret;
-   return -1;
-}
-if ((long) call.result < 0) {
-errno = - (long) call.result;
-return -1;
-}
-return call.result;
-}
-
-static void *minios_privcmd_map_foreign_bulk(xc_interface *xch, 
xc_osdep_handle h,
- uint32_t dom, int prot,
- const xen_pfn_t *arr, int *err, 
unsigned int num)
-{
-unsigned long pt_prot = 0;
-if (prot & PROT_READ)
-   pt_prot = L1_PROT_RO;
-if (prot & PROT_WRITE)
-   pt_prot = L1_PROT;
-return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-}
-
-static void *minios_privcmd_map_foreign_batch(xc_interface *xch,  
xc_osdep_handle h,
-  uint32_t dom, int prot,
-  xen_pfn_t *arr, int num)
-{
-unsigned long pt_prot = 0;
-int err[num];
-int i;
-unsigned long addr;
-
-if (prot & PROT_READ)
-   pt_prot = L1_PROT_RO;
-if (prot & PROT_WRITE)
-   pt_prot = L1_PROT;
-
-addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
-for (i = 0; i < num; i++) {
-if (err[i])
-arr[i] |= 0xF000;
-}
-return (void *) addr;
-}
-
-static void *minios_privcmd_map_foreign_range(xc_interface *xch, 
xc_osdep_handle h,
-  uint32_t dom,
-  int size, int prot,
-  unsigned long mfn)
-{
-unsigned long pt_prot = 0;
-
-if (prot & PROT_READ)
-   p

[Xen-devel] [PATCH v6 5/5] xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform

[Frediano Ziglio]

Until vGIC support is not implemented and tested, this will prevent
guest kernels to use their Hip04 driver, or crash when they don't
have any.

Signed-off-by: Frediano Ziglio 
---
 xen/arch/arm/gic-hip04.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index d96a29e..c90ea1e 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -598,17 +598,21 @@ static int hip04gic_make_dt_node(const struct domain *d,
   const struct dt_device_node *node, void *fdt)
 {
 const struct dt_device_node *gic = dt_interrupt_controller;
-const void *compatible = NULL;
+const void *compatible;
 u32 len;
 const __be32 *regs;
 int res = 0;
 
-compatible = dt_get_property(gic, "compatible", &len);
-if ( !compatible )
-{
-dprintk(XENLOG_ERR, "Can't find compatible property for the gic 
node\n");
-return -FDT_ERR_XEN(ENOENT);
-}
+/*
+ * Replace compatibility string with a standard one.
+ * dom0 will see a compatible GIC. This as GICC is compatible
+ * with standard one and GICD (emulated by Xen) is compatible
+ * to standard. Otherwise we should implement HIP04 GICD in
+ * the virtual GIC.
+ * This actually limit CPU number to 8 for dom0.
+ */
+compatible = DT_COMPAT_GIC_CORTEX_A15;
+len = strlen((char*) compatible) + 1;
 
 res = fdt_begin_node(fdt, "interrupt-controller");
 if ( res )
-- 
1.9.1



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

Re: [Xen-devel] [PATCH v3 1/3] x86/numa: Allow arbitrary value of PXM in PXM<->node mapping

[Dario Faggioli]

On Wed, 2015-02-25 at 18:41 -0500, Boris Ostrovsky wrote:
> ACPI defines proximity domain identifier as a 32-bit integer. While
> in most cases the values will be zero-based this is not guaranteed,
> making current pxm2node[256] mapping structure not appropriate.
> 
> We will instead use MAX_NUMNODES-sized array of struct pxm2node to
> store PXM-to-node mapping. To accommodate common case of zero-based
> and contiguios PXMs we will, whenever possible, try to use PXM as
> index into this array array for fast lookups.
> 
^array for fast lookups.

Dario


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/5] NetBSDRump: provide evtchn.h

[Wei Liu]

From: Ian Jackson 

Signed-off-by: Ian Jackson 

[ wei: write commit message ]

Signed-off-by: Wei Liu 
---
 tools/include/xen-sys/NetBSDRump/evtchn.h | 86 +++
 1 file changed, 86 insertions(+)
 create mode 100644 tools/include/xen-sys/NetBSDRump/evtchn.h

diff --git a/tools/include/xen-sys/NetBSDRump/evtchn.h 
b/tools/include/xen-sys/NetBSDRump/evtchn.h
new file mode 100644
index 000..2d8a1f9
--- /dev/null
+++ b/tools/include/xen-sys/NetBSDRump/evtchn.h
@@ -0,0 +1,86 @@
+/* $NetBSD: evtchn.h,v 1.1.1.1 2007/06/14 19:39:45 bouyer Exp $ */
+/**
+ * evtchn.h
+ * 
+ * Interface to /dev/xen/evtchn.
+ * 
+ * Copyright (c) 2003-2005, K A Fraser
+ * 
+ * This file may be distributed separately from the Linux kernel, or
+ * incorporated into other software packages, subject to the following license:
+ * 
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this source file (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use, copy, modify,
+ * merge, publish, distribute, sublicense, and/or sell copies of the Software,
+ * and to permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ * 
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ * 
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#ifndef __NetBSD_EVTCHN_H__
+#define __NetBSD_EVTCHN_H__
+
+/*
+ * Bind a fresh port to VIRQ @virq.
+ */
+#define IOCTL_EVTCHN_BIND_VIRQ \
+   _IOWR('E', 4, struct ioctl_evtchn_bind_virq)
+struct ioctl_evtchn_bind_virq {
+   unsigned int virq;
+   unsigned int port;
+};
+
+/*
+ * Bind a fresh port to remote <@remote_domain, @remote_port>.
+ */
+#define IOCTL_EVTCHN_BIND_INTERDOMAIN  \
+   _IOWR('E', 5, struct ioctl_evtchn_bind_interdomain)
+struct ioctl_evtchn_bind_interdomain {
+   unsigned int remote_domain, remote_port;
+   unsigned int port;
+};
+
+/*
+ * Allocate a fresh port for binding to @remote_domain.
+ */
+#define IOCTL_EVTCHN_BIND_UNBOUND_PORT \
+   _IOWR('E', 6, struct ioctl_evtchn_bind_unbound_port)
+struct ioctl_evtchn_bind_unbound_port {
+   unsigned int remote_domain;
+   unsigned int port;
+};
+
+/*
+ * Unbind previously allocated @port.
+ */
+#define IOCTL_EVTCHN_UNBIND\
+   _IOW('E', 7, struct ioctl_evtchn_unbind)
+struct ioctl_evtchn_unbind {
+   unsigned int port;
+};
+
+/*
+ * Send event to previously allocated @port.
+ */
+#define IOCTL_EVTCHN_NOTIFY\
+   _IOW('E', 8, struct ioctl_evtchn_notify)
+struct ioctl_evtchn_notify {
+   unsigned int port;
+};
+
+/* Clear and reinitialise the event buffer. Clear error condition. */
+#define IOCTL_EVTCHN_RESET \
+   _IO('E', 9)
+
+#endif /* __NetBSD_EVTCHN_H__ */
-- 
1.9.1


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

[Xen-devel] [PATCH 5/5] libxc: rumpxen: Provide xc_osdep_info

[Wei Liu]

From: Ian Jackson 

This allows programs which use the bulk of libxc to link.  We use
/dev/xenevt for event channels, the raw minios functions for privcmd
and gnttab, and the netbsd versions of discard_file_cache and
xc_memalign.

Signed-off-by: Ian Jackson 

[ wei: wrap long lines, adapt to changes in previous patch ]

Signed-off-by: Wei Liu 
---
 tools/libxc/Makefile |  2 ++
 tools/libxc/xc_minios_privcmd.c  | 36 +--
 tools/libxc/xc_netbsd_rumpkern.c | 62 
 3 files changed, 98 insertions(+), 2 deletions(-)
 create mode 100644 tools/libxc/xc_netbsd_rumpkern.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 0f3396c..bce2dd2 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -48,6 +48,8 @@ CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
 CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
 CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_netbsd_user.c
 CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_netbsd_rumpkern.c xc_netbsd_user.c
+CTRL_SRCS-$(CONFIG_NetBSDRump) += xc_minios_privcmd.c
 
 GUEST_SRCS-y :=
 GUEST_SRCS-y += xg_private.c xc_suspend.c
diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 27d9076..a8b1102 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -41,9 +41,19 @@
 
 #include "xc_private.h"
 
-#ifdef __RUMPRUN___
+#ifdef __RUMPRUN__
 # define map_frames_ex minios_map_frames_ex
-#endif /* __RUMPRUN__ */
+
+static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
+{
+return 1;
+}
+static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
+{
+return 0;
+}
+
+#else /* !__RUMPRUN__ */
 
 void minios_interface_close_fd(int fd);
 void minios_gnttab_close_fd(int fd);
@@ -69,6 +79,8 @@ void minios_interface_close_fd(int fd)
 files[fd].type = FTYPE_NONE;
 }
 
+#endif /* !__RUMPRUN__ */
+
 static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch,
   xc_osdep_handle h,
   int npages)
@@ -208,6 +220,24 @@ struct xc_osdep_ops xc_privcmd_ops = {
 },
 };
 
+#ifdef __RUMPRUN__
+
+static struct gntmap static_gntmap;
+
+#define GNTMAP(h) static_gntmap
+
+static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
+{
+return 1;
+}
+
+static int minios_gnttab_close(xc_gnttab *xcg, xc_osdep_handle h)
+{
+return 0;
+}
+
+#else /* !__RUMPRUN__ */
+
 #define GNTMAP(h) (files[(int)(h)].gntmap)
 
 static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
@@ -231,6 +261,8 @@ void minios_gnttab_close_fd(int fd)
 files[fd].type = FTYPE_NONE;
 }
 
+#endif /* !__RUMPRUN__ */
+
 static void *minios_gnttab_grant_map(xc_gnttab *xcg, xc_osdep_handle h,
  uint32_t count, int flags, int prot,
  uint32_t *domids, uint32_t *refs,
diff --git a/tools/libxc/xc_netbsd_rumpkern.c b/tools/libxc/xc_netbsd_rumpkern.c
new file mode 100644
index 000..11d4a63
--- /dev/null
+++ b/tools/libxc/xc_netbsd_rumpkern.c
@@ -0,0 +1,62 @@
+/**
+ *
+ * Copyright 2013 Citrix.
+ * Use is subject to license terms.
+ *
+ * xc_gnttab functions:
+ * Copyright (c) 2007-2008, D G Murray 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  
USA
+ */
+
+#include "xc_private.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct xc_osdep_ops *rumpxen_osdep_init(xc_interface *xch,
+   enum xc_osdep_type type)
+{
+switch ( type )
+{
+case XC_OSDEP_PRIVCMD:
+return &xc_privcmd_ops;
+case XC_OSDEP_EVTCHN:
+return &xc_evtchn_ops;
+case XC_OSDEP_GNTTAB:
+return &xc_gnttab_ops;
+default:
+return NULL;
+}
+}
+
+xc_osdep_info_t xc_osdep_info = {
+.name = "Rump kernel OS interface",
+.init = &rumpxen_osdep_init,
+.fake = 0,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v4] libxl_set_memory_target: retain the same maxmem offset on top of the current target

[Wei Liu]

On Wed, Feb 25, 2015 at 03:18:45PM +, Stefano Stabellini wrote:
> In libxl_set_memory_target when setting the new maxmem, retain the same
> offset on top of the current target. In the future the offset will
> include memory allocated by QEMU for rom files.
> 
> Signed-off-by: Stefano Stabellini 
> 
> ---
> 
> Changes in v4:
> - remove new_target_memkb <= 0 check.
> 
> Changes in v3:
> - move call to libxl__uuid2string and libxl_dominfo_dispose earlier;
> - error out if new_target_memkb <= 0.
> 
> Changes in v2:
> - remove LIBXL_MAXMEM_CONSTANT from LIBXL__LOG_ERRNO.
> ---
>  tools/libxl/libxl.c |   12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 52a783a..143cb3e 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -4681,6 +4681,12 @@ int libxl_set_memory_target(libxl_ctx *ctx, uint32_t 
> domid,
>  char *uuid;
>  xs_transaction_t t;
>  

Should have:

libxl_dominfo_init(&ptr);

> +if (libxl_domain_info(ctx, &ptr, domid) < 0)
> +goto out_no_transaction;
> +
> +uuid = libxl__uuid2string(gc, ptr.uuid);
> +libxl_dominfo_dispose(&ptr);
> +

Since you need to use ptr later, you cannot dispose it here.

You can safely call dispose before returning to caller.

>  retry_transaction:
>  t = xs_transaction_start(ctx->xsh);
>  
> @@ -4756,7 +4762,7 @@ retry_transaction:
>  }
>  
>  if (enforce) {
> -memorykb = new_target_memkb + videoram;
> +memorykb = ptr.max_memkb - current_target_memkb + new_target_memkb;
>  rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb);
>  if (rc != 0) {
>  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> @@ -4786,12 +4792,8 @@ retry_transaction:
>  goto out;
>  }
>  
> -libxl_dominfo_init(&ptr);
> -xcinfo2xlinfo(ctx, &info, &ptr);

If I'm not mistaken, &info is only used here. I think you can delete
info and relevant code all together.

Wei.

> -uuid = libxl__uuid2string(gc, ptr.uuid);
>  libxl__xs_write(gc, t, libxl__sprintf(gc, "/vm/%s/memory", uuid),
>  "%"PRIu32, new_target_memkb / 1024);
> -libxl_dominfo_dispose(&ptr);
>  
>  out:
>  if (!xs_transaction_end(ctx->xsh, t, abort_transaction)
> -- 
> 1.7.10.4

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

Re: [Xen-devel] [PATCH v5.99.1 RFC 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Ian Campbell]

On Wed, 2015-02-25 at 16:59 +, Ian Campbell wrote:
> > I think we should disable the build of all drivers in Xen by default,
> > except for the ARM standard compliant ones (for aarch64 the SBSA is a
> > nice summary of what is considered compliant), to keep the size of the
> > binary small.
> 
> I don't think the SBSA is necessarily the best reference here, since it
> only defines what is standardised within the scope of "server
> systems" (whatever you take that to mean) and there are things which do
> not fall under that umbrella.
> 
> That said I'm not sure what better reference there is.
> 
> Maybe even on non-server systems the set of hardware which Xen has to
> drive itself is limited to things which are covered by the SBSA in
> practice, by the nature of the fact that the majority of the wacky stuff
> is driven from hardware domains.
> 
> So maybe SBSA is OK then...

Having thought about this overnight I'm now not so sure of this again, I
don't think SBSA is the definition we want.

Lets take a step back...

The set of hardware which Xen needs to be able to drive (rather than
give to a hardware domain) is:

  * CPUs
  * Host interrupt controllers
  * Host timers
  * A UART
  * Second-state MMUs
  * Second-stage SMMUs/IOMMU (First-stage used by domains)
  * PCI host bridges (in the near future)

(did I forget any?)

NB: I'm only considering host level stuff here. Our virtualised hardware
as exposed to the guest is well defined right now and any conversation
about deviating from the set of hardware (e.g. providing a guest view to
a non-GIC compliant virtual interrupt controller) would be part of a
separate larger conversation about "hvm" style guests (and I'd, as you
might imagine, be very reluctant to code to Xen itself to support
non-standard vGICs in particular).

>From a "what does 'standards compliant' mean" PoV we have:

CPUs:

Specified in the ARM ARM (v7=ARM DDI 0406, v8=ARM DDI 0487).

Uncontroversial, I hope!

Host interrupt controllers:

Defined in "ARM Generic Interrupt Controller Architecture
Specification" (v2=ARM IHI 0048B, v3=???).

Referenced from ARMv8 ARM (but not required AFAICT) but
nonetheless this is what we consider when we talk about the
"standard interrupt controller".

Host timers:

Defined in the ARMv8 ARM "Generic Timers" chapter.

Defined as an extension to ARMv7 (don't have doc ref handy). For
our purposes such extensions are considered standardized[*].

UARTS:

SBSA defines some (pl011 only?), but there are lots, including
8250-alike ones (ns16550 etc) which is a well established
standard (from x86).

Given that UART drivers are generally small and pretty trivial I
think we can tolerate "non-standard" (i.e. non-SBSA, non-8250)
ones, so long as they are able to support our vuart interface.

I think the non-{pl011,8250} ones should be subject to non-core
(i.e. community) maintenance as I mentioned previously, i.e
should be listed in MAINTAINERS other than under the core ARM
entry. If we decide to go ahead with this approach I'll ask the
appropriate people to update MAINTAINERS.

Second stage MMU:

Defined in the ARMv8 ARM, or the ARMv7 LPAE extensions[*, **].

Second stage SMMU/IOMMU:

Defined in "ARM System Memory Management Unit Architecture
Specification" (ARM IHI 0062D?)

PCI host bridges:

We don't actually (properly) support PCI yet, but see my mails
in the "Enhance platform support for PCI" thread this morning,
for what we think the general shape might be taking.

The meaning of the PCI CFG (CAM, ECAM etc), MMIO and IO (MMIO
mapped) regions are, I think, all pretty well defined by the
(various?) PCI spec(s).

What's not quite so clear cut is the discovery of where the
controllers actually live (based on the fact that
Documentation/devicetree/bindings/pci/ has more than one entry
in it...).

SBSA doesn't really cover this either, it says "The base address
of each ECAM region within the system memory map is
IMPLEMENTATION DEFINED and is expected to be discoverable from
system firmware data."

However I think it will be the case that most "pci host bridge
drivers" for Xen will end up being fairly trivial affairs, i.e.
parse the DT, perhaps a little bit of basic setup and register
the resulting regions with the PCI core and perhaps provide some
simple accessors.

So, I think we can say that for PCI controllers which export a
set of PCI standard CFG, MMIO, IO space regions (all as MMIO
mapped regions) and just require a specific driver for discovery
of the hos

[Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]

[Wei Liu]

From: Ian Jackson 

We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.

As part of this we want to abstract away the use of files[] inside the
actual functions.  Do this with a #define whose definition we are
going to make conditional in just a moment.

No functional change in this patch.

Signed-off-by: Ian Jackson 
---
 tools/libxc/xc_minios_privcmd.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 7766b86..27d9076 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
 },
 };
 
+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
 static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
 {
 int fd = alloc_fd(FTYPE_GNTMAP);
 if ( fd == -1 )
 return XC_OSDEP_OPEN_ERROR;
-gntmap_init(&files[fd].gntmap);
+gntmap_init(&GNTMAP(h));
 return (xc_osdep_handle)fd;
 }
 
@@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg, 
xc_osdep_handle h)
 
 void minios_gnttab_close_fd(int fd)
 {
-gntmap_fini(&files[fd].gntmap);
+gntmap_fini(&GNTMAP(h));
 files[fd].type = FTYPE_NONE;
 }
 
@@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg, 
xc_osdep_handle h,
  uint32_t notify_offset,
  evtchn_port_t notify_port)
 {
-int fd = (int)h;
 int stride = 1;
 if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
 stride = 0;
@@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg, 
xc_osdep_handle h,
 errno = ENOSYS;
 return NULL;
 }
-return gntmap_map_grant_refs(&files[fd].gntmap,
+return gntmap_map_grant_refs(&GNTMAP(h),
  count, domids, stride,
  refs, prot & PROT_WRITE);
 }
@@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg, 
xc_osdep_handle h,
 void *start_address,
 uint32_t count)
 {
-int fd = (int)h;
 int ret;
-ret = gntmap_munmap(&files[fd].gntmap,
+ret = gntmap_munmap(&GNTMAP(h),
 (unsigned long) start_address,
 count);
 if (ret < 0) {
@@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg, 
xc_osdep_handle h,
 static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
  uint32_t count)
 {
-int fd = (int)h;
 int ret;
-ret = gntmap_set_max_grants(&files[fd].gntmap,
+ret = gntmap_set_max_grants(&GNTMAP(h),
 count);
 if (ret < 0) {
 errno = -ret;
-- 
1.9.1


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

Re: [Xen-devel] [PATCH] honor MEMF_no_refcount in alloc_heap_pages()

[Tim Deegan]

At 14:42 + on 25 Feb (1424871753), Jan Beulich wrote:
> Non-anonymous allocations with this flag set should - for the purpose
> of the availability check - be treated just like anonymous ones, as
> they wouldn't lead to a reduction of ->outstanding_pages.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Tim Deegan 

> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -617,7 +617,8 @@ static struct page_info *alloc_heap_page
>   */
>  if ( (outstanding_claims + request >
>total_avail_pages + tmem_freeable_pages()) &&
> -  (d == NULL || d->outstanding_pages < request) )
> +  ((memflags & MEMF_no_refcount) ||
> +   !d || d->outstanding_pages < request) )
>  goto not_found;
>  
>  /*
> 

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

Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?

[Lars Kurth]

Tim, Andrew, Jan,
it seems as if we are slowly coming to some conclusion on this thread. If
I am mistaken, I am wondering whether it would make sense to have an IRC
meeting with all the involved stake-holders and report back to the list.
Regards
Lars

On 26/02/2015 10:52, "Tim Deegan"  wrote:

>At 10:50 + on 24 Feb (1424771408), Andrew Cooper wrote:
>> On 24/02/15 10:31, Jan Beulich wrote:
>>  On 24.02.15 at 11:24,  wrote:
>> >> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote:
>> >>> Currently Jan Beulich is not happy with the addition of a new domain
>> >>> creation flag.  Andrew Cooper is not happy with a HVM param.  I am
>>stuck
>> >>> in the middle.
>> >> I prefer a new flag, for anything that's fixed for the life of the
>> >> domain.  We've already had too many bugs where HVM params changed
>> >> when people thought they wouldn't.
>> >>
>> >> Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits?
>>I
>> >> think we can add more flag fields to DOMCTL_createdomain (or a v2) if
>> >> that becomes a problem.
>> > In a couple of years we may end up with an x86-CPUID-like mess
>> > of hundreds of flags. And apart from that scalability issue I also
>> > dislike the gross mixing of arch specific and generic flags here.
>> > Perhaps the already arch-specific XEN_DOMCTL_configure_domain
>> > would be the better route then if HVM params are being disliked?
>> 
>> Given some recent consideration to the problem of domain architectural
>> state (x86 cpuid policy, arm gic/spi), a (set of?) configuration
>> hypercalls valid only during domain construction would perhaps be the
>> best way to proceed.
>
>That sounds like you're also arguing for using HVM params then.  :)
>
>The nice thing about having a single set of flags at creation time is
>that it avoids any worrying about what order the flag-setting and the
>init of VM state happens in (e.g. turning on a feature after vcpus are
>already assigned means extra code to update them; having the features
>be settable in any order means handling all O(N^2) interactions).
>
>> Extending createdomain itself is incompatible with XSM disaggregation
>
>Hrm.  Possibly, but I think that might be splitting hairs.
>A privileged VM creation component will already have to check its
>arguments (e.g. memory size, #vcpus, boot image) against some policy.
>
>> and having the architectural state in the migration stream.
>
>Not at all -- since these flags are immutable, you can trivially send
>them before any other state.  If a toolstack can't remember what it
>did, we could add a what-were-the-creation-flags domctl.
>
>Tim.

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

Re: [Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]

[Jürgen Groß]

On 02/26/2015 12:56 PM, Wei Liu wrote:

From: Ian Jackson 

We are going to want to reuse this code for NetBSD rump kernels, where
there is no gntmap device and we just want to call the MiniOS gntmap
code directly.

As part of this we want to abstract away the use of files[] inside the
actual functions.  Do this with a #define whose definition we are
going to make conditional in just a moment.

No functional change in this patch.

Signed-off-by: Ian Jackson 
---
  tools/libxc/xc_minios_privcmd.c | 15 +++
  1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
index 7766b86..27d9076 100644
--- a/tools/libxc/xc_minios_privcmd.c
+++ b/tools/libxc/xc_minios_privcmd.c
@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
  },
  };

+#define GNTMAP(h) (files[(int)(h)].gntmap)
+
  static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
  {
  int fd = alloc_fd(FTYPE_GNTMAP);
  if ( fd == -1 )
  return XC_OSDEP_OPEN_ERROR;
-gntmap_init(&files[fd].gntmap);
+gntmap_init(&GNTMAP(h));


GNTMAP(fd)?

Same multiple times below.


Juergen


  return (xc_osdep_handle)fd;
  }

@@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg, 
xc_osdep_handle h)

  void minios_gnttab_close_fd(int fd)
  {
-gntmap_fini(&files[fd].gntmap);
+gntmap_fini(&GNTMAP(h));
  files[fd].type = FTYPE_NONE;
  }

@@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg, 
xc_osdep_handle h,
   uint32_t notify_offset,
   evtchn_port_t notify_port)
  {
-int fd = (int)h;
  int stride = 1;
  if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
  stride = 0;
@@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg, 
xc_osdep_handle h,
  errno = ENOSYS;
  return NULL;
  }
-return gntmap_map_grant_refs(&files[fd].gntmap,
+return gntmap_map_grant_refs(&GNTMAP(h),
   count, domids, stride,
   refs, prot & PROT_WRITE);
  }
@@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg, 
xc_osdep_handle h,
  void *start_address,
  uint32_t count)
  {
-int fd = (int)h;
  int ret;
-ret = gntmap_munmap(&files[fd].gntmap,
+ret = gntmap_munmap(&GNTMAP(h),
  (unsigned long) start_address,
  count);
  if (ret < 0) {
@@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg, 
xc_osdep_handle h,
  static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
   uint32_t count)
  {
-int fd = (int)h;
  int ret;
-ret = gntmap_set_max_grants(&files[fd].gntmap,
+ret = gntmap_set_max_grants(&GNTMAP(h),
  count);
  if (ret < 0) {
  errno = -ret;




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

[Xen-devel] [PATCH v6 4/5] xen/arm: handle GICH register changes for hip04-d01 platform

[Frediano Ziglio]

The GICH in this platform is mainly compatible with the standard
GICv2 beside APR and LR register offsets.

Signed-off-by: Frediano Ziglio 
---
 xen/arch/arm/gic-hip04.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index 84d60fd..d96a29e 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -87,6 +87,9 @@ static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 #define HIP04_GICD_SGI_TARGET_SHIFT 8
 
+#define HIP04_GICH_APR   0x70
+#define HIP04_GICH_LR0x80
+
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
 writeb_relaxed(val, hip04gic.map_dbase + offset);
@@ -156,9 +159,9 @@ static void hip04gic_save_state(struct vcpu *v)
  * accessed simultaneously by another pCPU.
  */
 for ( i = 0; i < hip04gic_info.nr_lrs; i++ )
-v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+v->arch.gic.v2.lr[i] = readl_gich(HIP04_GICH_LR + i * 4);
 
-v->arch.gic.v2.apr = readl_gich(GICH_APR);
+v->arch.gic.v2.apr = readl_gich(HIP04_GICH_APR);
 v->arch.gic.v2.vmcr = readl_gich(GICH_VMCR);
 /* Disable until next VCPU scheduled */
 writel_gich(0, GICH_HCR);
@@ -169,9 +172,9 @@ static void hip04gic_restore_state(const struct vcpu *v)
 int i;
 
 for ( i = 0; i < hip04gic_info.nr_lrs; i++ )
-writel_gich(v->arch.gic.v2.lr[i], GICH_LR + i * 4);
+writel_gich(v->arch.gic.v2.lr[i], HIP04_GICH_LR + i * 4);
 
-writel_gich(v->arch.gic.v2.apr, GICH_APR);
+writel_gich(v->arch.gic.v2.apr, HIP04_GICH_APR);
 writel_gich(v->arch.gic.v2.vmcr, GICH_VMCR);
 writel_gich(GICH_HCR_EN, GICH_HCR);
 }
@@ -184,7 +187,7 @@ static void hip04gic_dump_state(const struct vcpu *v)
 {
 for ( i = 0; i < hip04gic_info.nr_lrs; i++ )
 printk("   HW_LR[%d]=%x\n", i,
-   readl_gich(GICH_LR + i * 4));
+   readl_gich(HIP04_GICH_LR + i * 4));
 }
 else
 {
@@ -412,12 +415,12 @@ static void hip04gic_update_lr(int lr, const struct 
pending_irq *p,
 << GICH_V2_LR_PHYSICAL_SHIFT);
 }
 
-writel_gich(lr_reg, GICH_LR + lr * 4);
+writel_gich(lr_reg, HIP04_GICH_LR + lr * 4);
 }
 
 static void hip04gic_clear_lr(int lr)
 {
-writel_gich(0, GICH_LR + lr * 4);
+writel_gich(0, HIP04_GICH_LR + lr * 4);
 }
 
 static int hip04gicv_setup(struct domain *d)
@@ -465,7 +468,7 @@ static void hip04gic_read_lr(int lr, struct gic_lr *lr_reg)
 {
 uint32_t lrv;
 
-lrv  = readl_gich(GICH_LR + lr * 4);
+lrv  = readl_gich(HIP04_GICH_LR + lr * 4);
 lr_reg->pirq = (lrv >> GICH_V2_LR_PHYSICAL_SHIFT) & 
GICH_V2_LR_PHYSICAL_MASK;
 lr_reg->virq = (lrv >> GICH_V2_LR_VIRTUAL_SHIFT) & GICH_V2_LR_VIRTUAL_MASK;
 lr_reg->priority = (lrv >> GICH_V2_LR_PRIORITY_SHIFT) & 
GICH_V2_LR_PRIORITY_MASK;
@@ -488,7 +491,7 @@ static void hip04gic_write_lr(int lr, const struct gic_lr 
*lr_reg)
<< GICH_V2_LR_HW_SHIFT)  |
   ((uint32_t)(lr_reg->grp & GICH_V2_LR_GRP_MASK) << 
GICH_V2_LR_GRP_SHIFT) );
 
-writel_gich(lrv, GICH_LR + lr * 4);
+writel_gich(lrv, HIP04_GICH_LR + lr * 4);
 }
 
 static void hip04gic_hcr_status(uint32_t flag, bool_t status)
@@ -511,7 +514,7 @@ static unsigned int hip04gic_read_vmcr_priority(void)
 
 static unsigned int hip04gic_read_apr(int apr_reg)
 {
-   return readl_gich(GICH_APR);
+   return readl_gich(HIP04_GICH_APR);
 }
 
 static void hip04gic_irq_enable(struct irq_desc *desc)
-- 
1.9.1



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

[Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Frediano Ziglio]

HiSilison Hip04 platform use a slightly different version.
This is just a verbatim copy of the file to workaround git
not fully supporting copy operation.

Signed-off-by: Frediano Ziglio 
---
 xen/arch/arm/gic-hip04.c | 788 +++
 1 file changed, 788 insertions(+)
 create mode 100644 xen/arch/arm/gic-hip04.c

diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
new file mode 100644
index 000..a401e3f
--- /dev/null
+++ b/xen/arch/arm/gic-hip04.c
@@ -0,0 +1,788 @@
+/*
+ * xen/arch/arm/gic-v2.c
+ *
+ * ARM Generic Interrupt Controller support v2
+ *
+ * Tim Deegan 
+ * Copyright (c) 2011 Citrix Systems.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/*
+ * LR register definitions are GIC v2 specific.
+ * Moved these definitions from header file to here
+ */
+#define GICH_V2_LR_VIRTUAL_MASK0x3ff
+#define GICH_V2_LR_VIRTUAL_SHIFT   0
+#define GICH_V2_LR_PHYSICAL_MASK   0x3ff
+#define GICH_V2_LR_PHYSICAL_SHIFT  10
+#define GICH_V2_LR_STATE_MASK  0x3
+#define GICH_V2_LR_STATE_SHIFT 28
+#define GICH_V2_LR_PRIORITY_SHIFT  23
+#define GICH_V2_LR_PRIORITY_MASK   0x1f
+#define GICH_V2_LR_HW_SHIFT31
+#define GICH_V2_LR_HW_MASK 0x1
+#define GICH_V2_LR_GRP_SHIFT   30
+#define GICH_V2_LR_GRP_MASK0x1
+#define GICH_V2_LR_MAINTENANCE_IRQ (1<<19)
+#define GICH_V2_LR_GRP1(1<<30)
+#define GICH_V2_LR_HW  (1<<31)
+#define GICH_V2_LR_CPUID_SHIFT 9
+#define GICH_V2_VTR_NRLRGS 0x3f
+
+#define GICH_V2_VMCR_PRIORITY_MASK   0x1f
+#define GICH_V2_VMCR_PRIORITY_SHIFT  27
+
+/* Global state */
+static struct {
+paddr_t dbase;/* Address of distributor registers */
+void __iomem * map_dbase; /* IO mapped Address of distributor registers */
+paddr_t cbase;/* Address of CPU interface registers */
+void __iomem * map_cbase[2]; /* IO mapped Address of CPU interface 
registers */
+paddr_t hbase;/* Address of virtual interface registers */
+void __iomem * map_hbase; /* IO Address of virtual interface registers */
+paddr_t vbase;/* Address of virtual cpu interface registers */
+spinlock_t lock;
+} gicv2;
+
+static struct gic_info gicv2_info;
+
+/* The GIC mapping of CPU interfaces does not necessarily match the
+ * logical CPU numbering. Let's use mapping as returned by the GIC
+ * itself
+ */
+static DEFINE_PER_CPU(u8, gic_cpu_id);
+
+/* Maximum cpu interface per GIC */
+#define NR_GIC_CPU_IF 8
+
+static inline void writeb_gicd(uint8_t val, unsigned int offset)
+{
+writeb_relaxed(val, gicv2.map_dbase + offset);
+}
+
+static inline void writel_gicd(uint32_t val, unsigned int offset)
+{
+writel_relaxed(val, gicv2.map_dbase + offset);
+}
+
+static inline uint32_t readl_gicd(unsigned int offset)
+{
+return readl_relaxed(gicv2.map_dbase + offset);
+}
+
+static inline void writel_gicc(uint32_t val, unsigned int offset)
+{
+unsigned int page = offset >> PAGE_SHIFT;
+offset &= ~PAGE_MASK;
+writel_relaxed(val, gicv2.map_cbase[page] + offset);
+}
+
+static inline uint32_t readl_gicc(unsigned int offset)
+{
+unsigned int page = offset >> PAGE_SHIFT;
+offset &= ~PAGE_MASK;
+return readl_relaxed(gicv2.map_cbase[page] + offset);
+}
+
+static inline void writel_gich(uint32_t val, unsigned int offset)
+{
+writel_relaxed(val, gicv2.map_hbase + offset);
+}
+
+static inline uint32_t readl_gich(int unsigned offset)
+{
+return readl_relaxed(gicv2.map_hbase + offset);
+}
+
+static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
+{
+unsigned int cpu;
+unsigned int mask = 0;
+cpumask_t possible_mask;
+
+cpumask_and(&possible_mask, cpumask, &cpu_possible_map);
+for_each_cpu( cpu, &possible_mask )
+{
+ASSERT(cpu < NR_GIC_CPU_IF);
+mask |= per_cpu(gic_cpu_id, cpu);
+}
+
+return mask;
+}
+
+static void gicv2_save_state(struct vcpu *v)
+{
+int i;
+
+/* No need for spinlocks here because interrupts are disabled around
+ * this call and it only accesses struct vcpu fields that cannot be
+ * accessed simultaneously by another pCPU.
+ */
+for ( i = 0; i < gicv2_info.nr_lrs; i++ )
+v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
+
+v->arch.gic.v2.apr = readl_gich(GICH_APR);
+v-

[Xen-devel] [PATCH v6 0/5] xen/arm: Add support for Huawei hip04-d01 platform

[Frediano Ziglio]

This set of patches add Xen support for hip04-d01 platform (see
https://wiki.linaro.org/Boards/D01 for details).

Changes from V5.99.1:
- removed RFC again;
- use different constants for hip04 instead of redefine standard ones;
- comment compatible string change;
- add an option to ARM to enable non standard drivers;
- rename gicv2 to hip04gic to make clear this is not a standard gic.

Changes from v5:
- do not change gic-v2.c code but use a copy.

To be considered RFC, to see if better to use copy or other techniques.

Changes from v4:
- rebased to new version;
- removed patch for computing GIC addresses as it apply to all platforms;
- removed patches to platform (cpu and system operations) as now they can
  use a bootwrapper which provide them.

Changes from v3:
- change the way regs property is computed for GICv2 (Julien Grall);
- revert order of compaible names for GIC (Julien Grall).

Changes from v2:
- rewrote DTS fix patch (Ian Campbell);
- use is_hip04 macro instead of doing explicit test (Julien Grall);
- do not use quirks to distinguish this platform (Ian Cambell);
- move some GIC constants to C files instead of header (Julien Grall);
- minor changes (Julien Grall).

Changes from v1:
- style (Julien Grall);
- make gicv2_send_SGI faster (Julien Grall);
- cleanup correctly if hip04_smp_init fails (Julien Grall);
- remove quirks using compatibility (Ian Campbell);
- other minor suggestions by Julien Grall.

Frediano Ziglio (5):
  xen/arm: Duplicate gic-v2.c file to support hip04 platform version
  xen/arm: Add HAS_NON_STANDARD_DRIVERS build option to arm
  xen/arm: Make gic-v2 code handle hip04-d01 platform
  xen/arm: handle GICH register changes for hip04-d01 platform
  xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform

 xen/arch/arm/Makefile   |   3 +
 xen/arch/arm/Rules.mk   |   1 +
 xen/arch/arm/domain_build.c |   1 +
 xen/arch/arm/gic-hip04.c| 800 
 xen/arch/arm/gic.c  |   3 +-
 xen/include/asm-arm/gic.h   |   4 +
 6 files changed, 811 insertions(+), 1 deletion(-)
 create mode 100644 xen/arch/arm/gic-hip04.c

-- 
1.9.1



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

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Ian Campbell]

On Thu, 2015-02-26 at 15:39 +0530, Manish Jaggi wrote:
> Have you reached a conclusion?

My current thinking on how PCI for Xen on ARM should look is thus:

xen/arch/arm/pci.c:

New file, containing core PCI infrastructure for ARM. Includes:

pci_hostbridge_register(), which registers a host bridge:

Registration includes:
DT node pointer

CFG space address

pci_hostbridge_ops function table, which
contains e.g. cfg space read/write ops, perhaps
other stuff).

Function for setting the (segment,bus) for a given host bridge.
Lets say pci_hostbridge_setup(), the host bridge must have been
previously registered. Looks up the host bridge via CFG space
address and maps that to (segment,bus).

Functions for looking up host bridges by various keys as needed
(cfg base address, DT node, etc)

pci_init() function, called from somewhere appropriate in
setup.c which calls device_init(node, DEVICE_PCIHOST, NULL) (see
gic_init() for the shape of this)

Any other common helper functions for managing PCI devices, e.g.
for implementing PHYSDEVOP_*, which cannot be made properly
common (i.e. shared with x86).

xen/drivers/pci/host-*.c (or pci/host/*.c):

New files, one per supported PCI controller IP block. Each
should use the normal DT_DEVICE infrastructure for probing,
i.e.:
DT_DEVICE_START(foo, "FOO", DEVICE_PCIHOST)

Probe function should call pci_hostbridge_register() for each
host bridge which the controller exposes.

xen/arch/arm/physdev.c:

Implements do_physdev_op handling PHYSDEVOP_*. Includes:

New hypercall subop PHYSDEVOP_pci_host_bridge_add:

As per 1424703761.27930.140.ca...@citrix.com> which
calls pci_hostbridge_setup() to map the (segment,bus) to
a specific pci_hostbridge_ops (i.e. must have previously
been registered with pci_hostbridge_register(), else
error).

PHYSDEVOP_pci_device_add/remove: Implement existing hypercall
interface used by x86 for ARM.

This requires that PHYSDEVOP_pci_host_bridge_add has
been called for the (segment,bus) which it refers to,
otherwise error.

Looks up the host bridge and does whatever setup is
required plus e.g. calling of pci_add_device().

No doubt various other existing interfaces will need wiring up, e.g.
pci_conf_{read,write}* should lookup the host bridge ops struct and call
the associated method.

I'm sure the above must be incomplete, but I hope the general shape
makes sense?

Ian.


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

[Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform

[Frediano Ziglio]

The GIC in this platform is mainly compatible with the standard
GICv2 beside:
- ITARGET is extended to 16 bit to support 16 CPUs;
- SGI mask is extended to support 16 CPUs;
- maximum supported interrupt is 510.

Use nr_lines to check for maximum irq supported. hip04-d01 support less
interrupts due to some field restriction. Any value above this is already
an error.

Signed-off-by: Frediano Ziglio 
Signed-off-by: Zoltan Kiss 
---
 xen/arch/arm/Makefile   |   3 +
 xen/arch/arm/domain_build.c |   1 +
 xen/arch/arm/gic-hip04.c| 351 ++--
 xen/arch/arm/gic.c  |   3 +-
 xen/include/asm-arm/gic.h   |   4 +
 5 files changed, 188 insertions(+), 174 deletions(-)

diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 41aba2e..fad72d2 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -12,6 +12,9 @@ obj-y += domctl.o
 obj-y += sysctl.o
 obj-y += domain_build.o
 obj-y += gic.o gic-v2.o
+ifeq (arm32,$(XEN_TARGET_ARCH))
+obj-$(HAS_NON_STANDARD_DRIVERS) += gic-hip04.o
+endif
 obj-$(CONFIG_ARM_64) += gic-v3.o
 obj-y += io.o
 obj-y += irq.o
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index c2dcb49..0834053 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct 
kernel_info *kinfo,
 static const struct dt_device_match gic_matches[] __initconst =
 {
 DT_MATCH_GIC_V2,
+DT_MATCH_GIC_HIP04,
 DT_MATCH_GIC_V3,
 { /* sentinel */ },
 };
diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
index a401e3f..84d60fd 100644
--- a/xen/arch/arm/gic-hip04.c
+++ b/xen/arch/arm/gic-hip04.c
@@ -1,7 +1,8 @@
 /*
- * xen/arch/arm/gic-v2.c
+ * xen/arch/arm/gic-hip04.c
  *
- * ARM Generic Interrupt Controller support v2
+ * Generic Interrupt Controller for HiSilicon Hip04 platform
+ * Based heavily from gic-v2.c
  *
  * Tim Deegan 
  * Copyright (c) 2011 Citrix Systems.
@@ -71,59 +72,66 @@ static struct {
 void __iomem * map_hbase; /* IO Address of virtual interface registers */
 paddr_t vbase;/* Address of virtual cpu interface registers */
 spinlock_t lock;
-} gicv2;
+} hip04gic;
 
-static struct gic_info gicv2_info;
+static struct gic_info hip04gic_info;
 
 /* The GIC mapping of CPU interfaces does not necessarily match the
  * logical CPU numbering. Let's use mapping as returned by the GIC
  * itself
  */
-static DEFINE_PER_CPU(u8, gic_cpu_id);
+static DEFINE_PER_CPU(u16, gic_cpu_id);
 
 /* Maximum cpu interface per GIC */
-#define NR_GIC_CPU_IF 8
+#define NR_GIC_CPU_IF 16
+
+#define HIP04_GICD_SGI_TARGET_SHIFT 8
 
 static inline void writeb_gicd(uint8_t val, unsigned int offset)
 {
-writeb_relaxed(val, gicv2.map_dbase + offset);
+writeb_relaxed(val, hip04gic.map_dbase + offset);
+}
+
+static inline void writew_gicd(uint16_t val, unsigned int offset)
+{
+writew_relaxed(val, hip04gic.map_dbase + offset);
 }
 
 static inline void writel_gicd(uint32_t val, unsigned int offset)
 {
-writel_relaxed(val, gicv2.map_dbase + offset);
+writel_relaxed(val, hip04gic.map_dbase + offset);
 }
 
 static inline uint32_t readl_gicd(unsigned int offset)
 {
-return readl_relaxed(gicv2.map_dbase + offset);
+return readl_relaxed(hip04gic.map_dbase + offset);
 }
 
 static inline void writel_gicc(uint32_t val, unsigned int offset)
 {
 unsigned int page = offset >> PAGE_SHIFT;
 offset &= ~PAGE_MASK;
-writel_relaxed(val, gicv2.map_cbase[page] + offset);
+writel_relaxed(val, hip04gic.map_cbase[page] + offset);
 }
 
 static inline uint32_t readl_gicc(unsigned int offset)
 {
 unsigned int page = offset >> PAGE_SHIFT;
 offset &= ~PAGE_MASK;
-return readl_relaxed(gicv2.map_cbase[page] + offset);
+return readl_relaxed(hip04gic.map_cbase[page] + offset);
 }
 
 static inline void writel_gich(uint32_t val, unsigned int offset)
 {
-writel_relaxed(val, gicv2.map_hbase + offset);
+writel_relaxed(val, hip04gic.map_hbase + offset);
 }
 
 static inline uint32_t readl_gich(int unsigned offset)
 {
-return readl_relaxed(gicv2.map_hbase + offset);
+return readl_relaxed(hip04gic.map_hbase + offset);
 }
 
-static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
+static unsigned int hip04gic_cpu_mask(const cpumask_t *cpumask)
 {
 unsigned int cpu;
 unsigned int mask = 0;
@@ -139,7 +147,7 @@ static unsigned int gicv2_cpu_mask(const cpumask_t *cpumask)
 return mask;
 }
 
-static void gicv2_save_state(struct vcpu *v)
+static void hip04gic_save_state(struct vcpu *v)
 {
 int i;
 
@@ -147,7 +155,7 @@ static void gicv2_save_state(struct vcpu *v)
  * this call and it only accesses struct vcpu fields that cannot be
  * accessed simultaneously by another pCPU.
  */
-for ( i = 0; i < gicv2_info.nr_lrs; i++ )
+for ( i = 0; i < hip04gic_info.nr_lrs; i++ )
 v->arch.gic.v2.lr[i] = readl_gich(GICH_LR + i * 4);
 
 

[Xen-devel] [PATCH v6 2/5] xen/arm: Add HAS_NON_STANDARD_DRIVERS build option to arm

[Frediano Ziglio]

Allow to enable non standard drivers in Xen.
Can be override in .config file.

Signed-off-by: Frediano Ziglio 
---
 xen/arch/arm/Rules.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk
index c7bd227..4ed142a 100644
--- a/xen/arch/arm/Rules.mk
+++ b/xen/arch/arm/Rules.mk
@@ -11,6 +11,7 @@ HAS_VIDEO := y
 HAS_ARM_HDLCD := y
 HAS_PASSTHROUGH := y
 HAS_PDX := y
+HAS_NON_STANDARD_DRIVERS ?= n
 
 CFLAGS += -I$(BASEDIR)/include
 
-- 
1.9.1



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

Re: [Xen-devel] [PATCH] libxl: remove LIBXL_MAXMEM_CONSTANT

[Ian Campbell]

On Thu, 2015-02-26 at 12:19 +, Stefano Stabellini wrote:
> On Wed, 25 Feb 2015, Don Slutz wrote:
> > On 02/25/15 10:07, Stefano Stabellini wrote:
> > > LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a
> > > domain by a constant amount. As it is not clear the reason why we should
> > > be doing this, remove the constant.
> > > 
> > > Signed-off-by: Stefano Stabellini 
> > > CC: mlati...@suse.com
> > > CC: ian.campb...@citrix.com
> > > ---
> > 
> > I think that some sort of link to commit 901230f in QEMU:
> > 
> > 
> > commit 901230fd8ce053cc21312a2eca2f3ba9f1d103f2
> > Author: Stefano Stabellini 
> > Date:   Wed Dec 3 08:15:19 2014 -0500
> > 
> > xen-hvm: increase maxmem before calling xc_domain_populate_physmap
> > 
> > Increase maxmem before calling xc_domain_populate_physmap_exact to
> > avoid the risk of running out of guest memory. This way we can also
> > avoid complex memory calculations in libxl at domain construction
> > time.
> > 
> > This patch fixes an abort() when assigning more than 4 NICs to a VM.
> > 
> > upstream-commit-id: c1d322e6048796296555dd36fdd102d7fa2f50bf
> > 
> > Signed-off-by: Stefano Stabellini 
> > Signed-off-by: Don Slutz 
> > 
> > 
> > Because after this patch and without a "correct" QEMU, the number of
> > e1000 NICs a guest can use is less then 4.
> 
> That is true, in fact is not even a single emulated NIC in my tests.
> I can either ask for a backport of
> c1d322e6048796296555dd36fdd102d7fa2f50bf "xen-hvm: increase maxmem
> before calling xc_domain_populate_physmap" to all QEMU stable branches,

It can't hurt to ask, I think?

> or we just have to keep this around for now and maybe just add a comment
> on why it is needed.

(assuming they say no to the backports)

Could we at least make it x86/HVM specific?

Ian.


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

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Ian Campbell]

On Thu, 2015-02-26 at 16:19 +0530, Vijay Kilari wrote:
> On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell  wrote:
> > On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
> >> On 24/02/15 7:13 pm, Julien Grall wrote:
> >> > On 24/02/15 00:23, Manish Jaggi wrote:
> >> >>> Because you have to parse all the device tree to remove the reference
> >> >>> to the second ITS. It's pointless and can be difficult to do it.
> >> >>>
> >> >> Could you please describe the case where it is difficult
> >> > You have to parse every node in the device tree and replace the
> >> > msi-parent properties with only one ITS.
> >> Thats the idea.
> >> >
> >> >>> If you are able to emulate on ITS, you can do it for multiple one.
> >> >> keeping it simple and similar across dom0/domUs
> >> >> Consider a case where a domU is assigned two PCI devices which are
> >> >> attached to different nodes. (Node is an entity having its own cores are
> >> >> host controllers).
> >> > The DOM0 view and guest view of the hardware are different.
> >> >
> >> > In the case of DOM0, we want to expose the same hardware layout as the
> >> > host. So if there is 2 ITS then we should expose the 2 ITS.
> >> AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are
> >> handled by xen and a virtualized interface is provided to the guest. So
> >> if none of SMMU in the layout of host is presented to dom0 the same can
> >> be valid for multiple ITS.
> >
> > SMMU is one of the things which Xen hides from dom0, for obvious
> > reasons.
> >
> > Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no
> > reason for ITS to differ here.
> >
> > Since dom0 needs to be able to cope with being able to see all of the
> > host host I/O devices (in the default no-passthrough case), it is
> > possible, if not likely, that it will need the same amount of ITS
> > resources (i.e. numbers of LPIs) as the host provides.
> >
> >> > In the case of the Guest, we (Xen) controls the memory layout.
> >> For Dom0 as well.
> >
> > Not true.
> >
> > For dom0 the memory layout is determined by the host memory layout. The
> > MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM
> > regions of the host physical address space (often in 1:1, but with
> > sufficient h/w support this need not be the case).
> >
> >> > Therefore
> >> > we can expose only one ITS.
> >> If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen
> >> GIC ITS emulation driver to work.
> >> It should check that request came from a dom0 handle it differently. I
> >> think this would be *difficult*.
> >
> > I don't think so. If the vITS is written to handle multiple instances
> > (i.e. in a modular way, as it should be) then it shouldn't matter
> > whether any given domain has 1 or many vITS. The fact that dom0 may have
> > one or more and domU only (currently) has one then becomes largely
> > uninteresting.
> 
> I have few queries
> 
> 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS
> command Q is
> mapped to which Physical ITS command Q.
> In case of linux, the ITS node is added as msi chip to pci using
> of_pci_msi_chip_add()
> and from pci_dev structure we can know which ITS to use.
> 
> But in case of Xen, when ITS command is trapped we have only
> dev_id info from ITS command.

With the proper PCI infrastructure in place we can map the vdev_id to a
pdev_id, and from there to our own struct pci_dev 

The mapping from pdev_id to pci_dev is based on the
PHYSDEVOP_pci_host_bridge_add and PHYSDEVOP_pci_device_add calls I
described just now in my mail to Manish in this thread (specifically
pci_device_add creates and registers struct pci_dev I think).

> 
> 2) If DomU is always given one virtual ITS node. If DomU is assinged
> with two different
> PCI devices connected to different physical ITS, then Xen vITS
> driver should know how to map
> PCI device to physical ITS

Correct, I think that all falls out from the proper tracking of the
vdev_id to pdev_id and from vits to pits for a given domain and the
management/tracking of the struct pci_dev.

Ian.

> For the two issues above, Xen should have mapping to pci segment and
> physical ITS node to use
> which can be queried by vITS driver and send command on to correct physical 
> ITS
> 
> Vijay



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

Re: [Xen-devel] Xen 4.5: can't create DomU guest on mustang(arm64)

[Ming Lei]

On Thu, Feb 26, 2015 at 11:55 AM, Ming Lei  wrote:
> Hi Guys,
>
> I just follow the guide in the link[1], and looks
> I can boot Dom0 successfully on mustang, and the
> xen 4.5 tools can be built OK on Dom0 side too.
>
> But when I try to create domU with the following
> commands:
>
> # losetup -f arm64-fs1.img
> # losetup -a
> /dev/loop0: [0802]:1318964 (/home/ubuntu/xt/arm64-fs1.img)
>
> # cat domu-test.cfg
> kernel = "./Image"
> memory = 512
> name = "ubuntu"
> vcpus = 2
> disk = [ 'phy:/dev/loop0,xvda,w' ]
> extra = 'console=hvc0 root=/dev/xvda rw earlyprintk=xen'
>
> # /etc/init.d/xencommons start || true
> # echo 9 > /proc/sysrq-trigger
> # export LIBXL_DEBUG_DUMP_DTB=guest.dtb
> # xl -vvv create domu-test.cfg
>
> I saw the failures in [2], so could anyone give a hand on it?

I just figured out the reason: xen-block backend drvier isn't built in
domU kernel. Once it is done, domU can be started successfully.

Sorry for the noise.

Thanks,
Ming Lei

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

Re: [Xen-devel] Xen's Linux kernel config options

[Stefano Stabellini]

On Wed, 25 Feb 2015, Luis R. Rodriguez wrote:
> On Wed, Feb 25, 2015 at 12:01:31PM +, Stefano Stabellini wrote:
> > On Tue, 24 Feb 2015, Luis R. Rodriguez wrote:
> > > On Tue, Feb 24, 2015 at 7:21 AM, Stefano Stabellini
> > >  wrote:
> > > > On Mon, 23 Feb 2015, Luis R. Rodriguez wrote:
> > > >> On Thu, Feb 19, 2015 at 3:43 PM, Luis R. Rodriguez  
> > > >> wrote:
> > > >> > On Fri, Dec 12, 2014 at 9:29 AM, David Vrabel 
> > > >> >  wrote:
> > > >> >> On 12/12/14 13:17, Juergen Gross wrote:
> > > >> >>> XEN_PVHVM
> > > >> >>
> > > >> >> Move XEN_PVHVM under XEN and have it select PARAVIRT and 
> > > >> >> PARAVIRT_CLOCK.
> > > >> >
> > > >> > FWIW, although it seems we do not want to let users just build
> > > >> > XEN_PVHVM hypervisors I have the changes required now to at least get
> > > >> > this to build so I do know what it takes.
> > > >> >
> > > >> >>> XEN_FRONTENDXEN_PV ||
> > > >> >>> XEN_PVH ||
> > > >> >>> XEN_PVHVM
> > > >> >>
> > > >> >> This enables all the basic infrastructure for frontends: event 
> > > >> >> channels,
> > > >> >> grant tables and Xenbus.
> > > >> >>
> > > >> >> Don't make XEN_FRONTEND depend on any XEN_* variant.  It should be
> > > >> >> possible to have frontend drivers without support for any of the
> > > >> >> PV/PVHVM/PVH guest types.
> > > >> >
> > > >> > David, can you elaborate on the type of Xen guest it would be on x86
> > > >> > its not PV, PVHVM, or PVH? I'm particularly curious about the
> > > >> > xen_domain_type and how it would end up to selected. As it is we tie
> > > >> > in XEN_PVHVM at build time with XEN_PVH, in order to have XEN_PVHVM
> > > >> > completely removed from XEN_PVH we need quite a bit of code changes
> > > >> > which at least as code exercise I have completed already. If we want
> > > >> > at the very least xen_domain_type set when XEN_PV, XEN_PVHVM, and
> > > >> > XEN_PVH are not available we need a bit more work.
> > > >>
> > > >> OK I think I see the issue. We have nothing quite like
> > > >> xen_guest_init() on x86 enlighten.c, we do have this for ARM and I
> > > >> think I can that close the gap I'm observing.
> > > >>
> > > >> >>  Frontends only need event channels, grant
> > > >> >> table and xenbus.
> > > >> >
> > > >> > Well xenbus_probe_initcall() will check for xen_domain() and that
> > > >> > won't be set on x86 right now unless we have XEN_PV, XEN_PVHVM or
> > > >> > XEN_PVH set -- to start off with. Then
> > > >> > drivers/xen/xenbus/xenbus_client.c will check xen_feature in quite a
> > > >> > bit of places as well, that won't be set unless xen_setup_features()
> > > >> > is called which right now is only done on x86 
> > > >> > arch/x86/xen/enlighten.c
> > > >> > which as Juergen pointed out, is not needed if you don't have XEN_PV
> > > >> > or XEN_PVH. As it turns out this is incorrect though, its needed for
> > > >> > XEN_PVHVM as well and my split exercise in code addresses this. Now,
> > > >> > at least in my code if you don't have XEN_PV, XEN_PVHVM, or XEN_PVH 
> > > >> > we
> > > >> > don't call xen_setup_features() and its unclear to me where or how
> > > >> > that should happen in other cases.
> > > >>
> > > >> Yeah I think having an x86 equivalent of xen_guest_init() would solve
> > > >> this, Stefano, thoughts?
> > > >
> > > > Having xen_guest_init() on x86 would be nice.  Being able to set
> > > > xen_domain_type to XEN_HVM_DOMAIN if we are running on Xen, regardless
> > > > of XEN_PV/PVH/PVHVM also makes sense from Linux POV.
> > > 
> > > OK great, thanks for the feedback.
> > > 
> > > > That said, I don't see much value in removing XEN_PVHVM: why are we even
> > > > doing this? What is the improvement we are seeking?
> > > 
> > > We would not, the above discussed about the possibility of letting
> > > users enable XEN_PVHVM without XEN_PVH, that's all.
> > 
> > OK, that makes sense.
> > 
> > > As is the only thing that can enable XEN_PVHVM is if you enable
> > > XEN_PVH.
> > 
> > This is the bit that we need to change but it shouldn't be difficult.
> > 
> > > If we want
> > > xen_guest_init() alone though we might need the decoupling though at
> > > least at build time so that if XEN_PV or XEN_PVH is not selected we'd
> > > at least have XEN_PVHVM. Thoughts?
> > 
> > Today pv(h) and pvhvm have very different boot paths already: pv and pvh
> > initialize via xen_start_kernel while pvhvm via xen_hvm_guest_init.
> 
> Ah I see, this helps a lot thanks!
> 
> > They are already very decoupled. You just need to make sure that
> > init_hvm_pv_info() is called regardless on any XEN_PV/PVH/PVHVM configs.
> 
> I'm a bit confused about this given that as I see it right now
> init_hvm_pv_info() is the Xen x86_hyper->init_platform() callback and that is
> only called on init_hypervisor_platform() *iff* x86_hyper->detect() passed
> (returned non-zero), but xen detect() r

Re: [Xen-devel] [DOCSDAY PATCH] xen: rework the comments for struct xen_domctl_vnuma.

[Wei Liu]

On Wed, Feb 25, 2015 at 04:33:17PM +0100, Dario Faggioli wrote:
> In fact: vnode_to_pnode is an array, not a mask; there was a
> typo in the one about vmemrange; there was no indication
> of the data directions.
> 
> Signed-off-by: Dario Faggioli 
> Cc: Wei Liu 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Keir Fraser 
> Cc: Elena Ufimtseva 
> ---
>  xen/include/public/domctl.h |   32 +---
>  1 file changed, 21 insertions(+), 11 deletions(-)
> 
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index b3413a2..ad76853 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -958,27 +958,37 @@ typedef struct xen_domctl_vcpu_msrs 
> xen_domctl_vcpu_msrs_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_vcpu_msrs_t);
>  #endif
>  
> -/*
> - * Use in XEN_DOMCTL_setvnumainfo to set
> - * vNUMA domain topology.
> - */
> +/* XEN_DOMCTL_setvnumainfo: specifies a virtual NUMA topology for the guest 
> */
>  struct xen_domctl_vnuma {
> +/* IN: number of vNUMA nodes to setup. Shall be greater than 0 */
>  uint32_t nr_vnodes;
> +/* IN: number of memory ranges to setup */
>  uint32_t nr_vmemranges;
> +/*
> + * IN: number of vCPUs of the domain (used as size of the vcpu_to_vnode
> + * array declared below). Shall be equal to the domain's max_vcpus.
> + */
>  uint32_t nr_vcpus;
> -uint32_t pad;
> +uint32_t pad;  /* must be zero */
> +
> +/*
> + * IN: array for specifying the distances of the vNUMA nodes
> + * between each others. Shall have nr_vnodes*nr_vnodes elements.
> + */
>  XEN_GUEST_HANDLE_64(uint) vdistance;
> +/*
> + * IN: array for specifying to what vNUMA node each vCPU
> + * belongs. Shall have nr_vcpus elements.
> + */
>  XEN_GUEST_HANDLE_64(uint) vcpu_to_vnode;
> -
>  /*
> - * vnodes to physical NUMA nodes mask.
> - * This kept on per-domain basis for
> - * interested consumers, such as numa aware ballooning.
> + * IN: array for specifying on what physical NUMA node
> + * each vNUMA node is placed. Shall have nr_vnodes elements.
>   */

At the very least this hunk should be backported to 4.5?

>  XEN_GUEST_HANDLE_64(uint) vnode_to_pnode;
> -
>  /*
> - * memory rages for each vNUMA node
> + * IN: array for specifying the memory ranges.
> + * Shall have nr_vmemranges elements.

Inconsistent filling column setup? This line wraps  at around 55
characters while others appear to be around 80. I think it might be
better to wrap around 72.

Wei.

>   */
>  XEN_GUEST_HANDLE_64(xen_vmemrange_t) vmemrange;
>  };

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

Re: [Xen-devel] Xen 4.5: can't create DomU guest on mustang(arm64)

[Ian Campbell]

On Thu, 2015-02-26 at 11:55 +0800, Ming Lei wrote:
> libxl: error: libxl_device.c:950:device_backend_callback: unable to
> add device with path /local/domain/0/backend/vbd/4/51712
> libxl: error: libxl_create.c:1153:domcreate_launch_dm: unable to add
> disk devices
> libxl: error: libxl_device.c:950:device_backend_callback: unable to
> remove device with path /local/domain/0/backend/vbd/4/51712
> libxl: error: libxl.c:1640:devices_destroy_cb: libxl__devices_destroy
> failed for 4

This makes me think that either your kernel does not have blkback
enabled or the module is not loaded.

Ian.


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

Re: [Xen-devel] RFC: xen config changes v4

[Stefano Stabellini]

On Thu, 26 Feb 2015, David Vrabel wrote:
> On 26/02/15 04:59, Juergen Gross wrote:
> > 
> > So we are again in the situation that pv-drivers always imply the pvops
> > kernel (PARAVIRT selected). I started the whole Kconfig rework to
> > eliminate this dependency.
> 
> Yes.  Can you produce a series that just addresses this one issue.
> 
> In the absence of any concrete requirement for this big Kconfig reorg I
> I don't think it is helpful.

I clearly missed some context as I didn't realize that this was the
intended goal. Why do we want this? Please explain as it won't come
for free.


We have a few PV interfaces for HVM guests that need PARAVIRT in Linux
in order to be used, for example pv_time_ops and HVMOP_pagetable_dying.
They are critical performance improvements and from the interface
perspective, small enough that doesn't make much sense having a separate
KConfig option for them.


In order to reach the goal above we necessarily need to introduce a
differentiation in terms of PV on HVM guests in Linux:

1) basic guests with PV network, disk, etc but no PV timers, no
   HVMOP_pagetable_dying, no PV IPIs
2) full PV on HVM guests that have PV network, disk, timers,
   HVMOP_pagetable_dying, PV IPIs and anything else that makes sense.

2) is much faster than 1) on Xen and 2) is only a tiny bit slower than
1) on native x86


>From Xen perspective and from code maintenance perspective I don't think
it makes sense to have the separation, actually it would make things
slower and harder to maintain.

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

[Xen-devel] backport c1d322e6048796296555dd36fdd102d7fa2f50bf to all stable trees

[Stefano Stabellini]

Hi all,

I would like to request a backport of

commit c1d322e6048796296555dd36fdd102d7fa2f50bf
Author: Stefano Stabellini 
Date:   Wed Dec 3 08:15:19 2014 -0500

xen-hvm: increase maxmem before calling xc_domain_populate_physmap


to all QEMU stable trees. Which ones are the currently maintained trees?

It applies without issues to 2.2, 2.1, 2.0, 1.7, 1.6, 1.5.
The filename in the commit needs to be changed from xen-hvm.c to
xen-all.c for 1.4, 1.3, 1.2, 1.1.  I didn't go father back.

Thanks,

Stefano

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

Re: [Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]

[Wei Liu]

On Thu, Feb 26, 2015 at 01:47:47PM +0100, Jürgen Groß wrote:
> On 02/26/2015 12:56 PM, Wei Liu wrote:
> >From: Ian Jackson 
> >
> >We are going to want to reuse this code for NetBSD rump kernels, where
> >there is no gntmap device and we just want to call the MiniOS gntmap
> >code directly.
> >
> >As part of this we want to abstract away the use of files[] inside the
> >actual functions.  Do this with a #define whose definition we are
> >going to make conditional in just a moment.
> >
> >No functional change in this patch.
> >
> >Signed-off-by: Ian Jackson 
> >---
> >  tools/libxc/xc_minios_privcmd.c | 15 +++
> >  1 file changed, 7 insertions(+), 8 deletions(-)
> >
> >diff --git a/tools/libxc/xc_minios_privcmd.c 
> >b/tools/libxc/xc_minios_privcmd.c
> >index 7766b86..27d9076 100644
> >--- a/tools/libxc/xc_minios_privcmd.c
> >+++ b/tools/libxc/xc_minios_privcmd.c
> >@@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
> >  },
> >  };
> >
> >+#define GNTMAP(h) (files[(int)(h)].gntmap)
> >+
> >  static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
> >  {
> >  int fd = alloc_fd(FTYPE_GNTMAP);
> >  if ( fd == -1 )
> >  return XC_OSDEP_OPEN_ERROR;
> >-gntmap_init(&files[fd].gntmap);
> >+gntmap_init(&GNTMAP(h));
> 
> GNTMAP(fd)?
> 
> Same multiple times below.
> 

Good catch. I will fix this, thanks.

Wei.

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

Re: [Xen-devel] [PATCH] libxl: remove LIBXL_MAXMEM_CONSTANT

[Stefano Stabellini]

On Wed, 25 Feb 2015, Don Slutz wrote:
> On 02/25/15 10:07, Stefano Stabellini wrote:
> > LIBXL_MAXMEM_CONSTANT is used to increase the maxmem setting for a
> > domain by a constant amount. As it is not clear the reason why we should
> > be doing this, remove the constant.
> > 
> > Signed-off-by: Stefano Stabellini 
> > CC: mlati...@suse.com
> > CC: ian.campb...@citrix.com
> > ---
> 
> I think that some sort of link to commit 901230f in QEMU:
> 
> 
> commit 901230fd8ce053cc21312a2eca2f3ba9f1d103f2
> Author: Stefano Stabellini 
> Date:   Wed Dec 3 08:15:19 2014 -0500
> 
> xen-hvm: increase maxmem before calling xc_domain_populate_physmap
> 
> Increase maxmem before calling xc_domain_populate_physmap_exact to
> avoid the risk of running out of guest memory. This way we can also
> avoid complex memory calculations in libxl at domain construction
> time.
> 
> This patch fixes an abort() when assigning more than 4 NICs to a VM.
> 
> upstream-commit-id: c1d322e6048796296555dd36fdd102d7fa2f50bf
> 
> Signed-off-by: Stefano Stabellini 
> Signed-off-by: Don Slutz 
> 
> 
> Because after this patch and without a "correct" QEMU, the number of
> e1000 NICs a guest can use is less then 4.

That is true, in fact is not even a single emulated NIC in my tests.
I can either ask for a backport of
c1d322e6048796296555dd36fdd102d7fa2f50bf "xen-hvm: increase maxmem
before calling xc_domain_populate_physmap" to all QEMU stable branches,
or we just have to keep this around for now and maybe just add a comment
on why it is needed.


> >  tools/libxl/libxl.c  |9 -
> >  tools/libxl/libxl_dom.c  |3 +--
> >  tools/libxl/libxl_internal.h |1 -
> >  3 files changed, 5 insertions(+), 8 deletions(-)
> > 
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index b9a1941..9556a92 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -4572,11 +4572,11 @@ int libxl_domain_setmaxmem(libxl_ctx *ctx, uint32_t 
> > domid, uint32_t max_memkb)
> >  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "memory_static_max must be 
> > greater than or or equal to memory_dynamic_max\n");
> >  goto out;
> >  }
> > -rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb + 
> > LIBXL_MAXMEM_CONSTANT);
> > +rc = xc_domain_setmaxmem(ctx->xch, domid, max_memkb);
> >  if (rc != 0) {
> >  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >  "xc_domain_setmaxmem domid=%d memkb=%d failed "
> > -"rc=%d\n", domid, max_memkb + LIBXL_MAXMEM_CONSTANT, rc);
> > +"rc=%d\n", domid, max_memkb, rc);
> >  goto out;
> >  }
> >  
> > @@ -4796,12 +4796,11 @@ retry_transaction:
> >  
> >  if (enforce) {
> >  memorykb = new_target_memkb + videoram;
> > -rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb +
> > -LIBXL_MAXMEM_CONSTANT);
> > +rc = xc_domain_setmaxmem(ctx->xch, domid, memorykb);
> >  if (rc != 0) {
> >  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR,
> >  "xc_domain_setmaxmem domid=%d memkb=%d failed "
> > -"rc=%d\n", domid, memorykb + LIBXL_MAXMEM_CONSTANT, 
> > rc);
> > +"rc=%d\n", domid, memorykb, rc);
> >  abort_transaction = 1;
> >  goto out;
> >  }
> > diff --git a/tools/libxl/libxl_dom.c b/tools/libxl/libxl_dom.c
> > index a16d4a1..923ba5c 100644
> > --- a/tools/libxl/libxl_dom.c
> > +++ b/tools/libxl/libxl_dom.c
> > @@ -408,8 +408,7 @@ int libxl__build_pre(libxl__gc *gc, uint32_t domid,
> >  }
> >  }
> >  
> > -if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb +
> > -LIBXL_MAXMEM_CONSTANT) < 0) {
> > +if (xc_domain_setmaxmem(ctx->xch, domid, info->target_memkb) < 0) {
> >  LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "Couldn't set max memory");
> >  return ERROR_FAIL;
> >  }
> > diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> > index 934465a..d5c5b68 100644
> > --- a/tools/libxl/libxl_internal.h
> > +++ b/tools/libxl/libxl_internal.h
> > @@ -89,7 +89,6 @@
> >  #define LIBXL_QEMU_BODGE_TIMEOUT 2
> >  #define LIBXL_XENCONSOLE_LIMIT 1048576
> >  #define LIBXL_XENCONSOLE_PROTOCOL "vt100"
> > -#define LIBXL_MAXMEM_CONSTANT 1024
> >  #define LIBXL_PV_EXTRA_MEMORY 1024
> >  #define LIBXL_HVM_EXTRA_MEMORY 2048
> >  #define LIBXL_MIN_DOM0_MEM (128*1024)
> > 
> 

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

Re: [Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c

[Samuel Thibault]

Wei Liu, le Thu 26 Feb 2015 11:56:18 +, a écrit :
> We are going to want to use some but not all of the machinery
> previously in xc_minios.c.  Split the privcmd and gnttab code into its
> own file.  This part is pure code motion.
> 
> But we also have to:
> 
>  - Alter the Makefile to build and link xc_minios_privcmd.c too.
> 
>  - Rename some of the minios_*_ops symbols to have proper namespaceing
>and make them have external linkage, so that the init code (which
>remains in xc_minios.c) can reference them.
> 
>  - Call these *_ops symbols xc_*_ops so that we can mix and match in
>the future.  This does not impede the existing mechanisms for
>run-time overriding.  (But leave a comment next to the new
>declarations in xc_private.h saying not to use these.)
> 
>  - Change map_frames_ex to minios_map_frames_ex if compiling on rump
>kernel.
> 
> Signed-off-by: Ian Jackson 
> 
> [ wei: wrap long lines, use __RUMPRUN__ and define macro for map_frames_ex ]
> 
> Signed-off-by: Wei Liu 

Acked-by: Samuel Thibault 

> ---
>  tools/libxc/Makefile|   2 +-
>  tools/libxc/xc_minios.c | 243 +
>  tools/libxc/xc_minios_privcmd.c | 291 
> 
>  tools/libxc/xc_private.h|   3 +
>  4 files changed, 299 insertions(+), 240 deletions(-)
>  create mode 100644 tools/libxc/xc_minios_privcmd.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index 6fa88c7..4ace2b6 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
>  CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
>  CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
>  CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
> -CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
> +CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
>  
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
> index e703684..90e3363 100644
> --- a/tools/libxc/xc_minios.c
> +++ b/tools/libxc/xc_minios.c
> @@ -41,164 +41,10 @@
>  
>  #include "xc_private.h"
>  
> -void minios_interface_close_fd(int fd);
>  void minios_evtchn_close_fd(int fd);
> -void minios_gnttab_close_fd(int fd);
> -
> -extern void minios_interface_close_fd(int fd);
> -extern void minios_evtchn_close_fd(int fd);
>  
>  extern struct wait_queue_head event_queue;
>  
> -static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
> -{
> -int fd = alloc_fd(FTYPE_XC);
> -
> -if ( fd == -1)
> -return XC_OSDEP_OPEN_ERROR;
> -
> -return (xc_osdep_handle)fd;
> -}
> -
> -static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
> -{
> -int fd = (int)h;
> -return close(fd);
> -}
> -
> -void minios_interface_close_fd(int fd)
> -{
> -files[fd].type = FTYPE_NONE;
> -}
> -
> -static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch, 
> xc_osdep_handle h, int npages)
> -{
> -return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
> -}
> -
> -static void minios_privcmd_free_hypercall_buffer(xc_interface *xch, 
> xc_osdep_handle h, void *ptr, int npages)
> -{
> -free(ptr);
> -}
> -
> -static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h, 
> privcmd_hypercall_t *hypercall)
> -{
> -multicall_entry_t call;
> -int i, ret;
> -
> -call.op = hypercall->op;
> -for (i = 0; i < ARRAY_SIZE(hypercall->arg); i++)
> - call.args[i] = hypercall->arg[i];
> -
> -ret = HYPERVISOR_multicall(&call, 1);
> -
> -if (ret < 0) {
> - errno = -ret;
> - return -1;
> -}
> -if ((long) call.result < 0) {
> -errno = - (long) call.result;
> -return -1;
> -}
> -return call.result;
> -}
> -
> -static void *minios_privcmd_map_foreign_bulk(xc_interface *xch, 
> xc_osdep_handle h,
> - uint32_t dom, int prot,
> - const xen_pfn_t *arr, int *err, 
> unsigned int num)
> -{
> -unsigned long pt_prot = 0;
> -if (prot & PROT_READ)
> - pt_prot = L1_PROT_RO;
> -if (prot & PROT_WRITE)
> - pt_prot = L1_PROT;
> -return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
> -}
> -
> -static void *minios_privcmd_map_foreign_batch(xc_interface *xch,  
> xc_osdep_handle h,
> -  uint32_t dom, int prot,
> -  xen_pfn_t *arr, int num)
> -{
> -unsigned long pt_prot = 0;
> -int err[num];
> -int i;
> -unsigned long addr;
> -
> -if (prot & PROT_READ)
> - pt_prot = L1_PROT_RO;
> -if (prot & PROT_WRITE)
> - pt_prot = L1_PROT;
> -
> -addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err, 
> pt_prot);
> -for (i = 0; i < num; i++) {
> -if (err[i])
> -arr[i] |= 0xF000;
> -}
> -return (void *) a

Re: [Xen-devel] [PATCH 2/5] libxc: Split off xc_minios_privcmd.c

[Wei Liu]

On Thu, Feb 26, 2015 at 11:56:18AM +, Wei Liu wrote:
> From: Ian Jackson 
> 
> We are going to want to use some but not all of the machinery
> previously in xc_minios.c.  Split the privcmd and gnttab code into its
> own file.  This part is pure code motion.
> 
> But we also have to:
> 
>  - Alter the Makefile to build and link xc_minios_privcmd.c too.
> 
>  - Rename some of the minios_*_ops symbols to have proper namespaceing
>and make them have external linkage, so that the init code (which
>remains in xc_minios.c) can reference them.
> 
>  - Call these *_ops symbols xc_*_ops so that we can mix and match in
>the future.  This does not impede the existing mechanisms for
>run-time overriding.  (But leave a comment next to the new
>declarations in xc_private.h saying not to use these.)
> 
>  - Change map_frames_ex to minios_map_frames_ex if compiling on rump
>kernel.
> 
> Signed-off-by: Ian Jackson 
> 
> [ wei: wrap long lines, use __RUMPRUN__ and define macro for map_frames_ex ]
> 
> Signed-off-by: Wei Liu 
> ---
>  tools/libxc/Makefile|   2 +-
>  tools/libxc/xc_minios.c | 243 +
>  tools/libxc/xc_minios_privcmd.c | 291 
> 
>  tools/libxc/xc_private.h|   3 +
>  4 files changed, 299 insertions(+), 240 deletions(-)
>  create mode 100644 tools/libxc/xc_minios_privcmd.c
> 
> diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
> index 6fa88c7..4ace2b6 100644
> --- a/tools/libxc/Makefile
> +++ b/tools/libxc/Makefile
> @@ -47,7 +47,7 @@ CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
>  CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
>  CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
>  CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
> -CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c
> +CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
>  
>  GUEST_SRCS-y :=
>  GUEST_SRCS-y += xg_private.c xc_suspend.c
> diff --git a/tools/libxc/xc_minios.c b/tools/libxc/xc_minios.c
> index e703684..90e3363 100644
> --- a/tools/libxc/xc_minios.c
> +++ b/tools/libxc/xc_minios.c
> @@ -41,164 +41,10 @@
>  
>  #include "xc_private.h"
>  
> -void minios_interface_close_fd(int fd);
>  void minios_evtchn_close_fd(int fd);
> -void minios_gnttab_close_fd(int fd);
> -
> -extern void minios_interface_close_fd(int fd);
> -extern void minios_evtchn_close_fd(int fd);
>  
>  extern struct wait_queue_head event_queue;
>  
> -static xc_osdep_handle minios_privcmd_open(xc_interface *xch)
> -{
> -int fd = alloc_fd(FTYPE_XC);
> -
> -if ( fd == -1)
> -return XC_OSDEP_OPEN_ERROR;
> -
> -return (xc_osdep_handle)fd;
> -}
> -
> -static int minios_privcmd_close(xc_interface *xch, xc_osdep_handle h)
> -{
> -int fd = (int)h;
> -return close(fd);
> -}
> -
> -void minios_interface_close_fd(int fd)
> -{
> -files[fd].type = FTYPE_NONE;
> -}
> -
> -static void *minios_privcmd_alloc_hypercall_buffer(xc_interface *xch, 
> xc_osdep_handle h, int npages)
> -{
> -return xc_memalign(xch, PAGE_SIZE, npages * PAGE_SIZE);
> -}
> -
> -static void minios_privcmd_free_hypercall_buffer(xc_interface *xch, 
> xc_osdep_handle h, void *ptr, int npages)
> -{
> -free(ptr);
> -}
> -
> -static int minios_privcmd_hypercall(xc_interface *xch, xc_osdep_handle h, 
> privcmd_hypercall_t *hypercall)
> -{
> -multicall_entry_t call;
> -int i, ret;
> -
> -call.op = hypercall->op;
> -for (i = 0; i < ARRAY_SIZE(hypercall->arg); i++)
> - call.args[i] = hypercall->arg[i];
> -
> -ret = HYPERVISOR_multicall(&call, 1);
> -
> -if (ret < 0) {
> - errno = -ret;
> - return -1;
> -}
> -if ((long) call.result < 0) {
> -errno = - (long) call.result;
> -return -1;
> -}
> -return call.result;
> -}
> -
> -static void *minios_privcmd_map_foreign_bulk(xc_interface *xch, 
> xc_osdep_handle h,
> - uint32_t dom, int prot,
> - const xen_pfn_t *arr, int *err, 
> unsigned int num)
> -{
> -unsigned long pt_prot = 0;
> -if (prot & PROT_READ)
> - pt_prot = L1_PROT_RO;
> -if (prot & PROT_WRITE)
> - pt_prot = L1_PROT;
> -return map_frames_ex(arr, num, 1, 0, 1, dom, err, pt_prot);
> -}
> -
> -static void *minios_privcmd_map_foreign_batch(xc_interface *xch,  
> xc_osdep_handle h,
> -  uint32_t dom, int prot,
> -  xen_pfn_t *arr, int num)
> -{
> -unsigned long pt_prot = 0;
> -int err[num];
> -int i;
> -unsigned long addr;
> -
> -if (prot & PROT_READ)
> - pt_prot = L1_PROT_RO;
> -if (prot & PROT_WRITE)
> - pt_prot = L1_PROT;
> -
> -addr = (unsigned long) map_frames_ex(arr, num, 1, 0, 1, dom, err, 
> pt_prot);
> -for (i = 0; i < num; i++) {
> -if (err[i])
> -arr[i] |= 0xF000;
> -}
> -return (void *) add

Re: [Xen-devel] Xen 4.5: can't create DomU guest on mustang(arm64)

[Ming Lei]

On Thu, Feb 26, 2015 at 5:41 PM, Ming Lei  wrote:
> On Thu, Feb 26, 2015 at 11:55 AM, Ming Lei  wrote:
>> Hi Guys,
>>
>> I just follow the guide in the link[1], and looks
>> I can boot Dom0 successfully on mustang, and the
>> xen 4.5 tools can be built OK on Dom0 side too.
>>
>> But when I try to create domU with the following
>> commands:
>>
>> # losetup -f arm64-fs1.img
>> # losetup -a
>> /dev/loop0: [0802]:1318964 (/home/ubuntu/xt/arm64-fs1.img)
>>
>> # cat domu-test.cfg
>> kernel = "./Image"
>> memory = 512
>> name = "ubuntu"
>> vcpus = 2
>> disk = [ 'phy:/dev/loop0,xvda,w' ]
>> extra = 'console=hvc0 root=/dev/xvda rw earlyprintk=xen'
>>
>> # /etc/init.d/xencommons start || true
>> # echo 9 > /proc/sysrq-trigger
>> # export LIBXL_DEBUG_DUMP_DTB=guest.dtb
>> # xl -vvv create domu-test.cfg
>>
>> I saw the failures in [2], so could anyone give a hand on it?
>
> I just figured out the reason: xen-block backend drvier isn't built in
> domU kernel.

It should be dom0 kernel.


Thanks,
Ming Lei

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

Re: [Xen-devel] [PATCH 4/5] libxc: minios: Introduce abstraction for files[]

[Samuel Thibault]

Wei Liu, le Thu 26 Feb 2015 11:56:20 +, a écrit :
> From: Ian Jackson 
> 
> We are going to want to reuse this code for NetBSD rump kernels, where
> there is no gntmap device and we just want to call the MiniOS gntmap
> code directly.
> 
> As part of this we want to abstract away the use of files[] inside the
> actual functions.  Do this with a #define whose definition we are
> going to make conditional in just a moment.
> 
> No functional change in this patch.
> 
> Signed-off-by: Ian Jackson 

Acked-by: Samuel Thibault 

> ---
>  tools/libxc/xc_minios_privcmd.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/libxc/xc_minios_privcmd.c b/tools/libxc/xc_minios_privcmd.c
> index 7766b86..27d9076 100644
> --- a/tools/libxc/xc_minios_privcmd.c
> +++ b/tools/libxc/xc_minios_privcmd.c
> @@ -208,12 +208,14 @@ struct xc_osdep_ops xc_privcmd_ops = {
>  },
>  };
>  
> +#define GNTMAP(h) (files[(int)(h)].gntmap)
> +
>  static xc_osdep_handle minios_gnttab_open(xc_gnttab *xcg)
>  {
>  int fd = alloc_fd(FTYPE_GNTMAP);
>  if ( fd == -1 )
>  return XC_OSDEP_OPEN_ERROR;
> -gntmap_init(&files[fd].gntmap);
> +gntmap_init(&GNTMAP(h));
>  return (xc_osdep_handle)fd;
>  }
>  
> @@ -225,7 +227,7 @@ static int minios_gnttab_close(xc_gnttab *xcg, 
> xc_osdep_handle h)
>  
>  void minios_gnttab_close_fd(int fd)
>  {
> -gntmap_fini(&files[fd].gntmap);
> +gntmap_fini(&GNTMAP(h));
>  files[fd].type = FTYPE_NONE;
>  }
>  
> @@ -235,7 +237,6 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg, 
> xc_osdep_handle h,
>   uint32_t notify_offset,
>   evtchn_port_t notify_port)
>  {
> -int fd = (int)h;
>  int stride = 1;
>  if (flags & XC_GRANT_MAP_SINGLE_DOMAIN)
>  stride = 0;
> @@ -243,7 +244,7 @@ static void *minios_gnttab_grant_map(xc_gnttab *xcg, 
> xc_osdep_handle h,
>  errno = ENOSYS;
>  return NULL;
>  }
> -return gntmap_map_grant_refs(&files[fd].gntmap,
> +return gntmap_map_grant_refs(&GNTMAP(h),
>   count, domids, stride,
>   refs, prot & PROT_WRITE);
>  }
> @@ -252,9 +253,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg, 
> xc_osdep_handle h,
>  void *start_address,
>  uint32_t count)
>  {
> -int fd = (int)h;
>  int ret;
> -ret = gntmap_munmap(&files[fd].gntmap,
> +ret = gntmap_munmap(&GNTMAP(h),
>  (unsigned long) start_address,
>  count);
>  if (ret < 0) {
> @@ -267,9 +267,8 @@ static int minios_gnttab_munmap(xc_gnttab *xcg, 
> xc_osdep_handle h,
>  static int minios_gnttab_set_max_grants(xc_gnttab *xcg, xc_osdep_handle h,
>   uint32_t count)
>  {
> -int fd = (int)h;
>  int ret;
> -ret = gntmap_set_max_grants(&files[fd].gntmap,
> +ret = gntmap_set_max_grants(&GNTMAP(h),
>  count);
>  if (ret < 0) {
>  errno = -ret;
> -- 
> 1.9.1
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 

-- 
Samuel
I am the "ILOVEGNU" signature virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.

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

[Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.

[Tim Deegan]

Shuffle some struct definitions up to file scope so that they remain
in scope in C++ when they're used again later.

Add an automatic check for similar C++ pitfalls, to be run only when
g++ is available.

RFC because it's not clear whether we want to make any commitments to
have the public headers be C++-friendly.

Explicitly _not_ addressing the use of 'private' in various fields,
since we'd previously decided not to fix that.

Reported-by: Razvan Cojocaru 
Signed-off-by: Tim Deegan 
Cc: Jan Beulich 
---
 .gitignore|  1 +
 xen/include/Makefile  | 12 +---
 xen/include/public/platform.h | 39 ++-
 3 files changed, 32 insertions(+), 20 deletions(-)

diff --git a/.gitignore b/.gitignore
index 13ee05b..78958ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -233,6 +233,7 @@ xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
 xen/arch/*/efi/runtime.c
 xen/include/headers.chk
+xen/include/headers++.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
 xen/include/compat/*
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 94112d1..c361877 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -87,13 +87,19 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) Makefile
 
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
-all: headers.chk
+all: headers.chk headers++.chk
 
-headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% 
public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
+PUBLIC_HEADERS_TO_CHECK := $(filter-out public/arch-% public/%ctl.h 
public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) 
$(public-y))
+
+headers.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W 
-Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done >$@.new
mv $@.new $@
 
+headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
+   if g++ -v >/dev/null; then for i in $(filter %.h,$^); do g++ -ansi 
-include stdint.h -Wall -W -Werror -S -o /dev/null -x c++ 
-Dprivate=private_is_a_keyword_in_c_plus_plus $$i || exit 1; echo $$i; done ; 
fi >$@.new
+   mv $@.new $@
+
 endif
 
 clean::
-   rm -rf compat headers.chk
+   rm -rf compat headers.chk headers++.chk
diff --git a/xen/include/public/platform.h b/xen/include/public/platform.h
index 3e340b4..dd03447 100644
--- a/xen/include/public/platform.h
+++ b/xen/include/public/platform.h
@@ -126,6 +126,26 @@ DEFINE_XEN_GUEST_HANDLE(xenpf_platform_quirk_t);
 #define XEN_EFI_query_variable_info   9
 #define XEN_EFI_query_capsule_capabilities   10
 #define XEN_EFI_update_capsule   11
+
+struct xenpf_efi_guid {
+uint32_t data1;
+uint16_t data2;
+uint16_t data3;
+uint8_t data4[8];
+};
+
+struct xenpf_efi_time {
+uint16_t year;
+uint8_t month;
+uint8_t day;
+uint8_t hour;
+uint8_t min;
+uint8_t sec;
+uint32_t ns;
+int16_t tz;
+uint8_t daylight;
+};
+
 struct xenpf_efi_runtime_call {
 uint32_t function;
 /*
@@ -138,17 +158,7 @@ struct xenpf_efi_runtime_call {
 union {
 #define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x0001
 struct {
-struct xenpf_efi_time {
-uint16_t year;
-uint8_t month;
-uint8_t day;
-uint8_t hour;
-uint8_t min;
-uint8_t sec;
-uint32_t ns;
-int16_t tz;
-uint8_t daylight;
-} time;
+struct xenpf_efi_time time;
 uint32_t resolution;
 uint32_t accuracy;
 } get_time;
@@ -170,12 +180,7 @@ struct xenpf_efi_runtime_call {
 XEN_GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
 xen_ulong_t size;
 XEN_GUEST_HANDLE(void) data;
-struct xenpf_efi_guid {
-uint32_t data1;
-uint16_t data2;
-uint16_t data3;
-uint8_t data4[8];
-} vendor_guid;
+struct xenpf_efi_guid vendor_guid;
 } get_variable, set_variable;
 
 struct {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Julien Grall]

Hi Frediano,

On 26/02/15 12:40, Frediano Ziglio wrote:
> HiSilison Hip04 platform use a slightly different version.
> This is just a verbatim copy of the file to workaround git
> not fully supporting copy operation.

This is an old verbatim copy. You miss at least one change in the copied
GICv2 driver.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform

[Julien Grall]

Hi Frediano,

On 26/02/15 12:40, Frediano Ziglio wrote:
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index c2dcb49..0834053 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct 
> kernel_info *kinfo,
>  static const struct dt_device_match gic_matches[] __initconst =
>  {
>  DT_MATCH_GIC_V2,
> +DT_MATCH_GIC_HIP04,
>  DT_MATCH_GIC_V3,
>  { /* sentinel */ },
>  };

I think this is the perfect time to introduce a callback to check if the
node is a GIC.

This would avoid to grow up this structure.

[..]

> -static const char * const gicv2_dt_compat[] __initconst =
> +static const char * const hip04gic_dt_compat[] __initconst =
>  {
> -DT_COMPAT_GIC_CORTEX_A15,
> -DT_COMPAT_GIC_CORTEX_A7,
> -DT_COMPAT_GIC_400,
> +DT_COMPAT_GIC_HIP04,
>  NULL
>  };
>  
> -DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
> -.compatible = gicv2_dt_compat,
> -.init = gicv2_init,
> +DT_DEVICE_START(hip04gic, "GIC-HIP04:", DEVICE_GIC)

The ":" was a mistake in the GICv2. Please don't reproduce it here.

> +.compatible = hip04gic_dt_compat,
> +.init = hip04gic_init,
>  DT_DEVICE_END
>  
>  /*
> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
> index 390c8b0..e4512a8 100644
> --- a/xen/arch/arm/gic.c
> +++ b/xen/arch/arm/gic.c
> @@ -565,12 +565,13 @@ static void do_sgi(struct cpu_user_regs *regs, enum 
> gic_sgi sgi)
>  void gic_interrupt(struct cpu_user_regs *regs, int is_fiq)
>  {
>  unsigned int irq;
> +unsigned int max_irq = gic_hw_ops->info->nr_lines;
>  
>  do  {
>  /* Reading IRQ will ACK it */
>  irq = gic_hw_ops->read_irq();
>  
> -if ( likely(irq >= 16 && irq < 1021) )
> +if ( likely(irq >= 16 && irq < max_irq) )
>  {
>  local_irq_enable();
>  do_IRQ(regs, irq, is_fiq);

This change should belong to a separate patch.

> diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> index 187dc46..a36f486 100644
> --- a/xen/include/asm-arm/gic.h
> +++ b/xen/include/asm-arm/gic.h
> @@ -160,6 +160,10 @@
>  DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7), \
>  DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
>  
> +#define DT_COMPAT_GIC_HIP04  "hisilicon,hip04-intc"
> +
> +#define DT_MATCH_GIC_HIP04 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
> +
>  #define DT_COMPAT_GIC_V3 "arm,gic-v3"
>  
>  #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_V3)

I would prefer if we avoid to add more compatibles like that in gic.h.

I have a patch to drop a part of this mess. I would advise your to use
cherry-pick the commit [1] in your branch.

[1]
http://xenbits.xen.org/gitweb/?p=people/julieng/xen-unstable.git;a=commit;h=7ba87910e557b06c589c3c0fbc6757fa664d029e

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v6 0/5] xen/arm: Add support for Huawei hip04-d01 platform

[Julien Grall]

Hi Frediano,

On 26/02/15 12:40, Frediano Ziglio wrote:
>   xen/arm: Make gic-v2 code handle hip04-d01 platform
>   xen/arm: handle GICH register changes for hip04-d01 platform
>   xen/arm: Force dom0 to use normal GICv2 driver on Hip04 platform

There is not much benefits to have 3 separate patches. I think they
could be merged in a single-patch.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v5.99.1 RFC 2/4] xen/arm: Make gic-v2 code handle hip04-d01 platform

[Frediano Ziglio]

2015-02-25 16:53 GMT+00:00 Stefano Stabellini
:
> On Wed, 25 Feb 2015, Frediano Ziglio wrote:
>> The GIC in this platform is mainly compatible with the standard
>> GICv2 beside:
>> - ITARGET is extended to 16 bit to support 16 CPUs;
>> - SGI mask is extended to support 16 CPUs;
>> - maximum supported interrupt is 510.
>>
>> Use nr_lines to check for maximum irq supported. hip04-d01 support less
>> interrupts due to some field restriction. Any value above this is already
>> an error.
>>
>> Signed-off-by: Frediano Ziglio 
>> Signed-off-by: Zoltan Kiss 
>> ---
>>  xen/arch/arm/domain_build.c |  1 +
>>  xen/arch/arm/gic-hip04.c| 43 +--
>>  xen/arch/arm/gic.c  |  3 ++-
>>  xen/include/asm-arm/gic.h   |  3 +++
>>  4 files changed, 31 insertions(+), 19 deletions(-)
>>
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index c2dcb49..0834053 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct 
>> kernel_info *kinfo,
>>  static const struct dt_device_match gic_matches[] __initconst =
>>  {
>>  DT_MATCH_GIC_V2,
>> +DT_MATCH_GIC_HIP04,
>>  DT_MATCH_GIC_V3,
>>  { /* sentinel */ },
>>  };
>> diff --git a/xen/arch/arm/gic-hip04.c b/xen/arch/arm/gic-hip04.c
>> index a401e3f..9a7ed46 100644
>> --- a/xen/arch/arm/gic-hip04.c
>> +++ b/xen/arch/arm/gic-hip04.c
>> @@ -1,7 +1,8 @@
>>  /*
>> - * xen/arch/arm/gic-v2.c
>> + * xen/arch/arm/gic-hip04.c
>>   *
>> - * ARM Generic Interrupt Controller support v2
>> + * ARM Generic Interrupt Controller support for HiSilicon Hip04 platform
>> + * Based heavily from gic-v2.c
>>   *
>>   * Tim Deegan 
>>   * Copyright (c) 2011 Citrix Systems.
>> @@ -79,16 +80,24 @@ static struct gic_info gicv2_info;
>>   * logical CPU numbering. Let's use mapping as returned by the GIC
>>   * itself
>>   */
>> -static DEFINE_PER_CPU(u8, gic_cpu_id);
>> +static DEFINE_PER_CPU(u16, gic_cpu_id);
>>
>>  /* Maximum cpu interface per GIC */
>> -#define NR_GIC_CPU_IF 8
>> +#define NR_GIC_CPU_IF 16
>> +
>> +#undef GICD_SGI_TARGET_SHIFT
>> +#define GICD_SGI_TARGET_SHIFT 8
>>
>>  static inline void writeb_gicd(uint8_t val, unsigned int offset)
>>  {
>>  writeb_relaxed(val, gicv2.map_dbase + offset);
>>  }
>>
>> +static inline void writew_gicd(uint16_t val, unsigned int offset)
>> +{
>> +writew_relaxed(val, gicv2.map_dbase + offset);
>> +}
>> +
>>  static inline void writel_gicd(uint32_t val, unsigned int offset)
>>  {
>>  writel_relaxed(val, gicv2.map_dbase + offset);
>> @@ -230,7 +239,7 @@ static void gicv2_set_irq_properties(struct irq_desc 
>> *desc,
>>  writel_gicd(cfg, GICD_ICFGR + (irq / 16) * 4);
>>
>>  /* Set target CPU mask (RAZ/WI on uniprocessor) */
>> -writeb_gicd(mask, GICD_ITARGETSR + irq);
>> +writew_gicd(mask, GICD_ITARGETSR + irq * 2);
>>  /* Set priority */
>>  writeb_gicd(priority, GICD_IPRIORITYR + irq);
>>
>> @@ -244,8 +253,7 @@ static void __init gicv2_dist_init(void)
>>  uint32_t gic_cpus;
>>  int i;
>>
>> -cpumask = readl_gicd(GICD_ITARGETSR) & 0xff;
>> -cpumask |= cpumask << 8;
>> +cpumask = readl_gicd(GICD_ITARGETSR) & 0x;
>>  cpumask |= cpumask << 16;
>>
>>  /* Disable the distributor */
>> @@ -253,7 +261,7 @@ static void __init gicv2_dist_init(void)
>>
>>  type = readl_gicd(GICD_TYPER);
>>  gicv2_info.nr_lines = 32 * ((type & GICD_TYPE_LINES) + 1);
>> -gic_cpus = 1 + ((type & GICD_TYPE_CPUS) >> 5);
>> +gic_cpus = 16;
>>  printk("GICv2: %d lines, %d cpu%s%s (IID %8.8x).\n",
>> gicv2_info.nr_lines, gic_cpus, (gic_cpus == 1) ? "" : "s",
>> (type & GICD_TYPE_SEC) ? ", secure" : "",
>> @@ -264,8 +272,8 @@ static void __init gicv2_dist_init(void)
>>  writel_gicd(0x0, GICD_ICFGR + (i / 16) * 4);
>>
>>  /* Route all global IRQs to this CPU */
>> -for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
>> -writel_gicd(cpumask, GICD_ITARGETSR + (i / 4) * 4);
>> +for ( i = 32; i < gicv2_info.nr_lines; i += 2 )
>> +writel_gicd(cpumask, GICD_ITARGETSR + (i / 2) * 4);
>>
>>  /* Default priority for global interrupts */
>>  for ( i = 32; i < gicv2_info.nr_lines; i += 4 )
>> @@ -285,7 +293,7 @@ static void __cpuinit gicv2_cpu_init(void)
>>  {
>>  int i;
>>
>> -this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0xff;
>> +this_cpu(gic_cpu_id) = readl_gicd(GICD_ITARGETSR) & 0x;
>>
>>  /* The first 32 interrupts (PPI and SGI) are banked per-cpu, so
>>   * even though they are controlled with GICD registers, they must
>> @@ -579,7 +587,7 @@ static void gicv2_irq_set_affinity(struct irq_desc 
>> *desc, const cpumask_t *cpu_m
>>  mask = gicv2_cpu_mask(cpu_mask);
>>
>>  /* Set target CPU mask (RAZ/WI on uniprocessor) */
>> -writeb_gicd(mask, GICD_ITARGETSR + desc->irq);
>> +writew_gicd(mask, GICD_ITARGETSR

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Manish Jaggi]

On Monday 23 February 2015 09:50 PM, Jan Beulich wrote:

On 23.02.15 at 16:46,  wrote:

On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:

On 23.02.15 at 16:02,  wrote:

Is the reason for the scan being of segment 0 only is that it is the one
which lives at the legacy PCI CFG addresses (or those magic I/O ports)?

Right - ideally we would scan all segments, but we need Dom0 to
tell us which MMCFG regions are safe to access,

Is this done via PHYSDEVOP_pci_mmcfg_reserved?

Yes.


  and hence can't
do that scan at boot time. But we also won't get away without
scanning, as we need to set up the IOMMU(s) to at least cover
the devices used for booting the system.

Which hopefully are all segment 0 or aren't needed until after dom0
tells Xen about them I suppose.

Right. With EFI one may be able to overcome this one day, but the
legacy BIOS doesn't even surface mechanisms (software interrupts)
to access devices outside of segment 0.


  (All devices on segment zero are supposed to
be accessible via config space access method 1.)

Is that "the legacy   or magic ..." again?

Yes (just that there are two of them).

Ian/Jan,
Have you reached a conclusion?

Jan


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



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

Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT

[Paul Durrant]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 February 2015 08:08
> To: Don Slutz
> Cc: Aravind Gopalakrishnan; Suravee Suthikulpanit; Andrew Cooper; Ian
> Campbell; Paul Durrant; George Dunlap; Ian Jackson; Stefano Stabellini; Eddie
> Dong; Jun Nakajima; Kevin Tian; xen-devel@lists.xen.org; Boris Ostrovsky;
> Konrad Rzeszutek Wilk; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
> 
> >>> On 25.02.15 at 21:20,  wrote:
> > On 02/24/15 10:34, Jan Beulich wrote:
> > On 17.02.15 at 00:05,  wrote:
> >>> @@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct
> domain *d, unsigned long gmfn)
> >>>  clear_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
> >>>  }
> >>>
> >>> -static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s,
> bool_t buf)
> >>> +static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, int
> buf)
> >>>  {
> >>> -struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> >>> +struct hvm_ioreq_page *iorp = NULL;
> >>> +
> >>> +switch ( buf )
> >>> +{
> >>> +case 0:
> >>> +iorp = &s->ioreq;
> >>> +break;
> >>> +case 1:
> >>> +iorp = &s->bufioreq;
> >>> +break;
> >>> +case 2:
> >>> +iorp = &s->vmport_ioreq;
> >>> +break;
> >>> +}
> >>
> >> These literals should become an enum.
> >>
> >
> > Paul Durrant asked for #defined values.  So it is not clear which way to
> > go. Will wait for response.
> 
> Obviously either would be fine. An enum has the potential advantage
> of the compiler being able to check switch statements for completeness
> (albeit there are cases where this ends up being a disadvantage).
> 

I'm fine with an enum... just not with (repeated) magic numbers in the code.

[snip]
> > Some background.  When Julien Grall added 2, this was said:
> >
> > Keir Fraser
> > [...]
> > They were almost certainly used for representing R-M-W ALU operations
> back
> > in the days of the old IO emulator, very long ago. Still, there''s no
> > harm in
> > leaving them unused.
> > [...]
> > I did find the old defn:
> >
> > dcs-xen-54:~/xen>git show 4ff8936 | grep IOREQ_TYPE_
> > #define IOREQ_TYPE_PIO  0 /* pio */
> > #define IOREQ_TYPE_COPY 1 /* mmio ops */
> > #define IOREQ_TYPE_AND  2
> > #define IOREQ_TYPE_OR   3
> > #define IOREQ_TYPE_XOR  4
> > #define IOREQ_TYPE_XCHG 5
> > #define IOREQ_TYPE_ADD  6
> > [...]
> > Which matches what Keir Fraser said.
> >
> > I did not find why Paul Durrant did not use 9.  I can only find it as 2
> > in all Paul's patch sets.  Which is closely connected to:
> >
> >  BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
> >  BUILD_BUG_ON(IOREQ_TYPE_COPY !=
> HVMOP_IO_RANGE_MEMORY);
> >  BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG !=
> HVMOP_IO_RANGE_PCI);
> >
> > (a new hyper call arg).  This also did not add a hole in "range" so
> > Paul Durrant did not have to check for a "range" hole.
> >
> > So I did just like Paul Durrant did.  He also approved the patch with
> > this number in QEMU.  Since this is now in upstream QEMU, changing it at
> > this time is a slower process.  Since the only time QEMU uses its
> > version is when Xen header files are missing, I do not see how a QEMU
> > built with its version would be usable as a QEMU for Xen.  So I am
> > happy to change to a new number like 9.
> 
> Yes please. I'm not saying we absolutely have to correct the one
> Paul added (unless we learn it causes problems), but I think we
> should avoid making the same (even if only potential) mistake twice.
> Of course it would help to get insight from Paul (now Cc-ed) here.
> 

I used the hole because I really did not think anyone would ever expect to use 
an ancient emulator against a recent Xen. Given there has been no fallout I 
don't see why we can't use the hole.

  Paul

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

Re: [Xen-devel] [PATCH 1/1] xen-netback: remove compilation warning

[Wei Liu]

On Thu, Feb 26, 2015 at 09:25:41AM +0100, pedro wrote:
> From: pmarzo 
> 
> offset and size are of type uint16_t so the %lu gives a warning
> A %u specifier, the same used in size makes gcc happy
> Not sure if a %x would be more correct
> 
> Signed-off-by: Pedro Marzo Perez 

Acked-by: Wei Liu 

Thanks

> ---
>  drivers/net/xen-netback/netback.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/xen-netback/netback.c 
> b/drivers/net/xen-netback/netback.c
> index f7a31d2..3888a2b 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1248,7 +1248,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
> *queue,
>   /* No crossing a page as the payload mustn't fragment. */
>   if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
>   netdev_err(queue->vif->dev,
> -"txreq.offset: %x, size: %u, end: %lu\n",
> +"txreq.offset: %x, size: %u, end: %u\n",
>  txreq.offset, txreq.size,
>  (txreq.offset&~PAGE_MASK) + txreq.size);
>   xenvif_fatal_tx_err(queue->vif);
> -- 
> 1.9.1

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

[Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

[Juergen Gross]

Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a driver domain
(usually Dom0) which is owner of the physical device.

The code is taken from the pvUSB implementation in Xen done by Fujitsu
based on Linux kernel 2.6.18.

Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- allocate resources dynamically
- use threaded irq
- correct sequence of state changes when assigning a device

Signed-off-by: Juergen Gross 
---
 drivers/usb/Makefile  |1 +
 drivers/usb/xen/Kconfig   |   10 +
 drivers/usb/xen/Makefile  |1 +
 drivers/usb/xen/xen-usbback.c | 1845 +
 4 files changed, 1857 insertions(+)
 create mode 100644 drivers/usb/xen/xen-usbback.c

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2676ef6..41f7398 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_USB_COMMON)  += common/
 obj-$(CONFIG_USBIP_CORE)   += usbip/
 
 obj-$(CONFIG_XEN_USB_FRONTEND) += xen/
+obj-$(CONFIG_XEN_USB_BACKEND)  += xen/
diff --git a/drivers/usb/xen/Kconfig b/drivers/usb/xen/Kconfig
index 5d995477..3414617 100644
--- a/drivers/usb/xen/Kconfig
+++ b/drivers/usb/xen/Kconfig
@@ -8,3 +8,13 @@ config XEN_USB_FRONTEND
  within another guest OS (usually Dom0).
  Only needed if the kernel is running in a Xen guest and generic
  access to a USB device is needed.
+
+config XEN_USB_BACKEND
+   tristate "Xen USB backend driver"
+   depends on XEN_BACKEND
+   default m
+   help
+ The USB backend driver allows the kernel to export its USB Devices
+ to other guests via a high-performance shared-memory interface.
+ Only needed for systems running as Xen driver domains (e.g. Dom0) and
+ if guests need generic access to USB devices.
diff --git a/drivers/usb/xen/Makefile b/drivers/usb/xen/Makefile
index 4568c26..c1a571065 100644
--- a/drivers/usb/xen/Makefile
+++ b/drivers/usb/xen/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_XEN_USB_FRONTEND) += xen-usbfront.o
+obj-$(CONFIG_XEN_USB_BACKEND)  += xen-usbback.o
diff --git a/drivers/usb/xen/xen-usbback.c b/drivers/usb/xen/xen-usbback.c
new file mode 100644
index 000..56a600e
--- /dev/null
+++ b/drivers/usb/xen/xen-usbback.c
@@ -0,0 +1,1845 @@
+/*
+ * xen-usbback.c
+ *
+ * Xen USB backend driver.
+ *
+ * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
+ * Author: Noboru Iwamatsu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ * or, by your choice,
+ *
+ * When distributed separately from the Linux kernel or incorporated into
+ * other software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct usbstub;
+
+#define USBBACK_BUS_ID_SIZE 20
+#define USB_DEV_ADDR_SIZE 128
+
+struct usbback_info {
+   domid_t domid;
+   unsigned handle;
+   int num_ports;
+ 

[Xen-devel] [PATCH 2/4] usb: Introduce Xen pvUSB frontend

[Juergen Gross]

Introduces the Xen pvUSB frontend. With pvUSB it is possible for a Xen
domU to communicate with a USB device assigned to that domU. The
communication is all done via the pvUSB backend in a driver domain
(usually Dom0) which is owner of the physical device.

The code is taken from the pvUSB implementation in Xen done by Fujitsu
based on Linux kernel 2.6.18.

Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- minor code modifications to increase readability

Signed-off-by: Juergen Gross 
---
 drivers/usb/Kconfig|2 +
 drivers/usb/Makefile   |2 +
 drivers/usb/xen/Kconfig|   10 +
 drivers/usb/xen/Makefile   |5 +
 drivers/usb/xen/xen-usbfront.c | 1634 
 5 files changed, 1653 insertions(+)
 create mode 100644 drivers/usb/xen/Kconfig
 create mode 100644 drivers/usb/xen/Makefile
 create mode 100644 drivers/usb/xen/xen-usbfront.c

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 8ed451d..de998f1 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -94,6 +94,8 @@ source "drivers/usb/image/Kconfig"
 
 source "drivers/usb/usbip/Kconfig"
 
+source "drivers/usb/xen/Kconfig"
+
 endif
 
 source "drivers/usb/musb/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2f1e2aa..2676ef6 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -62,3 +62,5 @@ obj-$(CONFIG_USB_GADGET)  += gadget/
 obj-$(CONFIG_USB_COMMON)   += common/
 
 obj-$(CONFIG_USBIP_CORE)   += usbip/
+
+obj-$(CONFIG_XEN_USB_FRONTEND) += xen/
diff --git a/drivers/usb/xen/Kconfig b/drivers/usb/xen/Kconfig
new file mode 100644
index 000..5d995477
--- /dev/null
+++ b/drivers/usb/xen/Kconfig
@@ -0,0 +1,10 @@
+config XEN_USB_FRONTEND
+   tristate "Xen USB frontend driver"
+   depends on XEN
+   default m
+   select XEN_XENBUS_FRONTEND
+   help
+ The Xen USB frontend driver allows the kernel to access USB Devices
+ within another guest OS (usually Dom0).
+ Only needed if the kernel is running in a Xen guest and generic
+ access to a USB device is needed.
diff --git a/drivers/usb/xen/Makefile b/drivers/usb/xen/Makefile
new file mode 100644
index 000..4568c26
--- /dev/null
+++ b/drivers/usb/xen/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for Xen pvUSB drivers
+#
+
+obj-$(CONFIG_XEN_USB_FRONTEND) += xen-usbfront.o
diff --git a/drivers/usb/xen/xen-usbfront.c b/drivers/usb/xen/xen-usbfront.c
new file mode 100644
index 000..f49e8e9
--- /dev/null
+++ b/drivers/usb/xen/xen-usbfront.c
@@ -0,0 +1,1634 @@
+/*
+ * xen-usbfront.c
+ *
+ * Xen USB Virtual Host Controller driver
+ *
+ * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
+ * Author: Noboru Iwamatsu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ * or, by your choice,
+ *
+ * When distributed separately from the Linux kernel or incorporated into
+ * other software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+/* Private per-URB data */
+struct urb_priv {
+   struct l

[Xen-devel] [PATCH 0/4] xen: sched: rework and add performance counters

[Dario Faggioli]

A small series that refactors a few of the existing scheduling related
performance counters, making them generic and updating them from all
schedulers, rather than just in Credit1.

It also (in the last patch) add a few new counters, specific to Credit2.

Thanks and Regards,
Dario
---
Dario Faggioli (4):
  xen: sched: honour generic perf conuters in the RTDS scheduler
  xen: sched: make counters for vCPU sleep and wakeup generic
  xen: sched: make counters for vCPU tickling generic
  xen: credit2: add a few performance counters

 xen/common/sched_credit2.c   |   37 +
 xen/common/sched_rt.c|   18 ++
 xen/include/xen/perfc_defn.h |   29 +
 3 files changed, 72 insertions(+), 12 deletions(-)

--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

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

[Xen-devel] [PATCH 2/4] xen: sched: make counters for vCPU sleep and wakeup generic

[Dario Faggioli]

and update them from Credit2 and RTDS. In Credit2, while there,
remove some stale comments too.

Signed-off-by: Dario Faggioli 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Keir Fraser 
---
 xen/common/sched_credit2.c   |   12 
 xen/common/sched_rt.c|   12 
 xen/include/xen/perfc_defn.h |   10 +-
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index ad0a5d4..2b852cc 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -931,6 +931,7 @@ csched2_vcpu_sleep(const struct scheduler *ops, struct vcpu 
*vc)
 struct csched2_vcpu * const svc = CSCHED2_VCPU(vc);
 
 BUG_ON( is_idle_vcpu(vc) );
+SCHED_STAT_CRANK(vcpu_sleep);
 
 if ( per_cpu(schedule_data, vc->processor).curr == vc )
 cpu_raise_softirq(vc->processor, SCHEDULE_SOFTIRQ);
@@ -956,19 +957,22 @@ csched2_vcpu_wake(const struct scheduler *ops, struct 
vcpu *vc)
 
 BUG_ON( is_idle_vcpu(vc) );
 
-/* Make sure svc priority mod happens before runq check */
 if ( unlikely(per_cpu(schedule_data, vc->processor).curr == vc) )
 {
+SCHED_STAT_CRANK(vcpu_wake_running);
 goto out;
 }
-
 if ( unlikely(__vcpu_on_runq(svc)) )
 {
-/* If we've boosted someone that's already on a runqueue, prioritize
- * it and inform the cpu in question. */
+SCHED_STAT_CRANK(vcpu_wake_onrunq);
 goto out;
 }
 
+if ( likely(vcpu_runnable(vc)) )
+SCHED_STAT_CRANK(vcpu_wake_runnable);
+else
+SCHED_STAT_CRANK(vcpu_wake_not_runnable);
+
 /* If the context hasn't been saved for this vcpu yet, we can't put it on
  * another runqueue.  Instead, we set a flag so that it will be put on the 
runqueue
  * after the context has been saved. */
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 58dd646..49d1b83 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -851,6 +851,7 @@ rt_vcpu_sleep(const struct scheduler *ops, struct vcpu *vc)
 struct rt_vcpu * const svc = rt_vcpu(vc);
 
 BUG_ON( is_idle_vcpu(vc) );
+SCHED_STAT_CRANK(vcpu_sleep);
 
 if ( curr_on_cpu(vc->processor) == vc )
 cpu_raise_softirq(vc->processor, SCHEDULE_SOFTIRQ);
@@ -966,11 +967,22 @@ rt_vcpu_wake(const struct scheduler *ops, struct vcpu *vc)
 BUG_ON( is_idle_vcpu(vc) );
 
 if ( unlikely(curr_on_cpu(vc->processor) == vc) )
+{
+SCHED_STAT_CRANK(vcpu_wake_running);
 return;
+}
 
 /* on RunQ/DepletedQ, just update info is ok */
 if ( unlikely(__vcpu_on_q(svc)) )
+{
+SCHED_STAT_CRANK(vcpu_wake_onrunq);
 return;
+}
+
+if ( likely(vcpu_runnable(vc)) )
+SCHED_STAT_CRANK(vcpu_wake_runnable);
+else
+SCHED_STAT_CRANK(vcpu_wake_not_runnable);
 
 /* If context hasn't been saved for this vcpu yet, we can't put it on
  * the Runqueue/DepletedQ. Instead, we set a flag so that it will be
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index 3ac7b45..2dc78fe 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -21,6 +21,11 @@ PERFCOUNTER(dom_init,   "sched: dom_init")
 PERFCOUNTER(dom_destroy,"sched: dom_destroy")
 PERFCOUNTER(vcpu_init,  "sched: vcpu_init")
 PERFCOUNTER(vcpu_destroy,   "sched: vcpu_destroy")
+PERFCOUNTER(vcpu_sleep, "sched: vcpu_sleep")
+PERFCOUNTER(vcpu_wake_running,  "sched: vcpu_wake_running")
+PERFCOUNTER(vcpu_wake_onrunq,   "sched: vcpu_wake_onrunq")
+PERFCOUNTER(vcpu_wake_runnable, "sched: vcpu_wake_runnable")
+PERFCOUNTER(vcpu_wake_not_runnable, "sched: vcpu_wake_not_runnable")
 
 /* credit specific counters */
 PERFCOUNTER(delay_ms,   "csched: delay")
@@ -32,11 +37,6 @@ PERFCOUNTER(acct_reorder,   "csched: acct_reorder")
 PERFCOUNTER(acct_min_credit,"csched: acct_min_credit")
 PERFCOUNTER(acct_vcpu_active,   "csched: acct_vcpu_active")
 PERFCOUNTER(acct_vcpu_idle, "csched: acct_vcpu_idle")
-PERFCOUNTER(vcpu_sleep, "csched: vcpu_sleep")
-PERFCOUNTER(vcpu_wake_running,  "csched: vcpu_wake_running")
-PERFCOUNTER(vcpu_wake_onrunq,   "csched: vcpu_wake_onrunq")
-PERFCOUNTER(vcpu_wake_runnable, "csched: vcpu_wake_runnable")
-PERFCOUNTER(vcpu_wake_not_runnable, "csched: vcpu_wake_not_runnable")
 PERFCOUNTER(vcpu_park,  "csched: vcpu_park")
 PERFCOUNTER(vcpu_unpark,"csched: vcpu_unpark")
 PERFCOUNTER(tickle_idlers_none, "csched: tickle_idlers_none")


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

[Xen-devel] [PATCH 0/4] xen, usb: support pvUSB drivers

[Juergen Gross]

This series adds XEN pvUSB support. With pvUSB it is possible to use physical
USB devices from a XEN domain.

The support consists of a backend in the privileged Domain-0 doing the real
I/O and a frontend in the unprivileged domU passing I/O-requests to the backend.

The code is taken (and adapted) from the original pvUSB implementation done
for Linux 2.6 in 2008 by Fujitsu.

Normal operation of USB devices by adding and removing them dynamically to/from
a domain has been tested using various USB devices (USB 1.1, 2.0 and 3.0).
Assignment of a USB device at domain creation via config file has been tested
as well.

Tests have been performed with the xm toolset and with xl using patches
from Chun Yan Liu which are not upstream yet.

Juergen Gross (4):
  usb: Add Xen pvUSB protocol description
  usb: Introduce Xen pvUSB frontend
  usb: Introduce Xen pvUSB backend
  xen: add Xen pvUSB maintainer

 MAINTAINERS  |8 +
 drivers/usb/Kconfig  |2 +
 drivers/usb/Makefile |3 +
 drivers/usb/xen/Kconfig  |   20 +
 drivers/usb/xen/Makefile |6 +
 drivers/usb/xen/xen-usbback.c| 1845 ++
 drivers/usb/xen/xen-usbfront.c   | 1634 +
 include/xen/interface/io/usbif.h |  220 +
 8 files changed, 3738 insertions(+)
 create mode 100644 drivers/usb/xen/Kconfig
 create mode 100644 drivers/usb/xen/Makefile
 create mode 100644 drivers/usb/xen/xen-usbback.c
 create mode 100644 drivers/usb/xen/xen-usbfront.c
 create mode 100644 include/xen/interface/io/usbif.h

-- 
2.1.4


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

[Xen-devel] [PATCH 4/4] xen: add Xen pvUSB maintainer

[Juergen Gross]

Add myself as maintainer for the Xen pvUSB stuff.

Signed-off-by: Juergen Gross 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..8ec1e1f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10787,6 +10787,14 @@ F: drivers/scsi/xen-scsifront.c
 F: drivers/xen/xen-scsiback.c
 F: include/xen/interface/io/vscsiif.h
 
+XEN PVUSB DRIVERS
+M: Juergen Gross 
+L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
+L: linux-...@vger.kernel.org
+S: Supported
+F: divers/usb/xen/
+F: include/xen/interface/io/usbif.h
+
 XEN SWIOTLB SUBSYSTEM
 M: Konrad Rzeszutek Wilk 
 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
-- 
2.1.4


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

[Xen-devel] [PATCH 3/4] xen: sched: make counters for vCPU tickling generic

[Dario Faggioli]

and update them from Credit2 and RTDS schedulers.

Signed-off-by: Dario Faggioli 
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Keir Fraser 
---
 xen/common/sched_credit2.c   |2 ++
 xen/common/sched_rt.c|2 ++
 xen/include/xen/perfc_defn.h |4 ++--
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index 2b852cc..bf13a84 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -571,9 +571,11 @@ tickle:
   (unsigned char *)&d);
 }
 cpumask_set_cpu(ipid, &rqd->tickled);
+SCHED_STAT_CRANK(tickle_idlers_some);
 cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
 
 no_tickle:
+SCHED_STAT_CRANK(tickle_idlers_none);
 return;
 }
 
diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 49d1b83..2ad0c68 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -929,6 +929,7 @@ runq_tickle(const struct scheduler *ops, struct rt_vcpu 
*new)
 }
 
 /* didn't tickle any cpu */
+SCHED_STAT_CRANK(tickle_idlers_none);
 return;
 out:
 /* TRACE */
@@ -944,6 +945,7 @@ out:
 }
 
 cpumask_set_cpu(cpu_to_tickle, &prv->tickled);
+SCHED_STAT_CRANK(tickle_idlers_some);
 cpu_raise_softirq(cpu_to_tickle, SCHEDULE_SOFTIRQ);
 return;
 }
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index 2dc78fe..f754331 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -26,6 +26,8 @@ PERFCOUNTER(vcpu_wake_running,  "sched: 
vcpu_wake_running")
 PERFCOUNTER(vcpu_wake_onrunq,   "sched: vcpu_wake_onrunq")
 PERFCOUNTER(vcpu_wake_runnable, "sched: vcpu_wake_runnable")
 PERFCOUNTER(vcpu_wake_not_runnable, "sched: vcpu_wake_not_runnable")
+PERFCOUNTER(tickle_idlers_none, "sched: tickle_idlers_none")
+PERFCOUNTER(tickle_idlers_some, "sched: tickle_idlers_some")
 
 /* credit specific counters */
 PERFCOUNTER(delay_ms,   "csched: delay")
@@ -39,8 +41,6 @@ PERFCOUNTER(acct_vcpu_active,   "csched: 
acct_vcpu_active")
 PERFCOUNTER(acct_vcpu_idle, "csched: acct_vcpu_idle")
 PERFCOUNTER(vcpu_park,  "csched: vcpu_park")
 PERFCOUNTER(vcpu_unpark,"csched: vcpu_unpark")
-PERFCOUNTER(tickle_idlers_none, "csched: tickle_idlers_none")
-PERFCOUNTER(tickle_idlers_some, "csched: tickle_idlers_some")
 PERFCOUNTER(load_balance_idle,  "csched: load_balance_idle")
 PERFCOUNTER(load_balance_over,  "csched: load_balance_over")
 PERFCOUNTER(load_balance_other, "csched: load_balance_other")


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

[Xen-devel] [PATCH 4/4] xen: credit2: add a few performance counters

[Dario Faggioli]

for events that are specific to Credit2 (as it happens
for Credit1 already).

Signed-off-by: Dario Faggioli 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Keir Fraser 
---
 xen/common/sched_credit2.c   |   23 +++
 xen/include/xen/perfc_defn.h |   15 ++-
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index bf13a84..fa764f9 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -652,6 +652,8 @@ static void reset_credit(const struct scheduler *ops, int 
cpu, s_time_t now,
 }
 }
 
+SCHED_STAT_CRANK(credit_reset);
+
 /* No need to resort runqueue, as everyone's order should be the same. */
 }
 
@@ -671,6 +673,7 @@ void burn_credits(struct csched2_runqueue_data *rqd, struct 
csched2_vcpu *svc, s
 delta = now - svc->start_time;
 
 if ( delta > 0 ) {
+SCHED_STAT_CRANK(burn_credits_t2c);
 t2c_update(rqd, delta, svc);
 svc->start_time = now;
 
@@ -711,6 +714,7 @@ static void update_max_weight(struct csched2_runqueue_data 
*rqd, int new_weight,
 {
 rqd->max_weight = new_weight;
 d2printk("%s: Runqueue id %d max weight %d\n", __func__, rqd->id, 
rqd->max_weight);
+SCHED_STAT_CRANK(upd_max_weight_quick);
 }
 else if ( old_weight == rqd->max_weight )
 {
@@ -727,6 +731,7 @@ static void update_max_weight(struct csched2_runqueue_data 
*rqd, int new_weight,
 
 rqd->max_weight = max_weight;
 d2printk("%s: Runqueue %d max weight %d\n", __func__, rqd->id, 
rqd->max_weight);
+SCHED_STAT_CRANK(upd_max_weight_full);
 }
 }
 
@@ -748,6 +753,7 @@ __csched2_vcpu_check(struct vcpu *vc)
 {
 BUG_ON( !is_idle_vcpu(vc) );
 }
+SCHED_STAT_CRANK(vcpu_check);
 }
 #define CSCHED2_VCPU_CHECK(_vc)  (__csched2_vcpu_check(_vc))
 #else
@@ -1201,6 +1207,7 @@ static void migrate(const struct scheduler *ops,
 svc->migrate_rqd = trqd;
 set_bit(_VPF_migrating, &svc->vcpu->pause_flags);
 set_bit(__CSFLAG_runq_migrate_request, &svc->flags);
+SCHED_STAT_CRANK(migrate_requested);
 }
 else
 {
@@ -1221,7 +1228,10 @@ static void migrate(const struct scheduler *ops,
 update_load(ops, svc->rqd, svc, 1, now);
 runq_insert(ops, svc->vcpu->processor, svc);
 runq_tickle(ops, svc->vcpu->processor, svc, now);
+SCHED_STAT_CRANK(migrate_on_runq);
 }
+else
+SCHED_STAT_CRANK(migrate_no_runq);
 }
 }
 
@@ -1575,7 +1585,10 @@ csched2_runtime(const struct scheduler *ops, int cpu, 
struct csched2_vcpu *snext
 /* The next guy may actually have a higher credit, if we've tried to
  * avoid migrating him from a different cpu.  DTRT.  */
 if ( rt_credit <= 0 )
+{
 time = CSCHED2_MIN_TIMER;
+SCHED_STAT_CRANK(runtime_min_timer);
+}
 else
 {
 /* FIXME: See if we can eliminate this conversion if we know time
@@ -1586,9 +1599,15 @@ csched2_runtime(const struct scheduler *ops, int cpu, 
struct csched2_vcpu *snext
 
 /* Check limits */
 if ( time < CSCHED2_MIN_TIMER )
+{
 time = CSCHED2_MIN_TIMER;
+SCHED_STAT_CRANK(runtime_min_timer);
+}
 else if ( time > CSCHED2_MAX_TIMER )
+{
 time = CSCHED2_MAX_TIMER;
+SCHED_STAT_CRANK(runtime_max_timer);
+}
 }
 
 return time;
@@ -1621,7 +1640,10 @@ runq_candidate(struct csched2_runqueue_data *rqd,
  * its credit is at least CSCHED2_MIGRATE_RESIST higher. */
 if ( svc->vcpu->processor != cpu
  && snext->credit + CSCHED2_MIGRATE_RESIST > svc->credit )
+{
+SCHED_STAT_CRANK(migrate_resisted);
 continue;
+}
 
 /* If the next one on the list has more credit than current
  * (or idle, if current is not runnable), choose it. */
@@ -1766,6 +1788,7 @@ csched2_schedule(
 {
 snext->credit += CSCHED2_MIGRATE_COMPENSATION;
 snext->vcpu->processor = cpu;
+SCHED_STAT_CRANK(migrated);
 ret.migrated = 1;
 }
 }
diff --git a/xen/include/xen/perfc_defn.h b/xen/include/xen/perfc_defn.h
index f754331..d3af41f 100644
--- a/xen/include/xen/perfc_defn.h
+++ b/xen/include/xen/perfc_defn.h
@@ -28,10 +28,10 @@ PERFCOUNTER(vcpu_wake_runnable, "sched: 
vcpu_wake_runnable")
 PERFCOUNTER(vcpu_wake_not_runnable, "sched: vcpu_wake_not_runnable")
 PERFCOUNTER(tickle_idlers_none, "sched: tickle_idlers_none")
 PERFCOUNTER(tickle_idlers_some, "sched: tickle_idlers_some")
+PERFCOUNTER(vcpu_check, "sched: vcpu_check")
 
 /* credit specific counters */
 PERFCOUNTER(delay_ms,   "csched: delay")
-PERFCOUNTER(vcpu_check, "csched: vcpu_check")
 PERFCOUNTER(acct_run,   "csched: acct_run")
 PERFCOUNTER(acct_no_work,   "csched: acct_no_work")
 PE

Re: [Xen-devel] Branch Trace Storage for guestsandVPMUinitialization

[Kevin.Mayer]

> -Ursprüngliche Nachricht-
> Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> Gesendet: Mittwoch, 25. Februar 2015 23:20
> An: Mayer, Kevin
> Betreff: Re: AW: AW: [Xen-devel] Branch Trace Storage for guests
> andVPMUinitialization
> 
> On 02/25/2015 01:23 PM, kevin.ma...@gdata.de wrote:
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
> >> Gesendet: Mittwoch, 25. Februar 2015 17:32
> >> An: Mayer, Kevin
> >> Cc: xen-devel@lists.xen.org
> >> Betreff: Re: AW: [Xen-devel] Branch Trace Storage for guests and
> >> VPMUinitialization
> >>
> >> On 02/25/2015 10:12 AM, kevin.ma...@gdata.de wrote:
>  -Ursprüngliche Nachricht-
>  Von: Boris Ostrovsky [mailto:boris.ostrov...@oracle.com]
>  Gesendet: Dienstag, 24. Februar 2015 18:13
>  An: Mayer, Kevin; xen-devel@lists.xen.org
>  Betreff: Re: [Xen-devel] Branch Trace Storage for guests and VPMU
>  initialization
> 
>  On 02/24/2015 10:27 AM, kevin.ma...@gdata.de wrote:
> > Hi guys
> >
> > I`m trying to set up the BTS so that I can log the branches taken
> > in the guest using Xen 4.4.1 with a WinXP SP3 guest on a Core i7
> > Sandy Bridge.
> >
> > I added the vpmu=bts boot parameter to my grub2 configuration and
> > extended the libxl,libxc,domctl,… with an own command so that I
> > can trigger the activation of the BTS whenever I want.
> >
>  I am not sure why you are doing all these changes to Xen code. BTS
>  is supposed to be managed from the guest. For example, a Fedora
> HVM
>  guest will produce this:
> 
>  [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# perf record -e
>  branches:u -c 1 -d sleep 1 [ perf record: Woken up 3838 times to
>  write data ] [ perf record: Captured and wrote 0.704 MB perf.data
>  (~30756 samples) ]
>  [root@dhcp-burlington7-2nd-B-east-10-152-55-140 ~]# perf script -f
>  ip,addr,sym,dso,symoff --show-kernel-path
>  8167c347 native_irq_return_iret+0x0 (/proc/kcore) =>
>  328c001590 [unknown] (/proc/kcore)
>  8167c347 native_irq_return_iret+0x0 (/proc/kcore) =>
>  328c001590 [unknown] ([unknown])
>    328c001593 [unknown] ([unknown]) =>   328c004b70 [unknown]
>  ([unknown])
>  ...
> 
> >>> I want to be able to log the taken branches (of the guest) without
> >>> the need
> >> to modify the guest at all.
> >>> This means I have to do all the logic in the hypervisor, or am I wrong?
> >> In that case, yes. But then you have to make sure that at least
> >>* you don't load guest's VPMU (or, at least, BTS-related
> >> registers) on context switch
> >>* You don't send the interrupt to the guest (meaning that you will
> >> need to somehow inform dom0 of the BTS interrupt)
> >>
> >> and probably more.
> >>
> >> Essentially, you want dom0 to profile the guest. I have been working
> >> on patches that would allow that but they are still under review.
> >>
> > Yes, this is exactly what I want to do.
> > Too bad that your patches are under review. Would have been pretty
> helpful I think.
> 
> To be honest, I never tested them for BTS so they may not work in that
> mode. In fact, as you will realize by reading what I said below, they probably
> don't ;-(
> 
> > Maybe I should point out that I´m a total noob with xen and I definitely
> don’t understand all parts yet.
> > So there may be some dumb mistakes in my assumptions.
> >
> > In this command I do the following:
> >
> > I set up the memory region for the BTS Buffer and the DS Buffer
> > Management Area using xzalloc_bytes
> >
>  I don't think you should be allocating BTS buffers in the
>  hypervisor, they
> >> are
>  in guest's memory.
> >>> I agree. As I said I think this is where my main problem is at the moment.
> >>> Is there any way I can allocate memory in the hypervisor in a way
> >>> the guest
> >> can access it?
> >>
> >> I am not sure this is what you want since you seem to *not* want the
> >> guest to process the samples, right?
> >>
> >> But yes, you can. E.g. something like what map_vcpu_info() does. (I
> >> have no idea how you'd do this from Windows.)
> > Right again. As you said my goal is to profile the guest from dom0. So
> whenever the CPU is in guestmode and a branch is taken it should be stored
> in the BTS, but not when the CPU is running dom0. My idea was basically to
> set up the memory for the BTS and the GUEST_IA32_DEBUGCTL so when
> there is a vmexit the logging stops and starts again when there is a vmenter.
> As far as I understand the IA32_DEBUGCTL gets switched between the
> dom0-value and the guest-value (stored in vmcs) when there is a
> vmexit/vmenter, right?
> 
> Right. And now I am not longer sure whether your buffer should be in
> hypervisor or guest's space: after VMENTER the hardware will load guest's
> versions of IA32_DEBUGCTLMSR and MSR_IA32_DS_AREA. I d

[Xen-devel] [PATCH 1/4] xen: sched: honour generic perf conuters in the RTDS scheduler

[Dario Faggioli]

more specifically, about vCPU initialization and destruction events,
in line with adb26c09f26e ("xen: sched: introduce a couple of counters
in credit2 and SEDF").

Signed-off-by: Dario Faggioli 
Cc: Meng Xu 
Cc: George Dunlap 
Cc: Jan Beulich 
Cc: Keir Fraser 
---
 xen/common/sched_rt.c |4 
 1 file changed, 4 insertions(+)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index df4adac..58dd646 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -525,6 +525,8 @@ rt_alloc_vdata(const struct scheduler *ops, struct vcpu 
*vc, void *dd)
 if ( !is_idle_vcpu(vc) )
 svc->budget = RTDS_DEFAULT_BUDGET;
 
+SCHED_STAT_CRANK(vcpu_init);
+
 return svc;
 }
 
@@ -574,6 +576,8 @@ rt_vcpu_remove(const struct scheduler *ops, struct vcpu *vc)
 struct rt_dom * const sdom = svc->sdom;
 spinlock_t *lock;
 
+SCHED_STAT_CRANK(vcpu_destroy);
+
 BUG_ON( sdom == NULL );
 
 lock = vcpu_schedule_lock_irq(vc);


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

[Xen-devel] [PATCH 1/4] usb: Add Xen pvUSB protocol description

[Juergen Gross]

Add the definition of pvUSB protocol used between the pvUSB frontend in
a Xen domU and the pvUSB backend in a Xen driver domain (usually Dom0).

This header was originally provided by Fujitsu for Xen based on Linux
2.6.18.

Changes are:
- adapt to Linux style guide

Signed-off-by: Juergen Gross 
---
 include/xen/interface/io/usbif.h | 220 +++
 1 file changed, 220 insertions(+)
 create mode 100644 include/xen/interface/io/usbif.h

diff --git a/include/xen/interface/io/usbif.h b/include/xen/interface/io/usbif.h
new file mode 100644
index 000..29815e2
--- /dev/null
+++ b/include/xen/interface/io/usbif.h
@@ -0,0 +1,220 @@
+/*
+ * usbif.h
+ *
+ * USB I/O interface for Xen guest OSes.
+ *
+ * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
+ * Author: Noboru Iwamatsu 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __XEN_PUBLIC_IO_USBIF_H__
+#define __XEN_PUBLIC_IO_USBIF_H__
+
+#include "ring.h"
+#include "../grant_table.h"
+
+/*
+ * Feature and Parameter Negotiation
+ * =
+ * The two halves of a Xen pvUSB driver utilize nodes within the XenStore to
+ * communicate capabilities and to negotiate operating parameters. This
+ * section enumerates these nodes which reside in the respective front and
+ * backend portions of the XenStore, following the XenBus convention.
+ *
+ * Any specified default value is in effect if the corresponding XenBus node
+ * is not present in the XenStore.
+ *
+ * XenStore nodes in sections marked "PRIVATE" are solely for use by the
+ * driver side whose XenBus tree contains them.
+ *
+ *
+ *Backend XenBus Nodes
+ *
+ *
+ *-- Backend Device Identification (PRIVATE) --
+ *
+ * num-ports
+ *  Values: unsigned [1...31]
+ *
+ *  Number of ports for this (virtual) USB host connector.
+ *
+ * usb-ver
+ *  Values: unsigned [1...2]
+ *
+ *  USB version of this host connector: 1 = USB 1.1, 2 = USB 2.0.
+ *
+ * port/[1...31]
+ *  Values: string
+ *
+ *  Physical USB device connected to the given port, e.g. "3-1.5".
+ *
+ *
+ *Frontend XenBus Nodes
+ *
+ *
+ *--- Request Transport Parameters ---
+ *
+ * event-channel
+ *  Values: unsigned
+ *
+ *  The identifier of the Xen event channel used to signal activity
+ *  in the ring buffer.
+ *
+ * urb-ring-ref
+ *  Values: unsigned
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer. This is the ring
+ *  buffer for urb requests.
+ *
+ * conn-ring-ref
+ *  Values: unsigned
+ *
+ *  The Xen grant reference granting permission for the backend to map
+ *  the sole page in a single page sized ring buffer. This is the ring
+ *  buffer for connection/disconnection requests.
+ *
+ * protocol
+ *  Values: string (XEN_IO_PROTO_ABI_*)
+ *  Default Value:  XEN_IO_PROTO_ABI_NATIVE
+ *
+ *  The machine ABI rules governing the format of all ring request and
+ *  response structures.
+ *
+ */
+
+enum usb_spec_version {
+   USB_VER_UNKNOWN = 0,
+   USB_VER_USB11,
+   USB_VER_USB20,
+   USB_VER_USB30,  /* not supported yet */
+};
+
+/*
+ *  USB pipe in usbif_request
+ *
+ *  bits 0-5 are specific bits for virtual USB driver.
+ *  bits 7-31 are standard urb pipe.
+ *
+ *  - port number(NEW):bits 0-4
+ * (USB_MAXCHILDREN is 31)
+ *
+ *  - operation flag(NEW): bit 5
+ *  

[Xen-devel] [PATCH 0/5] (not just)x86/Dom0: NUMA related adjustments

[Jan Beulich]

1: x86: allow specifying the NUMA nodes Dom0 should run on
2: allow domain heap allocations to specify more than one NUMA node
3: x86: widen NUMA nodes to be allocated from
4: VT-d: widen NUMA nodes to be allocated from
5: AMD IOMMU: widen NUMA nodes to be allocated from

Signed-off-by: Jan Beulich 
---
To apply cleanly his depends on "x86/Dom0: account for shadow/HAP allocation"
(http://lists.xenproject.org/archives/html/xen-devel/2015-02/msg03111.html).


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

[Xen-devel] [PATCH 1/5] x86: allow specifying the NUMA nodes Dom0 should run on

[Jan Beulich]

... by introducing a "dom0_nodes" option augmenting the "dom0_mem" and
"dom0_max_vcpus" ones.

Note that this gives meaning to MEMF_exact_node specified alone (i.e.
implicitly combined with NUMA_NO_NODE): In such a case any node inside
the domain's node mask is acceptable, but no other node. This changed
behavior is (implicitly) being exposed through the memop hypercalls.

Note further that this change doesn't take care of moving the initrd
image into memory matching Dom0's affinity when the initrd doesn't get
copied (because of being part of the initial mapping) anyway.

Signed-off-by: Jan Beulich 
---
I'm uncertain whether range restricting the PXMs permitted for Dom0 is
the right approach (matching what other NUMA code did until recently),
or whether we would instead want to simply limit the number of PXMs we
can handler there (i.e. using a static array instead of a static
bitmap).

--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -540,6 +540,15 @@ any dom0 autoballooning feature present 
 _xl.conf(5)_ man page or [Xen Best
 
Practices](http://wiki.xen.org/wiki/Xen_Best_Practices#Xen_dom0_dedicated_memory_and_preventing_dom0_memory_ballooning).
 
+### dom0\_nodes
+
+> `= [,...]`
+
+Specify the NUMA nodes to place Dom0 on. Defaults for vCPU-s created
+and memory assigned to Dom0 will be adjusted to match the node
+restrictions set up here. Note that the values to be specified here are
+ACPI PXM ones, not Xen internal node numbers.
+
 ### dom0\_shadow
 > `= `
 
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -100,11 +100,58 @@ static void __init parse_dom0_max_vcpus(
 }
 custom_param("dom0_max_vcpus", parse_dom0_max_vcpus);
 
+#define MAX_DOM0_PXM 255
+static __initdata DECLARE_BITMAP(dom0_pxms, MAX_DOM0_PXM + 1);
+
+static void __init parse_dom0_nodes(const char *s)
+{
+do {
+unsigned int pxm = simple_strtoul(s, &s, 0);
+
+if ( pxm <= MAX_DOM0_PXM )
+__set_bit(pxm, dom0_pxms);
+} while ( *s++ == ',' );
+}
+custom_param("dom0_nodes", parse_dom0_nodes);
+
+static cpumask_t __initdata dom0_cpus;
+
+static struct vcpu *__init setup_vcpu(struct domain *d, unsigned int vcpu_id,
+  unsigned int cpu)
+{
+struct vcpu *v = alloc_vcpu(d, vcpu_id, cpu);
+
+if ( v )
+{
+if ( !d->is_pinned )
+cpumask_copy(v->cpu_hard_affinity, &dom0_cpus);
+cpumask_copy(v->cpu_soft_affinity, &dom0_cpus);
+}
+
+return v;
+}
+
+static nodemask_t __initdata dom0_nodes;
+
 unsigned int __init dom0_max_vcpus(void)
 {
-unsigned max_vcpus;
+unsigned int pxm, max_vcpus;
+nodeid_t node;
+
+for ( pxm = 0; pxm <= MAX_DOM0_PXM; ++pxm )
+if ( test_bit(pxm, dom0_pxms) &&
+ (node = pxm_to_node(pxm)) != NUMA_NO_NODE )
+node_set(node, dom0_nodes);
+nodes_and(dom0_nodes, dom0_nodes, node_online_map);
+if ( nodes_empty(dom0_nodes) )
+dom0_nodes = node_online_map;
+for_each_node_mask ( node, dom0_nodes )
+cpumask_or(&dom0_cpus, &dom0_cpus, &node_to_cpumask(node));
+cpumask_and(&dom0_cpus, &dom0_cpus, cpupool0->cpu_valid);
+if ( cpumask_empty(&dom0_cpus) )
+cpumask_copy(&dom0_cpus, cpupool0->cpu_valid);
 
-max_vcpus = num_cpupool_cpus(cpupool0);
+max_vcpus = cpumask_weight(&dom0_cpus);
 if ( opt_dom0_max_vcpus_min > max_vcpus )
 max_vcpus = opt_dom0_max_vcpus_min;
 if ( opt_dom0_max_vcpus_max < max_vcpus )
@@ -119,12 +166,15 @@ struct vcpu *__init alloc_dom0_vcpu0(str
 {
 unsigned int max_vcpus = dom0_max_vcpus();
 
+dom0->node_affinity = dom0_nodes;
+dom0->auto_node_affinity = !!bitmap_empty(dom0_pxms, MAX_DOM0_PXM + 1);
+
 dom0->vcpu = xzalloc_array(struct vcpu *, max_vcpus);
 if ( !dom0->vcpu )
 return NULL;
 dom0->max_vcpus = max_vcpus;
 
-return alloc_vcpu(dom0, 0, 0);
+return setup_vcpu(dom0, 0, cpumask_first(&dom0_cpus));
 }
 
 #ifdef CONFIG_SHADOW_PAGING
@@ -156,7 +206,7 @@ static struct page_info * __init alloc_c
 struct domain *d, unsigned long max_pages)
 {
 static unsigned int __initdata last_order = MAX_ORDER;
-static unsigned int __initdata memflags = MEMF_no_dma;
+static unsigned int __initdata memflags = MEMF_no_dma|MEMF_exact_node;
 struct page_info *page;
 unsigned int order = get_order_from_pages(max_pages), free_order;
 
@@ -190,7 +240,7 @@ static struct page_info * __init alloc_c
 
 if ( d->tot_pages + (1 << order) > d->max_pages )
 continue;
-pg2 = alloc_domheap_pages(d, order, 0);
+pg2 = alloc_domheap_pages(d, order, MEMF_exact_node);
 if ( pg2 > page )
 {
 free_domheap_pages(page, free_order);
@@ -217,10 +267,14 @@ static unsigned long __init dom0_paging_
 static unsigned long __init compute_dom0_nr_pages(
 struct domain *d, struct elf_dom_parms *parms, unsigned long initrd_len)
 {
-unsigned long avail = av

[Xen-devel] [PATCH 3/5] x86: widen NUMA nodes to be allocated from

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -285,7 +285,8 @@ struct vcpu_guest_context *alloc_vcpu_gu
 
 for ( i = 0; i < PFN_UP(sizeof(struct vcpu_guest_context)); ++i )
 {
-struct page_info *pg = alloc_domheap_page(NULL, 0);
+struct page_info *pg = alloc_domheap_page(current->domain,
+  MEMF_no_owner);
 
 if ( unlikely(pg == NULL) )
 {
@@ -322,7 +323,7 @@ static int setup_compat_l4(struct vcpu *
 l4_pgentry_t *l4tab;
 int rc;
 
-pg = alloc_domheap_page(NULL, MEMF_node(vcpu_to_node(v)));
+pg = alloc_domheap_page(v->domain, MEMF_no_owner);
 if ( pg == NULL )
 return -ENOMEM;
 
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -1182,7 +1182,7 @@ int __init construct_dom0(
 }
 else
 {
-page = alloc_domheap_page(NULL, 0);
+page = alloc_domheap_page(d, MEMF_no_owner);
 if ( !page )
 panic("Not enough RAM for domain 0 PML4");
 page->u.inuse.type_info = PGT_l4_page_table|PGT_validated|1;
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -150,7 +150,7 @@ long arch_do_domctl(
 break;
 }
 
-page = alloc_domheap_page(NULL, 0);
+page = alloc_domheap_page(current->domain, MEMF_no_owner);
 if ( !page )
 {
 ret = -ENOMEM;
--- a/xen/arch/x86/hvm/stdvga.c
+++ b/xen/arch/x86/hvm/stdvga.c
@@ -604,7 +604,7 @@ void stdvga_init(struct domain *d)
 
 for ( i = 0; i != ARRAY_SIZE(s->vram_page); i++ )
 {
-pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( pg == NULL )
 break;
 s->vram_page[i] = pg;
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1417,7 +1417,6 @@ HVM_REGISTER_SAVE_RESTORE(LAPIC_REGS, la
 int vlapic_init(struct vcpu *v)
 {
 struct vlapic *vlapic = vcpu_vlapic(v);
-unsigned int memflags = MEMF_node(vcpu_to_node(v));
 
 HVM_DBG_LOG(DBG_LEVEL_VLAPIC, "%d", v->vcpu_id);
 
@@ -1431,7 +1430,7 @@ int vlapic_init(struct vcpu *v)
 
 if (vlapic->regs_page == NULL)
 {
-vlapic->regs_page = alloc_domheap_page(NULL, memflags);
+vlapic->regs_page = alloc_domheap_page(v->domain, MEMF_no_owner);
 if ( vlapic->regs_page == NULL )
 {
 dprintk(XENLOG_ERR, "alloc vlapic regs error: %d/%d\n",
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5879,7 +5879,6 @@ int create_perdomain_mapping(struct doma
 l3_pgentry_t *l3tab;
 l2_pgentry_t *l2tab;
 l1_pgentry_t *l1tab;
-unsigned int memf = MEMF_node(domain_to_node(d));
 int rc = 0;
 
 ASSERT(va >= PERDOMAIN_VIRT_START &&
@@ -5887,7 +5886,7 @@ int create_perdomain_mapping(struct doma
 
 if ( !d->arch.perdomain_l3_pg )
 {
-pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( !pg )
 return -ENOMEM;
 l3tab = __map_domain_page(pg);
@@ -5908,7 +5907,7 @@ int create_perdomain_mapping(struct doma
 
 if ( !(l3e_get_flags(l3tab[l3_table_offset(va)]) & _PAGE_PRESENT) )
 {
-pg = alloc_domheap_page(NULL, memf);
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( !pg )
 {
 unmap_domain_page(l3tab);
@@ -5937,7 +5936,7 @@ int create_perdomain_mapping(struct doma
 {
 if ( pl1tab && !IS_NIL(pl1tab) )
 {
-l1tab = alloc_xenheap_pages(0, memf);
+l1tab = alloc_xenheap_pages(0, MEMF_node(domain_to_node(d)));
 if ( !l1tab )
 {
 rc = -ENOMEM;
@@ -5949,7 +5948,7 @@ int create_perdomain_mapping(struct doma
 }
 else
 {
-pg = alloc_domheap_page(NULL, memf);
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( !pg )
 {
 rc = -ENOMEM;
@@ -5966,7 +5965,7 @@ int create_perdomain_mapping(struct doma
 if ( ppg &&
  !(l1e_get_flags(l1tab[l1_table_offset(va)]) & _PAGE_PRESENT) )
 {
-pg = alloc_domheap_page(NULL, memf);
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( pg )
 {
 clear_domain_page(page_to_mfn(pg));
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -331,7 +331,7 @@ hap_set_allocation(struct domain *d, uns
 if ( d->arch.paging.hap.total_pages < pages )
 {
 /* Need to allocate more memory from domheap */
-pg = alloc_domheap_page(NULL, MEMF_node(domain_to_node(d)));
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( pg == NULL )
 {
 HAP_PRINTK("failed to allocate hap pages.\n");
--- 

[Xen-devel] [PATCH 2/5] allow domain heap allocations to specify more than one NUMA node

[Jan Beulich]

... using struct domain as a container for passing the respective
affinity mask: Quite a number of allocations are domain specific, yet
not to be accounted for that domain. Introduce a flag suppressing the
accounting altogether (i.e. going beyond MEMF_no_refcount) and use it
right away in common code (x86 and IOMMU code will get adjusted
subsequently).

Signed-off-by: Jan Beulich 

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1657,7 +1657,8 @@ gnttab_transfer(
 struct page_info *new_page;
 void *sp, *dp;
 
-new_page = alloc_domheap_page(NULL, MEMF_bits(max_bitsize));
+new_page = alloc_domheap_page(e, MEMF_no_owner |
+ MEMF_bits(max_bitsize));
 if ( new_page == NULL )
 {
 gop.status = GNTST_address_too_big;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -462,7 +462,8 @@ static long memory_exchange(XEN_GUEST_HA
 /* Allocate a chunk's worth of anonymous output pages. */
 for ( j = 0; j < (1UL << out_chunk_order); j++ )
 {
-page = alloc_domheap_pages(NULL, exch.out.extent_order, memflags);
+page = alloc_domheap_pages(d, exch.out.extent_order,
+   MEMF_no_owner | memflags);
 if ( unlikely(page == NULL) )
 {
 rc = -ENOMEM;
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1685,10 +1685,14 @@ struct page_info *alloc_domheap_pages(
 
 ASSERT(!in_irq());
 
-bits = domain_clamp_alloc_bitsize(d, bits ? : (BITS_PER_LONG+PAGE_SHIFT));
+bits = domain_clamp_alloc_bitsize(memflags & MEMF_no_owner ? NULL : d,
+  bits ? : (BITS_PER_LONG+PAGE_SHIFT));
 if ( (zone_hi = min_t(unsigned int, bits_to_zone(bits), zone_hi)) == 0 )
 return NULL;
 
+if ( memflags & MEMF_no_owner )
+memflags |= MEMF_no_refcount;
+
 if ( dma_bitsize && ((dma_zone = bits_to_zone(dma_bitsize)) < zone_hi) )
 pg = alloc_heap_pages(dma_zone + 1, zone_hi, order, memflags, d);
 
@@ -1698,7 +1702,8 @@ struct page_info *alloc_domheap_pages(
   memflags, d)) == NULL)) )
  return NULL;
 
-if ( (d != NULL) && assign_pages(d, pg, order, memflags) )
+if ( d && !(memflags & MEMF_no_owner) &&
+ assign_pages(d, pg, order, memflags) )
 {
 free_heap_pages(pg, order);
 return NULL;
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -120,6 +120,8 @@ struct npfec {
 #define  MEMF_no_dma  (1U<<_MEMF_no_dma)
 #define _MEMF_exact_node  4
 #define  MEMF_exact_node  (1U<<_MEMF_exact_node)
+#define _MEMF_no_owner5
+#define  MEMF_no_owner(1U<<_MEMF_no_owner)
 #define _MEMF_node8
 #define  MEMF_node_mask   ((1U << (8 * sizeof(nodeid_t))) - 1)
 #define  MEMF_node(n) n) + 1) & MEMF_node_mask) << _MEMF_node)



allow domain heap allocations to specify more than one NUMA node

... using struct domain as a container for passing the respective
affinity mask: Quite a number of allocations are domain specific, yet
not to be accounted for that domain. Introduce a flag suppressing the
accounting altogether (i.e. going beyond MEMF_no_refcount) and use it
right away in common code (x86 and IOMMU code will get adjusted
subsequently).

Signed-off-by: Jan Beulich 

--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1657,7 +1657,8 @@ gnttab_transfer(
 struct page_info *new_page;
 void *sp, *dp;
 
-new_page = alloc_domheap_page(NULL, MEMF_bits(max_bitsize));
+new_page = alloc_domheap_page(e, MEMF_no_owner |
+ MEMF_bits(max_bitsize));
 if ( new_page == NULL )
 {
 gop.status = GNTST_address_too_big;
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -462,7 +462,8 @@ static long memory_exchange(XEN_GUEST_HA
 /* Allocate a chunk's worth of anonymous output pages. */
 for ( j = 0; j < (1UL << out_chunk_order); j++ )
 {
-page = alloc_domheap_pages(NULL, exch.out.extent_order, memflags);
+page = alloc_domheap_pages(d, exch.out.extent_order,
+   MEMF_no_owner | memflags);
 if ( unlikely(page == NULL) )
 {
 rc = -ENOMEM;
--- a/xen/common/page_alloc.c
+++ b/xen/common/page_alloc.c
@@ -1685,10 +1685,14 @@ struct page_info *alloc_domheap_pages(
 
 ASSERT(!in_irq());
 
-bits = domain_clamp_alloc_bitsize(d, bits ? : (BITS_PER_LONG+PAGE_SHIFT));
+bits = domain_clamp_alloc_bitsize(memflags & MEMF_no_owner ? NULL : d,
+  bits ? : (BITS_PER_LONG+PAGE_SHIFT));
 if ( (zone_hi = min_t(unsigned int, bits_to_zone(bits), zone_hi)) == 0 )
 return NULL;
 
+if ( memflags & MEMF_no_owner )
+memflags |=

[Xen-devel] [PATCH 4/5] VT-d: widen NUMA nodes to be allocated from

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -67,7 +67,8 @@ unsigned int get_cache_line_size(void);
 void cacheline_flush(char *);
 void flush_all_cache(void);
 
-u64 alloc_pgtable_maddr(struct acpi_drhd_unit *drhd, unsigned long npages);
+u64 alloc_pgtable_maddr(struct acpi_drhd_unit *, unsigned int npages,
+struct domain *);
 void free_pgtable_maddr(u64 maddr);
 void *map_vtd_domain_page(u64 maddr);
 void unmap_vtd_domain_page(void *va);
--- a/xen/drivers/passthrough/vtd/intremap.c
+++ b/xen/drivers/passthrough/vtd/intremap.c
@@ -739,7 +739,8 @@ int enable_intremap(struct iommu *iommu,
 if ( ir_ctrl->iremap_maddr == 0 )
 {
 drhd = iommu_to_drhd(iommu);
-ir_ctrl->iremap_maddr = alloc_pgtable_maddr(drhd, IREMAP_ARCH_PAGE_NR);
+ir_ctrl->iremap_maddr = alloc_pgtable_maddr(drhd, IREMAP_ARCH_PAGE_NR,
+NULL);
 if ( ir_ctrl->iremap_maddr == 0 )
 {
 dprintk(XENLOG_WARNING VTDPREFIX,
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -185,7 +185,8 @@ void iommu_flush_cache_page(void *addr, 
 }
 
 /* Allocate page table, return its machine address */
-u64 alloc_pgtable_maddr(struct acpi_drhd_unit *drhd, unsigned long npages)
+u64 alloc_pgtable_maddr(struct acpi_drhd_unit *drhd, unsigned int npages,
+struct domain *d)
 {
 struct acpi_rhsa_unit *rhsa;
 struct page_info *pg, *cur_pg;
@@ -195,10 +196,10 @@ u64 alloc_pgtable_maddr(struct acpi_drhd
 
 rhsa = drhd_to_rhsa(drhd);
 if ( rhsa )
-node =  pxm_to_node(rhsa->proximity_domain);
+node = pxm_to_node(rhsa->proximity_domain);
 
-pg = alloc_domheap_pages(NULL, get_order_from_pages(npages),
- (node == NUMA_NO_NODE) ? 0 : MEMF_node(node));
+pg = alloc_domheap_pages(d, get_order_from_pages(npages),
+ MEMF_node(node) | MEMF_no_owner);
 if ( !pg )
 return 0;
 
@@ -223,7 +224,7 @@ void free_pgtable_maddr(u64 maddr)
 }
 
 /* context entry handling */
-static u64 bus_to_context_maddr(struct iommu *iommu, u8 bus)
+static u64 bus_to_context_maddr(struct iommu *iommu, u8 bus, struct domain *d)
 {
 struct acpi_drhd_unit *drhd;
 struct root_entry *root, *root_entries;
@@ -235,7 +236,7 @@ static u64 bus_to_context_maddr(struct i
 if ( !root_present(*root) )
 {
 drhd = iommu_to_drhd(iommu);
-maddr = alloc_pgtable_maddr(drhd, 1);
+maddr = alloc_pgtable_maddr(drhd, 1, d);
 if ( maddr == 0 )
 {
 unmap_vtd_domain_page(root_entries);
@@ -271,7 +272,9 @@ static u64 addr_to_dma_page_maddr(struct
  */
 pdev = pci_get_pdev_by_domain(domain, -1, -1, -1);
 drhd = acpi_find_matched_drhd_unit(pdev);
-if ( !alloc || ((hd->arch.pgd_maddr = alloc_pgtable_maddr(drhd, 1)) == 
0) )
+if ( !alloc ||
+ ((hd->arch.pgd_maddr = alloc_pgtable_maddr(drhd, 1,
+domain)) == 0) )
 goto out;
 }
 
@@ -289,7 +292,7 @@ static u64 addr_to_dma_page_maddr(struct
 
 pdev = pci_get_pdev_by_domain(domain, -1, -1, -1);
 drhd = acpi_find_matched_drhd_unit(pdev);
-pte_maddr = alloc_pgtable_maddr(drhd, 1);
+pte_maddr = alloc_pgtable_maddr(drhd, 1, domain);
 if ( !pte_maddr )
 break;
 
@@ -1119,7 +1122,7 @@ int __init iommu_alloc(struct acpi_drhd_
 iommu->intel->drhd = drhd;
 drhd->iommu = iommu;
 
-if ( !(iommu->root_maddr = alloc_pgtable_maddr(drhd, 1)) )
+if ( !(iommu->root_maddr = alloc_pgtable_maddr(drhd, 1, NULL)) )
 return -ENOMEM;
 
 iommu->reg = ioremap(drhd->address, PAGE_SIZE);
@@ -1270,7 +1273,7 @@ int domain_context_mapping_one(
 
 ASSERT(spin_is_locked(&pcidevs_lock));
 spin_lock(&iommu->lock);
-maddr = bus_to_context_maddr(iommu, bus);
+maddr = bus_to_context_maddr(iommu, bus, domain);
 context_entries = (struct context_entry *)map_vtd_domain_page(maddr);
 context = &context_entries[devfn];
 
@@ -1495,7 +1498,7 @@ int domain_context_unmap_one(
 ASSERT(spin_is_locked(&pcidevs_lock));
 spin_lock(&iommu->lock);
 
-maddr = bus_to_context_maddr(iommu, bus);
+maddr = bus_to_context_maddr(iommu, bus, domain);
 context_entries = (struct context_entry *)map_vtd_domain_page(maddr);
 context = &context_entries[devfn];
 
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -374,7 +374,8 @@ int enable_qinval(struct iommu *iommu)
 if ( qi_ctrl->qinval_maddr == 0 )
 {
 drhd = iommu_to_drhd(iommu);
-qi_ctrl->qinval_maddr = alloc_pgtable_maddr(drhd, QINVAL_ARCH_PAGE_NR);
+qi_ctrl->qinval_maddr = alloc_pgtable_maddr(drhd, QINVAL_ARCH_PAGE_NR,
+ 

Re: [Xen-devel] [PATCH v5.99.1 RFC 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Julien Grall]

Hi Ian,

On 26/02/15 12:44, Ian Campbell wrote:
> The set of hardware which Xen needs to be able to drive (rather than
> give to a hardware domain) is:
> 
>   * CPUs
>   * Host interrupt controllers
>   * Host timers
>   * A UART
>   * Second-state MMUs
>   * Second-stage SMMUs/IOMMU (First-stage used by domains)
>   * PCI host bridges (in the near future)
> 
> (did I forget any?)

I think everything is there.

> NB: I'm only considering host level stuff here. Our virtualised hardware
> as exposed to the guest is well defined right now and any conversation
> about deviating from the set of hardware (e.g. providing a guest view to
> a non-GIC compliant virtual interrupt controller) would be part of a
> separate larger conversation about "hvm" style guests (and I'd, as you
> might imagine, be very reluctant to code to Xen itself to support
> non-standard vGICs in particular).

That would mean on platform such as Hisilicon, Guest (including DOM0)
won't be able to use more than 8 CPUs. But I guess this is a fair trade
for having a GIC which differs from the spec.

> From a "what does 'standards compliant' mean" PoV we have:
> 
> CPUs:
> 
> Specified in the ARM ARM (v7=ARM DDI 0406, v8=ARM DDI 0487).
> 
> Uncontroversial, I hope!
> 
> Host interrupt controllers:
> 
> Defined in "ARM Generic Interrupt Controller Architecture
> Specification" (v2=ARM IHI 0048B, v3=???).

AFAICT, for GICv3 there is a hardware spec available (though not
publicly) but no developer spec.

> Referenced from ARMv8 ARM (but not required AFAICT) but
> nonetheless this is what we consider when we talk about the
> "standard interrupt controller".
> 
> Host timers:
> 
> Defined in the ARMv8 ARM "Generic Timers" chapter.
> 
> Defined as an extension to ARMv7 (don't have doc ref handy). For
> our purposes such extensions are considered standardized[*].

It's worth to mention that we don't support generic memory mapped timer
for now. I don't know if we aim to support it.

> UARTS:
> 
> SBSA defines some (pl011 only?), but there are lots, including
> 8250-alike ones (ns16550 etc) which is a well established
> standard (from x86).
> 
> Given that UART drivers are generally small and pretty trivial I
> think we can tolerate "non-standard" (i.e. non-SBSA, non-8250)
> ones, so long as they are able to support our vuart interface.
> 
> I think the non-{pl011,8250} ones should be subject to non-core
> (i.e. community) maintenance as I mentioned previously, i.e
> should be listed in MAINTAINERS other than under the core ARM
> entry. If we decide to go ahead with this approach I'll ask the
> appropriate people to update MAINTAINERS.

At that time we have 3 "non-compliant" UART in Xen: exynos4210, scif and
omap.

Having maintainers per non-compliant UART would make some generic more
complicate to upstream. Indeed, it would require all the ack.

> 
> Second stage MMU:
> 
> Defined in the ARMv8 ARM, or the ARMv7 LPAE extensions[*, **].
> 
> Second stage SMMU/IOMMU:
> 
> Defined in "ARM System Memory Management Unit Architecture
> Specification" (ARM IHI 0062D?)

The D is the revision, so this would be ARM IHI 0062 for all the SMMUs.

[..]

> I think the above is a workable definition of what it is reasonable to
> expect the core Xen/ARM maintainers to look after (with that particular
> hat on) vs. what it should be expected for interested members of the
> community to step up and maintain (where the people who happen to be
> core Xen/ARM maintainers may occasionally chose to have such a hat too.)

I got few questions about it:
-  What happen if the maintainers of a specific driver (UART/IRQ
controller) doesn't answer?
- How do we handle possible security issue related to a specific
driver? Is it even considered as a security one?
- As a new drivers would tight to a new set of maintainers, how do we
decide that a new drivers is accepted in Xen?

Given the governance spec [1], we may decide to reject a maintainers for
some reason. Does it mean the drivers is rejected too?

Overall, I think we should clearly define the condition of
acceptance/maintenance of a specific driver.

[..]

> [**] The LPAE extensions include/are mixed with the hyp mode page table
> format, so we pretty certainly need it.

Rigth, the ARM spec required LPAE extensions when virtualization is
supported.

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH 5/5] AMD IOMMU: widen NUMA nodes to be allocated from

[Jan Beulich]

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -488,7 +488,7 @@ static int iommu_pde_from_gfn(struct dom
 mfn = next_table_mfn;
 
 /* allocate lower level page table */
-table = alloc_amd_iommu_pgtable();
+table = alloc_amd_iommu_pgtable(d);
 if ( table == NULL )
 {
 AMD_IOMMU_DEBUG("Cannot allocate I/O page table\n");
@@ -516,7 +516,7 @@ static int iommu_pde_from_gfn(struct dom
 {
 if ( next_table_mfn == 0 )
 {
-table = alloc_amd_iommu_pgtable();
+table = alloc_amd_iommu_pgtable(d);
 if ( table == NULL )
 {
 AMD_IOMMU_DEBUG("Cannot allocate I/O page table\n");
@@ -567,7 +567,7 @@ static int update_paging_mode(struct dom
 {
 /* Allocate and install a new root table.
  * Only upper I/O page table grows, no need to fix next level bits */
-new_root = alloc_amd_iommu_pgtable();
+new_root = alloc_amd_iommu_pgtable(d);
 if ( new_root == NULL )
 {
 AMD_IOMMU_DEBUG("%s Cannot allocate I/O page table\n",
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -225,13 +225,15 @@ int __init amd_iov_detect(void)
 return scan_pci_devices();
 }
 
-static int allocate_domain_resources(struct hvm_iommu *hd)
+static int allocate_domain_resources(struct domain *d)
 {
+struct hvm_iommu *hd = domain_hvm_iommu(d);
+
 /* allocate root table */
 spin_lock(&hd->arch.mapping_lock);
 if ( !hd->arch.root_table )
 {
-hd->arch.root_table = alloc_amd_iommu_pgtable();
+hd->arch.root_table = alloc_amd_iommu_pgtable(d);
 if ( !hd->arch.root_table )
 {
 spin_unlock(&hd->arch.mapping_lock);
@@ -263,7 +265,7 @@ static int amd_iommu_domain_init(struct 
 struct hvm_iommu *hd = domain_hvm_iommu(d);
 
 /* allocate page directroy */
-if ( allocate_domain_resources(hd) != 0 )
+if ( allocate_domain_resources(d) != 0 )
 {
 if ( hd->arch.root_table )
 free_domheap_page(hd->arch.root_table);
@@ -383,7 +385,7 @@ static int reassign_device(struct domain
 /* IO page tables might be destroyed after pci-detach the last device
  * In this case, we have to re-allocate root table for next pci-attach.*/
 if ( t->arch.root_table == NULL )
-allocate_domain_resources(t);
+allocate_domain_resources(target);
 
 amd_iommu_setup_domain_device(target, iommu, devfn, pdev);
 AMD_IOMMU_DEBUG("Re-assign %04x:%02x:%02x.%u from dom%d to dom%d\n",
--- a/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
+++ b/xen/include/asm-x86/hvm/svm/amd-iommu-proto.h
@@ -158,12 +158,12 @@ static inline unsigned long region_to_pa
 return (PAGE_ALIGN(addr + size) - (addr & PAGE_MASK)) >> PAGE_SHIFT;
 }
 
-static inline struct page_info* alloc_amd_iommu_pgtable(void)
+static inline struct page_info *alloc_amd_iommu_pgtable(struct domain *d)
 {
 struct page_info *pg;
 void *vaddr;
 
-pg = alloc_domheap_page(NULL, 0);
+pg = alloc_domheap_page(d, MEMF_no_owner);
 if ( pg == NULL )
 return 0;
 vaddr = __map_domain_page(pg);



AMD IOMMU: widen NUMA nodes to be allocated from

Signed-off-by: Jan Beulich 

--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -488,7 +488,7 @@ static int iommu_pde_from_gfn(struct dom
 mfn = next_table_mfn;
 
 /* allocate lower level page table */
-table = alloc_amd_iommu_pgtable();
+table = alloc_amd_iommu_pgtable(d);
 if ( table == NULL )
 {
 AMD_IOMMU_DEBUG("Cannot allocate I/O page table\n");
@@ -516,7 +516,7 @@ static int iommu_pde_from_gfn(struct dom
 {
 if ( next_table_mfn == 0 )
 {
-table = alloc_amd_iommu_pgtable();
+table = alloc_amd_iommu_pgtable(d);
 if ( table == NULL )
 {
 AMD_IOMMU_DEBUG("Cannot allocate I/O page table\n");
@@ -567,7 +567,7 @@ static int update_paging_mode(struct dom
 {
 /* Allocate and install a new root table.
  * Only upper I/O page table grows, no need to fix next level bits */
-new_root = alloc_amd_iommu_pgtable();
+new_root = alloc_amd_iommu_pgtable(d);
 if ( new_root == NULL )
 {
 AMD_IOMMU_DEBUG("%s Cannot allocate I/O page table\n",
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -225,13 +225,15 @@ int __init amd_iov_detect(void)
 return scan_pci_devices();
 }
 
-static int allocate_domain_resources(struct hvm_iommu *hd)
+static int allocate_domain_resources(struct domain *d)
 {
+struct hvm_iommu *hd = d

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Julien Grall]

Hi Ian,

On 26/02/15 11:12, Ian Campbell wrote:
>> I have few queries
>>
>> 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS
>> command Q is
>> mapped to which Physical ITS command Q.
>> In case of linux, the ITS node is added as msi chip to pci using
>> of_pci_msi_chip_add()
>> and from pci_dev structure we can know which ITS to use.
>>
>> But in case of Xen, when ITS command is trapped we have only
>> dev_id info from ITS command.
> 
> With the proper PCI infrastructure in place we can map the vdev_id to a
> pdev_id, and from there to our own struct pci_dev 
> 
> The mapping from pdev_id to pci_dev is based on the
> PHYSDEVOP_pci_host_bridge_add and PHYSDEVOP_pci_device_add calls I
> described just now in my mail to Manish in this thread (specifically
> pci_device_add creates and registers struct pci_dev I think).

We may need an hypercall to map the dev_id to a vdev_id.

IIRC, Vijay and Manish was already planned to add one.

> 
>>
>> 2) If DomU is always given one virtual ITS node. If DomU is assinged
>> with two different
>> PCI devices connected to different physical ITS, then Xen vITS
>> driver should know how to map
>> PCI device to physical ITS
> 
> Correct, I think that all falls out from the proper tracking of the
> vdev_id to pdev_id and from vits to pits for a given domain and the
> management/tracking of the struct pci_dev.

I think this is the right way to go. Though I haven't read the ITS spec
closely.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Jan Beulich]

>>> On 26.02.15 at 11:09,  wrote:
> On Monday 23 February 2015 09:50 PM, Jan Beulich wrote:
> On 23.02.15 at 16:46,  wrote:
>>> On Mon, 2015-02-23 at 15:27 +, Jan Beulich wrote:
>>> On 23.02.15 at 16:02,  wrote:
> Is the reason for the scan being of segment 0 only is that it is the one
> which lives at the legacy PCI CFG addresses (or those magic I/O ports)?
 Right - ideally we would scan all segments, but we need Dom0 to
 tell us which MMCFG regions are safe to access,
>>> Is this done via PHYSDEVOP_pci_mmcfg_reserved?
>> Yes.
>>
   and hence can't
 do that scan at boot time. But we also won't get away without
 scanning, as we need to set up the IOMMU(s) to at least cover
 the devices used for booting the system.
>>> Which hopefully are all segment 0 or aren't needed until after dom0
>>> tells Xen about them I suppose.
>> Right. With EFI one may be able to overcome this one day, but the
>> legacy BIOS doesn't even surface mechanisms (software interrupts)
>> to access devices outside of segment 0.
>>
   (All devices on segment zero are supposed to
 be accessible via config space access method 1.)
>>> Is that "the legacy   or magic ..." again?
>> Yes (just that there are two of them).
> Ian/Jan,
> Have you reached a conclusion?

Regarding what? The context above - at least to me - doesn't make
clear what you refer to.

Jan


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

Re: [Xen-devel] [PATCH 2/4] usb: Introduce Xen pvUSB frontend

[Oliver Neukum]

On Thu, 2015-02-26 at 14:35 +0100, Juergen Gross wrote:
> +
> +   /* reset completion */
> +   if ((info->ports[wIndex].status &
> USB_PORT_STAT_RESET) != 0 &&
> +   time_after_eq(jiffies,
> info->ports[wIndex].timeout)) {
> +   info->ports[wIndex].status |=
> +   USB_PORT_STAT_C_RESET << 16;
> +   info->ports[wIndex].status &=
> ~USB_PORT_STAT_RESET;
> +
> +   if (info->devices[wIndex].status !=
> +   USB_STATE_NOTATTACHED) {
> +   info->ports[wIndex].status |=
> +   USB_PORT_STAT_ENABLE;
> +   info->devices[wIndex].status =
> +   USB_STATE_DEFAULT;
> +   }
> +
> +   switch (info->devices[wIndex].speed) {
> +   case USB_SPEED_LOW:
> +   info->ports[wIndex].status |=
> +   USB_PORT_STAT_LOW_SPEED;
> +   break;
> +   case USB_SPEED_HIGH:
> +   info->ports[wIndex].status |=
> +   USB_PORT_STAT_HIGH_SPEED;
> +   break;
> +   default:
> +   break;
> +   }
> +   }
> +
> +   ((u16 *)buf)[0] =
> cpu_to_le16(info->ports[wIndex].status);
> +   ((u16 *)buf)[1] =
> cpu_to_le16(info->ports[wIndex].status >> 16);

Why in two chunks?
Regards
Oliver
> +   break;


-- 
Oliver Neukum 


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

[Xen-devel] [PATCH] x86/traps: consolidate PV RDMSR emulation paths

[Jan Beulich]

Settle on just using one variable (val), and move the other into
WRMSR's local scope. Chain up further success paths to the
rdmsr_writeback label rather than open coding them.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2008,7 +2008,7 @@ static int emulate_privileged_op(struct 
 unsigned long code_base, code_limit;
 char io_emul_stub[32];
 void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
-uint64_t val, msr_content;
+uint64_t val;
 
 if ( !read_descriptor(regs->cs, v, regs,
   &code_base, &code_limit, &ar,
@@ -2498,8 +2498,9 @@ static int emulate_privileged_op(struct 
 case 0x30: /* WRMSR */ {
 uint32_t eax = regs->eax;
 uint32_t edx = regs->edx;
-msr_content = ((uint64_t)edx << 32) | eax;
-switch ( (u32)regs->ecx )
+uint64_t msr_content = ((uint64_t)edx << 32) | eax;
+
+switch ( regs->_ecx )
 {
 case MSR_FS_BASE:
 if ( is_pv_32on64_vcpu(v) )
@@ -2670,7 +2671,7 @@ static int emulate_privileged_op(struct 
 break;
 
 case 0x32: /* RDMSR */
-switch ( (u32)regs->ecx )
+switch ( regs->_ecx )
 {
 case MSR_FS_BASE:
 if ( is_pv_32on64_vcpu(v) )
@@ -2686,9 +2687,8 @@ static int emulate_privileged_op(struct 
 case MSR_SHADOW_GS_BASE:
 if ( is_pv_32on64_vcpu(v) )
 goto fail;
-regs->eax = v->arch.pv_vcpu.gs_base_user & 0xUL;
-regs->edx = v->arch.pv_vcpu.gs_base_user >> 32;
-break;
+val = v->arch.pv_vcpu.gs_base_user;
+goto rdmsr_writeback;
 case MSR_K7_FID_VID_CTL:
 case MSR_K7_FID_VID_STATUS:
 case MSR_K8_PSTATE_LIMIT:
@@ -2720,12 +2720,10 @@ static int emulate_privileged_op(struct 
 }
 goto rdmsr_normal;
 case MSR_IA32_MISC_ENABLE:
-if ( rdmsr_safe(regs->ecx, msr_content) )
+if ( rdmsr_safe(regs->ecx, val) )
 goto fail;
-msr_content = guest_misc_enable(msr_content);
-regs->eax = (uint32_t)msr_content;
-regs->edx = (uint32_t)(msr_content >> 32);
-break;
+val = guest_misc_enable(val);
+goto rdmsr_writeback;
 
 case MSR_AMD64_DR0_ADDRESS_MASK:
 if ( !boot_cpu_has(X86_FEATURE_DBEXT) )
@@ -2743,12 +2741,7 @@ static int emulate_privileged_op(struct 
 
 default:
 if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
-{
- rdmsr_writeback:
-regs->eax = (uint32_t)val;
-regs->edx = (uint32_t)(val >> 32);
-break;
-}
+goto rdmsr_writeback;
 
 rc = vmce_rdmsr(regs->ecx, &val);
 if ( rc < 0 )
@@ -2761,10 +2754,11 @@ static int emulate_privileged_op(struct 
 /* Everyone can read the MSR space. */
 /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
 _p(regs->ecx));*/
-if ( rdmsr_safe(regs->ecx, msr_content) )
+if ( rdmsr_safe(regs->ecx, val) )
 goto fail;
-regs->eax = (uint32_t)msr_content;
-regs->edx = (uint32_t)(msr_content >> 32);
+ rdmsr_writeback:
+regs->eax = (uint32_t)val;
+regs->edx = (uint32_t)(val >> 32);
 break;
 }
 break;



x86/traps: consolidate PV RDMSR emulation paths

Settle on just using one variable (val), and move the other into
WRMSR's local scope. Chain up further success paths to the
rdmsr_writeback label rather than open coding them.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2008,7 +2008,7 @@ static int emulate_privileged_op(struct 
 unsigned long code_base, code_limit;
 char io_emul_stub[32];
 void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
-uint64_t val, msr_content;
+uint64_t val;
 
 if ( !read_descriptor(regs->cs, v, regs,
   &code_base, &code_limit, &ar,
@@ -2498,8 +2498,9 @@ static int emulate_privileged_op(struct 
 case 0x30: /* WRMSR */ {
 uint32_t eax = regs->eax;
 uint32_t edx = regs->edx;
-msr_content = ((uint64_t)edx << 32) | eax;
-switch ( (u32)regs->ecx )
+uint64_t msr_content = ((uint64_t)edx << 32) | eax;
+
+switch ( regs->_ecx )
 {
 case MSR_FS_BASE:
 if ( is_pv_32on64_vcpu(v) )
@@ -2670,7 +2671,7 @@ static int emulate_privileged_op(struct 
 break;
 
 case 0x32: /* RDMSR */
-switch ( (u32)regs->ecx )
+switch ( regs->_ecx )
 {
 case MSR_FS_BASE:
 if ( is_pv_32on64_vcpu(v) )
@@ -2686,9 +2687,8 @@ static int emulate_privileged_op(struct 
 case MSR_SHADOW_GS_BASE:
 if ( is_pv_32on64_vcpu(v) )
   

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Vijay Kilari]

On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell  wrote:
> On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
>> On 24/02/15 7:13 pm, Julien Grall wrote:
>> > On 24/02/15 00:23, Manish Jaggi wrote:
>> >>> Because you have to parse all the device tree to remove the reference
>> >>> to the second ITS. It's pointless and can be difficult to do it.
>> >>>
>> >> Could you please describe the case where it is difficult
>> > You have to parse every node in the device tree and replace the
>> > msi-parent properties with only one ITS.
>> Thats the idea.
>> >
>> >>> If you are able to emulate on ITS, you can do it for multiple one.
>> >> keeping it simple and similar across dom0/domUs
>> >> Consider a case where a domU is assigned two PCI devices which are
>> >> attached to different nodes. (Node is an entity having its own cores are
>> >> host controllers).
>> > The DOM0 view and guest view of the hardware are different.
>> >
>> > In the case of DOM0, we want to expose the same hardware layout as the
>> > host. So if there is 2 ITS then we should expose the 2 ITS.
>> AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are
>> handled by xen and a virtualized interface is provided to the guest. So
>> if none of SMMU in the layout of host is presented to dom0 the same can
>> be valid for multiple ITS.
>
> SMMU is one of the things which Xen hides from dom0, for obvious
> reasons.
>
> Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no
> reason for ITS to differ here.
>
> Since dom0 needs to be able to cope with being able to see all of the
> host host I/O devices (in the default no-passthrough case), it is
> possible, if not likely, that it will need the same amount of ITS
> resources (i.e. numbers of LPIs) as the host provides.
>
>> > In the case of the Guest, we (Xen) controls the memory layout.
>> For Dom0 as well.
>
> Not true.
>
> For dom0 the memory layout is determined by the host memory layout. The
> MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM
> regions of the host physical address space (often in 1:1, but with
> sufficient h/w support this need not be the case).
>
>> > Therefore
>> > we can expose only one ITS.
>> If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen
>> GIC ITS emulation driver to work.
>> It should check that request came from a dom0 handle it differently. I
>> think this would be *difficult*.
>
> I don't think so. If the vITS is written to handle multiple instances
> (i.e. in a modular way, as it should be) then it shouldn't matter
> whether any given domain has 1 or many vITS. The fact that dom0 may have
> one or more and domU only (currently) has one then becomes largely
> uninteresting.

I have few queries

1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS
command Q is
mapped to which Physical ITS command Q.
In case of linux, the ITS node is added as msi chip to pci using
of_pci_msi_chip_add()
and from pci_dev structure we can know which ITS to use.

But in case of Xen, when ITS command is trapped we have only
dev_id info from ITS command.

2) If DomU is always given one virtual ITS node. If DomU is assinged
with two different
PCI devices connected to different physical ITS, then Xen vITS
driver should know how to map
PCI device to physical ITS

For the two issues above, Xen should have mapping to pci segment and
physical ITS node to use
which can be queried by vITS driver and send command on to correct physical ITS

Vijay

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

Re: [Xen-devel] libxl__device_pci_reset() questions

[Jan Beulich]

>>> On 19.02.15 at 15:30,  wrote:
> On Thu, 2015-02-19 at 13:59 +, Jan Beulich wrote:
>> All,
>> 
>> in the context of someone seeing "The kernel doesn't support reset
>> from sysfs for PCI device", is my understanding correct that the lack
>> of error checking in any caller (perhaps intentional) means that any
>> of the errors logged from this function are really just warnings, i.e.
>> don't prevent the assignment from taking place?
> 
> It was a long while ago, but I believe that was the intention, yes.
> 
>> Furthermore I'm puzzled by the function first thing trying to access
>> a "do_flr" file supposedly made available by the pciback driver, yet
>> I can't see either the upstream or the old 2.6.18 driver surfacing
>> such a file. What am I missing here?
> 
> I'm not sure, on the basis of
> http://lists.xen.org/archives/html/xen-devel/2014-06/msg03105.html and 
> http://lists.xen.org/archives/html/xen-devel/2014-07/msg01108.html I've
> added Konrad to the CC.

Konrad?

Thanks, Jan


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

Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Frediano Ziglio]

> 
> Hi Frediano,
> 
> On 26/02/15 12:40, Frediano Ziglio wrote:
> > HiSilison Hip04 platform use a slightly different version.
> > This is just a verbatim copy of the file to workaround git not fully
> > supporting copy operation.
> 
> This is an old verbatim copy. You miss at least one change in the
> copied
> GICv2 driver.
> 
> Regards,
> 
> --
> Julien Grall

I think you are referring to changes in staging, right ?

Frediano


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

Re: [Xen-devel] [PATCH] x86/traps: consolidate PV RDMSR emulation paths

[Andrew Cooper]

On 26/02/15 14:16, Jan Beulich wrote:
> Settle on just using one variable (val), and move the other into
> WRMSR's local scope. Chain up further success paths to the
> rdmsr_writeback label rather than open coding them.
>
> Signed-off-by: Jan Beulich 

Reviewed-by: Andrew Cooper 

>
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2008,7 +2008,7 @@ static int emulate_privileged_op(struct 
>  unsigned long code_base, code_limit;
>  char io_emul_stub[32];
>  void (*io_emul)(struct cpu_user_regs *) __attribute__((__regparm__(1)));
> -uint64_t val, msr_content;
> +uint64_t val;
>  
>  if ( !read_descriptor(regs->cs, v, regs,
>&code_base, &code_limit, &ar,
> @@ -2498,8 +2498,9 @@ static int emulate_privileged_op(struct 
>  case 0x30: /* WRMSR */ {
>  uint32_t eax = regs->eax;
>  uint32_t edx = regs->edx;
> -msr_content = ((uint64_t)edx << 32) | eax;
> -switch ( (u32)regs->ecx )
> +uint64_t msr_content = ((uint64_t)edx << 32) | eax;
> +
> +switch ( regs->_ecx )
>  {
>  case MSR_FS_BASE:
>  if ( is_pv_32on64_vcpu(v) )
> @@ -2670,7 +2671,7 @@ static int emulate_privileged_op(struct 
>  break;
>  
>  case 0x32: /* RDMSR */
> -switch ( (u32)regs->ecx )
> +switch ( regs->_ecx )
>  {
>  case MSR_FS_BASE:
>  if ( is_pv_32on64_vcpu(v) )
> @@ -2686,9 +2687,8 @@ static int emulate_privileged_op(struct 
>  case MSR_SHADOW_GS_BASE:
>  if ( is_pv_32on64_vcpu(v) )
>  goto fail;
> -regs->eax = v->arch.pv_vcpu.gs_base_user & 0xUL;
> -regs->edx = v->arch.pv_vcpu.gs_base_user >> 32;
> -break;
> +val = v->arch.pv_vcpu.gs_base_user;
> +goto rdmsr_writeback;
>  case MSR_K7_FID_VID_CTL:
>  case MSR_K7_FID_VID_STATUS:
>  case MSR_K8_PSTATE_LIMIT:
> @@ -2720,12 +2720,10 @@ static int emulate_privileged_op(struct 
>  }
>  goto rdmsr_normal;
>  case MSR_IA32_MISC_ENABLE:
> -if ( rdmsr_safe(regs->ecx, msr_content) )
> +if ( rdmsr_safe(regs->ecx, val) )
>  goto fail;
> -msr_content = guest_misc_enable(msr_content);
> -regs->eax = (uint32_t)msr_content;
> -regs->edx = (uint32_t)(msr_content >> 32);
> -break;
> +val = guest_misc_enable(val);
> +goto rdmsr_writeback;
>  
>  case MSR_AMD64_DR0_ADDRESS_MASK:
>  if ( !boot_cpu_has(X86_FEATURE_DBEXT) )
> @@ -2743,12 +2741,7 @@ static int emulate_privileged_op(struct 
>  
>  default:
>  if ( rdmsr_hypervisor_regs(regs->ecx, &val) )
> -{
> - rdmsr_writeback:
> -regs->eax = (uint32_t)val;
> -regs->edx = (uint32_t)(val >> 32);
> -break;
> -}
> +goto rdmsr_writeback;
>  
>  rc = vmce_rdmsr(regs->ecx, &val);
>  if ( rc < 0 )
> @@ -2761,10 +2754,11 @@ static int emulate_privileged_op(struct 
>  /* Everyone can read the MSR space. */
>  /* gdprintk(XENLOG_WARNING,"Domain attempted RDMSR %p.\n",
>  _p(regs->ecx));*/
> -if ( rdmsr_safe(regs->ecx, msr_content) )
> +if ( rdmsr_safe(regs->ecx, val) )
>  goto fail;
> -regs->eax = (uint32_t)msr_content;
> -regs->edx = (uint32_t)(msr_content >> 32);
> + rdmsr_writeback:
> +regs->eax = (uint32_t)val;
> +regs->edx = (uint32_t)(val >> 32);
>  break;
>  }
>  break;
>
>
>


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

Re: [Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.

[Jan Beulich]

>>> On 26.02.15 at 14:11,  wrote:
> Shuffle some struct definitions up to file scope so that they remain
> in scope in C++ when they're used again later.
> 
> Add an automatic check for similar C++ pitfalls, to be run only when
> g++ is available.
> 
> RFC because it's not clear whether we want to make any commitments to
> have the public headers be C++-friendly.

I like this, and it looks it was easier to do than I thought. Albeit ...

> --- a/xen/include/Makefile
> +++ b/xen/include/Makefile
> @@ -87,13 +87,19 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) 
> Makefile
>  
>  ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
>  
> -all: headers.chk
> +all: headers.chk headers++.chk
>  
> -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% 
> public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
> +PUBLIC_HEADERS_TO_CHECK := $(filter-out public/arch-% public/%ctl.h 
> public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) 
> $(public-y))
> +
> +headers.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
>   for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W 
> -Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done >$@.new
>   mv $@.new $@
>  
> +headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile

... I don't think limiting this to a subset of the headers is the right
thing here: C++ consumers are (most likely) going to be user space,
i.e. tools, and those would want to be able to use those excluded
headers.

> + if g++ -v >/dev/null; then for i in $(filter %.h,$^); do g++ -ansi 
> -include stdint.h -Wall -W -Werror -S -o /dev/null -x c++ 
> -Dprivate=private_is_a_keyword_in_c_plus_plus $$i || exit 1; echo $$i; done ; 
> fi >$@.new

You may want to define __XEN_TOOLS__ (and un-define __XEN__)
here. Also g++ ought to by abstracted to $(CXX), and I don't see
how this step is being avoided when there's no C++ compiler there.

> --- a/xen/include/public/platform.h
> +++ b/xen/include/public/platform.h

These changes went in a few minutes ago.

Jan


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

Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?

[Tim Deegan]

At 10:50 + on 24 Feb (1424771408), Andrew Cooper wrote:
> On 24/02/15 10:31, Jan Beulich wrote:
>  On 24.02.15 at 11:24,  wrote:
> >> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote:
> >>> Currently Jan Beulich is not happy with the addition of a new domain
> >>> creation flag.  Andrew Cooper is not happy with a HVM param.  I am stuck
> >>> in the middle.
> >> I prefer a new flag, for anything that's fixed for the life of the
> >> domain.  We've already had too many bugs where HVM params changed
> >> when people thought they wouldn't.
> >>
> >> Jan, is your objection that we'll run out of XEN_DOMCTL_CDF_* bits?  I
> >> think we can add more flag fields to DOMCTL_createdomain (or a v2) if
> >> that becomes a problem.
> > In a couple of years we may end up with an x86-CPUID-like mess
> > of hundreds of flags. And apart from that scalability issue I also
> > dislike the gross mixing of arch specific and generic flags here.
> > Perhaps the already arch-specific XEN_DOMCTL_configure_domain
> > would be the better route then if HVM params are being disliked?
> 
> Given some recent consideration to the problem of domain architectural
> state (x86 cpuid policy, arm gic/spi), a (set of?) configuration
> hypercalls valid only during domain construction would perhaps be the
> best way to proceed.

That sounds like you're also arguing for using HVM params then.  :)

The nice thing about having a single set of flags at creation time is
that it avoids any worrying about what order the flag-setting and the
init of VM state happens in (e.g. turning on a feature after vcpus are
already assigned means extra code to update them; having the features
be settable in any order means handling all O(N^2) interactions).

> Extending createdomain itself is incompatible with XSM disaggregation

Hrm.  Possibly, but I think that might be splitting hairs.
A privileged VM creation component will already have to check its
arguments (e.g. memory size, #vcpus, boot image) against some policy.

> and having the architectural state in the migration stream.

Not at all -- since these flags are immutable, you can trivially send
them before any other state.  If a toolstack can't remember what it
did, we could add a what-were-the-creation-flags domctl.

Tim.

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

[Xen-devel] [xen-4.3-testing test] 35333: FAIL

[xen . org]

flight 35333 xen-4.3-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35333/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf  3 host-install(3) broken in 35226 REGR. vs. 34190
 build-armhf-pvops3 host-install(3) broken in 35226 REGR. vs. 34190

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64  7 windows-install fail pass in 35226

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-sedf-pin  7 debian-installfail REGR. vs. 34190
 test-amd64-amd64-xl-qemut-winxpsp3  7 windows-install  fail like 34190

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 debian-hvm-install fail never pass
 test-amd64-amd64-xl-pcipt-intel  9 guest-start fail never pass
 test-amd64-amd64-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  10 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt  5 xen-boot fail   never pass
 test-armhf-armhf-xl-sedf-pin  5 xen-boot fail   never pass
 test-armhf-armhf-xl-sedf  5 xen-boot fail   never pass
 test-armhf-armhf-xl   5 xen-boot fail   never pass
 test-armhf-armhf-xl-credit2   5 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  5 xen-boot fail  never pass
 test-armhf-armhf-xl-midway5 xen-boot fail   never pass
 test-amd64-i386-xl-win7-amd64 14 guest-stop   fail  never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/checkfail never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop  fail never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop   fail never pass
 test-amd64-amd64-xl-win7-amd64 14 guest-stop   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
 test-amd64-i386-xend-winxpsp3 17 leak-check/check fail  never pass
 test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop   fail never pass
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass
 test-amd64-amd64-xl-winxpsp3 14 guest-stop   fail   never pass
 test-armhf-armhf-libvirt  1 build-check(1)blocked in 35226 n/a
 test-armhf-armhf-xl-sedf-pin  1 build-check(1)blocked in 35226 n/a
 test-armhf-armhf-xl-sedf  1 build-check(1)blocked in 35226 n/a
 test-armhf-armhf-xl   1 build-check(1)blocked in 35226 n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)blocked in 35226 n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked in 35226 n/a
 test-armhf-armhf-xl-midway1 build-check(1)blocked in 35226 n/a
 build-armhf-libvirt   1 build-check(1)blocked in 35226 n/a
 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stopfail in 35226 never pass

version targeted for testing:
 xen  9ebac5765496b34f15b2328f41c00f789ed6d712
baseline version:
 xen  ef73de2a84a3042c3481c9a521e8e0c756b793f2


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Ian Jackson 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass

Re: [Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform

[Frediano Ziglio]

> 
> Hi Frediano,
> 
> On 26/02/15 12:40, Frediano Ziglio wrote:
> > diff --git a/xen/arch/arm/domain_build.c
> b/xen/arch/arm/domain_build.c
> > index c2dcb49..0834053 100644
> > --- a/xen/arch/arm/domain_build.c
> > +++ b/xen/arch/arm/domain_build.c
> > @@ -1038,6 +1038,7 @@ static int handle_node(struct domain *d, struct
> kernel_info *kinfo,
> >  static const struct dt_device_match gic_matches[] __initconst =
> >  {
> >  DT_MATCH_GIC_V2,
> > +DT_MATCH_GIC_HIP04,
> >  DT_MATCH_GIC_V3,
> >  { /* sentinel */ },
> >  };
> 
> I think this is the perfect time to introduce a callback to check if
> the node is a GIC.
> 
> This would avoid to grow up this structure.
> 
> [..]
> 

Actually looking at assignment of dt_interrupt_controller (a dt_device_node) 
and calls to register_gic_ops there is a one-to-one correspondence so you can 
check if node == dt_interrupt_controller in handle_node instead of using a 
manually compiled gic_matches and checking with dt_match_node? This way I could 
even avoid to defined in a header the DT compatible string.

> > -static const char * const gicv2_dt_compat[] __initconst =
> > +static const char * const hip04gic_dt_compat[] __initconst =
> >  {
> > -DT_COMPAT_GIC_CORTEX_A15,
> > -DT_COMPAT_GIC_CORTEX_A7,
> > -DT_COMPAT_GIC_400,
> > +DT_COMPAT_GIC_HIP04,
> >  NULL
> >  };
> >
> > -DT_DEVICE_START(gicv2, "GICv2:", DEVICE_GIC)
> > -.compatible = gicv2_dt_compat,
> > -.init = gicv2_init,
> > +DT_DEVICE_START(hip04gic, "GIC-HIP04:", DEVICE_GIC)
> 
> The ":" was a mistake in the GICv2. Please don't reproduce it here.
> 
> > +.compatible = hip04gic_dt_compat,
> > +.init = hip04gic_init,
> >  DT_DEVICE_END
> >
> >  /*
> > diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c index
> > 390c8b0..e4512a8 100644
> > --- a/xen/arch/arm/gic.c
> > +++ b/xen/arch/arm/gic.c
> > @@ -565,12 +565,13 @@ static void do_sgi(struct cpu_user_regs *regs,
> > enum gic_sgi sgi)  void gic_interrupt(struct cpu_user_regs *regs, int
> > is_fiq)  {
> >  unsigned int irq;
> > +unsigned int max_irq = gic_hw_ops->info->nr_lines;
> >
> >  do  {
> >  /* Reading IRQ will ACK it */
> >  irq = gic_hw_ops->read_irq();
> >
> > -if ( likely(irq >= 16 && irq < 1021) )
> > +if ( likely(irq >= 16 && irq < max_irq) )
> >  {
> >  local_irq_enable();
> >  do_IRQ(regs, irq, is_fiq);
> 
> This change should belong to a separate patch.
> 
> > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > index 187dc46..a36f486 100644
> > --- a/xen/include/asm-arm/gic.h
> > +++ b/xen/include/asm-arm/gic.h
> > @@ -160,6 +160,10 @@
> >  DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_CORTEX_A7),
> \
> >  DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_400)
> >
> > +#define DT_COMPAT_GIC_HIP04  "hisilicon,hip04-intc"
> > +
> > +#define DT_MATCH_GIC_HIP04 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_HIP04)
> > +
> >  #define DT_COMPAT_GIC_V3 "arm,gic-v3"
> >
> >  #define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(DT_COMPAT_GIC_V3)
> 
> I would prefer if we avoid to add more compatibles like that in gic.h.
> 
> I have a patch to drop a part of this mess. I would advise your to use
> cherry-pick the commit [1] in your branch.
> 
> [1]
> http://xenbits.xen.org/gitweb/?p=people/julieng/xen-
> unstable.git;a=commit;h=7ba87910e557b06c589c3c0fbc6757fa664d029e
> 
> Regards,
> 
> --
> Julien Grall

Is this patch in staging?

Frediano


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

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Pranavkumar Sawargaonkar]

Hi

On Thu, Feb 26, 2015 at 4:19 PM, Vijay Kilari  wrote:
> On Wed, Feb 25, 2015 at 3:50 PM, Ian Campbell  wrote:
>> On Wed, 2015-02-25 at 08:03 +0530, Manish Jaggi wrote:
>>> On 24/02/15 7:13 pm, Julien Grall wrote:
>>> > On 24/02/15 00:23, Manish Jaggi wrote:
>>> >>> Because you have to parse all the device tree to remove the reference
>>> >>> to the second ITS. It's pointless and can be difficult to do it.
>>> >>>
>>> >> Could you please describe the case where it is difficult
>>> > You have to parse every node in the device tree and replace the
>>> > msi-parent properties with only one ITS.
>>> Thats the idea.
>>> >
>>> >>> If you are able to emulate on ITS, you can do it for multiple one.
>>> >> keeping it simple and similar across dom0/domUs
>>> >> Consider a case where a domU is assigned two PCI devices which are
>>> >> attached to different nodes. (Node is an entity having its own cores are
>>> >> host controllers).
>>> > The DOM0 view and guest view of the hardware are different.
>>> >
>>> > In the case of DOM0, we want to expose the same hardware layout as the
>>> > host. So if there is 2 ITS then we should expose the 2 ITS.
>>> AFAIK Xen has a microkernel design and timer/mmu/smmu/gic/its are
>>> handled by xen and a virtualized interface is provided to the guest. So
>>> if none of SMMU in the layout of host is presented to dom0 the same can
>>> be valid for multiple ITS.
>>
>> SMMU is one of the things which Xen hides from dom0, for obvious
>> reasons.
>>
>> Interrupts are exposed to dom0 in a 1:1 manner. AFAICT there is no
>> reason for ITS to differ here.
>>
>> Since dom0 needs to be able to cope with being able to see all of the
>> host host I/O devices (in the default no-passthrough case), it is
>> possible, if not likely, that it will need the same amount of ITS
>> resources (i.e. numbers of LPIs) as the host provides.
>>
>>> > In the case of the Guest, we (Xen) controls the memory layout.
>>> For Dom0 as well.
>>
>> Not true.
>>
>> For dom0 the memory layout is determined by the host memory layout. The
>> MMIO regions are mapped through 1:1 and the RAM is a subset of the RAM
>> regions of the host physical address space (often in 1:1, but with
>> sufficient h/w support this need not be the case).
>>
>>> > Therefore
>>> > we can expose only one ITS.
>>> If we follow 2 ITS in dom0 and 1 ITS in domU, how do u expect the Xen
>>> GIC ITS emulation driver to work.
>>> It should check that request came from a dom0 handle it differently. I
>>> think this would be *difficult*.
>>
>> I don't think so. If the vITS is written to handle multiple instances
>> (i.e. in a modular way, as it should be) then it shouldn't matter
>> whether any given domain has 1 or many vITS. The fact that dom0 may have
>> one or more and domU only (currently) has one then becomes largely
>> uninteresting.
>
> I have few queries
>
> 1) If Dom0 has 'n' ITS nodes, then how does Xen know which virtual ITS
> command Q is
> mapped to which Physical ITS command Q.
> In case of linux, the ITS node is added as msi chip to pci using
> of_pci_msi_chip_add()
> and from pci_dev structure we can know which ITS to use.
>
> But in case of Xen, when ITS command is trapped we have only
> dev_id info from ITS command.
>
> 2) If DomU is always given one virtual ITS node. If DomU is assinged
> with two different
> PCI devices connected to different physical ITS, then Xen vITS
> driver should know how to map
> PCI device to physical ITS
>
> For the two issues above, Xen should have mapping to pci segment and
> physical ITS node to use
> which can be queried by vITS driver and send command on to correct physical 
> ITS
>

Also if we just show only one vITS (or only one Virtual v2m frame)
instead of two vITS
then actual hardware interrupt number and virtual interrupt number
which guest will see will become different
This will hamper direct irq routing to guest.

-
Pranav



> Vijay
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT

[Paul Durrant]

> -Original Message-
> From: Don Slutz [mailto:dsl...@verizon.com]
> Sent: 26 February 2015 14:55
> To: Paul Durrant; Jan Beulich; Don Slutz
> Cc: Aravind Gopalakrishnan; Suravee Suthikulpanit; Andrew Cooper; Ian
> Campbell; George Dunlap; Ian Jackson; Stefano Stabellini; Eddie Dong; Jun
> Nakajima; Kevin Tian; xen-devel@lists.xen.org; Boris Ostrovsky; Konrad
> Rzeszutek Wilk; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
> 
> On 02/26/15 06:49, Paul Durrant wrote:
> >> -Original Message-
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: 26 February 2015 08:08
> >> To: Don Slutz
> >> Cc: Aravind Gopalakrishnan; Suravee Suthikulpanit; Andrew Cooper; Ian
> >> Campbell; Paul Durrant; George Dunlap; Ian Jackson; Stefano Stabellini;
> Eddie
> >> Dong; Jun Nakajima; Kevin Tian; xen-devel@lists.xen.org; Boris Ostrovsky;
> >> Konrad Rzeszutek Wilk; Keir (Xen.org); Tim (Xen.org)
> >> Subject: Re: [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
> >>
> > On 25.02.15 at 21:20,  wrote:
> >>> On 02/24/15 10:34, Jan Beulich wrote:
> >>> On 17.02.15 at 00:05,  wrote:
> > @@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct
> >> domain *d, unsigned long gmfn)
> >  clear_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
> >  }
> >
> > -static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s,
> >> bool_t buf)
> > +static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, int
> >> buf)
> >  {
> > -struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> > +struct hvm_ioreq_page *iorp = NULL;
> > +
> > +switch ( buf )
> > +{
> > +case 0:
> > +iorp = &s->ioreq;
> > +break;
> > +case 1:
> > +iorp = &s->bufioreq;
> > +break;
> > +case 2:
> > +iorp = &s->vmport_ioreq;
> > +break;
> > +}
> 
>  These literals should become an enum.
> 
> >>>
> >>> Paul Durrant asked for #defined values.  So it is not clear which way to
> >>> go. Will wait for response.
> >>
> >> Obviously either would be fine. An enum has the potential advantage
> >> of the compiler being able to check switch statements for completeness
> >> (albeit there are cases where this ends up being a disadvantage).
> >>
> >
> > I'm fine with an enum... just not with (repeated) magic numbers in the
> code.
> >
> 
> Ok, will use enum.
> 
> 
> > [snip]
> >>> Some background.  When Julien Grall added 2, this was said:
> >>>
> >>> Keir Fraser
> >>> [...]
> >>> They were almost certainly used for representing R-M-W ALU
> operations
> >> back
> >>> in the days of the old IO emulator, very long ago. Still, there''s no
> >>> harm in
> >>> leaving them unused.
> >>> [...]
> >>> I did find the old defn:
> >>>
> >>> dcs-xen-54:~/xen>git show 4ff8936 | grep IOREQ_TYPE_
> >>> #define IOREQ_TYPE_PIO  0 /* pio */
> >>> #define IOREQ_TYPE_COPY 1 /* mmio ops */
> >>> #define IOREQ_TYPE_AND  2
> >>> #define IOREQ_TYPE_OR   3
> >>> #define IOREQ_TYPE_XOR  4
> >>> #define IOREQ_TYPE_XCHG 5
> >>> #define IOREQ_TYPE_ADD  6
> >>> [...]
> >>> Which matches what Keir Fraser said.
> >>>
> >>> I did not find why Paul Durrant did not use 9.  I can only find it as 2
> >>> in all Paul's patch sets.  Which is closely connected to:
> >>>
> >>>  BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
> >>>  BUILD_BUG_ON(IOREQ_TYPE_COPY !=
> >> HVMOP_IO_RANGE_MEMORY);
> >>>  BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG !=
> >> HVMOP_IO_RANGE_PCI);
> >>>
> >>> (a new hyper call arg).  This also did not add a hole in "range" so
> >>> Paul Durrant did not have to check for a "range" hole.
> >>>
> >>> So I did just like Paul Durrant did.  He also approved the patch with
> >>> this number in QEMU.  Since this is now in upstream QEMU, changing it
> at
> >>> this time is a slower process.  Since the only time QEMU uses its
> >>> version is when Xen header files are missing, I do not see how a QEMU
> >>> built with its version would be usable as a QEMU for Xen.  So I am
> >>> happy to change to a new number like 9.
> >>
> >> Yes please. I'm not saying we absolutely have to correct the one
> >> Paul added (unless we learn it causes problems), but I think we
> >> should avoid making the same (even if only potential) mistake twice.
> >> Of course it would help to get insight from Paul (now Cc-ed) here.
> >>
> >
> > I used the hole because I really did not think anyone would
> > ever expect to use an ancient emulator against a recent
> > Xen. Given there has been no fallout I don't see why we can't
> > use the hole.
> 
> 
> Well, this is a little confusing (I read this as Paul is fine with 3).
> Since both Jan Beulich and Keir Fraser want to skip the hole, I will
> switch to 9.

I read Keir's comment as meaning he didn't care either way. If Jan wants to use 
9 then I have no objection.

Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT

[Jan Beulich]

>>> On 26.02.15 at 15:55,  wrote:
> Well, this is a little confusing (I read this as Paul is fine with 3).
> Since both Jan Beulich and Keir Fraser want to skip the hole, I will
> switch to 9.

If not leaving a hole makes the code meaningfully simpler, then go
with what you have. But if the hole left doesn't cause any other
problem for you, then (citing Keir) "there's no harm in leaving them
unused".

Jan


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

Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT

[Jan Beulich]

>>> On 25.02.15 at 21:20,  wrote:
> On 02/24/15 10:34, Jan Beulich wrote:
> On 17.02.15 at 00:05,  wrote:
>>> @@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct domain *d, 
>>> unsigned long gmfn)
>>>  clear_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
>>>  }
>>>  
>>> -static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, bool_t buf)
>>> +static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, int buf)
>>>  {
>>> -struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
>>> +struct hvm_ioreq_page *iorp = NULL;
>>> +
>>> +switch ( buf )
>>> +{
>>> +case 0:
>>> +iorp = &s->ioreq;
>>> +break;
>>> +case 1:
>>> +iorp = &s->bufioreq;
>>> +break;
>>> +case 2:
>>> +iorp = &s->vmport_ioreq;
>>> +break;
>>> +}
>> 
>> These literals should become an enum.
>> 
> 
> Paul Durrant asked for #defined values.  So it is not clear which way to
> go. Will wait for response.

Obviously either would be fine. An enum has the potential advantage
of the compiler being able to check switch statements for completeness
(albeit there are cases where this ends up being a disadvantage).

>>> @@ -2429,9 +2552,6 @@ struct hvm_ioreq_server 
>>> *hvm_select_ioreq_server(struct 
> domain *d,
>>>  if ( list_empty(&d->arch.hvm_domain.ioreq_server.list) )
>>>  return NULL;
>>>  
>>> -if ( p->type != IOREQ_TYPE_COPY && p->type != IOREQ_TYPE_PIO )
>>> -return d->arch.hvm_domain.default_ioreq_server;
>> 
>> Shouldn't this rather be amended than deleted?
>> 
> 
> The reason is below:
> 
>>> @@ -2474,7 +2594,12 @@ struct hvm_ioreq_server 
>>> *hvm_select_ioreq_server(struct domain *d,
>>>  BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
>>>  BUILD_BUG_ON(IOREQ_TYPE_COPY != HVMOP_IO_RANGE_MEMORY);
>>>  BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG != HVMOP_IO_RANGE_PCI);
>>> +BUILD_BUG_ON(IOREQ_TYPE_VMWARE_PORT != HVMOP_IO_RANGE_VMWARE_PORT);
>>> +BUILD_BUG_ON(IOREQ_TYPE_TIMEOFFSET != HVMOP_IO_RANGE_TIMEOFFSET);
>>> +BUILD_BUG_ON(IOREQ_TYPE_INVALIDATE != HVMOP_IO_RANGE_INVALIDATE);
>>>  r = s->range[type];
>>> +if ( !r )
>>> +continue;
>> 
>> Why, all of the sudden?
>> 
> 
> This is the replacement for the deleted "if" above.  Continue will lead
> to the same return that was remove above (it is at the end).  They are
> currently the same because all ioreq servers have the same set of
> ranges.  But if it would help, I can change "continue" into the "return
> default".

So further down you talk of the "special range 1" (see there for
further remarks in this regard) - how would r be NULL here in the
first place? That said - yes, making this explicitly do what is
intended (perhaps rather using "break" instead of "return") would
seem very desirable. There simply is no point in continuing the
loop.

>>> @@ -2501,6 +2626,13 @@ struct hvm_ioreq_server 
>>> *hvm_select_ioreq_server(struct domain *d,
>>>  }
>>>  
>>>  break;
>>> +case IOREQ_TYPE_VMWARE_PORT:
>>> +case IOREQ_TYPE_TIMEOFFSET:
>>> +case IOREQ_TYPE_INVALIDATE:
>>> +if ( rangeset_contains_singleton(r, 1) )
>>> +return s;
>> 
>> This literal 1 at least needs explanation (i.e. a comment).
>> 
> 
> The comment is below (copied here).  Will duplicate it here (with any
> adjustments needed):
> 
>  + * NOTE: The 'special' range of 1 is what is checked for outside
>  + * of the three types of I/O.
> 
> How about /* The 'special' range of 1 is checked for being enabled */?

Along these lines, yes (fixed for coding style). And then "1" is not
a range of any kind. I suppose writing it as a proper range (e.g.
[1,1]) would already help.

>>> --- a/xen/arch/x86/x86_emulate/x86_emulate.h
>>> +++ b/xen/arch/x86/x86_emulate/x86_emulate.h
>>> @@ -112,6 +112,8 @@ struct __packed segment_register {
>>>  #define X86EMUL_RETRY  3
>>>   /* (cmpxchg accessor): CMPXCHG failed. Maps to X86EMUL_RETRY in caller. */
>>>  #define X86EMUL_CMPXCHG_FAILED 3
>>> + /* Send part of registers also to DM. */
>>> +#define X86EMUL_VMPORT_SEND4
>> 
>> Introducing a new value here seems rather fragile, as various code
>> paths you don't touch would need auditing that they do the right
>> thing upon this value being returned. Plus even conceptually this
>> doesn't belong here - the instruction emulator shouldn't be concerned
>> with things like VMware emulation.
>> 
> 
> The only place I know of where rc is not checked by name is in
> x86_emulate.c.  There are a lot of 0 and != 0 checks.  Also in area of
> code there are places that return X86EMUL_OKAY when it looks to me that
> the return value is checked for 0 and ignored otherwise.

The point aren't the checks against zero, but the ones against the
#define-d values. Code may exist that, after excluding certain
values, assumes that only some specific value can be left. While
we aim at adding AS

[Xen-devel] [PATCH 3/5] libxc: Split off xc_netbsd_user.c

[Wei Liu]

From: Ian Jackson 

We are going to want to use some but not all of the machinery
previously in xc_netbsd.c Split the evtchn and ancillary code into its
own file.  This part is pure code motion.

But we also have to alter the Makefile, and rename some symbols, as
with xc_minios*.c.

Signed-off-by: Ian Jackson 
---
 tools/libxc/Makefile |   2 +-
 tools/libxc/xc_netbsd.c  | 168 +
 tools/libxc/xc_netbsd_user.c | 196 +++
 3 files changed, 198 insertions(+), 168 deletions(-)
 create mode 100644 tools/libxc/xc_netbsd_user.c

diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 4ace2b6..0f3396c 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -46,7 +46,7 @@ CTRL_SRCS-$(CONFIG_X86) += xc_pagetab.c
 CTRL_SRCS-$(CONFIG_Linux) += xc_linux.c xc_linux_osdep.c
 CTRL_SRCS-$(CONFIG_FreeBSD) += xc_freebsd.c xc_freebsd_osdep.c
 CTRL_SRCS-$(CONFIG_SunOS) += xc_solaris.c
-CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c
+CTRL_SRCS-$(CONFIG_NetBSD) += xc_netbsd.c xc_netbsd_user.c
 CTRL_SRCS-$(CONFIG_MiniOS) += xc_minios.c xc_minios_privcmd.c
 
 GUEST_SRCS-y :=
diff --git a/tools/libxc/xc_netbsd.c b/tools/libxc/xc_netbsd.c
index 8a90ef3..f940607 100644
--- a/tools/libxc/xc_netbsd.c
+++ b/tools/libxc/xc_netbsd.c
@@ -224,172 +224,6 @@ static struct xc_osdep_ops netbsd_privcmd_ops = {
 },
 };
 
-#define EVTCHN_DEV_NAME  "/dev/xenevt"
-
-static xc_osdep_handle netbsd_evtchn_open(xc_evtchn *xce)
-{
-int fd = open(EVTCHN_DEV_NAME, O_NONBLOCK|O_RDWR);
-if ( fd == -1 )
-return XC_OSDEP_OPEN_ERROR;
-
-return (xc_osdep_handle)fd;
-}
-
-static int netbsd_evtchn_close(xc_evtchn *xce, xc_osdep_handle h)
-{
-int fd = (int)h;
-return close(fd);
-}
-
-static int netbsd_evtchn_fd(xc_evtchn *xce, xc_osdep_handle h)
-{
-return (int)h;
-}
-
-static int netbsd_evtchn_notify(xc_evtchn *xce, xc_osdep_handle h, 
evtchn_port_t port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_notify notify;
-
-notify.port = port;
-
-return ioctl(fd, IOCTL_EVTCHN_NOTIFY, ¬ify);
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_unbound_port(xc_evtchn * xce, xc_osdep_handle h, int domid)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_unbound_port bind;
-int ret;
-
-bind.remote_domain = domid;
-
-ret = ioctl(fd, IOCTL_EVTCHN_BIND_UNBOUND_PORT, &bind);
-if (ret == 0)
-   return bind.port;
-else
-   return -1;
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_interdomain(xc_evtchn *xce, xc_osdep_handle h, int domid,
-   evtchn_port_t remote_port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_interdomain bind;
-int ret;
-
-bind.remote_domain = domid;
-bind.remote_port = remote_port;
-
-ret = ioctl(fd, IOCTL_EVTCHN_BIND_INTERDOMAIN, &bind);
-if (ret == 0)
-   return bind.port;
-else
-   return -1;
-}
-
-static int netbsd_evtchn_unbind(xc_evtchn *xce, xc_osdep_handle h, 
evtchn_port_t port)
-{
-int fd = (int)h;
-struct ioctl_evtchn_unbind unbind;
-
-unbind.port = port;
-
-return ioctl(fd, IOCTL_EVTCHN_UNBIND, &unbind);
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_bind_virq(xc_evtchn *xce, xc_osdep_handle h, unsigned int virq)
-{
-int fd = (int)h;
-struct ioctl_evtchn_bind_virq bind;
-int err;
-
-bind.virq = virq;
-
-err = ioctl(fd, IOCTL_EVTCHN_BIND_VIRQ, &bind);
-if (err)
-   return -1;
-else
-   return bind.port;
-}
-
-static evtchn_port_or_error_t
-netbsd_evtchn_pending(xc_evtchn *xce, xc_osdep_handle h)
-{
-int fd = (int)h;
-evtchn_port_t port;
-
-if ( read_exact(fd, (char *)&port, sizeof(port)) == -1 )
-return -1;
-
-return port;
-}
-
-static int netbsd_evtchn_unmask(xc_evtchn *xce, xc_osdep_handle h, 
evtchn_port_t port)
-{
-int fd = (int)h;
-return write_exact(fd, (char *)&port, sizeof(port));
-}
-
-static struct xc_osdep_ops netbsd_evtchn_ops = {
-.open = &netbsd_evtchn_open,
-.close = &netbsd_evtchn_close,
-
-.u.evtchn = {
- .fd = &netbsd_evtchn_fd,
- .notify = &netbsd_evtchn_notify,
- .bind_unbound_port = &netbsd_evtchn_bind_unbound_port,
- .bind_interdomain = &netbsd_evtchn_bind_interdomain,
- .bind_virq = &netbsd_evtchn_bind_virq,
- .unbind = &netbsd_evtchn_unbind,
- .pending = &netbsd_evtchn_pending,
- .unmask = &netbsd_evtchn_unmask,
-},
-};
-
-/* Optionally flush file to disk and discard page cache */
-void discard_file_cache(xc_interface *xch, int fd, int flush) 
-{
-off_t cur = 0;
-int saved_errno = errno;
-
-if ( flush && (fsync(fd) < 0) )
-{
-/*PERROR("Failed to flush file: %s", strerror(errno));*/
-goto out;
-}
-
-/*
- * Calculate last page boundry of amount written so far
- * unless we are flushing in which case entire cache
- * is discarded.
- */
-if ( !flush )
-

[Xen-devel] [rumpuserxen test] 35449: regressions - FAIL

[xen . org]

flight 35449 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35449/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 33866

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a

version targeted for testing:
 rumpuserxen  21909666eb2d85c02770d04691795abfd4417392
baseline version:
 rumpuserxen  30d72f3fc5e35cd53afd82c8179cc0e0b11146ad


People who touched revisions under test:
  Antti Kantee 
  Ian Jackson 
  Martin Lucina 


jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-i386-rumpuserxen-i386 blocked 



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 339 lines long.)

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

[Xen-devel] [PATCH 1/1] xen-netback: remove compilation warning

[pedro]

From: pmarzo 

offset and size are of type uint16_t so the %lu gives a warning
A %u specifier, the same used in size makes gcc happy
Not sure if a %x would be more correct

Signed-off-by: Pedro Marzo Perez 
---
 drivers/net/xen-netback/netback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index f7a31d2..3888a2b 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1248,7 +1248,7 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
*queue,
/* No crossing a page as the payload mustn't fragment. */
if (unlikely((txreq.offset + txreq.size) > PAGE_SIZE)) {
netdev_err(queue->vif->dev,
-  "txreq.offset: %x, size: %u, end: %lu\n",
+  "txreq.offset: %x, size: %u, end: %u\n",
   txreq.offset, txreq.size,
   (txreq.offset&~PAGE_MASK) + txreq.size);
xenvif_fatal_tx_err(queue->vif);
-- 
1.9.1


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

Re: [Xen-devel] [PATCH v5.99.1 RFC 1/4] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Ian Campbell]

On Thu, 2015-02-26 at 13:54 +, Julien Grall wrote:
> > NB: I'm only considering host level stuff here. Our virtualised hardware
> > as exposed to the guest is well defined right now and any conversation
> > about deviating from the set of hardware (e.g. providing a guest view to
> > a non-GIC compliant virtual interrupt controller) would be part of a
> > separate larger conversation about "hvm" style guests (and I'd, as you
> > might imagine, be very reluctant to code to Xen itself to support
> > non-standard vGICs in particular).
> 
> That would mean on platform such as Hisilicon, Guest (including DOM0)
> won't be able to use more than 8 CPUs. But I guess this is a fair trade
> for having a GIC which differs from the spec.

Correct.

> 
> > From a "what does 'standards compliant' mean" PoV we have:
> > 
> > CPUs:
> > 
> > Specified in the ARM ARM (v7=ARM DDI 0406, v8=ARM DDI 0487).
> > 
> > Uncontroversial, I hope!
> > 
> > Host interrupt controllers:
> > 
> > Defined in "ARM Generic Interrupt Controller Architecture
> > Specification" (v2=ARM IHI 0048B, v3=???).
> 
> AFAICT, for GICv3 there is a hardware spec available (though not
> publicly) but no developer spec.


The "Architecture Specification" is the one we want, I don't know if
that is what you meant by hardware spec, I have one although as you say
I don't think it is public yet.

> 
> > Referenced from ARMv8 ARM (but not required AFAICT) but
> > nonetheless this is what we consider when we talk about the
> > "standard interrupt controller".
> > 
> > Host timers:
> > 
> > Defined in the ARMv8 ARM "Generic Timers" chapter.
> > 
> > Defined as an extension to ARMv7 (don't have doc ref handy). For
> > our purposes such extensions are considered standardized[*].
> 
> It's worth to mention that we don't support generic memory mapped timer
> for now. I don't know if we aim to support it.

I don't know either, yet. For now we don't, that's correct.

> > UARTS:
> > 
> > SBSA defines some (pl011 only?), but there are lots, including
> > 8250-alike ones (ns16550 etc) which is a well established
> > standard (from x86).
> > 
> > Given that UART drivers are generally small and pretty trivial I
> > think we can tolerate "non-standard" (i.e. non-SBSA, non-8250)
> > ones, so long as they are able to support our vuart interface.
> > 
> > I think the non-{pl011,8250} ones should be subject to non-core
> > (i.e. community) maintenance as I mentioned previously, i.e
> > should be listed in MAINTAINERS other than under the core ARM
> > entry. If we decide to go ahead with this approach I'll ask the
> > appropriate people to update MAINTAINERS.
> 
> At that time we have 3 "non-compliant" UART in Xen: exynos4210, scif and
> omap.
> 
> Having maintainers per non-compliant UART would make some generic more
> complicate to upstream.

In reality by a negligible amount, I expect.

>  Indeed, it would require all the ack.

I don't think that's true, an update to core which requires updates to
all drivers shouldn't be blocked by non-responsive maintainer. If they
don't respond then their driver might break.

This all works fine for much larger projects. Take Linux for example:
you don't see them getting stalled on core infrastructure updates
because the author of some niche serial driver isn't responding to his
mail. They do the sensible thing and get on with it.

> [..]
> 
> > I think the above is a workable definition of what it is reasonable to
> > expect the core Xen/ARM maintainers to look after (with that particular
> > hat on) vs. what it should be expected for interested members of the
> > community to step up and maintain (where the people who happen to be
> > core Xen/ARM maintainers may occasionally chose to have such a hat too.)
> 
> I got few questions about it:
>   -  What happen if the maintainers of a specific driver (UART/IRQ
> controller) doesn't answer?

Then their driver might break or bitrot, and eventually be removed.

>   - How do we handle possible security issue related to a specific
> driver? Is it even considered as a security one?

In the same way we do today with any security issue, which is to say the
security team will deal with it, bringing in people as they feel
appropriate (and the discoverer agrees). This is no different to a bug
in any other bit of Xen who's maintainer is not on the security team.

>   - As a new drivers would tight to a new set of maintainers, how do we
> decide that a new drivers is accepted in Xen?

In the normal way.

> Given the governance spec [1], we may decide to reject a maintainers for
> some reason. Does it mean the drivers is rejected too?

If someone writes a driver for a h/w component and wants to be the
maintainer then there is no normal reason to reject them IMHO.

To put it anoth

Re: [Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.

[Tim Deegan]

At 14:09 + on 26 Feb (1424956161), Jan Beulich wrote:
> >>> On 26.02.15 at 14:11,  wrote:
> > -headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% 
> > public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) 
> > Makefile
> > +PUBLIC_HEADERS_TO_CHECK := $(filter-out public/arch-% public/%ctl.h 
> > public/xsm/% public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) 
> > $(public-y))
> > +
> > +headers.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
> > for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W 
> > -Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done >$@.new
> > mv $@.new $@
> >  
> > +headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
> 
> ... I don't think limiting this to a subset of the headers is the right
> thing here: C++ consumers are (most likely) going to be user space,
> i.e. tools, and those would want to be able to use those excluded
> headers.

OK.  I'll have a look through that list.  I presume I'll still want to
exclude e.g. the arch/ headers on the grounds that users shouldn't
be including them directly (and we won't want cross-arch includes)?

If I'm extending this to cover more headers than the ANSI-C check
does, should I also relax the '-ansi' requirement to, e.g. '-std=gnu++98'?

> > +   if g++ -v >/dev/null; then for i in $(filter %.h,$^); do g++ -ansi 
> > -include stdint.h -Wall -W -Werror -S -o /dev/null -x c++ 
> > -Dprivate=private_is_a_keyword_in_c_plus_plus $$i || exit 1; echo $$i; done 
> > ; fi >$@.new
> 
> You may want to define __XEN_TOOLS__ (and un-define __XEN__)
> here.

OK.  I wonder how many more things will break when I do that. :)

> Also g++ ought to by abstracted to $(CXX)

Sure, I'll define up $(CXX) in StdGnu.mk.  

> and I don't see
> how this step is being avoided when there's no C++ compiler there.

if g++ isn't on the path, 'g++ -v' fails and we end up with an empty
headers++.chk file.  It doesn't deal with a present-but-broken g++ but
that way lies autoconf.

> > --- a/xen/include/public/platform.h
> > +++ b/xen/include/public/platform.h
> 
> These changes went in a few minutes ago.

Good-oh; I'll drop them from a v2.

Tim.

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

Re: [Xen-devel] [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT

[Don Slutz]

On 02/26/15 06:49, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 February 2015 08:08
>> To: Don Slutz
>> Cc: Aravind Gopalakrishnan; Suravee Suthikulpanit; Andrew Cooper; Ian
>> Campbell; Paul Durrant; George Dunlap; Ian Jackson; Stefano Stabellini; Eddie
>> Dong; Jun Nakajima; Kevin Tian; xen-devel@lists.xen.org; Boris Ostrovsky;
>> Konrad Rzeszutek Wilk; Keir (Xen.org); Tim (Xen.org)
>> Subject: Re: [PATCH v9 08/13] Add IOREQ_TYPE_VMWARE_PORT
>>
> On 25.02.15 at 21:20,  wrote:
>>> On 02/24/15 10:34, Jan Beulich wrote:
>>> On 17.02.15 at 00:05,  wrote:
> @@ -501,22 +542,50 @@ static void hvm_free_ioreq_gmfn(struct
>> domain *d, unsigned long gmfn)
>  clear_bit(i, &d->arch.hvm_domain.ioreq_gmfn.mask);
>  }
>
> -static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s,
>> bool_t buf)
> +static void hvm_unmap_ioreq_page(struct hvm_ioreq_server *s, int
>> buf)
>  {
> -struct hvm_ioreq_page *iorp = buf ? &s->bufioreq : &s->ioreq;
> +struct hvm_ioreq_page *iorp = NULL;
> +
> +switch ( buf )
> +{
> +case 0:
> +iorp = &s->ioreq;
> +break;
> +case 1:
> +iorp = &s->bufioreq;
> +break;
> +case 2:
> +iorp = &s->vmport_ioreq;
> +break;
> +}

 These literals should become an enum.

>>>
>>> Paul Durrant asked for #defined values.  So it is not clear which way to
>>> go. Will wait for response.
>>
>> Obviously either would be fine. An enum has the potential advantage
>> of the compiler being able to check switch statements for completeness
>> (albeit there are cases where this ends up being a disadvantage).
>>
> 
> I'm fine with an enum... just not with (repeated) magic numbers in the code.
> 

Ok, will use enum.


> [snip]
>>> Some background.  When Julien Grall added 2, this was said:
>>>
>>> Keir Fraser
>>> [...]
>>> They were almost certainly used for representing R-M-W ALU operations
>> back
>>> in the days of the old IO emulator, very long ago. Still, there''s no
>>> harm in
>>> leaving them unused.
>>> [...]
>>> I did find the old defn:
>>>
>>> dcs-xen-54:~/xen>git show 4ff8936 | grep IOREQ_TYPE_
>>> #define IOREQ_TYPE_PIO  0 /* pio */
>>> #define IOREQ_TYPE_COPY 1 /* mmio ops */
>>> #define IOREQ_TYPE_AND  2
>>> #define IOREQ_TYPE_OR   3
>>> #define IOREQ_TYPE_XOR  4
>>> #define IOREQ_TYPE_XCHG 5
>>> #define IOREQ_TYPE_ADD  6
>>> [...]
>>> Which matches what Keir Fraser said.
>>>
>>> I did not find why Paul Durrant did not use 9.  I can only find it as 2
>>> in all Paul's patch sets.  Which is closely connected to:
>>>
>>>  BUILD_BUG_ON(IOREQ_TYPE_PIO != HVMOP_IO_RANGE_PORT);
>>>  BUILD_BUG_ON(IOREQ_TYPE_COPY !=
>> HVMOP_IO_RANGE_MEMORY);
>>>  BUILD_BUG_ON(IOREQ_TYPE_PCI_CONFIG !=
>> HVMOP_IO_RANGE_PCI);
>>>
>>> (a new hyper call arg).  This also did not add a hole in "range" so
>>> Paul Durrant did not have to check for a "range" hole.
>>>
>>> So I did just like Paul Durrant did.  He also approved the patch with
>>> this number in QEMU.  Since this is now in upstream QEMU, changing it at
>>> this time is a slower process.  Since the only time QEMU uses its
>>> version is when Xen header files are missing, I do not see how a QEMU
>>> built with its version would be usable as a QEMU for Xen.  So I am
>>> happy to change to a new number like 9.
>>
>> Yes please. I'm not saying we absolutely have to correct the one
>> Paul added (unless we learn it causes problems), but I think we
>> should avoid making the same (even if only potential) mistake twice.
>> Of course it would help to get insight from Paul (now Cc-ed) here.
>>
> 
> I used the hole because I really did not think anyone would
> ever expect to use an ancient emulator against a recent
> Xen. Given there has been no fallout I don't see why we can't
> use the hole.


Well, this is a little confusing (I read this as Paul is fine with 3).
Since both Jan Beulich and Keir Fraser want to skip the hole, I will
switch to 9.

   -Don Slutz

>   Paul
> 

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

Re: [Xen-devel] [PATCH 3/4] xen: sched: make counters for vCPU tickling generic

[Dario Faggioli]

On Thu, 2015-02-26 at 15:22 +, Jan Beulich wrote:
> >>> On 26.02.15 at 14:37,  wrote:
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -571,9 +571,11 @@ tickle:
> >(unsigned char *)&d);
> >  }
> >  cpumask_set_cpu(ipid, &rqd->tickled);
> > +SCHED_STAT_CRANK(tickle_idlers_some);
> >  cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
> >  
> >  no_tickle:
> > +SCHED_STAT_CRANK(tickle_idlers_none);
> >  return;
> >  }
> 
> Isn't there a return statement missing ahead of "no_tickle:" now?
> 
There is. I reworked this last minute, and overlooked this... sorry.
Will fix for v2.

Thanks and Regards,
Dario


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Frediano Ziglio]

> On 26/02/15 14:31, Frediano Ziglio wrote:
> >>
> >> Hi Frediano,
> >>
> >> On 26/02/15 12:40, Frediano Ziglio wrote:
> >>> HiSilison Hip04 platform use a slightly different version.
> >>> This is just a verbatim copy of the file to workaround git not
> fully
> >>> supporting copy operation.
> >>
> >> This is an old verbatim copy. You miss at least one change in the
> >> copied
> >> GICv2 driver.
> >>
> >> Regards,
> >>
> >> --
> >> Julien Grall
> >
> > I think you are referring to changes in staging, right ?
> 
> Yes. If you already start to diverge from staging that's not good.
> 
> We may have some patches reaching upstream before this series. You have
> to keep up-date every-time you send a new version.
> 
> Regards,
> 

Ok, I always used master as a start, not staging. I'll rebase on staging then.

Frediano


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

Re: [Xen-devel] [PATCH 0/4] xen: sched: rework and add performance counters

[Jan Beulich]

>>> On 26.02.15 at 14:36,  wrote:
> A small series that refactors a few of the existing scheduling related
> performance counters, making them generic and updating them from all
> schedulers, rather than just in Credit1.
> 
> It also (in the last patch) add a few new counters, specific to Credit2.
> 
> Thanks and Regards,
> Dario
> ---
> Dario Faggioli (4):
>   xen: sched: honour generic perf conuters in the RTDS scheduler
>   xen: sched: make counters for vCPU sleep and wakeup generic
>   xen: sched: make counters for vCPU tickling generic
>   xen: credit2: add a few performance counters
> 
>  xen/common/sched_credit2.c   |   37 +
>  xen/common/sched_rt.c|   18 ++
>  xen/include/xen/perfc_defn.h |   29 +

With the typos in patch 4 fixed, all changes to this file in this series
Acked-by: Jan Beulich 

Jan


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

[Xen-devel] [libvirt test] 35360: regressions - FAIL

[xen . org]

flight 35360 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/35360/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt 13 guest-destroy fail REGR. vs. 34580
 test-amd64-amd64-libvirt 13 guest-destroy fail REGR. vs. 34580

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 10 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  10 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  efd30e2e1cb2b9e467c225db92e8a16eb8de2632
baseline version:
 libvirt  4438646c0d7ff5c4857e6b010032f0fdf0a6039c


People who touched revisions under test:
  Cole Robinson 
  Daniel Hansel 
  Daniel P. Berrange 
  Jiri Denemark 
  Ján Tomko 
  Laine Stump 
  Luyao Huang 
  Marek Marczykowski 
  Marek Marczykowski-Górecki 
  Martin Kletzander 
  Michal Privoznik 
  Mikhail Feoktistov 
  Pavel Hrdina 
  Peter Krempa 
  Prerna Saxena 
  Stefan Zimmermann 


jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt fail
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass



sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

(No revision log; it would be 849 lines long.)

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

[Xen-devel] [PATCH v4 03/30] xen/PCI: Don't use deprecated function pci_scan_bus_parented()

[Yijing Wang]

From: Arnd Bergmann 

Use pci_scan_root_bus() instead of deprecated function
pci_scan_bus_parented().

Signed-off-by: Arnd Bergmann 
Signed-off-by: Yijing Wang 
CC: Konrad Rzeszutek Wilk 
CC: xen-de...@lists.xenproject.org
---
 drivers/pci/xen-pcifront.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index b1ffebe..240ddbc 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -446,6 +446,7 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
 unsigned int domain, unsigned int bus)
 {
struct pci_bus *b;
+   LIST_HEAD(resources);
struct pcifront_sd *sd = NULL;
struct pci_bus_entry *bus_entry = NULL;
int err = 0;
@@ -470,17 +471,20 @@ static int pcifront_scan_root(struct pcifront_device 
*pdev,
err = -ENOMEM;
goto err_out;
}
+   pci_add_resource(&resources, &ioport_resource);
+   pci_add_resource(&resources, &iomem_resource);
pcifront_init_sd(sd, domain, bus, pdev);
 
pci_lock_rescan_remove();
 
-   b = pci_scan_bus_parented(&pdev->xdev->dev, bus,
- &pcifront_bus_ops, sd);
+   b = pci_scan_root_bus(&pdev->xdev->dev, bus,
+ &pcifront_bus_ops, sd, &resources);
if (!b) {
dev_err(&pdev->xdev->dev,
"Error creating PCI Frontend Bus!\n");
err = -ENOMEM;
pci_unlock_rescan_remove();
+   pci_free_resource_list(&resources);
goto err_out;
}
 
@@ -488,7 +492,7 @@ static int pcifront_scan_root(struct pcifront_device *pdev,
 
list_add(&bus_entry->list, &pdev->root_buses);
 
-   /* pci_scan_bus_parented skips devices which do not have a have
+   /* pci_scan_root_bus skips devices which do not have a have
* devfn==0. The pcifront_scan_bus enumerates all devfn. */
err = pcifront_scan_bus(pdev, domain, bus, b);
 
-- 
1.7.1


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

[Xen-devel] [PATCH v10 1/4] tools: correct coding style for psr

[Chao Peng]

- space: remove space after '(' or before ')' in 'if' condition;
- indention: align function definition/call arguments;

Signed-off-by: Chao Peng 
Acked-by: Wei Liu 
---
 tools/libxc/include/xenctrl.h | 10 +-
 tools/libxc/xc_psr.c  | 10 +-
 tools/libxl/libxl.h   | 11 +++
 tools/libxl/libxl_psr.c   | 11 +++
 tools/libxl/xl_cmdimpl.c  | 11 ++-
 5 files changed, 30 insertions(+), 23 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 790db53..09d819f 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2693,14 +2693,14 @@ typedef enum xc_psr_cmt_type xc_psr_cmt_type;
 int xc_psr_cmt_attach(xc_interface *xch, uint32_t domid);
 int xc_psr_cmt_detach(xc_interface *xch, uint32_t domid);
 int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
-uint32_t *rmid);
+   uint32_t *rmid);
 int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t *total_rmid);
 int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
-uint32_t *upscaling_factor);
+   uint32_t *upscaling_factor);
 int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
-uint32_t *l3_cache_size);
-int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
-uint32_t cpu, uint32_t psr_cmt_type, uint64_t *monitor_data);
+ uint32_t *l3_cache_size);
+int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid, uint32_t cpu,
+uint32_t psr_cmt_type, uint64_t *monitor_data);
 int xc_psr_cmt_enabled(xc_interface *xch);
 #endif
 
diff --git a/tools/libxc/xc_psr.c b/tools/libxc/xc_psr.c
index 872e6dc..cfae172 100644
--- a/tools/libxc/xc_psr.c
+++ b/tools/libxc/xc_psr.c
@@ -47,7 +47,7 @@ int xc_psr_cmt_detach(xc_interface *xch, uint32_t domid)
 }
 
 int xc_psr_cmt_get_domain_rmid(xc_interface *xch, uint32_t domid,
-uint32_t *rmid)
+   uint32_t *rmid)
 {
 int rc;
 DECLARE_DOMCTL;
@@ -88,7 +88,7 @@ int xc_psr_cmt_get_total_rmid(xc_interface *xch, uint32_t 
*total_rmid)
 }
 
 int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
-uint32_t *upscaling_factor)
+   uint32_t *upscaling_factor)
 {
 static int val = 0;
 int rc;
@@ -113,7 +113,7 @@ int xc_psr_cmt_get_l3_upscaling_factor(xc_interface *xch,
 }
 
 int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, uint32_t cpu,
-  uint32_t *l3_cache_size)
+ uint32_t *l3_cache_size)
 {
 static int val = 0;
 int rc;
@@ -138,8 +138,8 @@ int xc_psr_cmt_get_l3_cache_size(xc_interface *xch, 
uint32_t cpu,
 return rc;
 }
 
-int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid,
-uint32_t cpu, xc_psr_cmt_type type, uint64_t *monitor_data)
+int xc_psr_cmt_get_data(xc_interface *xch, uint32_t rmid, uint32_t cpu,
+xc_psr_cmt_type type, uint64_t *monitor_data)
 {
 xc_resource_op_t op;
 xc_resource_entry_t entries[2];
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index c219f59..f784df5 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1476,10 +1476,13 @@ int libxl_psr_cmt_detach(libxl_ctx *ctx, uint32_t 
domid);
 int libxl_psr_cmt_domain_attached(libxl_ctx *ctx, uint32_t domid);
 int libxl_psr_cmt_enabled(libxl_ctx *ctx);
 int libxl_psr_cmt_get_total_rmid(libxl_ctx *ctx, uint32_t *total_rmid);
-int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx, uint32_t socketid,
-uint32_t *l3_cache_size);
-int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
-uint32_t socketid, uint32_t *l3_cache_occupancy);
+int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx,
+uint32_t socketid,
+uint32_t *l3_cache_size);
+int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx,
+  uint32_t domid,
+  uint32_t socketid,
+  uint32_t *l3_cache_occupancy);
 #endif
 
 /* misc */
diff --git a/tools/libxl/libxl_psr.c b/tools/libxl/libxl_psr.c
index 0437465..ec3b6e9 100644
--- a/tools/libxl/libxl_psr.c
+++ b/tools/libxl/libxl_psr.c
@@ -135,8 +135,9 @@ int libxl_psr_cmt_get_total_rmid(libxl_ctx *ctx, uint32_t 
*total_rmid)
 return rc;
 }
 
-int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx, uint32_t socketid,
- uint32_t *l3_cache_size)
+int libxl_psr_cmt_get_l3_cache_size(libxl_ctx *ctx,
+uint32_t socketid,
+uint32_t *l3_cache_size)
 {
 GC_INIT(ctx);
 
@@ -160,8 +161,10 @@ out:
 return rc;
 }
 
-int libxl_psr_cmt_get_cache_occupancy(libxl_ctx *ctx, uint32_t domid,
-uint32_t 

Re: [Xen-devel] [PATCH v6 3/5] xen/arm: Make gic-v2 code handle hip04-d01 platform

[Julien Grall]

On 26/02/15 14:45, Frediano Ziglio wrote:
>> I would prefer if we avoid to add more compatibles like that in gic.h.
>>
>> I have a patch to drop a part of this mess. I would advise your to use
>> cherry-pick the commit [1] in your branch.
>>
>> [1]
>> http://xenbits.xen.org/gitweb/?p=people/julieng/xen-
>> unstable.git;a=commit;h=7ba87910e557b06c589c3c0fbc6757fa664d029e
>>
>> Regards,
>>
>> --
>> Julien Grall

Please quote the correct part when you answer.

> Is this patch in staging?

Not yet. But we should avoid to introduce more mess in the headers.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] x86/Dom0: account for shadow/HAP allocation

[Jan Beulich]

>>> On 25.02.15 at 18:06,  wrote:
> On 25/02/15 14:45, Jan Beulich wrote:
>> +static unsigned long __init dom0_paging_pages(const struct domain *d,
>> +  unsigned long nr_pages)
>> +{
>> +/* Copied from: libxl_get_required_shadow_memory() */
>> +unsigned long memkb = nr_pages * (PAGE_SIZE / 1024);
>> +
>> +memkb = 4 * (256 * d->max_vcpus + 2 * (memkb / 1024));
> 
> I have recently raised a bug against Xapi for similar wrong logic when
> calculating the size of the shadow pool.
> 
> A per-vcpu reservation of shadow allocation is only needed if shadow
> paging is actually in use, and even then should match
> shadow_min_acceptable_pages() at 128 pages per vcpu.
> 
> If HAP is in use, the only allocations from the shadow pool are for the
> EPT/NPT tables (1% of nr_pages), IOMMU tables (another 1% of nr_pages if
> in use), and the logdirty radix tree (substantially less than than 1% of
> nr_pages).
> 
> One could argue that structure such as the vmcs/vmcb should have their
> allocations accounted against the domain, in which case a small per-vcpu
> component would be appropriate.
> 
> However as it currently stands, this calculation wastes 4MB of ram per
> vcpu in shadow allocation which is not going to be used.

But you realize that the functional change here explicitly only covers
the shadow case - the PVH (i.e. HAP) case is effectively unchanged
(merely correcting the mistake of not accounting for what gets
actually allocated), and I don't intend any functional change for PVH
(other than said bug fix) with this patch. Hence correcting this (i.e.
lowering the accounted for as well as the allocated amount) as well
as adding accounting for VMCS/VMCB (just like we account for
struct vcpu) should be the subject of a separate patch, presumably
by someone actively working on PVH (and then perhaps at once for
libxc). I also think that this calculation would better become a paging
variant specific hook if calculations differ between shadow and HAP.

Jan


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

Re: [Xen-devel] Can Xen Project Hypervisor work in Xenserver?

[Andrew Cooper]

On 26/02/15 15:06, D'Mita Levy wrote:
> Hello,
>
> Assuming one builds the Xen hypervisor avaialable from the
> http://www.xenproject.org/ respository and then uses it to replace the
> hypervisor in the Citrix Xenserver /boot directory - will this work.
> Rather, is it possible to build and mondify the xenproject hypervisor
> and use it to replace the Citrix Xenserver or would one have to get
> the code for Xenserver and compile that instead?

A plain Xenproject hypervisor will not work under XenServer.

However, XenServer is open source and available from
https://github.com/xenserver/

You will find that the hypervisor and tools in use is not too different
from upstream Xen.

~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 4/4] xen: credit2: add a few performance counters

[Jan Beulich]

>>> On 26.02.15 at 14:37,  wrote:
> @@ -51,6 +51,19 @@ PERFCOUNTER(migrate_running,"csched: 
> migrate_running")
>  PERFCOUNTER(migrate_kicked_away,"csched: migrate_kicked_away")
>  PERFCOUNTER(vcpu_hot,   "csched: vcpu_hot")
>  
> +/* credit2 specific counters */
> +PERFCOUNTER(burn_credits_t2c,   "csched2: burn_credits_t2c")
> +PERFCOUNTER(upd_max_weight_quick,   "cshced2: update_max_weight_quick")
> +PERFCOUNTER(upd_max_weight_full,"cshced2: update_max_weight_full")
> +PERFCOUNTER(migrate_requested,  "cshced2: migrate_requested")
> +PERFCOUNTER(migrate_on_runq,"cshced2: migrate_on_runq")
> +PERFCOUNTER(migrate_no_runq,"cshced2: migrate_no_runq")

Repeated typos.

Jan


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

[Xen-devel] Can Xen Project Hypervisor work in Xenserver?

[D'Mita Levy]

Hello,

Assuming one builds the Xen hypervisor avaialable from the
http://www.xenproject.org/ respository and then uses it to replace the
hypervisor in the Citrix Xenserver /boot directory - will this work.
Rather, is it possible to build and mondify the xenproject hypervisor and
use it to replace the Citrix Xenserver or would one have to get the code
for Xenserver and compile that instead?

Thanks,
D'Mita

-- 
D'Mita Levy
Cyber Fellow, Applied Research Center
Florida International University
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v6 1/5] xen/arm: Duplicate gic-v2.c file to support hip04 platform version

[Julien Grall]

On 26/02/15 14:31, Frediano Ziglio wrote:
>>
>> Hi Frediano,
>>
>> On 26/02/15 12:40, Frediano Ziglio wrote:
>>> HiSilison Hip04 platform use a slightly different version.
>>> This is just a verbatim copy of the file to workaround git not fully
>>> supporting copy operation.
>>
>> This is an old verbatim copy. You miss at least one change in the
>> copied
>> GICv2 driver.
>>
>> Regards,
>>
>> --
>> Julien Grall
> 
> I think you are referring to changes in staging, right ?

Yes. If you already start to diverge from staging that's not good.

We may have some patches reaching upstream before this series. You have
to keep up-date every-time you send a new version.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH 3/4] xen: sched: make counters for vCPU tickling generic

[Jan Beulich]

>>> On 26.02.15 at 14:37,  wrote:
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -571,9 +571,11 @@ tickle:
>(unsigned char *)&d);
>  }
>  cpumask_set_cpu(ipid, &rqd->tickled);
> +SCHED_STAT_CRANK(tickle_idlers_some);
>  cpu_raise_softirq(ipid, SCHEDULE_SOFTIRQ);
>  
>  no_tickle:
> +SCHED_STAT_CRANK(tickle_idlers_none);
>  return;
>  }

Isn't there a return statement missing ahead of "no_tickle:" now?

Jan


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

Re: [Xen-devel] [RFC] When to use "domain creation flag" or "HVM param"?

[Julien Grall]

Hi,

On 26/02/15 11:09, Lars Kurth wrote:
> Tim, Andrew, Jan,
> it seems as if we are slowly coming to some conclusion on this thread. If
> I am mistaken, I am wondering whether it would make sense to have an IRC
> meeting with all the involved stake-holders and report back to the list.

I'm not sure where I should answer...

We have a similar problem on ARM where we have arch-specific information
(GIC version, number of interrupts) which changes between each domain.

On Xen 4.5, we took the approach to create a separate DOMCTL for passing
information. It has to be called before any VCPUs is created
(DOMCTL_set_max_vcpus) and make the code more complicate to handle
because we have to defer some domain initialization.

I took another approach for Xen 4.6 based on Jan suggestion [1]. A v3 as
been send recently [2] and we had some discussion about what is the best
approach.

I hope this will help to sort out a good approach for both ARM and x86.

Regards,

[1] http://lists.xen.org/archives/html/xen-devel/2014-11/msg00522.html
[2] http://lists.xen.org/archives/html/xen-devel/2015-01/msg01184.html

-- 
Julien Grall

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

Re: [Xen-devel] RFC: [PATCH 1/3] Enhance platform support for PCI

[Julien Grall]

On 26/02/15 14:46, Pranavkumar Sawargaonkar wrote:
> Hi

Hi Pranavkumar,

> Also if we just show only one vITS (or only one Virtual v2m frame)
> instead of two vITS
> then actual hardware interrupt number and virtual interrupt number
> which guest will see will become different
> This will hamper direct irq routing to guest.

The IRQ injection should not consider a 1:1 mapping between pIRQ and vIRQ.

I have a patch which allow virq != pirq:

https://patches.linaro.org/43012/

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH v4 07/30] PCI: Pass PCI domain number combined with root bus number

[Yijing Wang]

Now we could pass PCI domain combined with bus number
in u32 argu. Because in arm/arm64, PCI domain number
is assigned by pci_bus_assign_domain_nr(). So we leave
pci_scan_root_bus() and pci_create_root_bus() in arm/arm64
unchanged. A new function pci_host_assign_domain_nr()
will be introduced for arm/arm64 to assign domain number
in later patch.

Signed-off-by: Yijing Wang 
CC: Richard Henderson 
CC: Ivan Kokshaysky 
CC: Matt Turner 
CC: Tony Luck 
CC: Fenghua Yu 
CC: Michal Simek 
CC: Ralf Baechle 
CC: Benjamin Herrenschmidt 
CC: Paul Mackerras 
CC: Michael Ellerman 
CC: Sebastian Ott 
CC: Gerald Schaefer 
CC: "David S. Miller" 
CC: Chris Metcalf 
CC: Thomas Gleixner 
CC: Konrad Rzeszutek Wilk 
CC: linux-al...@vger.kernel.org
CC: linux-ker...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-m...@linux-mips.org
CC: linuxppc-...@lists.ozlabs.org
CC: linux-s...@vger.kernel.org
CC: linux...@vger.kernel.org
CC: sparcli...@vger.kernel.org
CC: xen-de...@lists.xenproject.org
---
 arch/alpha/kernel/pci.c  |5 +++--
 arch/alpha/kernel/sys_nautilus.c |3 ++-
 arch/ia64/pci/pci.c  |4 ++--
 arch/ia64/sn/kernel/io_init.c|5 +++--
 arch/microblaze/pci/pci-common.c |5 +++--
 arch/mips/pci/pci.c  |4 ++--
 arch/powerpc/kernel/pci-common.c |5 +++--
 arch/s390/pci/pci.c  |5 +++--
 arch/sh/drivers/pci/pci.c|5 +++--
 arch/sparc/kernel/pci.c  |5 +++--
 arch/tile/kernel/pci.c   |4 ++--
 arch/tile/kernel/pci_gx.c|5 +++--
 arch/x86/pci/acpi.c  |6 +++---
 arch/x86/pci/common.c|3 ++-
 drivers/pci/xen-pcifront.c   |5 +++--
 15 files changed, 40 insertions(+), 29 deletions(-)

diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
index 518b767..b053888 100644
--- a/arch/alpha/kernel/pci.c
+++ b/arch/alpha/kernel/pci.c
@@ -336,8 +336,9 @@ common_init_pci(void)
pci_add_resource_offset(&resources, hose->mem_space,
hose->mem_space->start);
 
-   bus = pci_scan_root_bus(NULL, next_busno, alpha_mv.pci_ops,
-   hose, &resources);
+   bus = pci_scan_root_bus(NULL, 
+   PCI_DOMBUS(hose->index, next_busno), 
alpha_mv.pci_ops,
+   hose, &resources);
if (bus)
pci_bus_add_devices(bus);
hose->bus = bus;
diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index 2c864bb..f7bfdf3 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -206,7 +206,8 @@ nautilus_init_pci(void)
unsigned long memtop = max_low_pfn << PAGE_SHIFT;
 
/* Scan our single hose.  */
-   bus = pci_scan_bus_legacy(0, alpha_mv.pci_ops, hose);
+   bus = pci_scan_bus_legacy(PCI_DOMBUS(hose->index, 0), 
+   alpha_mv.pci_ops, hose);
hose->bus = bus;
pcibios_claim_one_bus(bus);
 
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 48cc657..e4cda61 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -465,8 +465,8 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root 
*root)
 * should handle the case here, but it appears that IA64 hasn't
 * such quirk. So we just ignore the case now.
 */
-   pbus = pci_create_root_bus(NULL, bus, &pci_root_ops, controller,
-  &info->resources);
+   pbus = pci_create_root_bus(NULL, PCI_DOMBUS(domain, bus), 
+   &pci_root_ops, controller, &info->resources);
if (!pbus) {
pci_free_resource_list(&info->resources);
__release_pci_root_info(info);
diff --git a/arch/ia64/sn/kernel/io_init.c b/arch/ia64/sn/kernel/io_init.c
index 63b43a6..bcdc5b8 100644
--- a/arch/ia64/sn/kernel/io_init.c
+++ b/arch/ia64/sn/kernel/io_init.c
@@ -266,8 +266,9 @@ sn_pci_controller_fixup(int segment, int busnum, struct 
pci_bus *bus)
pci_add_resource_offset(&resources, &res[1],
prom_bussoft_ptr->bs_legacy_mem);
 
-   bus = pci_scan_root_bus(NULL, busnum, &pci_root_ops, controller,
-   &resources);
+   bus = pci_scan_root_bus(NULL, 
+   PCI_DOMBUS(controller->segment, busnum), 
+   &pci_root_ops, controller, &resources);
if (bus == NULL) {
kfree(res);
kfree(controller);
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index d8bbad9..5c332c0 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -1350,8 +1350,9 @@ static void pcibios_scan_phb(struct pci_controller *hose)
 
pcibios_setup_phb_resources(hose, &resources);
 
-   bus = pci_scan_root_bus(hose->parent, hose->first_busno,
-  

Re: [Xen-devel] freemem-slack and large memory environments

[Mike Latimer]

On Wednesday, February 25, 2015 02:09:50 PM Stefano Stabellini wrote:
> > Is the upshot that Mike doesn't need to do anything further with his
> > patch (i.e. can drop it)? I think so?
> 
> Yes, I think so. Maybe he could help out testing the patches I am going
> to write :-)

Sorry for not responding to this yesterday.

There is still one aspect of my original patch that is important. As the code 
currently stands, the target for dom0 is set lower during each iteration of 
the loop. Unless only one iteration is required, dom0 will end up being set to 
a much lower target than is actually required.

There are two ways to fix this issue:

 - Set the memory target for dom0 once, before entering the loop
 - During each iteration of the loop, compare the amount of needed memory to 
the amount of memory which will be available once dom0 hits the target, and 
only lower the target if additional memory is needed.

My patch earlier in this thread does the former, but I think the second option 
is also possible. Is there a preference between those approaches (or a better 
idea)?

Thanks,
Mike

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

[Xen-devel] [PATCH 0/5] Build libxc on rump kernels

[Wei Liu]

This is a series done by Ian Jackson. I only changed a few macros and rewrote
some commit logs.

With this series we can build libxc with rump kernels.

Wei.

Ian Jackson (5):
  NetBSDRump: provide evtchn.h
  libxc: Split off xc_minios_privcmd.c
  libxc: Split off xc_netbsd_user.c
  libxc: minios: Introduce abstraction for files[]
  libxc: rumpxen: Provide xc_osdep_info

 tools/include/xen-sys/NetBSDRump/evtchn.h |  86 
 tools/libxc/Makefile  |   6 +-
 tools/libxc/xc_minios.c   | 243 +-
 tools/libxc/xc_minios_privcmd.c   | 322 ++
 tools/libxc/xc_netbsd.c   | 168 +---
 tools/libxc/xc_netbsd_rumpkern.c  |  62 ++
 tools/libxc/xc_netbsd_user.c  | 196 ++
 tools/libxc/xc_private.h  |   3 +
 8 files changed, 678 insertions(+), 408 deletions(-)
 create mode 100644 tools/include/xen-sys/NetBSDRump/evtchn.h
 create mode 100644 tools/libxc/xc_minios_privcmd.c
 create mode 100644 tools/libxc/xc_netbsd_rumpkern.c
 create mode 100644 tools/libxc/xc_netbsd_user.c

-- 
1.9.1


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

Re: [Xen-devel] [PATCH] RFC: Make xen's public headers a little friendlier for C++.

[Jan Beulich]

>>> On 26.02.15 at 16:22,  wrote:
> At 14:09 + on 26 Feb (1424956161), Jan Beulich wrote:
>> >>> On 26.02.15 at 14:11,  wrote:
>> > +headers++.chk: $(PUBLIC_HEADERS_TO_CHECK) Makefile
>> 
>> ... I don't think limiting this to a subset of the headers is the right
>> thing here: C++ consumers are (most likely) going to be user space,
>> i.e. tools, and those would want to be able to use those excluded
>> headers.
> 
> OK.  I'll have a look through that list.  I presume I'll still want to
> exclude e.g. the arch/ headers on the grounds that users shouldn't
> be including them directly (and we won't want cross-arch includes)?

Aren't even our tools doing cross-arch includes. I've been trying to
remember why they're excluded from the C check, but can't.

> If I'm extending this to cover more headers than the ANSI-C check
> does, should I also relax the '-ansi' requirement to, e.g. '-std=gnu++98'?

I think that would be reasonable nowadays. Anyone wanting
compatibility farther back could contribute a patch...

>> and I don't see
>> how this step is being avoided when there's no C++ compiler there.
> 
> if g++ isn't on the path, 'g++ -v' fails and we end up with an empty
> headers++.chk file.

The line is so long that I overlooked that "if g++ -v" at the
beginning (having expected some different mechanism, like
suppressing the dependency in that case). Sorry for the noise.

Jan


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

Re: [Xen-devel] [PATCH v3 1/3] x86/numa: Allow arbitrary value of PXM in PXM<->node mapping

[Jan Beulich]

>>> On 26.02.15 at 00:41,  wrote:
> * Made changes to K&R style (which is what this file uses)

I don't find anything K&R style here, and I think the compiler would
have prevented you from doing any such (by way for issuing
warnings and us using -Werror). I'm sure you mean Linux instead.

> @@ -111,8 +154,8 @@ static __init void bad_srat(void)
>   acpi_numa = -1;
>   for (i = 0; i < MAX_LOCAL_APIC; i++)
>   apicid_to_node[i] = NUMA_NO_NODE;
> - for (i = 0; i < ARRAY_SIZE(pxm2node); i++)
> - pxm2node[i] = NUMA_NO_NODE;
> + for (i = 0; i < MAX_NUMNODES; i++)
> + pxm2node[i].node = NUMA_NO_NODE;

It escapes me why the ARRAY_SIZE() use needed replacing. I'm
going to undo that before committing, and in fact will adjust other
similar bounds checks to use it too.

Jan


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

[Xen-devel] [PATCH v3] RFC: Automatically check xen's public headers for C++ pitfalls.

[Tim Deegan]

Add a check, like the existing check for non-ANSI C in the public
headers, that runs the public headers through a C++ compiler to
flag non-C++-friendly constructs.

Unlike the ANSI C check, we accept GCC-isms (gnu++98), and we also
check various tools-only headers.

Explicitly _not_ addressing the use of 'private' in various fields,
since we'd previously decided not to fix that.

Also tidy up the runes for these checks to be a bit more readable.

Reported-by: Razvan Cojocaru 
Signed-off-by: Tim Deegan 
Cc: Jan Beulich 

---

v3: rebase on staging.

v2: test more headers;
define __XEN_TOOLS__;
use g++98 rather than ansi;
tidy the makefile for readability;
add a missing include to flask_op.h, which uses evtchn_port_t.
---
 .gitignore|  1 +
 config/StdGNU.mk  |  2 ++
 config/SunOS.mk   |  1 +
 xen/include/Makefile  | 28 
 xen/include/public/xsm/flask_op.h |  2 ++
 5 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/.gitignore b/.gitignore
index 13ee05b..78958ea 100644
--- a/.gitignore
+++ b/.gitignore
@@ -233,6 +233,7 @@ xen/arch/*/efi/compat.c
 xen/arch/*/efi/efi.h
 xen/arch/*/efi/runtime.c
 xen/include/headers.chk
+xen/include/headers++.chk
 xen/include/asm
 xen/include/asm-*/asm-offsets.h
 xen/include/compat/*
diff --git a/config/StdGNU.mk b/config/StdGNU.mk
index 4efebe3..e10ed39 100644
--- a/config/StdGNU.mk
+++ b/config/StdGNU.mk
@@ -2,9 +2,11 @@ AS = $(CROSS_COMPILE)as
 LD = $(CROSS_COMPILE)ld
 ifeq ($(clang),y)
 CC = $(CROSS_COMPILE)clang
+CXX= $(CROSS_COMPILE)clang++
 LD_LTO = $(CROSS_COMPILE)llvm-ld
 else
 CC = $(CROSS_COMPILE)gcc
+CXX= $(CROSS_COMPILE)g++
 LD_LTO = $(CROSS_COMPILE)ld
 endif
 CPP= $(CC) -E
diff --git a/config/SunOS.mk b/config/SunOS.mk
index 3316280..c2be37d 100644
--- a/config/SunOS.mk
+++ b/config/SunOS.mk
@@ -2,6 +2,7 @@ AS = $(CROSS_COMPILE)gas
 LD = $(CROSS_COMPILE)gld
 CC = $(CROSS_COMPILE)gcc
 CPP= $(CROSS_COMPILE)gcc -E
+CXX= $(CROSS_COMPILE)g++
 AR = $(CROSS_COMPILE)gar
 RANLIB = $(CROSS_COMPILE)granlib
 NM = $(CROSS_COMPILE)gnm
diff --git a/xen/include/Makefile b/xen/include/Makefile
index 94112d1..d48a642 100644
--- a/xen/include/Makefile
+++ b/xen/include/Makefile
@@ -87,13 +87,33 @@ compat/xlat.h: $(addprefix compat/.xlat/,$(xlat-y)) Makefile
 
 ifeq ($(XEN_TARGET_ARCH),$(XEN_COMPILE_ARCH))
 
-all: headers.chk
+all: headers.chk headers++.chk
 
-headers.chk: $(filter-out public/arch-% public/%ctl.h public/xsm/% 
public/%hvm/save.h, $(wildcard public/*.h public/*/*.h) $(public-y)) Makefile
-   for i in $(filter %.h,$^); do $(CC) -ansi -include stdint.h -Wall -W 
-Werror -S -o /dev/null -x c $$i || exit 1; echo $$i; done >$@.new
+PUBLIC_HEADERS := $(filter-out public/arch-% public/dom0_ops.h, $(wildcard 
public/*.h public/*/*.h) $(public-y))
+
+PUBLIC_ANSI_HEADERS := $(filter-out public/%ctl.h public/xsm/% 
public/%hvm/save.h, $(PUBLIC_HEADERS))
+
+headers.chk: $(PUBLIC_ANSI_HEADERS) Makefile
+   for i in $(filter %.h,$^); do \
+   $(CC) -x c -ansi -Wall -Werror -include stdint.h \
+ -S -o /dev/null $$i || exit 1; \
+   echo $$i; \
+   done >$@.new
+   mv $@.new $@
+
+headers++.chk: $(PUBLIC_HEADERS) Makefile
+   if $(CXX) -v >/dev/null 2>&1; then \
+   for i in $(filter %.h,$^); do \
+   $(CXX) -x c++ -std=gnu++98 -Wall -Werror \
+  -D__XEN_TOOLS__ -Dprivate=private_is_a_keyword_in_cpp \
+  -include stdint.h -include public/xen.h \
+  -S -o /dev/null $$i || exit 1; \
+   echo $$i; \
+   done ; \
+   fi >$@.new
mv $@.new $@
 
 endif
 
 clean::
-   rm -rf compat headers.chk
+   rm -rf compat headers.chk headers++.chk
diff --git a/xen/include/public/xsm/flask_op.h 
b/xen/include/public/xsm/flask_op.h
index 233de81..f874589 100644
--- a/xen/include/public/xsm/flask_op.h
+++ b/xen/include/public/xsm/flask_op.h
@@ -25,6 +25,8 @@
 #ifndef __FLASK_OP_H__
 #define __FLASK_OP_H__
 
+#include "../event_channel.h"
+
 #define XEN_FLASK_INTERFACE_VERSION 1
 
 struct xen_flask_load {
-- 
2.1.4


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