[Xen-devel] [PATCH v4 3/3] xen: add pvUSB backend

[Juergen Gross]

Add a backend for para-virtualized USB devices for xen domains.

The backend is using host-libusb to forward USB requests from a
domain via libusb to the real device(s) passed through.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
---
V3: multiple small changes as requested by Anthony Perard
check for full ring in case of hotplug events as requested by
Anthony Perard
use RING_COPY_REQUEST() instead of RING_GET_REQUEST()
add check for required header version and disable backend in
case header is too old

V2: use xen_be_printf() instead of fprintf() for diagnostic prints as
requested by Stefano Stabellini
lots of small changes requested by Konrad Wilk
removed isoc request support, will be in separate patch
---
 hw/usb/Makefile.objs |4 +
 hw/usb/xen-usb.c | 1080 ++
 hw/xenpv/xen_machine_pv.c|3 +
 include/hw/xen/xen_backend.h |3 +
 include/hw/xen/xen_common.h  |2 +
 5 files changed, 1092 insertions(+)
 create mode 100644 hw/usb/xen-usb.c

diff --git a/hw/usb/Makefile.objs b/hw/usb/Makefile.objs
index 2717027..98b5c9d 100644
--- a/hw/usb/Makefile.objs
+++ b/hw/usb/Makefile.objs
@@ -38,3 +38,7 @@ common-obj-$(CONFIG_USB_REDIR) += redirect.o quirks.o
 
 # usb pass-through
 common-obj-y += $(patsubst %,host-%.o,$(HOST_USB))
+
+ifeq ($(CONFIG_USB_LIBUSB),y)
+common-obj-$(CONFIG_XEN_BACKEND) += xen-usb.o
+endif
diff --git a/hw/usb/xen-usb.c b/hw/usb/xen-usb.c
new file mode 100644
index 000..664df04
--- /dev/null
+++ b/hw/usb/xen-usb.c
@@ -0,0 +1,1080 @@
+/*
+ *  xen paravirt usb device backend
+ *
+ *  (c) Juergen Gross 
+ *
+ *  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; under version 2 of the License.
+ *
+ *  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 .
+ *
+ *  Contributions after 2012-01-13 are licensed under the terms of the
+ *  GNU GPL, version 2 or (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "qemu/config-file.h"
+#include "hw/sysbus.h"
+#include "hw/usb.h"
+#include "hw/xen/xen_backend.h"
+#include "monitor/qdev.h"
+#include "qapi/qmp/qbool.h"
+#include "qapi/qmp/qint.h"
+#include "qapi/qmp/qstring.h"
+#include "sys/user.h"
+
+#include 
+#include 
+
+/*
+ * Check for required support of usbif.h: USBIF_SHORT_NOT_OK was the last
+ * macro added we rely on.
+ */
+#ifdef USBIF_SHORT_NOT_OK
+
+#define TR(xendev, lvl, fmt, args...)   \
+{   \
+struct timeval tv;  \
+\
+gettimeofday(, NULL);\
+xen_be_printf(xendev, lvl, "%8ld.%06ld xen-usb(%s):" fmt,   \
+  tv.tv_sec, tv.tv_usec, __func__, ##args); \
+}
+#define TR_BUS(xendev, fmt, args...) TR(xendev, 2, fmt, ##args)
+#define TR_REQ(xendev, fmt, args...) TR(xendev, 3, fmt, ##args)
+
+#define USBBACK_MAXPORTSUSBIF_PIPE_PORT_MASK
+#define USB_DEV_ADDR_SIZE   (USBIF_PIPE_DEV_MASK + 1)
+
+/* USB wire protocol: structure describing control request parameter. */
+struct usbif_ctrlrequest {
+uint8_tbRequestType;
+uint8_tbRequest;
+uint16_t   wValue;
+uint16_t   wIndex;
+uint16_t   wLength;
+};
+
+struct usbback_info;
+struct usbback_req;
+
+struct usbback_stub {
+USBDevice *dev;
+USBPort   port;
+unsigned int  speed;
+bool  attached;
+QTAILQ_HEAD(submit_q_head, usbback_req) submit_q;
+};
+
+struct usbback_req {
+struct usbback_info  *usbif;
+struct usbback_stub  *stub;
+struct usbif_urb_request req;
+USBPacketpacket;
+
+unsigned int nr_buffer_segs; /* # of transfer_buffer segments 
*/
+unsigned int nr_extra_segs;  /* # of iso_frame_desc segments  
*/
+
+QTAILQ_ENTRY(usbback_req) q;
+
+void *buffer;
+void *isoc_buffer;
+struct libusb_transfer   *xfer;
+};
+
+struct usbback_hotplug {
+QSIMPLEQ_ENTRY(usbback_hotplug) q;
+unsigned port;
+};
+
+struct usbback_info {
+struct XenDevice xendev;  /* must be first */
+USBBus   bus;
+void 

[Xen-devel] [PATCH v4 1/3] xen: introduce dummy system device

[Juergen Gross]

Introduce a new dummy system device serving as parent for virtual
buses. This will enable new pv backends to introduce virtual buses
which are removable again opposed to system buses which are meant
to stay once added.

Signed-off-by: Juergen Gross 
Acked-by: Anthony PERARD 
---
V2: NOT changed, even if requested by Stefano Stabellini: the xen dummy
system device is needed by virtfs for Xen PV(H) guests, too
---
 hw/xenpv/xen_machine_pv.c| 40 
 include/hw/xen/xen_backend.h |  1 +
 2 files changed, 41 insertions(+)

diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index fc13535..48d5bc6 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -25,10 +25,15 @@
 #include "qemu/osdep.h"
 #include "hw/hw.h"
 #include "hw/boards.h"
+#include "hw/sysbus.h"
 #include "hw/xen/xen_backend.h"
 #include "xen_domainbuild.h"
 #include "sysemu/block-backend.h"
 
+#define TYPE_XENSYSDEV "xensysdev"
+
+DeviceState *xen_sysdev;
+
 static void xen_init_pv(MachineState *machine)
 {
 DriveInfo *dinfo;
@@ -67,6 +72,9 @@ static void xen_init_pv(MachineState *machine)
 break;
 }
 
+xen_sysdev = qdev_create(NULL, TYPE_XENSYSDEV);
+qdev_init_nofail(xen_sysdev);
+
 xen_be_register("console", _console_ops);
 xen_be_register("vkbd", _kbdmouse_ops);
 xen_be_register("vfb", _framebuffer_ops);
@@ -101,6 +109,38 @@ static void xen_init_pv(MachineState *machine)
 xen_init_display(xen_domid);
 }
 
+static int xen_sysdev_init(SysBusDevice *dev)
+{
+return 0;
+}
+
+static Property xen_sysdev_properties[] = {
+{/* end of property list */},
+};
+
+static void xen_sysdev_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
+
+k->init = xen_sysdev_init;
+dc->props = xen_sysdev_properties;
+}
+
+static const TypeInfo xensysdev_info = {
+.name  = TYPE_XENSYSDEV,
+.parent= TYPE_SYS_BUS_DEVICE,
+.instance_size = sizeof(SysBusDevice),
+.class_init= xen_sysdev_class_init,
+};
+
+static void xenpv_register_types(void)
+{
+type_register_static(_info);
+}
+
+type_init(xenpv_register_types);
+
 static void xenpv_machine_init(MachineClass *mc)
 {
 mc->desc = "Xen Para-virtualized PC";
diff --git a/include/hw/xen/xen_backend.h b/include/hw/xen/xen_backend.h
index c839eeb..b4b4ff0 100644
--- a/include/hw/xen/xen_backend.h
+++ b/include/hw/xen/xen_backend.h
@@ -60,6 +60,7 @@ extern xc_interface *xen_xc;
 extern xenforeignmemory_handle *xen_fmem;
 extern struct xs_handle *xenstore;
 extern const char *xen_protocol;
+extern DeviceState *xen_sysdev;
 
 /* xenstore helper functions */
 int xenstore_write_str(const char *base, const char *node, const char *val);
-- 
2.6.6


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

[Xen-devel] [PATCH v4 0/3] usb, xen: add pvUSB backend

[Juergen Gross]

This series adds a Xen pvUSB backend driver to qemu. USB devices
connected to the host can be passed through to a Xen guest. The
devices are specified via Xenstore. Access to the devices is done
via host-libusb.c

I've tested the backend with various USB devices (memory sticks,
keyboard, ...).

Changes in V4:
- patch 2: don't allow guest reading the new directory as requested by
  Anthony Perard

Changes in V3:
- added new patch 2 (was sent formerly on it's own)
- patch 3 (was 2): multiple small changes as requested by Anthony Perard
- patch 3 (was 2): check for full ring in case of hotplug events as
  requested by Anthony Perard
- patch 3 (was 2): use RING_COPY_REQUEST() instead of RING_GET_REQUEST()
- patch 3 (was 2): add check for required header version and disable
  backend in case header is too old

Changes in V2:
- rebased to current qemu master
- removed support for isoc requests in this series, as the optimal way to
  support those isn't clear yet. Will be added in a followup series.
- several changes as requested by Stefano Stabellini and Konrad Wilk

Changes since RFC:
- open device via qdev_device_add(), making patch 1 obsolete
- modify patch 2 to use isoc passthrough via libusb instead of one
  job per frame

Juergen Gross (3):
  xen: introduce dummy system device
  xen: write information about supported backends
  xen: add pvUSB backend

 hw/usb/Makefile.objs |4 +
 hw/usb/xen-usb.c | 1080 ++
 hw/xen/xen_backend.c |   60 +++
 hw/xen/xen_devconfig.c   |   52 +-
 hw/xenpv/xen_machine_pv.c|   43 ++
 include/hw/xen/xen_backend.h |6 +
 include/hw/xen/xen_common.h  |2 +
 7 files changed, 1197 insertions(+), 50 deletions(-)
 create mode 100644 hw/usb/xen-usb.c

-- 
2.6.6


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

[Xen-devel] [PATCH v4 2/3] xen: write information about supported backends

[Juergen Gross]

Add a Xenstore directory for each supported pv backend. This will allow
Xen tools to decide which backend type to use in case there are
multiple possibilities.

The information is added under
/local/domain//device-model//backends
before the "running" state is written to Xenstore. Using a directory
for each backend enables us to add parameters for specific backends
in the future.

This interface is documented in the Xen source repository in the file
docs/misc/qemu-backends.txt

In order to reuse the Xenstore directory creation already present in
hw/xen/xen_devconfig.c move the related functions to
hw/xen/xen_backend.c where they fit better.

Signed-off-by: Juergen Gross 
---
V4: don't allow guest reading the new directory as requested by
Anthony Perard

V3: Added .backend_register function to XenDevOps in order to have a
way to let the backend decide whether all prerequisites are met
for support.

V2: update commit message as requested by Stefano
---
 hw/xen/xen_backend.c | 60 
 hw/xen/xen_devconfig.c   | 52 ++
 include/hw/xen/xen_backend.h |  2 ++
 3 files changed, 64 insertions(+), 50 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 60575ad..4608f55 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -42,11 +42,35 @@ struct xs_handle *xenstore = NULL;
 const char *xen_protocol;
 
 /* private */
+struct xs_dirs {
+char *xs_dir;
+QTAILQ_ENTRY(xs_dirs) list;
+};
+static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup = 
QTAILQ_HEAD_INITIALIZER(xs_cleanup);
+
 static QTAILQ_HEAD(XenDeviceHead, XenDevice) xendevs = 
QTAILQ_HEAD_INITIALIZER(xendevs);
 static int debug = 0;
 
 /* - */
 
+static void xenstore_cleanup_dir(char *dir)
+{
+struct xs_dirs *d;
+
+d = g_malloc(sizeof(*d));
+d->xs_dir = dir;
+QTAILQ_INSERT_TAIL(_cleanup, d, list);
+}
+
+void xen_config_cleanup(void)
+{
+struct xs_dirs *d;
+
+QTAILQ_FOREACH(d, _cleanup, list) {
+xs_rm(xenstore, 0, d->xs_dir);
+}
+}
+
 int xenstore_write_str(const char *base, const char *node, const char *val)
 {
 char abspath[XEN_BUFSIZE];
@@ -75,6 +99,28 @@ char *xenstore_read_str(const char *base, const char *node)
 return ret;
 }
 
+int xenstore_mkdir(char *path, int p)
+{
+struct xs_permissions perms[2] = {{
+.id= 0, /* set owner: dom0 */
+},{
+.id= xen_domid,
+.perms = p,
+}};
+
+if (!xs_mkdir(xenstore, 0, path)) {
+xen_be_printf(NULL, 0, "xs_mkdir %s: failed\n", path);
+return -1;
+}
+xenstore_cleanup_dir(g_strdup(path));
+
+if (!xs_set_permissions(xenstore, 0, path, perms, 2)) {
+xen_be_printf(NULL, 0, "xs_set_permissions %s: failed\n", path);
+return -1;
+}
+return 0;
+}
+
 int xenstore_write_int(const char *base, const char *node, int ival)
 {
 char val[12];
@@ -726,6 +772,20 @@ err:
 
 int xen_be_register(const char *type, struct XenDevOps *ops)
 {
+char path[50];
+int rc;
+
+if (ops->backend_register) {
+rc = ops->backend_register();
+if (rc) {
+return rc;
+}
+}
+
+snprintf(path, sizeof (path), "device-model/%u/backends/%s", xen_domid,
+ type);
+xenstore_mkdir(path, XS_PERM_NONE);
+
 return xenstore_scan(type, xen_domid, ops);
 }
 
diff --git a/hw/xen/xen_devconfig.c b/hw/xen/xen_devconfig.c
index 1f30fe4..b7d290d 100644
--- a/hw/xen/xen_devconfig.c
+++ b/hw/xen/xen_devconfig.c
@@ -5,54 +5,6 @@
 
 /* - */
 
-struct xs_dirs {
-char *xs_dir;
-QTAILQ_ENTRY(xs_dirs) list;
-};
-static QTAILQ_HEAD(xs_dirs_head, xs_dirs) xs_cleanup = 
QTAILQ_HEAD_INITIALIZER(xs_cleanup);
-
-static void xen_config_cleanup_dir(char *dir)
-{
-struct xs_dirs *d;
-
-d = g_malloc(sizeof(*d));
-d->xs_dir = dir;
-QTAILQ_INSERT_TAIL(_cleanup, d, list);
-}
-
-void xen_config_cleanup(void)
-{
-struct xs_dirs *d;
-
-QTAILQ_FOREACH(d, _cleanup, list) {
-   xs_rm(xenstore, 0, d->xs_dir);
-}
-}
-
-/* - */
-
-static int xen_config_dev_mkdir(char *dev, int p)
-{
-struct xs_permissions perms[2] = {{
-.id= 0, /* set owner: dom0 */
-},{
-.id= xen_domid,
-.perms = p,
-}};
-
-if (!xs_mkdir(xenstore, 0, dev)) {
-   xen_be_printf(NULL, 0, "xs_mkdir %s: failed\n", dev);
-   return -1;
-}
-xen_config_cleanup_dir(g_strdup(dev));
-
-if (!xs_set_permissions(xenstore, 0, dev, perms, 2)) {
-   xen_be_printf(NULL, 0, "xs_set_permissions %s: failed\n", dev);
-   return -1;
-}
-return 0;
-}
-
 static int xen_config_dev_dirs(const char *ftype, const char *btype, int vdev,
  

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

[Juergen Gross]

Gentle ping...

On 03/03/16 10:38, Juergen Gross wrote:
> The Xen hypervisor supports starting a dom0 with large memory (up to
> the TB range) by not including the initrd and p2m list in the initial
> kernel mapping. Especially the p2m list can grow larger than the
> available virtual space in the initial mapping.
> 
> The started kernel is indicating the support of each feature via
> elf notes.
> 
> This series enables grub-xen to do the same as the hypervisor.
> 
> Tested with:
> - 32 bit domU (kernel not supporting unmapped initrd)
> - 32 bit domU (kernel supporting unmapped initrd)
> - 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
> - 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> - 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> 
> Changes in V7:
> - patch 9: set initrd size once instead of in if and else clause as requested
>   by Daniel Kiper
> - patch 10: add GRUB_PACKED attribute to structure, drop alignments in 
> assembly
>   files as requested by Daniel Kiper
> 
> Changes in V6:
> - patch 9: rename grub_xen_alloc_final() as requested by Daniel Kiper
> 
> Changes in V5:
> - patch 2: set grub_errno to GRUB_ERR_NONE to avoid false error reports as
>   requested by Daniel Kiper
> - patch 9: let call grub_xen_alloc_final() all subfunctions unconditionally
>   and let them decide whether they need to do anything as suggested by
>   Daniel Kiper
> 
> Changes in V4:
> - split patch 1 into two patches as requested by Daniel Kiper
> - patch 9 (was 8): rename grub_xen_alloc_end() as requested by Daniel Kiper
> - patch 10 (was 9): align variables in assembly sources,
>   use separate structure define as requested by Daniel Kiper
> 
> Changes in V3:
> - added new patch 1 (free memory in case of error) as requested by
>   Daniel Kiper
> - added new patch 2 (avoid global variables) as requested by Daniel Kiper
> - added new patch 3 (use constants for elf notes) as requested by Daniel Kiper
> - added new patch 4 (sync with new Xen headers) in order to use constants
>   in assembly code
> - modified patch 9 (was patch 5) to use constants instead of numbers as
>   requested by Daniel Kiper
> 
> Changes in V2:
> - rebased patch 5 to current master
> 
> Juergen Gross (11):
>   xen: make xen loader callable multiple times
>   xen: avoid memleaks on error
>   xen: reduce number of global variables in xen loader
>   xen: add elfnote.h to avoid using numbers instead of constants
>   xen: synchronize xen header
>   xen: factor out p2m list allocation into separate function
>   xen: factor out allocation of special pages into separate function
>   xen: factor out allocation of page tables into separate function
>   xen: add capability to load initrd outside of initial mapping
>   xen: modify page table construction
>   xen: add capability to load p2m list outside of kernel mapping
> 
>  grub-core/lib/i386/xen/relocator.S   |  87 ++--
>  grub-core/lib/x86_64/xen/relocator.S | 134 +++---
>  grub-core/lib/xen/relocator.c|  28 +-
>  grub-core/loader/i386/xen.c  | 778 
> +++
>  grub-core/loader/i386/xen_fileXX.c   |  45 +-
>  include/grub/i386/memory.h   |   7 +
>  include/grub/xen/relocator.h |   6 +-
>  include/grub/xen_file.h  |   3 +
>  include/xen/arch-x86/xen-x86_32.h|  22 +-
>  include/xen/arch-x86/xen-x86_64.h|   8 +-
>  include/xen/elfnote.h| 281 +
>  include/xen/xen.h| 125 --
>  12 files changed, 1076 insertions(+), 448 deletions(-)
>  create mode 100644 include/xen/elfnote.h
> 


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

Re: [Xen-devel] [PATCH v4 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

[Xu, Quan]

On May 11, 2016 5:07 PM, Jan Beulich  wrote:
> >>> On 11.05.16 at 10:35,  wrote:
> > On May 10, 2016 5:29 PM, Jan Beulich  wrote:
> >> >>> On 06.05.16 at 10:54,  wrote:
> >> > @@ -1430,7 +1430,12 @@ int domain_context_mapping_one(
> >> >  unmap_vtd_domain_page(context_entries);
> >> >
> >> >  if ( !seg )
> >> > -me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
> >> > +{
> >> > +ret = me_wifi_quirk(domain, bus, devfn,
> >> > + MAP_ME_PHANTOM_FUNC);
> >> > +
> >> > +if ( !rc )
> >> > +rc = ret;
> >> > +}
> >>
> >> Is there any use in calling this function if an earlier error occurred?
> >> If not,
> >
> > It is  no use.
> 
> With this I don't understand ...
> 
> > We may need to consider this call tree:
> >$
> > me_wifi_quirk()--domain_context_mapping_one()--
> domain_context_mapping(
> > )--reass
> > ign_device_ownership()--...
> >
> > Then, what about dropping this patch? Leave it as is,  or remove '
> > __must_check' annotation and propagate error up to the above call tree
> > only?
> 
> ... this. If calling the function is pointless if an earlier error occurred, 
> why don't
> you just check rc to be zero alongside the !seg check?
> 

---
Good idea.

---

Taken together, there are 3 call trees to me_wifi_quirk():

 1). 
...--me_wifi_quirk()--domain_context_mapping_one()--domain_context_mapping()--setup_hwdom_device()

There is no use in calling this function if an earlier 
error occurred. The change can be more lightweight (the detailed change is 
pending).

2).  me_wifi_quirk()--domain_context_unmap_one()--...

   As you mentioned,  while in the unmap case it should 
probably stay as is, to fit the "best effort" theme. 

  Then I need to remove the  __must_check annotation  of 
me_wifi_quirk().

3). 
me_wifi_quirk()--domain_context_mapping_one()--domain_context_mapping()--reassign_device_ownership()
This is not an earlier error, so we need propagate the 
error up to the call tree (the detailed change is pending).



The below is based on previous v4 p1...p9:
---

diff --git a/xen/drivers/passthrough/vtd/extern.h 
b/xen/drivers/passthrough/vtd/extern.h
index cbe0286..d4d37c3 100644
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -91,7 +91,7 @@ int is_igd_vt_enabled_quirk(void);
 void platform_quirks_init(void);
 void vtd_ops_preamble_quirk(struct iommu* iommu);
 void vtd_ops_postamble_quirk(struct iommu* iommu);
-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
+int me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
 void pci_vtd_quirk(const struct pci_dev *);
 bool_t platform_supports_intremap(void);
 bool_t platform_supports_x2apic(void);
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 29cf870..0ac7894 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1429,8 +1429,8 @@ int domain_context_mapping_one(

 unmap_vtd_domain_page(context_entries);

-if ( !seg )
-me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
+if ( !seg && !rc )
+rc = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);

 return rc;
 }
diff --git a/xen/drivers/passthrough/vtd/quirks.c 
b/xen/drivers/passthrough/vtd/quirks.c
index 473d1fc..3606b52 100644
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -331,10 +331,12 @@ void __init platform_quirks_init(void)
  * assigning Intel integrated wifi device to a guest.
  */

-static void map_me_phantom_function(struct domain *domain, u32 dev, int map)
+static int __must_check map_me_phantom_function(struct domain *domain,
+u32 dev, int map)
 {
 struct acpi_drhd_unit *drhd;
 struct pci_dev *pdev;
+int rc;

 /* find ME VT-d engine base on a real ME device */
 pdev = pci_get_pdev(0, 0, PCI_DEVFN(dev, 0));
@@ -342,23 +344,27 @@ static void map_me_phantom_function(struct domain 
*domain, u32 dev, int map)

 /* map or unmap ME phantom function */
 if ( map )
-domain_context_mapping_one(domain, drhd->iommu, 0,
-   PCI_DEVFN(dev, 7), NULL);
+rc = domain_context_mapping_one(domain, drhd->iommu, 0,
+PCI_DEVFN(dev, 7), NULL);
 else
-domain_context_unmap_one(domain, drhd->iommu, 0,
- PCI_DEVFN(dev, 7));
+rc = domain_context_unmap_one(domain, drhd->iommu, 0,
+  PCI_DEVFN(dev, 7));
+
+return rc;
 }

-void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
+int me_wifi_quirk(struct domain *domain,
+  u8 bus, u8 devfn, int map)
 {
 u32 id;
+int rc = 0;

 id = 

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Kevin Moraga]

Hi Boris,

On 05/10/2016 02:11 PM, Boris Ostrovsky wrote:
> On 05/10/2016 12:11 PM, Kevin Moraga wrote:
> Can you boot your system bare-metal and post output of 'biosdecode' command?
>
> -boris
Sure, it's attached.

-- 
Sincerely,
Kevin Moraga
PGP: F258EDCB
Fingerprint: 3915 A5A9 959C D18F 0A89 B47E FB4B 55F5 F258 EDCB

# biosdecode 2.12
SMBIOS 2.8 present.
Structure Table Length: 3297 bytes
Structure Table Address: 0xD7BDC000
Number Of Structures: 66
Maximum Structure Size: 287 bytes
ACPI 2.0 present.
OEM Identifier: LENOVO
RSD Table 32-bit Address: 0xD7FD10C4
XSD Table 64-bit Address: 0xD7FD1188
PNP BIOS 1.0 present.
Event Notification: Not Supported
Real Mode 16-bit Code Address: F000:0A6D
Real Mode 16-bit Data Address: F000:
16-bit Protected Mode Code Address: 0x000F0A48
16-bit Protected Mode Data Address: 0x000F
BIOS32 Service Directory present.
Revision: 0
Calling Interface Address: 0x000FD000
PCI Interrupt Routing 1.0 present.
Router ID: 00:1f.0
Exclusive IRQs: None
Compatible Router: 8086:9d48
Slot Entry 1: ID 00:02, on-board
Slot Entry 2: ID 00:14, on-board
Slot Entry 3: ID 00:16, on-board
Slot Entry 4: ID 00:17, on-board
Slot Entry 5: ID 00:1c, on-board
Slot Entry 6: ID 02:00, slot number 33
Slot Entry 7: ID 04:00, slot number 8
Slot Entry 8: ID 00:1f, on-board
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [linux-3.14 test] 94027: tolerable FAIL - PUSHED

[osstest service owner]

flight 94027 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94027/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 93503
 build-amd64-rumpuserxen   6 xen-buildfail   like 93503
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93503
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93503
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93503

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 linux1c767107ef341cdc080d44d3ee1c9ca1b6957ce0
baseline version:
 linux48763742b1bceb119b04656b8dd06e0617dfa89a

Last test of basis93503  2016-05-04 22:24:20 Z7 days
Testing same since94027  2016-05-11 09:44:33 Z0 days1 attempts


People who touched revisions under test:
  Andrew Morton 
  Andrey Gelman 
  Andy Lutomirski  # On a Dell XPS 13 9350
  Anton Blanchard 
  Antonio Quartulli 
  Arnd Bergmann 
  Behan Webster 
  Bob Moore 
  Chen Yu 
  Chunyu Hu 
  Dan Streetman 
  Dinh Nguyen 
  Dirk Behme 
  Dmitry Torokhov 
  Greg Kroah-Hartman 
  Gregor Boirie 
  Haibo Chen 
  Igor Grinberg 
  Ingo Molnar 
  Jan-Simon Möller 
  Jasem Mutlaq 
  Joe Perches 
  Johan Hovold 
  Jonathan Cameron 
  Julian Anastasov 
  Kevin Hilman 
  Knut Wohlrab 
  Krzysztof Kozlowski 
  Linus Lüssing 
  Linus Torvalds 
  Linus Walleij 
  Lv Zheng 
  Marco Angaroni 
  Marek Lindner 
  Markus Pargmann 
  Martin K. Petersen 
  Mathias Krause 
  Matt Fleming 
  Michael Ellerman 
  Mike Manning 
  Oleksij Rempel 
  Paolo Bonzini 
  Prarit Bhargava 
  Rafael J. Wysocki 
  Sascha Hauer 
  Sasha Levin 
  Simon Horman 
  Stephen Boyd 
  Steven Rostedt 
  Sven Eckelmann 
  Thomas Gleixner 
  Wang YanQing 

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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

On 2016/5/12 7:24, Matt Fleming wrote:
> On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote:
>>> > > 
>>> > > Also, why do you need to setup efi.runtime_version here? Isn't that
>>> > > done inside uefi_init()?
>>> > > 
>> > I don't see any codes which setup efi.runtime_version in uefi_init().
>  
> Look in the EFI tree,
> 
>   
> https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/tree/drivers/firmware/efi/arm-init.c?h=next#n120
> 
Ah, there are some patches in EFI tree introducing this change, but they
are not in kernel matser but I didn't notice this, sorry.

>>> > > Here is how I would have expected this patch to look:
>>> > > 
>>> > >   - Add FDT code to find hypervisor EFI params
>>> > > 
>>> > >   - Force enable EFI_RUNTIME_SERVICES for Xen and call
>>> > > xen_efi_runtime_setup() inside xen_guest_init()
>>> > > 
>>> > >   - Change arm_enable_runtime_services() to handle the case where
>>> > > EFI_RUNTIME_SERVICES is already set
>>> > > 
>>> > > Am I misunderstanding some ordering issues?
>> > 
>> > Since xen_guest_init() and arm_enable_runtime_services() are both
>> > early_initcall and the calling order is random I think.
> Urgh, right, I missed that.
> 
>> > And when we call xen_efi_runtime_setup() and setup
>> > efi.runtime_version in xen_guest_init(), the efi.systab might be
>> > NULL. So it needs to map the systanle explicitly before we use
>> > efi.systab.
> Could you explain why you need to copy efi.runtime_version instead of
> letting the existing code in uefi_init() set it up?
> 
> Also, efi.systab isn't used by xen_efi_runtime_setup() as far I can
> see, not sure why you need that either?
As said above, I will rebase this patch on top of the EFI next branch.

Thanks,
-- 
Shannon


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

[Xen-devel] [xen-unstable test] 94021: tolerable FAIL - PUSHED

[osstest service owner]

flight 94021 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94021/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 93920
 build-amd64-rumpuserxen   6 xen-buildfail   like 93920
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93920
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93920
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93920
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 93920
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93920

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-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47
baseline version:
 xen  4084fee7a3204bf8ccf7d993dea09186e4e7dd48

Last test of basis93920  2016-05-09 16:46:05 Z2 days
Failing since 93963  2016-05-10 08:02:04 Z1 days2 attempts
Testing same since94021  2016-05-11 07:32:40 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Ross Lagerwall 
  Tim Deegan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt   

[Xen-devel] [PATCH V2 2/2] xen/arm: mm: clean up code in setup_pagetables

[Peng Fan]

In setup_pagetables, need to map BOOT_RELOC_VIRT_START
in xen_second and boot_second, so we can merge the two
pieces code into one code block.

Also no need to use write_pte when map BOOT_RELOC_VIRT_START
in xen_second, because CPU0 is using boot page tables now.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

V2:
 Follow Julien's comments:
   split the V1 patch into two patches, this patch is the code movement part.

 xen/arch/arm/mm.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index addd699..0a4f845 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,11 +443,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 lpae_t pte, *p;
 int i;
 
-/* Map the destination in the boot misc area. */
-dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
-write_pte(xen_second + second_table_offset(dest_va), pte);
-
 /* Calculate virt-to-phys offset for the new location */
 phys_offset = xen_paddr - (unsigned long) _start;
 
@@ -494,9 +489,12 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 pte = boot_second[second_table_offset(BOOT_FDT_VIRT_START)];
 xen_second[second_table_offset(BOOT_FDT_VIRT_START)] = pte;
 
-/* Map the destination in the boot misc area. */
+/* ... Boot Misc area for xen relocation */
 dest_va = BOOT_RELOC_VIRT_START;
 pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
+/* Map the destination in xen_second. */
+xen_second[second_table_offset(dest_va)] = pte;
+/* Map the destination in boot_second. */
 write_pte(boot_second + second_table_offset(dest_va), pte);
 flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
 #ifdef CONFIG_ARM_64
-- 
2.6.2


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

[Xen-devel] [PATCH V2 1/2] xen/arm: mm: remove unnecessary tlb flush in setup_pagetables

[Peng Fan]

CPU0 is using the boot pages table before relocating xen and
xen_second is not part of them. So, no need to flush the TLB
when filling xen_second.

Signed-off-by: Peng Fan 
Cc: Stefano Stabellini 
Cc: Julien Grall 
---

V2:
 Following Julien's comments:
   split the V1 patch into two patches. This patch only remove tlb flush.
   refine commit log

 xen/arch/arm/mm.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..addd699 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -447,7 +447,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
 dest_va = BOOT_RELOC_VIRT_START;
 pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
 write_pte(xen_second + second_table_offset(dest_va), pte);
-flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
 
 /* Calculate virt-to-phys offset for the new location */
 phys_offset = xen_paddr - (unsigned long) _start;
-- 
2.6.2


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

[Xen-devel] [qemu-upstream-4.4-testing test] 94023: regressions - FAIL

[osstest service owner]

flight 94023 qemu-upstream-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94023/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pv  17 guest-localmigrate/x10fail REGR. vs. 83041

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-localmigrate fail in 93978 
pass in 94023
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 
93978
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 93978

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 93978 like 83041

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuua2fd7eba04d4c69e4ee18a43eb6cf32aaffb3c98
baseline version:
 qemuu16169ab825a03262cd66382dc0b02caa0dbd636a

Last test of basis83041  2016-02-18 17:58:50 Z   83 days
Testing same since93978  2016-05-10 11:10:44 Z1 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-xl-qemuu-win7-amd64 pass
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2  pass
 test-amd64-i386-freebsd10-i386   pass
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-amd64-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-xl-multivcpupass
 test-amd64-amd64-pairpass
 test-amd64-i386-pair pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-amd64-pv  fail
 test-amd64-i386-pv   pass
 test-amd64-amd64-amd64-pvgrubpass
 test-amd64-amd64-i386-pvgrub pass
 test-amd64-amd64-pygrub  pass
 test-amd64-amd64-xl-qcow2pass
 test-amd64-i386-xl-raw   pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-libvirt-vhd pass
 test-amd64-amd64-xl-qemuu-winxpsp3   fail



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master

Re: [Xen-devel] Running Xen on Nvidia Jetson-TK1

[Meng Xu]

Hi Dushyant,

On Tue, Mar 8, 2016 at 3:23 AM, Dushyant K Behl  wrote:
>
> Hi All,
>
> I'm working on a research project with IBM, and I want to run Xen on Nvidia 
> Tegra Jetson-tk1 board.
> I looked at a post on this mailing list 
> (http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01122.html),
> and I am using this git tree -
>
> git://xenbits.xen.org/people/ianc/xen.git
> and branch  - tegra-tk1-jetson-v1
>
> But when I try to boot Xen on the board I am not able to see any output (even 
> with earlyprintk enabled).
> After jumping to Xen the board just resets without showing any output.
>
> I am using upstream u-boot with non secure mode enabled.


I just got the Jetson TK1 board and I'm trying to run Xen on it.

May I know which u-boot repo and which branch you used to enable the
non-secure mode? If you could also share your u-boot config file, that
will be awesome!

The u-boot from NVIDEA didn't turn on the HYP mode. I tried the
git://git.denx.de/u-boot.git, tag v2016.03, but the board won't boot
after I flashed the uboot. No message at all... :-(
If I use NVIDEA's uboot, I can boot into the linux kernel without problem.

Thank you very much for your help and time!

Best Regards,

Meng

-- 
---
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH 1/3] libxl: switch to using libxl_domain_create_restore from v4.4 API

[Jim Fehlig]

On 05/11/2016 12:01 AM, Olaf Hering wrote:
> On Mon, May 02, Jim Fehlig wrote:
>
>> In LIBXL_API_VERSION 0x040400, the libxl_domain_create_restore API
>> gained a parameter for specifying restore parameters. Switch to
>> using version 0x040400, which will be useful in a subsequent commit
>> to specify the Xen migration stream version when restoring.
> This breaks compilation with xen-4.3 etc. Is this intentional?

Yes. Did you see my message elsewhere in the thread when I notified I was
pushing the series?

https://www.redhat.com/archives/libvir-list/2016-May/msg00686.html

Regards,
Jim


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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Matt Fleming]

On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote:
> > 
> > Also, why do you need to setup efi.runtime_version here? Isn't that
> > done inside uefi_init()?
> > 
> I don't see any codes which setup efi.runtime_version in uefi_init().
 
Look in the EFI tree,

  
https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/tree/drivers/firmware/efi/arm-init.c?h=next#n120

> > Here is how I would have expected this patch to look:
> > 
> >   - Add FDT code to find hypervisor EFI params
> > 
> >   - Force enable EFI_RUNTIME_SERVICES for Xen and call
> > xen_efi_runtime_setup() inside xen_guest_init()
> > 
> >   - Change arm_enable_runtime_services() to handle the case where
> > EFI_RUNTIME_SERVICES is already set
> > 
> > Am I misunderstanding some ordering issues?
> 
> Since xen_guest_init() and arm_enable_runtime_services() are both
> early_initcall and the calling order is random I think.

Urgh, right, I missed that.

> And when we call xen_efi_runtime_setup() and setup
> efi.runtime_version in xen_guest_init(), the efi.systab might be
> NULL. So it needs to map the systanle explicitly before we use
> efi.systab.

Could you explain why you need to copy efi.runtime_version instead of
letting the existing code in uefi_init() set it up?

Also, efi.systab isn't used by xen_efi_runtime_setup() as far I can
see, not sure why you need that either?

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

[Xen-devel] [ovmf test] 94010: regressions - FAIL

[osstest service owner]

flight 94010 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94010/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543

version targeted for testing:
 ovmf 2d063646b9f566f227db5df535cf72bec2f34649
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z  155 days
Failing since 65593  2015-12-08 23:44:51 Z  154 days  253 attempts
Testing same since94010  2016-05-10 23:23:36 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Wu, Hao A" 
  "Yao, Jiewen" 
  Abdul Lateef Attar 
  Alcantara, Paulo 
  Anbazhagan Baraneedharan 
  Andrew Fish 
  Ard Biesheuvel 
  Arthur Crippa Burigo 
  Cecil Sheng 
  Chao Zhang 
  Chao Zhang
  Charles Duffy 
  chenzhihui 
  Cinnamon Shia 
  Cohen, Eugene 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  David Woodhouse 
  Derek Lin 
  Dong, Eric 
  edk2 dev 
  edk2-devel 
  Eric Dong 
  Eric Dong 
  erictian
  Eugene Cohen 
  Evan Lloyd 
  Feng Tian 
  Fu Siyuan 
  Gabriel Somlo 
  Gary Ching-Pang Lin 
  Gary Lin 
  Ghazi Belaam 
  Hao Wu 
  Haojian Zhuang 
  Hegde Nagaraj P 
  Hegde, Nagaraj P 
  Hess Chen 
  Heyi Guo 
  Hot Tian 
  Jaben Carsey 
  James Bottomley 
  Jeff Fan 
  Jeremy Linton 
  Jiaxin Wu 
  jiewen yao 
  Jim Dailey 
  jim_dai...@dell.com 
  jljusten
  Jordan Justen 
  Juliano Ciocari 
  Justen, Jordan L 
  Karyne Mayer 
  Ken Lu 
  Kun Gui 
  Larry Hauch 
  Laszlo Ersek 
  Leahy, Leroy P
  Leahy, Leroy P 
  Lee Leahy 
  Leekha Shaveta 
  Leendert van Doorn 
  Leif Lindholm 
  Leif Lindholm 
  Leo Duran 
  Leon Li 
  Liming Gao 
  Linn Crosetto 
  lzeng14
  Mark 
  Mark Doran 
  Mark Rutland 
  Marvin H?user 
  Marvin Haeuser 
  Marvin Häuser 
  marvin.haeu...@outlook.com 
  Michael D Kinney 
  Michael Kinney 
  Michael LeMay 
  Michael Thomas 
  Michael Zimmermann 
  Michał Zegan 
  Nagaraj Hegde 
  Ni, Ruiyu 
  Ni, Ruiyu 
  niruiyu
  Olivier Martin 
  Paolo Bonzini 
  Paulo Alcantara 
  Paulo Alcantara Cavalcanti 
  Peter Kirmeier 
  Qin Long 
  Qing Huang 
  Qiu Shumin 
  Qiu, Shumin 
  Rodrigo Dias Correa 
  Ruiyu Ni 
  Ryan Harkin 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Sami Mujawar 
  Shivamurthy Shastri 
  Shumin Qiu 
  Star Zeng 
  Sunny Wang 
  Supreeth Venkatesh 
  Tapan Shah 
  Thomas Palmer 
  Tian Feng 

[Xen-devel] [xen-unstable-smoke test] 94043: tolerable all pass - PUSHED

[osstest service owner]

flight 94043 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94043/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c5ed88110cd1b72af643d7d9e255d587f2c90d3d
baseline version:
 xen  1c7fa3dc039487d18ad0c6fb6b773c831dca5e5d

Last test of basis94032  2016-05-11 15:02:17 Z0 days
Testing same since94043  2016-05-11 19:03:49 Z0 days1 attempts


People who touched revisions under test:
  Konrad Rzeszutek Wilk 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=c5ed88110cd1b72af643d7d9e255d587f2c90d3d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
c5ed88110cd1b72af643d7d9e255d587f2c90d3d
+ branch=xen-unstable-smoke
+ revision=c5ed88110cd1b72af643d7d9e255d587f2c90d3d
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xc5ed88110cd1b72af643d7d9e255d587f2c90d3d = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

[Xen-devel] [ovmf bisection] complete test-amd64-i386-xl-qemuu-ovmf-amd64

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-ovmf-amd64
testid debian-hvm-install

Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  ovmf https://github.com/tianocore/edk2.git
  Bug introduced:  7b0a1ead7d2efa7f9eae4c2b254ff154d9c5f74f
  Bug not present: e90f51a822c319b0e36bf55e260684239da325b4
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/85860/


  commit 7b0a1ead7d2efa7f9eae4c2b254ff154d9c5f74f
  Author: Ruiyu Ni 
  Date:   Wed Feb 17 18:06:36 2016 +0800
  
  MdeModuelPkg/PciBus: Return AddrTranslationOffset in GetBarAttributes
  
  Some platform doesn't use CPU(HOST)/Device 1:1 mapping for PCI Bus.
  But PCI IO doesn't have interface to tell caller (device driver)
  whether the address returned by GetBarAttributes() is HOST address
  or device address.
  UEFI Spec 2.6 addresses this issue by clarifying the address returned
  is HOST address and caller can use AddrTranslationOffset to calculate
  the device address.
  
  Contributed-under: TianoCore Contribution Agreement 1.0
  Signed-off-by: Ruiyu Ni 
  Reviewed-by: Feng Tian 
  Reviewed-by: Laszlo Ersek 


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/ovmf/test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/ovmf/test-amd64-i386-xl-qemuu-ovmf-amd64.debian-hvm-install
 --summary-out=tmp/94040.bisection-summary --basis-template=65543 
--blessings=real,real-bisect ovmf test-amd64-i386-xl-qemuu-ovmf-amd64 
debian-hvm-install
Searching for failure / basis pass:
 93944 fail [host=rimava1] / 84435 ok.
Failure / basis pass flights: 93944 / 84435
(tree with no url: minios)
(tree with no url: seabios)
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 48763742b1bceb119b04656b8dd06e0617dfa89a 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
259d87146b07c5d95f301dfffca6f00b32d2c74b 
21f6526d1da331611ac5fe12967549d1a04e149b 
ae69b059498e8a563c6d64c4aa4cb95e53d76680 
f8c66c2ad2efdb281e4ebf15bf329d73c4f02ce7
Basis pass 0b2737d1affeecfcf2f5ceeadeecfcbecba21e35 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d2ba6f41e2f8cbc8dffee8bddaebbbd6f3a3b9ab 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
abf8824fe530bcf060c757596f68663c87546a6a
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/linux-pvops.git#0b2737d1affeecfcf2f5ceeadeecfcbecba21e35-48763742b1bceb119b04656b8dd06e0617dfa89a
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
https://github.com/tianocore/edk2.git#d2ba6f41e2f8cbc8dffee8bddaebbbd6f3a3b9ab-259d87146b07c5d95f301dfffca6f00b32d2c74b
 
git://xenbits.xen.org/qemu-xen-traditional.git#21f6526d1da331611ac5fe12967549d1a04e149b-21f6526d1da331611ac5fe12967549d1a04e149b
 
git://xenbits.xen.org/qemu-xen.git#316a862e5534249a6e6d876b4e203342d3fb870e-ae69b059498e8a563c6d64c4aa4cb95e53d76680
 
git://xenbits.xen.org/xen.git#abf8824fe530bcf060c757596f68663c87546a6a-f8c66c2ad2efdb281e4ebf15bf329d73c4f02ce7
Loaded 4083 nodes in revision graph
Searching for test results:
 84243 pass irrelevant
 84435 pass 0b2737d1affeecfcf2f5ceeadeecfcbecba21e35 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d2ba6f41e2f8cbc8dffee8bddaebbbd6f3a3b9ab 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
abf8824fe530bcf060c757596f68663c87546a6a
 84351 pass 0b2737d1affeecfcf2f5ceeadeecfcbecba21e35 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d2ba6f41e2f8cbc8dffee8bddaebbbd6f3a3b9ab 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
abf8824fe530bcf060c757596f68663c87546a6a
 84489 fail irrelevant
 84626 fail irrelevant
 84581 fail irrelevant
 84577 pass 0b2737d1affeecfcf2f5ceeadeecfcbecba21e35 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
d2ba6f41e2f8cbc8dffee8bddaebbbd6f3a3b9ab 
21f6526d1da331611ac5fe12967549d1a04e149b 
316a862e5534249a6e6d876b4e203342d3fb870e 
abf8824fe530bcf060c757596f68663c87546a6a
 84880 []
 84886 pass 0b2737d1affeecfcf2f5ceeadeecfcbecba21e35 

[Xen-devel] [xen-4.5-testing baseline-only test] 44406: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44406 xen-4.5-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44406/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44358
 build-armhf   3 host-install(3) broken REGR. vs. 44358
 test-amd64-i386-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 
44358

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 44358
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 44358
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 44358
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 44358

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3
baseline version:
 xen  c70ab649fcde2f0c3d750d35f5e2b77d619ba80b

Last test of basis44358  2016-04-23 10:48:54 Z   18 days
Testing same since44406  2016-05-11 13:21:34 Z0 days1 attempts


People who touched revisions under test:
  David Vrabel 
  Jan Beulich 
  Juergen Gross 
  Mike Meyer 
  Mike Meyer Mon Apr 4 15:02:59 2016 +0200 
  Olaf Hering 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 

[Xen-devel] [libvirt test] 94018: tolerable FAIL - PUSHED

[osstest service owner]

flight 94018 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94018/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass

version targeted for testing:
 libvirt  e5aecc2f800e8e14edd561dc5af4f763f040d842
baseline version:
 libvirt  8b62c65d24bdb20121d3147b4f4dc98bac4f024b

Last test of basis91479  2016-04-15 05:33:51 Z   26 days
Failing since 91597  2016-04-16 04:20:46 Z   25 days   25 attempts
Testing same since94018  2016-05-11 04:21:08 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Ben Gray 
  Bjoern Walk 
  Boris Fiuczynski 
  Cole Robinson 
  Cédric Bosdonnat 
  Daniel P. Berrange 
  Daniel Veillard 
  Dmitry Andreev 
  Eric Blake 
  Erik Skultety 
  Jason J. Herne 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Nishith Shah 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Pavel Hrdina 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Shivaprasad G Bhat 
  Shivaprasad G Bhat 
  Simon Arlott 
  Yuri Chornoivan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 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-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 

[Xen-devel] [qemu-upstream-4.3-testing test] 94019: trouble: blocked/broken

[osstest service owner]

flight 94019 qemu-upstream-4.3-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94019/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3863 host-install(3) broken REGR. vs. 80927
 build-i386-pvops  3 host-install(3) broken REGR. vs. 80927
 build-amd64   3 host-install(3) broken REGR. vs. 80927
 build-amd64-pvops 3 host-install(3) broken REGR. vs. 80927

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-pv   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-pv1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemuu-winxpsp3  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a

version targeted for testing:
 qemuuc97c20f71240a538a19cb6b0e598bc1bbd5168f1
baseline version:
 qemuu10c1b763c26feb645627a1639e722515f3e1e876

Last test of basis80927  2016-02-06 13:30:02 Z   95 days
Testing same since93977  2016-05-10 11:09:16 Z1 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64  broken  
 build-i386   broken  
 build-amd64-libvirt  blocked 
 build-i386-libvirt   blocked 
 build-amd64-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-xl  blocked 
 test-amd64-i386-xl   blocked 
 test-amd64-i386-qemuu-rhel6hvm-amd   blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64blocked 
 test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked 
 test-amd64-i386-freebsd10-amd64  blocked 
 test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked 
 test-amd64-i386-xl-qemuu-ovmf-amd64  blocked 
 test-amd64-amd64-xl-qemuu-win7-amd64 blocked 
 test-amd64-i386-xl-qemuu-win7-amd64  blocked 
 test-amd64-amd64-xl-credit2  blocked 
 test-amd64-i386-freebsd10-i386   blocked 
 test-amd64-i386-qemuu-rhel6hvm-intel blocked 
 test-amd64-amd64-libvirt blocked 
 test-amd64-i386-libvirt  blocked 
 test-amd64-amd64-xl-multivcpublocked 
 

Re: [Xen-devel] [PATCH v3 5/6] build: convert perfc{, _arrays} to Kconfig

[Doug Goldstein]

On 5/11/16 4:53 AM, Jan Beulich wrote:
 On 10.05.16 at 23:05,  wrote:
>> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
>> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.
> 
> I don't understand the "to minimize code changes" part.

Instead of calling the options "CONFIG_PERFC" and CONFIG_PERFC_ARRAYS"
as the originals would be called.

I do most of these Kconfig patches with sed and not by hand.

> 
>> @@ -12,18 +10,15 @@ lto   ?= n
>>  
>>  include $(XEN_ROOT)/Config.mk
>>  
>> -# Hardcoded configuration implications and dependencies.
>> -# Do this is a neater way if it becomes unwieldy.
>> -ifeq ($(perfc_arrays),y)
>> -perfc := y
>> -endif
>> -
>>  ifneq ($(origin kexec),undefined)
>>  $(error "You must use 'make menuconfig' to enable/disable kexec now.")
>>  endif
>>  ifneq ($(origin crash_debug),undefined)
>>  $(error "You must use 'make menuconfig' to enable/disable crash_debug now.")
>>  endif
>> +ifneq ($(origin perfc),undefined)
>> +$(error "You must use 'make menuconfig' to enable/disable perfc now.")
>> +endif
> 
> I'm pretty sure I've asked before: Why do you add something
> here for crash_debug and perfc, but not for debug, verbose,
> and frame_pointer?

I added the one you had mentioned. I didn't realize it was a uniform
statement. In the past (for other series) I've been told to drop those
statements for not common options.

As far as the debug one, I had that in patch 5 but passing the value in
but that was dropped.


> 
>> --- a/xen/arch/x86/x86_64/asm-offsets.c
>> +++ b/xen/arch/x86/x86_64/asm-offsets.c
>> @@ -151,7 +151,7 @@ void __dummy__(void)
>>  OFFSET(TRAPBOUNCE_eip, struct trap_bounce, eip);
>>  BLANK();
>>  
>> -#if PERF_COUNTERS
>> +#if CONFIG_PERF_COUNTERS
> 
> Same here - I'm pretty sure I've already asked for this to become
> #ifdef.
> 
> Jan
> 


-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 3/6] build: convert verbose to Kconfig

[Doug Goldstein]

On 5/11/16 4:45 AM, Jan Beulich wrote:
 On 10.05.16 at 23:05,  wrote:
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -15,4 +15,11 @@ config DEBUG
>>option is intended for development purposes only, and not for
>>production use.
>>  
>> +config VERBOSE_DEBUG
>> +bool "Verbose debug messages"
>> +default DEBUG
>> +---help---
>> +  Guest output from HYPERVISOR_console_io and hypervisor parsing
>> +  ELF images (dom0) is logged in the Xen ring buffer.
> 
> The "depends on DEBUG || EXPERT" did get lost here (or, looking at
> the following patch, a respective "if" framing them all).
> 
> Jan
> 

This option is always visible to someone and is not dependent on DEBUG
due to the if not being possible in the form you asked. So I adjusted it
to "default DEBUG" as you had asked. I can make this option dependent on
DEBUG or EXPERT.

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 2/6] build: convert crash_debug to Kconfig

[Doug Goldstein]

On 5/11/16 4:47 AM, Jan Beulich wrote:
 On 10.05.16 at 23:05,  wrote:
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -1,6 +1,13 @@
>>  
>>  menu "Debugging Options"
>>  
>> +config CRASH_DEBUG
>> +bool "Crash Debugging Support"
>> +depends on X86
>> +---help---
>> +  If you want to be able to attach gdb to Xen to be able to debug
>> +  Xen if it crashes then say Y.
>> +
>>  config DEBUG
>>  bool "Developer Checks"
>>  ---help---
> 
> Is this really meant to be independent of DEBUG (or EXPERT), as it's
> being placed ahead of DEBUG?
> 
> Jan
> 

That's what we talked about with v2. You wanted it to be independent if
EXPERT was set but when you have something defined as "menuconfig "
you cannot then have a rule "if  || EXPERT" as you asked for in v2.
So I needed to make them independent always which is what I did.

Let me restate more generically, if things are dependent on a menu for
the sub-menu items to be displayed (as in v2) then the menu must be
enabled and cannot be conditionally displayed on another option.

Roughly think of it this way:

menuconfig SOME_STATE

if SOME_STATE || EXPERT

config OTHER

endif


is the following code:


if (SOME_STATE) {
  if (SOME_STATE or EXPERT) {
printf("got here\n");
  }
}

-- 
Doug Goldstein



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-4.4-testing test] 94001: regressions - FAIL

[osstest service owner]

flight 94001 xen-4.4-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94001/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xend-qemut-winxpsp3  9 windows-installfail REGR. vs. 92242

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92242
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92242
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92242

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
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass

version targeted for testing:
 xen  ab6f8993136a10fee4336e0cbb90f491ce505212
baseline version:
 xen  24ebffa9f57a14b6f20376ae422b941715af9a4e

Last test of basis92242  2016-04-21 08:21:20 Z   20 days
Testing same since94001  2016-05-10 18:47:20 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xend pass
 build-i386-xend  pass
 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
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Sahita, Ravi]

Hi Fangtuo,

#VE can be setup to be delivered to any dom that is a HVM.

Ravi

From: Big Strong [mailto:fangtu...@gmail.com]
Sent: Wednesday, May 11, 2016 8:38 AM
To: Wei Liu 
Cc: Tamas K Lengyel ; Sahita, Ravi 
; Xen-devel 
Subject: Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

Is that a bug or does #ve info page can only exist on dom0? If this is true, 
why would there be a is_hvm_domain check which will stop the execution of 
xc_altp2m_vcpu_enable_notify?

2016-05-11 15:56 GMT+08:00 Big Strong 
>:
From what I analyzed, can I draw a concolusion that the current implementation 
of do_altp2m_op means #ve info page can only be set on dom0 memory and the dom0 
must be a hvm? This seems like ridiculous as dom0 is a special pv guest.

2016-05-11 11:37 GMT+08:00 Big Strong 
>:
Further debugging shows that the domain is changed to domain 0 during the check 
of whether the cmd of do_altp2m_op is HVMOP_altp2m_vcpu_enable_notify, located 
at 
here.
 As domain 0 is a pv guest, it causes the 
is_hvm_domain
 check failed, and thus the execution never goes to 
HVMOP_altp2m_vcpu_enable_notify,
 which in the end cause xc_altp2m_set_vcpu_enable_notify fail. Why would the 
logic of do_altp2m_op change the domain to dom0 when the cmd of do_altp2m_op is 
HVMOP_altp2m_vcpu_enable_notify?

Thanks for the suggestion, after adding printk to all the routines of 
xc_altp2m_set_vcpu_enable_notify, it turns out that the problem is because the 
check of 
is_hvm_domain()
 failed in function 
do_altp2m_op().
 However, I've already configure the VM to build as a HVM by adding option 
"builder=hvm" in the config file, but for unknown reason the .printk of 
domain->type is guest_type_pv. I've tried both windows and linux as the guest 
VM, both failed for the same reason. Any ideas?



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

Re: [Xen-devel] [PATCH net-next v3 1/4] xen-netback: add control ring boilerplate

[Wei Liu]

On Wed, May 11, 2016 at 04:33:34PM +0100, Paul Durrant wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
> 
> This patch adds the necessary code to xen-netback to map this new shared
> ring, should it be created by a frontend, but does not add implementations
> for any of the defined protocol messages. These are added in a subsequent
> patch for clarity.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH net-next v3 2/4] xen-netback: add control protocol implementation

[Wei Liu]

On Wed, May 11, 2016 at 04:33:35PM +0100, Paul Durrant wrote:
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
> 
> A previous patch added the necessary boilerplate for mapping the control
> ring from the frontend, should it be created. This patch adds
> implementations for each of the defined protocol messages.
> 
> Signed-off-by: Paul Durrant 

Acked-by: Wei Liu 

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

[Xen-devel] [PATCH net-next v2 3/4] xen-netback: pass hash value to the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
 drivers/net/xen-netback/interface.c | 13 ++-
 drivers/net/xen-netback/netback.c   | 78 +++--
 2 files changed, 77 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 483080f..dcca498 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -158,8 +158,17 @@ static u16 xenvif_select_queue(struct net_device *dev, 
struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
 
-   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
-   return fallback(dev, skb) % dev->real_num_tx_queues;
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
+   u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
+
+   /* Make sure there is no hash information in the socket
+* buffer otherwise it would be incorrectly forwarded
+* to the frontend.
+*/
+   skb_clear_hash(skb);
+
+   return index;
+   }
 
xenvif_set_skb_hash(vif, skb);
 
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 6509d11..7c72510 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -168,6 +168,8 @@ static bool xenvif_rx_ring_slots_available(struct 
xenvif_queue *queue)
needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
if (skb_is_gso(skb))
needed++;
+   if (skb->sw_hash)
+   needed++;
 
do {
prod = queue->rx.sring->req_prod;
@@ -285,6 +287,8 @@ struct gop_frag_copy {
struct xenvif_rx_meta *meta;
int head;
int gso_type;
+   int protocol;
+   int hash_present;
 
struct page *page;
 };
@@ -331,8 +335,15 @@ static void xenvif_setup_copy_gop(unsigned long gfn,
npo->copy_off += *len;
info->meta->size += *len;
 
+   if (!info->head)
+   return;
+
/* Leave a gap for the GSO descriptor. */
-   if (info->head && ((1 << info->gso_type) & queue->vif->gso_mask))
+   if ((1 << info->gso_type) & queue->vif->gso_mask)
+   queue->rx.req_cons++;
+
+   /* Leave a gap for the hash extra segment. */
+   if (info->hash_present)
queue->rx.req_cons++;
 
info->head = 0; /* There must be something in this buffer now */
@@ -367,6 +378,11 @@ static void xenvif_gop_frag_copy(struct xenvif_queue 
*queue, struct sk_buff *skb
.npo = npo,
.head = *head,
.gso_type = XEN_NETIF_GSO_TYPE_NONE,
+   /* xenvif_set_skb_hash() will have either set a s/w
+* hash or cleared the hash depending on
+* whether the the frontend wants a hash for this skb.
+*/
+   .hash_present = skb->sw_hash,
};
unsigned long bytes;
 
@@ -555,6 +571,7 @@ void xenvif_kick_thread(struct xenvif_queue *queue)
 
 static void xenvif_rx_action(struct xenvif_queue *queue)
 {
+   struct xenvif *vif = queue->vif;
s8 status;
u16 flags;
struct xen_netif_rx_response *resp;
@@ -590,9 +607,10 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
gnttab_batch_copy(queue->grant_copy_op, npo.copy_prod);
 
while ((skb = __skb_dequeue()) != NULL) {
+   struct xen_netif_extra_info *extra = NULL;
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_prefix_mask) {
+   vif->gso_prefix_mask) {
resp = RING_GET_RESPONSE(>rx,
 queue->rx.rsp_prod_pvt++);
 
@@ -610,7 +628,7 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
queue->stats.tx_bytes += skb->len;
queue->stats.tx_packets++;
 
-   status = xenvif_check_gop(queue->vif,
+   status = xenvif_check_gop(vif,
  XENVIF_RX_CB(skb)->meta_slots_used,
  );
 
@@ -632,21 +650,57 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
flags);
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_mask) {
-   struct xen_netif_extra_info *gso =
-   (struct xen_netif_extra_info *)
+  

[Xen-devel] [PATCH net-next v3 0/4] xen-netback: support for control ring

[Paul Durrant]

My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.

Patch #1 adds the necessary boilerplate to map the control ring and handle
messages. No implementation of the new protocol is included in this patch
so that it can be kept to a reasonable size.

Patch #2 adds the protocol implementation.

Patch #3 adds support for passing has values calculated by xen-netback to
capable frontends.

Patch #4 adds support for accepting hash values calculated by capable
frontends and using them the set the socket buffer hash.

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

[Xen-devel] [PATCH net-next v2 4/4] xen-netback: use hash value from the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to use the value in a hash extra
info fragment passed from the guest frontend in a transmit-side
(i.e. netback receive side) packet to set the skb hash accordingly.

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
 drivers/net/xen-netback/netback.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 7c72510..a5b5aad 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1509,6 +1509,33 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
*queue,
}
}
 
+   if (extras[XEN_NETIF_EXTRA_TYPE_HASH - 1].type) {
+   struct xen_netif_extra_info *extra;
+   enum pkt_hash_types type = PKT_HASH_TYPE_NONE;
+
+   extra = [XEN_NETIF_EXTRA_TYPE_HASH - 1];
+
+   switch (extra->u.hash.type) {
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV4:
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV6:
+   type = PKT_HASH_TYPE_L3;
+   break;
+
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP:
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP:
+   type = PKT_HASH_TYPE_L4;
+   break;
+
+   default:
+   break;
+   }
+
+   if (type != PKT_HASH_TYPE_NONE)
+   skb_set_hash(skb,
+*(u32 *)extra->u.hash.value,
+type);
+   }
+
XENVIF_TX_CB(skb)->pending_idx = pending_idx;
 
__skb_put(skb, data_len);
-- 
2.1.4


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

[Xen-devel] [PATCH net-next v2 2/4] xen-netback: add control protocol implementation

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it be created. This patch adds
implementations for each of the defined protocol messages.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---

v2:
 - Use RCU list for hash cache
---
 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  46 +
 drivers/net/xen-netback/hash.c  | 386 
 drivers/net/xen-netback/interface.c |  28 ++-
 drivers/net/xen-netback/netback.c   |  49 -
 5 files changed, 506 insertions(+), 5 deletions(-)
 create mode 100644 drivers/net/xen-netback/hash.c

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..11e02be 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o hash.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 093a12a..84d6cbd 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -220,6 +220,35 @@ struct xenvif_mcast_addr {
 
 #define XEN_NETBK_MCAST_MAX 64
 
+#define XEN_NETBK_MAX_HASH_KEY_SIZE 40
+#define XEN_NETBK_MAX_HASH_MAPPING_SIZE 128
+#define XEN_NETBK_HASH_TAG_SIZE 40
+
+struct xenvif_hash_cache_entry {
+   struct list_head link;
+   struct rcu_head rcu;
+   u8 tag[XEN_NETBK_HASH_TAG_SIZE];
+   unsigned int len;
+   u32 val;
+   int seq;
+};
+
+struct xenvif_hash_cache {
+   spinlock_t lock;
+   struct list_head list;
+   unsigned int count;
+   atomic_t seq;
+};
+
+struct xenvif_hash {
+   unsigned int alg;
+   u32 flags;
+   u8 key[XEN_NETBK_MAX_HASH_KEY_SIZE];
+   u32 mapping[XEN_NETBK_MAX_HASH_MAPPING_SIZE];
+   unsigned int size;
+   struct xenvif_hash_cache cache;
+};
+
 struct xenvif {
/* Unique identifier for this interface. */
domid_t  domid;
@@ -251,6 +280,8 @@ struct xenvif {
unsigned int num_queues; /* active queues, resource allocated */
unsigned int stalled_queues;
 
+   struct xenvif_hash hash;
+
struct xenbus_watch credit_watch;
struct xenbus_watch mcast_ctrl_watch;
 
@@ -353,6 +384,7 @@ extern bool separate_tx_rx_irq;
 extern unsigned int rx_drain_timeout_msecs;
 extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
+extern unsigned int xenvif_hash_cache_size;
 
 #ifdef CONFIG_DEBUG_FS
 extern struct dentry *xen_netback_dbg_root;
@@ -366,4 +398,18 @@ void xenvif_skb_zerocopy_complete(struct xenvif_queue 
*queue);
 bool xenvif_mcast_match(struct xenvif *vif, const u8 *addr);
 void xenvif_mcast_addr_list_free(struct xenvif *vif);
 
+/* Hash */
+void xenvif_init_hash(struct xenvif *vif);
+void xenvif_deinit_hash(struct xenvif *vif);
+
+u32 xenvif_set_hash_alg(struct xenvif *vif, u32 alg);
+u32 xenvif_get_hash_flags(struct xenvif *vif, u32 *flags);
+u32 xenvif_set_hash_flags(struct xenvif *vif, u32 flags);
+u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32 len);
+u32 xenvif_set_hash_mapping_size(struct xenvif *vif, u32 size);
+u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
+   u32 off);
+
+void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
new file mode 100644
index 000..47edfe9
--- /dev/null
+++ b/drivers/net/xen-netback/hash.c
@@ -0,0 +1,386 @@
+/*
+ * Copyright (c) 2016 Citrix Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Softare Foundation; or, 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 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 

[Xen-devel] [PATCH net-next v3 4/4] xen-netback: use hash value from the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to use the value in a hash extra
info fragment passed from the guest frontend in a transmit-side
(i.e. netback receive side) packet to set the skb hash accordingly.

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
 drivers/net/xen-netback/netback.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 7c72510..a5b5aad 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1509,6 +1509,33 @@ static void xenvif_tx_build_gops(struct xenvif_queue 
*queue,
}
}
 
+   if (extras[XEN_NETIF_EXTRA_TYPE_HASH - 1].type) {
+   struct xen_netif_extra_info *extra;
+   enum pkt_hash_types type = PKT_HASH_TYPE_NONE;
+
+   extra = [XEN_NETIF_EXTRA_TYPE_HASH - 1];
+
+   switch (extra->u.hash.type) {
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV4:
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV6:
+   type = PKT_HASH_TYPE_L3;
+   break;
+
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV4_TCP:
+   case _XEN_NETIF_CTRL_HASH_TYPE_IPV6_TCP:
+   type = PKT_HASH_TYPE_L4;
+   break;
+
+   default:
+   break;
+   }
+
+   if (type != PKT_HASH_TYPE_NONE)
+   skb_set_hash(skb,
+*(u32 *)extra->u.hash.value,
+type);
+   }
+
XENVIF_TX_CB(skb)->pending_idx = pending_idx;
 
__skb_put(skb, data_len);
-- 
2.1.4


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

[Xen-devel] [PATCH net-next v3 3/4] xen-netback: pass hash value to the frontend

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new extra
info type that can be used to pass hash values between backend and guest
frontend.

This patch adds code to xen-netback to pass hash values calculated for
guest receive-side packets (i.e. netback transmit side) to the frontend.

Signed-off-by: Paul Durrant 
Acked-by: Wei Liu 
---
 drivers/net/xen-netback/interface.c | 13 ++-
 drivers/net/xen-netback/netback.c   | 78 +++--
 2 files changed, 77 insertions(+), 14 deletions(-)

diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index 5a39cdb..1c7f49b 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -158,8 +158,17 @@ static u16 xenvif_select_queue(struct net_device *dev, 
struct sk_buff *skb,
struct xenvif *vif = netdev_priv(dev);
unsigned int size = vif->hash.size;
 
-   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE)
-   return fallback(dev, skb) % dev->real_num_tx_queues;
+   if (vif->hash.alg == XEN_NETIF_CTRL_HASH_ALGORITHM_NONE) {
+   u16 index = fallback(dev, skb) % dev->real_num_tx_queues;
+
+   /* Make sure there is no hash information in the socket
+* buffer otherwise it would be incorrectly forwarded
+* to the frontend.
+*/
+   skb_clear_hash(skb);
+
+   return index;
+   }
 
xenvif_set_skb_hash(vif, skb);
 
diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 6509d11..7c72510 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -168,6 +168,8 @@ static bool xenvif_rx_ring_slots_available(struct 
xenvif_queue *queue)
needed = DIV_ROUND_UP(skb->len, XEN_PAGE_SIZE);
if (skb_is_gso(skb))
needed++;
+   if (skb->sw_hash)
+   needed++;
 
do {
prod = queue->rx.sring->req_prod;
@@ -285,6 +287,8 @@ struct gop_frag_copy {
struct xenvif_rx_meta *meta;
int head;
int gso_type;
+   int protocol;
+   int hash_present;
 
struct page *page;
 };
@@ -331,8 +335,15 @@ static void xenvif_setup_copy_gop(unsigned long gfn,
npo->copy_off += *len;
info->meta->size += *len;
 
+   if (!info->head)
+   return;
+
/* Leave a gap for the GSO descriptor. */
-   if (info->head && ((1 << info->gso_type) & queue->vif->gso_mask))
+   if ((1 << info->gso_type) & queue->vif->gso_mask)
+   queue->rx.req_cons++;
+
+   /* Leave a gap for the hash extra segment. */
+   if (info->hash_present)
queue->rx.req_cons++;
 
info->head = 0; /* There must be something in this buffer now */
@@ -367,6 +378,11 @@ static void xenvif_gop_frag_copy(struct xenvif_queue 
*queue, struct sk_buff *skb
.npo = npo,
.head = *head,
.gso_type = XEN_NETIF_GSO_TYPE_NONE,
+   /* xenvif_set_skb_hash() will have either set a s/w
+* hash or cleared the hash depending on
+* whether the the frontend wants a hash for this skb.
+*/
+   .hash_present = skb->sw_hash,
};
unsigned long bytes;
 
@@ -555,6 +571,7 @@ void xenvif_kick_thread(struct xenvif_queue *queue)
 
 static void xenvif_rx_action(struct xenvif_queue *queue)
 {
+   struct xenvif *vif = queue->vif;
s8 status;
u16 flags;
struct xen_netif_rx_response *resp;
@@ -590,9 +607,10 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
gnttab_batch_copy(queue->grant_copy_op, npo.copy_prod);
 
while ((skb = __skb_dequeue()) != NULL) {
+   struct xen_netif_extra_info *extra = NULL;
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_prefix_mask) {
+   vif->gso_prefix_mask) {
resp = RING_GET_RESPONSE(>rx,
 queue->rx.rsp_prod_pvt++);
 
@@ -610,7 +628,7 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
queue->stats.tx_bytes += skb->len;
queue->stats.tx_packets++;
 
-   status = xenvif_check_gop(queue->vif,
+   status = xenvif_check_gop(vif,
  XENVIF_RX_CB(skb)->meta_slots_used,
  );
 
@@ -632,21 +650,57 @@ static void xenvif_rx_action(struct xenvif_queue *queue)
flags);
 
if ((1 << queue->meta[npo.meta_cons].gso_type) &
-   queue->vif->gso_mask) {
-   struct xen_netif_extra_info *gso =
-   (struct xen_netif_extra_info *)
+  

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

Is that a bug or does #ve info page can only exist on dom0? If this is
true, why would there be a is_hvm_domain check which will stop the
execution of xc_altp2m_vcpu_enable_notify?

2016-05-11 15:56 GMT+08:00 Big Strong :

> From what I analyzed, can I draw a concolusion that the current
> implementation of do_altp2m_op means #ve info page can only be set on dom0
> memory and the dom0 must be a hvm? This seems like ridiculous as dom0 is a
> special pv guest.
>
> 2016-05-11 11:37 GMT+08:00 Big Strong :
>
>> Further debugging shows that the domain is changed to domain 0 during the
>> check of whether the cmd of do_altp2m_op
>> is HVMOP_altp2m_vcpu_enable_notify, located at here
>> .
>> As domain 0 is a pv guest, it causes the is_hvm_domain
>> 
>> check failed, and thus the execution never goes to
>> HVMOP_altp2m_vcpu_enable_notify
>> ,
>> which in the end cause xc_altp2m_set_vcpu_enable_notify fail. Why would *the
>> logic of do_altp2m_op change the domain to dom0 when the cmd of
>> do_altp2m_op is HVMOP_altp2m_vcpu_enable_notify*?
>>
>> Thanks for the suggestion, after adding printk to all the routines
 of xc_altp2m_set_vcpu_enable_notify, it turns out that the problem is
 because* the check of is_hvm_domain()
 
 failed* in function do_altp2m_op()
 .
 However, I've already configure the VM to build as a HVM by adding option
 "builder=hvm" in the config file, but for unknown reason the .printk of
 domain->type is guest_type_pv. I've tried both windows and linux as the
 guest VM, both failed for the same reason. Any ideas?

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

[Xen-devel] [PATCH net-next v3 1/4] xen-netback: add control ring boilerplate

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a frontend, but does not add implementations
for any of the defined protocol messages. These are added in a subsequent
patch for clarity.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---

v2:
 - Changed error handling style in connect_ctrl_ring()
---
 drivers/net/xen-netback/common.h|  28 +++---
 drivers/net/xen-netback/interface.c | 101 +---
 drivers/net/xen-netback/netback.c   |  99 +--
 drivers/net/xen-netback/xenbus.c|  79 
 4 files changed, 277 insertions(+), 30 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f44b388..093a12a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -260,6 +260,11 @@ struct xenvif {
struct dentry *xenvif_dbg_root;
 #endif
 
+   struct xen_netif_ctrl_back_ring ctrl;
+   struct task_struct *ctrl_task;
+   wait_queue_head_t ctrl_wq;
+   unsigned int ctrl_irq;
+
/* Miscellaneous private stuff. */
struct net_device *dev;
 };
@@ -285,10 +290,15 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_init_queue(struct xenvif_queue *queue);
 void xenvif_deinit_queue(struct xenvif_queue *queue);
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn);
-void xenvif_disconnect(struct xenvif *vif);
+int xenvif_connect_data(struct xenvif_queue *queue,
+   unsigned long tx_ring_ref,
+   unsigned long rx_ring_ref,
+   unsigned int tx_evtchn,
+   unsigned int rx_evtchn);
+void xenvif_disconnect_data(struct xenvif *vif);
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn);
+void xenvif_disconnect_ctrl(struct xenvif *vif);
 void xenvif_free(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -300,10 +310,10 @@ int xenvif_queue_stopped(struct xenvif_queue *queue);
 void xenvif_wake_queue(struct xenvif_queue *queue);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif_queue *queue);
-int xenvif_map_frontend_rings(struct xenvif_queue *queue,
- grant_ref_t tx_ring_ref,
- grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_data_rings(struct xenvif_queue *queue);
+int xenvif_map_frontend_data_rings(struct xenvif_queue *queue,
+  grant_ref_t tx_ring_ref,
+  grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_napi_schedule_or_enable_events(struct xenvif_queue *queue);
@@ -318,6 +328,8 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
 
 int xenvif_dealloc_kthread(void *data);
 
+int xenvif_ctrl_kthread(void *data);
+
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
 void xenvif_carrier_on(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index f5231a2..78a10d2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -128,6 +128,15 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+irqreturn_t xenvif_ctrl_interrupt(int irq, void *dev_id)
+{
+   struct xenvif *vif = dev_id;
+
+   wake_up(>ctrl_wq);
+
+   return IRQ_HANDLED;
+}
+
 int xenvif_queue_stopped(struct xenvif_queue *queue)
 {
struct net_device *dev = queue->vif->dev;
@@ -527,9 +536,66 @@ void xenvif_carrier_on(struct xenvif *vif)
rtnl_unlock();
 }
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn)
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn)
+{
+   struct net_device *dev = vif->dev;
+   void *addr;
+   struct xen_netif_ctrl_sring *shared;
+   struct task_struct *task;
+   int err = -ENOMEM;
+
+   err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
+_ref, 1, );
+   if (err)
+   goto err;
+
+   shared = (struct xen_netif_ctrl_sring *)addr;
+   BACK_RING_INIT(>ctrl, shared, XEN_PAGE_SIZE);
+
+   init_waitqueue_head(>ctrl_wq);
+
+   err = bind_interdomain_evtchn_to_irqhandler(vif->domid, evtchn,
+   

[Xen-devel] [PATCH net-next v2 1/4] xen-netback: add control ring boilerplate

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

This patch adds the necessary code to xen-netback to map this new shared
ring, should it be created by a frontend, but does not add implementations
for any of the defined protocol messages. These are added in a subsequent
patch for clarity.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---

v2:
 - Changed error handling style in connect_ctrl_ring()
---
 drivers/net/xen-netback/common.h|  28 +++---
 drivers/net/xen-netback/interface.c | 101 +---
 drivers/net/xen-netback/netback.c   |  99 +--
 drivers/net/xen-netback/xenbus.c|  79 
 4 files changed, 277 insertions(+), 30 deletions(-)

diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index f44b388..093a12a 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -260,6 +260,11 @@ struct xenvif {
struct dentry *xenvif_dbg_root;
 #endif
 
+   struct xen_netif_ctrl_back_ring ctrl;
+   struct task_struct *ctrl_task;
+   wait_queue_head_t ctrl_wq;
+   unsigned int ctrl_irq;
+
/* Miscellaneous private stuff. */
struct net_device *dev;
 };
@@ -285,10 +290,15 @@ struct xenvif *xenvif_alloc(struct device *parent,
 int xenvif_init_queue(struct xenvif_queue *queue);
 void xenvif_deinit_queue(struct xenvif_queue *queue);
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn);
-void xenvif_disconnect(struct xenvif *vif);
+int xenvif_connect_data(struct xenvif_queue *queue,
+   unsigned long tx_ring_ref,
+   unsigned long rx_ring_ref,
+   unsigned int tx_evtchn,
+   unsigned int rx_evtchn);
+void xenvif_disconnect_data(struct xenvif *vif);
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn);
+void xenvif_disconnect_ctrl(struct xenvif *vif);
 void xenvif_free(struct xenvif *vif);
 
 int xenvif_xenbus_init(void);
@@ -300,10 +310,10 @@ int xenvif_queue_stopped(struct xenvif_queue *queue);
 void xenvif_wake_queue(struct xenvif_queue *queue);
 
 /* (Un)Map communication rings. */
-void xenvif_unmap_frontend_rings(struct xenvif_queue *queue);
-int xenvif_map_frontend_rings(struct xenvif_queue *queue,
- grant_ref_t tx_ring_ref,
- grant_ref_t rx_ring_ref);
+void xenvif_unmap_frontend_data_rings(struct xenvif_queue *queue);
+int xenvif_map_frontend_data_rings(struct xenvif_queue *queue,
+  grant_ref_t tx_ring_ref,
+  grant_ref_t rx_ring_ref);
 
 /* Check for SKBs from frontend and schedule backend processing */
 void xenvif_napi_schedule_or_enable_events(struct xenvif_queue *queue);
@@ -318,6 +328,8 @@ void xenvif_kick_thread(struct xenvif_queue *queue);
 
 int xenvif_dealloc_kthread(void *data);
 
+int xenvif_ctrl_kthread(void *data);
+
 void xenvif_rx_queue_tail(struct xenvif_queue *queue, struct sk_buff *skb);
 
 void xenvif_carrier_on(struct xenvif *vif);
diff --git a/drivers/net/xen-netback/interface.c 
b/drivers/net/xen-netback/interface.c
index f5231a2..78a10d2 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -128,6 +128,15 @@ irqreturn_t xenvif_interrupt(int irq, void *dev_id)
return IRQ_HANDLED;
 }
 
+irqreturn_t xenvif_ctrl_interrupt(int irq, void *dev_id)
+{
+   struct xenvif *vif = dev_id;
+
+   wake_up(>ctrl_wq);
+
+   return IRQ_HANDLED;
+}
+
 int xenvif_queue_stopped(struct xenvif_queue *queue)
 {
struct net_device *dev = queue->vif->dev;
@@ -527,9 +536,66 @@ void xenvif_carrier_on(struct xenvif *vif)
rtnl_unlock();
 }
 
-int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
-  unsigned long rx_ring_ref, unsigned int tx_evtchn,
-  unsigned int rx_evtchn)
+int xenvif_connect_ctrl(struct xenvif *vif, grant_ref_t ring_ref,
+   unsigned int evtchn)
+{
+   struct net_device *dev = vif->dev;
+   void *addr;
+   struct xen_netif_ctrl_sring *shared;
+   struct task_struct *task;
+   int err = -ENOMEM;
+
+   err = xenbus_map_ring_valloc(xenvif_to_xenbus_device(vif),
+_ref, 1, );
+   if (err)
+   goto err;
+
+   shared = (struct xen_netif_ctrl_sring *)addr;
+   BACK_RING_INIT(>ctrl, shared, XEN_PAGE_SIZE);
+
+   init_waitqueue_head(>ctrl_wq);
+
+   err = bind_interdomain_evtchn_to_irqhandler(vif->domid, evtchn,
+   

[Xen-devel] [PATCH net-next v2 0/4] xen-netback: support for control ring

[Paul Durrant]

My recent patch to import an up-to-date include/xen/interface/io/netif.h
from the Xen Project brought in the necessary definitions to support the
new control shared ring and protocol. This patch series updates xen-netback
to support the new ring.

Patch #1 adds the necessary boilerplate to map the control ring and handle
messages. No implementation of the new protocol is included in this patch
so that it can be kept to a reasonable size.

Patch #2 adds the protocol implementation.

Patch #3 adds support for passing has values calculated by xen-netback to
capable frontends.

Patch #4 adds support for accepting hash values calculated by capable
frontends and using them the set the socket buffer hash.

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

[Xen-devel] [PATCH net-next v3 2/4] xen-netback: add control protocol implementation

[Paul Durrant]

My recent patch to include/xen/interface/io/netif.h defines a new shared
ring (in addition to the rx and tx rings) for passing control messages
from a VM frontend driver to a backend driver.

A previous patch added the necessary boilerplate for mapping the control
ring from the frontend, should it be created. This patch adds
implementations for each of the defined protocol messages.

Signed-off-by: Paul Durrant 
Cc: Wei Liu 
---

v3:
 - Remove unintentional label rename

v2:
 - Use RCU list for hash cache
---
 drivers/net/xen-netback/Makefile|   2 +-
 drivers/net/xen-netback/common.h|  46 +
 drivers/net/xen-netback/hash.c  | 386 
 drivers/net/xen-netback/interface.c |  24 +++
 drivers/net/xen-netback/netback.c   |  49 -
 5 files changed, 504 insertions(+), 3 deletions(-)
 create mode 100644 drivers/net/xen-netback/hash.c

diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-netback/Makefile
index e346e81..11e02be 100644
--- a/drivers/net/xen-netback/Makefile
+++ b/drivers/net/xen-netback/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
 
-xen-netback-y := netback.o xenbus.o interface.o
+xen-netback-y := netback.o xenbus.o interface.o hash.o
diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-netback/common.h
index 093a12a..84d6cbd 100644
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -220,6 +220,35 @@ struct xenvif_mcast_addr {
 
 #define XEN_NETBK_MCAST_MAX 64
 
+#define XEN_NETBK_MAX_HASH_KEY_SIZE 40
+#define XEN_NETBK_MAX_HASH_MAPPING_SIZE 128
+#define XEN_NETBK_HASH_TAG_SIZE 40
+
+struct xenvif_hash_cache_entry {
+   struct list_head link;
+   struct rcu_head rcu;
+   u8 tag[XEN_NETBK_HASH_TAG_SIZE];
+   unsigned int len;
+   u32 val;
+   int seq;
+};
+
+struct xenvif_hash_cache {
+   spinlock_t lock;
+   struct list_head list;
+   unsigned int count;
+   atomic_t seq;
+};
+
+struct xenvif_hash {
+   unsigned int alg;
+   u32 flags;
+   u8 key[XEN_NETBK_MAX_HASH_KEY_SIZE];
+   u32 mapping[XEN_NETBK_MAX_HASH_MAPPING_SIZE];
+   unsigned int size;
+   struct xenvif_hash_cache cache;
+};
+
 struct xenvif {
/* Unique identifier for this interface. */
domid_t  domid;
@@ -251,6 +280,8 @@ struct xenvif {
unsigned int num_queues; /* active queues, resource allocated */
unsigned int stalled_queues;
 
+   struct xenvif_hash hash;
+
struct xenbus_watch credit_watch;
struct xenbus_watch mcast_ctrl_watch;
 
@@ -353,6 +384,7 @@ extern bool separate_tx_rx_irq;
 extern unsigned int rx_drain_timeout_msecs;
 extern unsigned int rx_stall_timeout_msecs;
 extern unsigned int xenvif_max_queues;
+extern unsigned int xenvif_hash_cache_size;
 
 #ifdef CONFIG_DEBUG_FS
 extern struct dentry *xen_netback_dbg_root;
@@ -366,4 +398,18 @@ void xenvif_skb_zerocopy_complete(struct xenvif_queue 
*queue);
 bool xenvif_mcast_match(struct xenvif *vif, const u8 *addr);
 void xenvif_mcast_addr_list_free(struct xenvif *vif);
 
+/* Hash */
+void xenvif_init_hash(struct xenvif *vif);
+void xenvif_deinit_hash(struct xenvif *vif);
+
+u32 xenvif_set_hash_alg(struct xenvif *vif, u32 alg);
+u32 xenvif_get_hash_flags(struct xenvif *vif, u32 *flags);
+u32 xenvif_set_hash_flags(struct xenvif *vif, u32 flags);
+u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32 len);
+u32 xenvif_set_hash_mapping_size(struct xenvif *vif, u32 size);
+u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
+   u32 off);
+
+void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
+
 #endif /* __XEN_NETBACK__COMMON_H__ */
diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-netback/hash.c
new file mode 100644
index 000..47edfe9
--- /dev/null
+++ b/drivers/net/xen-netback/hash.c
@@ -0,0 +1,386 @@
+/*
+ * Copyright (c) 2016 Citrix Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version 2
+ * as published by the Free Softare Foundation; or, 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 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 

[Xen-devel] [xen-4.6-testing test] 94000: regressions - FAIL

[osstest service owner]

flight 94000 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94000/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-arndale   7 host-ping-check-xen   fail REGR. vs. 93932

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 93932
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93932
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93932
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93932

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass

version targeted for testing:
 xen  5f05c100ca54acad94f73b6d679470323e664b16
baseline version:
 xen  39546d1360d954c2d0e2ff71dc74851e7081f61f

Last test of basis93932  2016-05-09 21:11:10 Z1 days
Testing same since94000  2016-05-10 18:10:33 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 

Re: [Xen-devel] [PATCH net-next v2 2/4] xen-netback: add control protocol implementation

[Paul Durrant]

> -Original Message-
> From: Paul Durrant [mailto:paul.durr...@citrix.com]
> Sent: 11 May 2016 16:16
> To: xen-de...@lists.xenproject.org; net...@vger.kernel.org
> Cc: Paul Durrant; Wei Liu
> Subject: [PATCH net-next v2 2/4] xen-netback: add control protocol
> implementation
> 
> My recent patch to include/xen/interface/io/netif.h defines a new shared
> ring (in addition to the rx and tx rings) for passing control messages
> from a VM frontend driver to a backend driver.
> 
> A previous patch added the necessary boilerplate for mapping the control
> ring from the frontend, should it be created. This patch adds
> implementations for each of the defined protocol messages.
> 
> Signed-off-by: Paul Durrant 
> Cc: Wei Liu 
> ---
> 
> v2:
>  - Use RCU list for hash cache
> ---
>  drivers/net/xen-netback/Makefile|   2 +-
>  drivers/net/xen-netback/common.h|  46 +
>  drivers/net/xen-netback/hash.c  | 386
> 
>  drivers/net/xen-netback/interface.c |  28 ++-
>  drivers/net/xen-netback/netback.c   |  49 -
>  5 files changed, 506 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/net/xen-netback/hash.c
> 
> diff --git a/drivers/net/xen-netback/Makefile b/drivers/net/xen-
> netback/Makefile
> index e346e81..11e02be 100644
> --- a/drivers/net/xen-netback/Makefile
> +++ b/drivers/net/xen-netback/Makefile
> @@ -1,3 +1,3 @@
>  obj-$(CONFIG_XEN_NETDEV_BACKEND) := xen-netback.o
> 
> -xen-netback-y := netback.o xenbus.o interface.o
> +xen-netback-y := netback.o xenbus.o interface.o hash.o
> diff --git a/drivers/net/xen-netback/common.h b/drivers/net/xen-
> netback/common.h
> index 093a12a..84d6cbd 100644
> --- a/drivers/net/xen-netback/common.h
> +++ b/drivers/net/xen-netback/common.h
> @@ -220,6 +220,35 @@ struct xenvif_mcast_addr {
> 
>  #define XEN_NETBK_MCAST_MAX 64
> 
> +#define XEN_NETBK_MAX_HASH_KEY_SIZE 40
> +#define XEN_NETBK_MAX_HASH_MAPPING_SIZE 128
> +#define XEN_NETBK_HASH_TAG_SIZE 40
> +
> +struct xenvif_hash_cache_entry {
> + struct list_head link;
> + struct rcu_head rcu;
> + u8 tag[XEN_NETBK_HASH_TAG_SIZE];
> + unsigned int len;
> + u32 val;
> + int seq;
> +};
> +
> +struct xenvif_hash_cache {
> + spinlock_t lock;
> + struct list_head list;
> + unsigned int count;
> + atomic_t seq;
> +};
> +
> +struct xenvif_hash {
> + unsigned int alg;
> + u32 flags;
> + u8 key[XEN_NETBK_MAX_HASH_KEY_SIZE];
> + u32 mapping[XEN_NETBK_MAX_HASH_MAPPING_SIZE];
> + unsigned int size;
> + struct xenvif_hash_cache cache;
> +};
> +
>  struct xenvif {
>   /* Unique identifier for this interface. */
>   domid_t  domid;
> @@ -251,6 +280,8 @@ struct xenvif {
>   unsigned int num_queues; /* active queues, resource allocated */
>   unsigned int stalled_queues;
> 
> + struct xenvif_hash hash;
> +
>   struct xenbus_watch credit_watch;
>   struct xenbus_watch mcast_ctrl_watch;
> 
> @@ -353,6 +384,7 @@ extern bool separate_tx_rx_irq;
>  extern unsigned int rx_drain_timeout_msecs;
>  extern unsigned int rx_stall_timeout_msecs;
>  extern unsigned int xenvif_max_queues;
> +extern unsigned int xenvif_hash_cache_size;
> 
>  #ifdef CONFIG_DEBUG_FS
>  extern struct dentry *xen_netback_dbg_root;
> @@ -366,4 +398,18 @@ void xenvif_skb_zerocopy_complete(struct
> xenvif_queue *queue);
>  bool xenvif_mcast_match(struct xenvif *vif, const u8 *addr);
>  void xenvif_mcast_addr_list_free(struct xenvif *vif);
> 
> +/* Hash */
> +void xenvif_init_hash(struct xenvif *vif);
> +void xenvif_deinit_hash(struct xenvif *vif);
> +
> +u32 xenvif_set_hash_alg(struct xenvif *vif, u32 alg);
> +u32 xenvif_get_hash_flags(struct xenvif *vif, u32 *flags);
> +u32 xenvif_set_hash_flags(struct xenvif *vif, u32 flags);
> +u32 xenvif_set_hash_key(struct xenvif *vif, u32 gref, u32 len);
> +u32 xenvif_set_hash_mapping_size(struct xenvif *vif, u32 size);
> +u32 xenvif_set_hash_mapping(struct xenvif *vif, u32 gref, u32 len,
> + u32 off);
> +
> +void xenvif_set_skb_hash(struct xenvif *vif, struct sk_buff *skb);
> +
>  #endif /* __XEN_NETBACK__COMMON_H__ */
> diff --git a/drivers/net/xen-netback/hash.c b/drivers/net/xen-
> netback/hash.c
> new file mode 100644
> index 000..47edfe9
> --- /dev/null
> +++ b/drivers/net/xen-netback/hash.c
> @@ -0,0 +1,386 @@
> +/*
> + * Copyright (c) 2016 Citrix Systems Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2
> + * as published by the Free Softare Foundation; or, 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 source file (the "Software"), to deal in the Software without
> + * restriction, including without 

[Xen-devel] [PATCH] xen: sched: rtds: refactor code

[Tianyang Chen]

No functional change:
 -Various coding style fix
 -Added comments for UPDATE_LIMIT_SHIFT.

Use non-atomic bit-ops:
 -Vcpu flags are checked and cleared atomically. Performance can be
  improved with corresponding non-atomic versions since schedule.c
  already has spin_locks in place.

Suggested-by: Dario Faggioli 
Signed-off-by: Tianyang Chen 
---
 xen/common/sched_rt.c |  122 ++---
 1 file changed, 64 insertions(+), 58 deletions(-)

diff --git a/xen/common/sched_rt.c b/xen/common/sched_rt.c
index 7f8f411..1a18f6d 100644
--- a/xen/common/sched_rt.c
+++ b/xen/common/sched_rt.c
@@ -80,7 +80,7 @@
  * in schedule.c
  *
  * The functions involes RunQ and needs to grab locks are:
- *vcpu_insert, vcpu_remove, context_saved, __runq_insert
+ *vcpu_insert, vcpu_remove, context_saved, runq_insert
  */
 
 
@@ -107,6 +107,12 @@
  */
 #define RTDS_MIN_BUDGET (MICROSECS(10))
 
+/*
+ * UPDATE_LIMIT_SHIT: a constant used in rt_update_deadline(). When finding
+ * the next deadline, performing addition could be faster if the difference
+ * between cur_deadline and now is small. If the difference is bigger than
+ * 1024 * period, use multiplication.
+ */
 #define UPDATE_LIMIT_SHIFT  10
 
 /*
@@ -158,25 +164,25 @@
 static void repl_timer_handler(void *data);
 
 /*
- * Systme-wide private data, include global RunQueue/DepletedQ
+ * System-wide private data, include global RunQueue/DepletedQ
  * Global lock is referenced by schedule_data.schedule_lock from all
  * physical cpus. It can be grabbed via vcpu_schedule_lock_irq()
  */
 struct rt_private {
-spinlock_t lock;/* the global coarse grand lock */
-struct list_head sdom;  /* list of availalbe domains, used for dump */
-struct list_head runq;  /* ordered list of runnable vcpus */
-struct list_head depletedq; /* unordered list of depleted vcpus */
-struct list_head replq; /* ordered list of vcpus that need 
replenishment */
-cpumask_t tickled;  /* cpus been tickled */
-struct timer *repl_timer;   /* replenishment timer */
+spinlock_t lock; /* the global coarse grand lock */
+struct list_head sdom;   /* list of availalbe domains, used for dump */
+struct list_head runq;   /* ordered list of runnable vcpus */
+struct list_head depletedq;  /* unordered list of depleted vcpus */
+struct list_head replq;  /* ordered list of vcpus that need 
replenishment */
+cpumask_t tickled;   /* cpus been tickled */
+struct timer *repl_timer;/* replenishment timer */
 };
 
 /*
  * Virtual CPU
  */
 struct rt_vcpu {
-struct list_head q_elem;/* on the runq/depletedq list */
+struct list_head q_elem; /* on the runq/depletedq list */
 struct list_head replq_elem; /* on the replenishment events list */
 
 /* Up-pointers */
@@ -188,19 +194,19 @@ struct rt_vcpu {
 s_time_t budget;
 
 /* VCPU current infomation in nanosecond */
-s_time_t cur_budget;/* current budget */
-s_time_t last_start;/* last start time */
-s_time_t cur_deadline;  /* current deadline for EDF */
+s_time_t cur_budget; /* current budget */
+s_time_t last_start; /* last start time */
+s_time_t cur_deadline;   /* current deadline for EDF */
 
-unsigned flags; /* mark __RTDS_scheduled, etc.. */
+unsigned flags;  /* mark __RTDS_scheduled, etc.. */
 };
 
 /*
  * Domain
  */
 struct rt_dom {
-struct list_head sdom_elem; /* link list on rt_priv */
-struct domain *dom; /* pointer to upper domain */
+struct list_head sdom_elem;  /* link list on rt_priv */
+struct domain *dom;  /* pointer to upper domain */
 };
 
 /*
@@ -241,13 +247,13 @@ static inline struct list_head *rt_replq(const struct 
scheduler *ops)
  * and the replenishment events queue.
  */
 static int
-__vcpu_on_q(const struct rt_vcpu *svc)
+vcpu_on_q(const struct rt_vcpu *svc)
 {
return !list_empty(>q_elem);
 }
 
 static struct rt_vcpu *
-__q_elem(struct list_head *elem)
+q_elem(struct list_head *elem)
 {
 return list_entry(elem, struct rt_vcpu, q_elem);
 }
@@ -303,7 +309,7 @@ rt_dump_vcpu(const struct scheduler *ops, const struct 
rt_vcpu *svc)
 svc->cur_budget,
 svc->cur_deadline,
 svc->last_start,
-__vcpu_on_q(svc),
+vcpu_on_q(svc),
 vcpu_runnable(svc->vcpu),
 svc->flags,
 keyhandler_scratch);
@@ -339,28 +345,28 @@ rt_dump(const struct scheduler *ops)
 replq = rt_replq(ops);
 
 printk("Global RunQueue info:\n");
-list_for_each( iter, runq )
+list_for_each ( iter, runq )
 {
-svc = __q_elem(iter);
+svc = q_elem(iter);
 rt_dump_vcpu(ops, svc);
 }
 
 printk("Global DepletedQueue info:\n");
-list_for_each( iter, depletedq )
+

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

[Ross Lagerwall]

On 05/11/2016 03:05 PM, Juergen Gross wrote:

On 11/05/16 15:07, Arnd Bergmann wrote:

A bugfix patch for the xen balloon driver introduced a forward
declaration for a static function that is conditionally compiled,
causing a warning if only the declaration but not the definition
are there:

drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
'static' but never defined [-Werror=unused-function]
  static void release_memory_resource(struct resource *resource);

This removes the declaration again and instead moves the function
definition to the right place, before its first caller and inside
of the #ifdef protecting both.

The patch that introduced the warning is marked for stable
backports, so if that gets applied to 4.4, so should this one.

Signed-off-by: Arnd Bergmann 
Fixes: dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE")
Cc: sta...@vger.kernel.org


So you've CC'ed Ross, who sent the very same patch just yesterday, but
without the backport request.



Well it wasn't clear to me whether it should be the maintainer or the 
patch submitter who should request the backport and 
Documentation/SubmittingPatches is not clear about it. Regardless, the 
build fix should be backported to 4.4.


--
Ross Lagerwall

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

[Xen-devel] Please reconsider bug 26

[Sébastien Chaumat]

Hello,

  http://bugs.xenproject.org/xen/bug/26 is nearly 3yrs old.

(bassically one can attach the same vbd rw to 2 domUs with xl without
warning )

 Combined with a distribution behavior  like

https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1572446

 (a trailing domu.cfg~ backup file will be blindly used to launch twice a
domU config with only the name changed)

 leads to real fun  (namely filesystem corruption)

 Recalling early discussion here about xen philosophy, isolation  accross
domUs should be the default. Clearly xl does not provide vbd isolation by
default.

 Would you mind considering implementing vbd usage detection in xl ?

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

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

[Olaf Hering]

On Wed, May 11, George Dunlap wrote:

> At the moment, the xendomains init script will only create a lockfile
> if when started, it actually does something -- either tries to restore
> a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> to create a domain as a result of XENDOMAINS_AUTO.
> 
> RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
> on systems which actually have an actively running component; and they
> use the existence of /var/lock/subsys/${SERVICE} to determine which
> systems are running.
> 
> This means that at the moment, on RedHat-based SYSV systems (such as
> CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
> to "true", but don't happen to start a VM, then your running VMs will
> not be suspended on shutdown.
> 
> Since the lockfile doesn't really have any other effect than to
> prevent duplicate starting, just create it unconditionally every time
> we start the xendomains script.

Acked-by: Olaf Hering 

Olaf

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

Re: [Xen-devel] [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems

[Olaf Hering]

On Wed, May 11, George Dunlap wrote:

> Commit c996572 changed the LOCKFILE path from a check between two
> hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
> XEN_LOCK_DIR variable designated at configure time.  Since
> XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this
> effectively moves all the lock files by default to /var/lock instead.
> 
> Unfortunately, this breaks xendomains on RedHat-based SYSV init
> systems.  RedHat-based SYSV init systems try to only call "${SERVICE}
> shutdown" on systems which actually have an actively running
> component; and they use the existence of /var/lock/subsys/${SERVICE}
> to determine which systems are running.
> 
> Changing XEN_LOCK_DIR to /var/lock/subsys is not suitable, as only
> system services like xendomains should create lockfiles there; other
> locks (such as the console locks) should be created in /var/lock
> instead.
> 
> Instead, re-instate the check for the subsys/ subdirectory of the lock
> directory in the xendomains script.

Acked-by: Olaf Hering 

Olaf

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

Re: [Xen-devel] [PATCH] xsplice: Unmask (aka reinstall NMI handler) if we need to abort.

[Andrew Cooper]

On 11/05/16 14:59, Konrad Rzeszutek Wilk wrote:
> If we have to abort in xsplice_spin() we end following
> the goto abort. But unfortunataly we neglected to unmask.
> This patch fixes that.
>
> Reported-by: Martin Pohlack 
> Signed-off-by: Konrad Rzeszutek Wilk 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

[Wei Liu]

On Wed, May 11, 2016 at 12:14:45PM +0100, George Dunlap wrote:
> At the moment, the xendomains init script will only create a lockfile
> if when started, it actually does something -- either tries to restore
> a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> to create a domain as a result of XENDOMAINS_AUTO.
> 
> RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
> on systems which actually have an actively running component; and they
> use the existence of /var/lock/subsys/${SERVICE} to determine which
> systems are running.
> 
> This means that at the moment, on RedHat-based SYSV systems (such as
> CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
> to "true", but don't happen to start a VM, then your running VMs will
> not be suspended on shutdown.
> 
> Since the lockfile doesn't really have any other effect than to
> prevent duplicate starting, just create it unconditionally every time
> we start the xendomains script.
> 
> The other option would have been to touch the lockfile if
> XENDOMAINS_RESTORE was true regardless of whether there were any
> domains to be restored.  But this would mean that if you started with
> the xendomains script active but XENDOMAINS_RESTORE set to "false",
> and then changed it to "true", then xendomains would still not run the
> next time you shut down.  This seems to me to violate the principle of
> least surprise.
> 
> Signed-off-by: George Dunlap 

Acked-by: Wei Liu 

> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Olaf Hering 
> ---
>  tools/hotplug/Linux/xendomains.in | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/xendomains.in 
> b/tools/hotplug/Linux/xendomains.in
> index 727cd42..334d244 100644
> --- a/tools/hotplug/Linux/xendomains.in
> +++ b/tools/hotplug/Linux/xendomains.in
> @@ -255,12 +255,13 @@ start()
>   return;
>  fi
>  
> +mkdir -p $(dirname "$LOCKFILE")
> +touch $LOCKFILE
> +
>  saved_domains=" "
>  if [ "$XENDOMAINS_RESTORE" = "true" ] &&
> contains_something "$XENDOMAINS_SAVE"
>  then
> - mkdir -p $(dirname "$LOCKFILE")
> - touch $LOCKFILE
>   echo -n "Restoring Xen domains:"
>   saved_domains=`ls $XENDOMAINS_SAVE`
>  for dom in $XENDOMAINS_SAVE/*; do
> @@ -286,7 +287,6 @@ start()
>  
>  if contains_something "$XENDOMAINS_AUTO"
>  then
> - touch $LOCKFILE
>   echo -n "Starting auto Xen domains:"
>   # We expect config scripts for auto starting domains to be in
>   # XENDOMAINS_AUTO - they could just be symlinks to files elsewhere
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

[Wei Liu]

On Wed, May 11, 2016 at 12:19:45PM +0100, George Dunlap wrote:
> On 11/05/16 12:14, George Dunlap wrote:
> > At the moment, the xendomains init script will only create a lockfile
> > if when started, it actually does something -- either tries to restore
> > a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> > to create a domain as a result of XENDOMAINS_AUTO.
> > 
> > RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
> > on systems which actually have an actively running component; and they
> > use the existence of /var/lock/subsys/${SERVICE} to determine which
> > systems are running.
> > 
> > This means that at the moment, on RedHat-based SYSV systems (such as
> > CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
> > to "true", but don't happen to start a VM, then your running VMs will
> > not be suspended on shutdown.
> > 
> > Since the lockfile doesn't really have any other effect than to
> > prevent duplicate starting, just create it unconditionally every time
> > we start the xendomains script.
> > 
> > The other option would have been to touch the lockfile if
> > XENDOMAINS_RESTORE was true regardless of whether there were any
> > domains to be restored.  But this would mean that if you started with
> > the xendomains script active but XENDOMAINS_RESTORE set to "false",
> > and then changed it to "true", then xendomains would still not run the
> > next time you shut down.  This seems to me to violate the principle of
> > least surprise.
> > 
> > Signed-off-by: George Dunlap 
> > ---
> > CC: Ian Jackson 
> > CC: Wei Liu 
> > CC: Olaf Hering 
> 
> Forgot the release justification.
> 
> This is a bug in xendomains under RHEL sysv init systems -- albeit one
> that's been there from the beginning.  Creating the lockfile
> unconditionally shouldn't cause any problems as far as I can tell.
> 

I agree.

Release-acked-by: Wei Liu 

I've queued this series.

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

Re: [Xen-devel] [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems

[Wei Liu]

On Wed, May 11, 2016 at 12:14:44PM +0100, George Dunlap wrote:
> Commit c996572 changed the LOCKFILE path from a check between two
> hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
> XEN_LOCK_DIR variable designated at configure time.  Since
> XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this
> effectively moves all the lock files by default to /var/lock instead.
> 
> Unfortunately, this breaks xendomains on RedHat-based SYSV init
> systems.  RedHat-based SYSV init systems try to only call "${SERVICE}
> shutdown" on systems which actually have an actively running
> component; and they use the existence of /var/lock/subsys/${SERVICE}
> to determine which systems are running.
> 
> Changing XEN_LOCK_DIR to /var/lock/subsys is not suitable, as only
> system services like xendomains should create lockfiles there; other
> locks (such as the console locks) should be created in /var/lock
> instead.
> 
> Instead, re-instate the check for the subsys/ subdirectory of the lock
> directory in the xendomains script.
> 
> Signed-off-by: George Dunlap 

Acked-by: Wei Liu 

> ---
> 
> Release justification: This is a regression in functionality (although
> it's been there for the entire 4.6 cycle now).
> 
> 
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Olaf Hering 
> ---
>  tools/hotplug/Linux/xendomains.in | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/hotplug/Linux/xendomains.in 
> b/tools/hotplug/Linux/xendomains.in
> index 9f88649..727cd42 100644
> --- a/tools/hotplug/Linux/xendomains.in
> +++ b/tools/hotplug/Linux/xendomains.in
> @@ -49,7 +49,13 @@ if [ ! -e /dev/xen/privcmd ] && [ ! -e /proc/xen/privcmd 
> ]; then
>   exit 0
>  fi
>  
> -LOCKFILE=${XEN_LOCK_DIR}/xendomains
> +# RHEL-based systems only shutdown a service if they find a lockfile
> +# in /var/lock/subsys
> +if [[ -d ${XEN_LOCK_DIR}/subsys ]] ; then
> +LOCKFILE=${XEN_LOCK_DIR}/subsys/xendomains
> +else
> +LOCKFILE=${XEN_LOCK_DIR}/xendomains
> +fi
>  
>  XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
>  
> -- 
> 2.1.4
> 

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

Re: [Xen-devel] [PATCH] xen: remove incorrect forward declaration

[Juergen Gross]

On 11/05/16 15:07, Arnd Bergmann wrote:
> A bugfix patch for the xen balloon driver introduced a forward
> declaration for a static function that is conditionally compiled,
> causing a warning if only the declaration but not the definition
> are there:
> 
> drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
> 'static' but never defined [-Werror=unused-function]
>  static void release_memory_resource(struct resource *resource);
> 
> This removes the declaration again and instead moves the function
> definition to the right place, before its first caller and inside
> of the #ifdef protecting both.
> 
> The patch that introduced the warning is marked for stable
> backports, so if that gets applied to 4.4, so should this one.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit 
> PAE")
> Cc: sta...@vger.kernel.org

So you've CC'ed Ross, who sent the very same patch just yesterday, but
without the backport request.

Confused,

Juergen

> ---
>  drivers/xen/balloon.c | 28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> index d46839f51e73..e4db19e88ab1 100644
> --- a/drivers/xen/balloon.c
> +++ b/drivers/xen/balloon.c
> @@ -151,8 +151,6 @@ static DECLARE_WAIT_QUEUE_HEAD(balloon_wq);
>  static void balloon_process(struct work_struct *work);
>  static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
>  
> -static void release_memory_resource(struct resource *resource);
> -
>  /* When ballooning out (allocating memory to return to Xen) we don't really
> want the kernel to try too hard since that can trigger the oom killer. */
>  #define GFP_BALLOON \
> @@ -248,6 +246,19 @@ static enum bp_state update_schedule(enum bp_state state)
>  }
>  
>  #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
> +static void release_memory_resource(struct resource *resource)
> +{
> + if (!resource)
> + return;
> +
> + /*
> +  * No need to reset region to identity mapped since we now
> +  * know that no I/O can be in this region
> +  */
> + release_resource(resource);
> + kfree(resource);
> +}
> +
>  static struct resource *additional_memory_resource(phys_addr_t size)
>  {
>   struct resource *res;
> @@ -286,19 +297,6 @@ static struct resource 
> *additional_memory_resource(phys_addr_t size)
>   return res;
>  }
>  
> -static void release_memory_resource(struct resource *resource)
> -{
> - if (!resource)
> - return;
> -
> - /*
> -  * No need to reset region to identity mapped since we now
> -  * know that no I/O can be in this region
> -  */
> - release_resource(resource);
> - kfree(resource);
> -}
> -
>  static enum bp_state reserve_additional_memory(void)
>  {
>   long credit;
> 


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

Re: [Xen-devel] [PATCH] xsplice: Unmask (aka reinstall NMI handler) if we need to abort.

[Wei Liu]

On Wed, May 11, 2016 at 09:59:08AM -0400, Konrad Rzeszutek Wilk wrote:
> If we have to abort in xsplice_spin() we end following
> the goto abort. But unfortunataly we neglected to unmask.
> This patch fixes that.
> 
> Reported-by: Martin Pohlack 
> Signed-off-by: Konrad Rzeszutek Wilk 
> 

Reviewed-by: Wei Liu 
Release-acked-by: Wei Liu 

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

Re: [Xen-devel] [REVERT] blktap2: Use RING_COPY_REQUEST

[Konrad Rzeszutek Wilk]

On Wed, May 11, 2016 at 02:44:19PM +0100, Wei Liu wrote:
> On Wed, May 11, 2016 at 04:00:39AM -0600, Jan Beulich wrote:
> > >>> On 02.05.16 at 12:16,  wrote:
> > > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
> > >> Short of getting any feedback on the previous discussion item
> > >> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html
> > >>  
> > >> here's a formal revert request: Please revert commit 19f6c522a6
> > >> from the staging tree (afaict it didn't get mirrored to any of the
> > >> stable trees yet), as the changes it does are not necessary and
> > >> possibly misleading.
> > > 
> > > FWIW your analysis in the other thread makes sense to me. There doesn't
> > > seem to be interaction between untrusted frontend and backend.
> > 
> > Since there was no further follow-up: Can the above be taken as
> > an ack (and a release ack for one)?
> > 
> 
> Doesn't this need an ack from member(s) of the security team before it
> can be committed? It is related to an XSA after all.
> 
> I don't have clear idea how to proceed in this case TBH. In any case:
> 
> Acked-by: Wei Liu 
> 
> And subject to an ack from security team member:
> 
> Release-acked-by: Wei Liu 


Acked-by: Konrad Rzeszutek Wilk 
> 
> Wei.
> 
> > Jan
> > 

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

[Xen-devel] [PATCH] xsplice: Unmask (aka reinstall NMI handler) if we need to abort.

[Konrad Rzeszutek Wilk]

If we have to abort in xsplice_spin() we end following
the goto abort. But unfortunataly we neglected to unmask.
This patch fixes that.

Reported-by: Martin Pohlack 
Signed-off-by: Konrad Rzeszutek Wilk 

---
Cc: jbeul...@suse.com
Cc: 

This has been since v6 posting. v5 posting used the
set_nmi_callback and only used it around the IRQ semaphore.
---
 xen/common/xsplice.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 21b9ec0..b68875b 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -1262,9 +1262,10 @@ void check_for_xsplice_work(void)
 arch_xsplice_post_action();
 local_irq_restore(flags);
 }
-arch_xsplice_unmask();
 
  abort:
+arch_xsplice_unmask();
+
 per_cpu(work_to_do, cpu) = 0;
 xsplice_work.do_work = 0;
 
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

[Konrad Rzeszutek Wilk]

On Wed, May 11, 2016 at 11:51:53AM +0200, Martin Pohlack wrote:
> On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote:
> [...]
> > +/* "Mask" NMIs. */
> > +arch_xsplice_mask();
> 
> You mask here ...
> 
> > +barrier(); /* MUST do it after get_cpu_maps. */
> > +cpus = num_online_cpus() - 1;
> > +
> > +if ( cpus )
> > +{
> > +dprintk(XENLOG_DEBUG, XSPLICE "%s: CPU%u - IPIing the other %u 
> > CPUs\n",
> > +p->name, cpu, cpus);
> > +smp_call_function(reschedule_fn, NULL, 0);
> > +}
> > +
> > +timeout = xsplice_work.timeout + NOW();
> > +if ( xsplice_spin(_work.semaphore, timeout, cpus, "CPU") )
> > +goto abort;
> 
> ... and potentially abort here, but the abort path does not unmask, so
> you lose the NMI handler.

Ouch! Sending a patch shortly out! Thanks for spotting that

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

Re: [Xen-devel] potential problem with qdisk backend

[Juergen Gross]

On 06/05/16 13:41, Juergen Gross wrote:
> Looking at the qdisk backend implementation I wondered whether
> blkif_get_x86_32_req() is really correct, especially for the
> BLKIF_OP_DISCARD case. The Linux kernel based blk backend seems to
> distinguish 32- and 64-bit layouts of blkif_request_discard while
> qemu treats them to be the same.
> 
> Am I completely wrong here?

Adding some maintainers.


Juergen


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

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 44405: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44405 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44405/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44383
 build-armhf   3 host-install(3) broken REGR. vs. 44383
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44383
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
44383

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu14a60f98e0cd16e2636afb136129ed7f11cbfce0
baseline version:
 qemuu62936f64308aae81530b1273ad2c248b6476e62e

Last test of basis44383  2016-05-04 04:20:35 Z7 days
Testing same since44405  2016-05-11 08:00:51 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Stefano Stabellini 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  blocked 
 test-amd64-i386-xl-xsm   pass
 

[Xen-devel] panic("queue invalidate wait descriptor was not executed\n")

[Zytaruk, Kelly]

During Xen boot I am seeing the panic in the subject line from 
.../xen/drivers/passthrough/vgt/qinval.c

From the Fault Status Register (= 0x40 (ITE)). I am seeing a hardware timeout 
on the invalidate

Disabling queued invalidation is not an option.  I need to find out why the 
operation is timing out and fix it.  

I found two timeouts; one in software and one in hardware. 
After the invalidate is submitted there is a wait packet submitted and the boot 
software waits for the wait packet to complete in a loop with a software 
timeout.  At the end of the software timeout it issues the panic.  I can 
increase the software timeout but it still doesn't solve the problem.  Just 
before the panic I dump the value of the Fault Status Register and I see that 
the hardware has already timed out (FSTS_REG = 0x40 = ITE = "Invalidation 
Timeout Error").  As a first step in solving this I would like to increase the 
hardware timeout value.

I have the Intel spec and I was reading from the spec...

" Hardware starts an invalidation completion timer for this ITag, and issues 
the invalidation request message to the specified endpoint. If the invalidation 
command from software is for a first-level mapping, the invalidation request 
message is generated with the appropriate PASID prefix to identify the target 
PASID. The invalidation completion time-out value is recommended to be 
sufficiently larger than the PCI-Express read completion time-outs. "

The above leads me to believe that there should be some way of setting the 
invalidation completion time-out value.  Unfortunately I couldn't find anything 
in the Intel spec that tells me how to set the "invalidation completion 
time-out".   Can someone point me in the right direction to setting the 
completion timer?

Thanks,
Kelly

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

Re: [Xen-devel] [REVERT] blktap2: Use RING_COPY_REQUEST

[Wei Liu]

On Wed, May 11, 2016 at 04:00:39AM -0600, Jan Beulich wrote:
> >>> On 02.05.16 at 12:16,  wrote:
> > On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
> >> Short of getting any feedback on the previous discussion item
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html 
> >> here's a formal revert request: Please revert commit 19f6c522a6
> >> from the staging tree (afaict it didn't get mirrored to any of the
> >> stable trees yet), as the changes it does are not necessary and
> >> possibly misleading.
> > 
> > FWIW your analysis in the other thread makes sense to me. There doesn't
> > seem to be interaction between untrusted frontend and backend.
> 
> Since there was no further follow-up: Can the above be taken as
> an ack (and a release ack for one)?
> 

Doesn't this need an ack from member(s) of the security team before it
can be committed? It is related to an XSA after all.

I don't have clear idea how to proceed in this case TBH. In any case:

Acked-by: Wei Liu 

And subject to an ack from security team member:

Release-acked-by: Wei Liu 

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Shannon Zhao]

On 2016年05月11日 20:27, Matt Fleming wrote:
> On Fri, 06 May, at 04:32:06PM, Shannon Zhao wrote:
>> > From: Shannon Zhao 
>> > 
>> > Add a new function to parse DT parameters for Xen specific UEFI just
>> > like the way for normal UEFI. Then it could reuse the existing codes.
>> > 
>> > If Xen supports EFI, initialize runtime services.
>  
> This commit log would benefit from a little expansion. I'd like to see
> information that answers the following questions,
> 
>  - How do the Xen DT paramters differ from bare metal?
>  - What existing code is reused with your patch?
>  - How are Xen runtime services different from bare metal?
>  - Why is it OK to force enable EFI runtime services for Xen?
> 
> I think it would also be good to explicitly state that we do not
> expect to find both Xen EFI DT parameters and bare metal EFI DT
> parameters when performing the search; the two should be mutually
> exclusive.
> 
>> > CC: Matt Fleming 
>> > Signed-off-by: Shannon Zhao 
>> > ---
>> > Drop using of EFI_PARAVIRT. Discussion can be found from [1].
>> > [1] https://lkml.org/lkml/2016/4/29/8
>> > ---
>> >  arch/arm/include/asm/efi.h |  2 +
>> >  arch/arm/xen/enlighten.c   | 16 
>> >  arch/arm64/include/asm/efi.h   |  2 +
>> >  drivers/firmware/efi/arm-runtime.c | 70 +++-
>> >  drivers/firmware/efi/efi.c | 81 
>> > ++
>> >  5 files changed, 137 insertions(+), 34 deletions(-)
>> > 
>> > diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
>> > index e0eea72..5ba4343 100644
>> > --- a/arch/arm/include/asm/efi.h
>> > +++ b/arch/arm/include/asm/efi.h
>> > @@ -52,9 +52,11 @@ static inline void efi_set_pgd(struct mm_struct *mm)
>> >  
>> >  void efi_virtmap_load(void);
>> >  void efi_virtmap_unload(void);
>> > +int xen_arm_enable_runtime_services(void);
>> >  
>> >  #else
>> >  #define efi_init()
>> > +#define xen_arm_enable_runtime_services() (0)
>> >  #endif /* CONFIG_EFI */
>> >  
>> >  /* arch specific definitions used by the stub code */
>> > diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> > index 13e3e9f..3362870 100644
>> > --- a/arch/arm/xen/enlighten.c
>> > +++ b/arch/arm/xen/enlighten.c
>> > @@ -16,6 +16,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >  #include 
>> >  #include 
>> >  #include 
>> > @@ -261,6 +262,13 @@ static int __init fdt_find_hyper_node(unsigned long 
>> > node, const char *uname,
>> >!strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
>> >hyper_node.version = s + strlen(hyper_node.prefix);
>> >  
>> > +  if (IS_ENABLED(CONFIG_XEN_EFI)) {
>> > +  /* Check if Xen supports EFI */
>> > +  if ((of_get_flat_dt_subnode_by_name(node, "uefi") > 0) &&
>> > +  !efi_runtime_disabled())
>> > +  set_bit(EFI_RUNTIME_SERVICES, );
>> > +  }
>> > +
>> >return 0;
>> >  }
>> >  
> The above comment could do with including similar information to the
> commit log as to why we want to force enable runtime services. For x86
> we have this,
> 
>*
>* When EFI_PARAVIRT is in force then we could not map runtime
>* service memory region because we do not have direct access to it.
>* However, runtime services are available through proxy functions
>* (e.g. in case of Xen dom0 EFI implementation they call special
>* hypercall which executes relevant EFI functions) and that is why
>* they are always enabled.
>*/
> 
> We need something similar here.
> 
>> > @@ -338,6 +346,7 @@ static int __init xen_guest_init(void)
>> >  {
>> >struct xen_add_to_physmap xatp;
>> >struct shared_info *shared_info_page = NULL;
>> > +  int ret;
>> >  
>> >if (!xen_domain())
>> >return 0;
>> > @@ -352,6 +361,13 @@ static int __init xen_guest_init(void)
>> >return -ENODEV;
>> >}
>> >  
>> > +  if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_BOOT) &&
>> > +  efi_enabled(EFI_RUNTIME_SERVICES)) {
>> > +  ret = xen_arm_enable_runtime_services();
>> > +  if (ret)
>> > +  return ret;
>> > +  }
>> > +
> Is it ever possible to have EFI_RUNTIME_SERVICES set but
> efi_enabled(EFI_BOOT) and IS_ENABLED(CONFIG_XEN_EFI) be false inside
> this function? If the answer is "no", I'd suggest just reducing this
> down to,
> 
>   /*
>* The fdt parsing code will have set EFI_RUNTIME_SERVICES if
>* it found Xen EFI parameters. Force enable runtime services.
>*/ 
>   if (efi_enabled(EFI_RUNTIME_SERVICES)) {
>   ret = xen_arm_enable_runtime_services();
>   if (ret)
>   return ret;
>   }
> 
> But first, see my comments below.
> 
>> > @@ -39,6 +40,33 @@ static struct mm_struct efi_mm = {
>> >.mmlist = LIST_HEAD_INIT(efi_mm.mmlist),

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Juergen Gross]

On 11/05/16 14:48, David Vrabel wrote:
> On 11/05/16 13:21, Jan Beulich wrote:
> On 11.05.16 at 12:16,  wrote:
>>> On 11/05/16 08:00, Juergen Gross wrote:
 Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>>
>>> Why don't we get the RW bits correct when making the pteval when we
>>> already have the pfn, instead trying to fix it up afterwards.
>>
>> While it looks like this would help in this specific situation, the next
>> time something is found to access the M2P early, that would need
>> another fix then. I.e. dealing with the underlying more general
>> issue would seem preferable to me.
> 
> I'm more concerned with future regression caused by changes to the
> generic x86 code to (for example) install a different early page fault
> handler.
> 
> Can we fix this specific issue in the way I suggested (avoiding the
> unnecessary m2p lookup entirely) and then discuss the merits of the page
> fault handler approach as a separate topic?

Sure.


Juergen


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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Jan Beulich]

>>> On 11.05.16 at 14:48,  wrote:
> On 11/05/16 13:21, Jan Beulich wrote:
> On 11.05.16 at 12:16,  wrote:
>>> On 11/05/16 08:00, Juergen Gross wrote:
 Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>>
>>> Why don't we get the RW bits correct when making the pteval when we
>>> already have the pfn, instead trying to fix it up afterwards.
>> 
>> While it looks like this would help in this specific situation, the next
>> time something is found to access the M2P early, that would need
>> another fix then. I.e. dealing with the underlying more general
>> issue would seem preferable to me.
> 
> I'm more concerned with future regression caused by changes to the
> generic x86 code to (for example) install a different early page fault
> handler.
> 
> Can we fix this specific issue in the way I suggested (avoiding the
> unnecessary m2p lookup entirely) and then discuss the merits of the page
> fault handler approach as a separate topic?

That's fine with me.

Jan


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

[Xen-devel] [PATCH] xen: remove incorrect forward declaration

[Arnd Bergmann]

A bugfix patch for the xen balloon driver introduced a forward
declaration for a static function that is conditionally compiled,
causing a warning if only the declaration but not the definition
are there:

drivers/xen/balloon.c:154:13: error: 'release_memory_resource' declared 
'static' but never defined [-Werror=unused-function]
 static void release_memory_resource(struct resource *resource);

This removes the declaration again and instead moves the function
definition to the right place, before its first caller and inside
of the #ifdef protecting both.

The patch that introduced the warning is marked for stable
backports, so if that gets applied to 4.4, so should this one.

Signed-off-by: Arnd Bergmann 
Fixes: dfd74a1edfab ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE")
Cc: sta...@vger.kernel.org
---
 drivers/xen/balloon.c | 28 +---
 1 file changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index d46839f51e73..e4db19e88ab1 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -151,8 +151,6 @@ static DECLARE_WAIT_QUEUE_HEAD(balloon_wq);
 static void balloon_process(struct work_struct *work);
 static DECLARE_DELAYED_WORK(balloon_worker, balloon_process);
 
-static void release_memory_resource(struct resource *resource);
-
 /* When ballooning out (allocating memory to return to Xen) we don't really
want the kernel to try too hard since that can trigger the oom killer. */
 #define GFP_BALLOON \
@@ -248,6 +246,19 @@ static enum bp_state update_schedule(enum bp_state state)
 }
 
 #ifdef CONFIG_XEN_BALLOON_MEMORY_HOTPLUG
+static void release_memory_resource(struct resource *resource)
+{
+   if (!resource)
+   return;
+
+   /*
+* No need to reset region to identity mapped since we now
+* know that no I/O can be in this region
+*/
+   release_resource(resource);
+   kfree(resource);
+}
+
 static struct resource *additional_memory_resource(phys_addr_t size)
 {
struct resource *res;
@@ -286,19 +297,6 @@ static struct resource 
*additional_memory_resource(phys_addr_t size)
return res;
 }
 
-static void release_memory_resource(struct resource *resource)
-{
-   if (!resource)
-   return;
-
-   /*
-* No need to reset region to identity mapped since we now
-* know that no I/O can be in this region
-*/
-   release_resource(resource);
-   kfree(resource);
-}
-
 static enum bp_state reserve_additional_memory(void)
 {
long credit;
-- 
2.7.0


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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Olaf Hering]

On Wed, May 11, Olaf Hering wrote:

> Migration from staging-4.4 to staging-4.6 fails in the same way. We did
> not have a 4.6 based Xen, so noone noticed until now.

And migration from staging-4.5 to staging works as well. So this leaves
staging-4.4.

Olaf

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

[Xen-devel] [xen-unstable-smoke test] 94028: tolerable all pass - PUSHED

[osstest service owner]

flight 94028 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94028/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  46ed6a814c2867260c0ebd9a7399466c801637be
baseline version:
 xen  a6abcd8f758d968f6eb4d93ab37db4388eb9df7e

Last test of basis94022  2016-05-11 08:02:05 Z0 days
Testing same since94028  2016-05-11 11:02:34 Z0 days1 attempts


People who touched revisions under test:
  Paul Durrant 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=46ed6a814c2867260c0ebd9a7399466c801637be
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
46ed6a814c2867260c0ebd9a7399466c801637be
+ branch=xen-unstable-smoke
+ revision=46ed6a814c2867260c0ebd9a7399466c801637be
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x46ed6a814c2867260c0ebd9a7399466c801637be = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' 

[Xen-devel] [xen-4.5-testing test] 93989: tolerable FAIL - PUSHED

[osstest service owner]

flight 93989 xen-4.5-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93989/

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-libvirt 14 guest-saverestore  fail in 93928 pass in 93989
 test-armhf-armhf-xl   15 guest-start/debian.repeat fail in 93928 pass in 93989
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 93928 
pass in 93989
 test-amd64-amd64-xl-qemut-winxpsp3 15 guest-localmigrate/x10 fail pass in 93928
 test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-localmigratefail pass in 93928

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail in 93928 like 92182
 test-amd64-i386-libvirt  14 guest-saverestore fail in 93928 like 92237
 test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-localmigrate fail in 93928 like 
92345
 test-armhf-armhf-xl-credit2   6 xen-boot fail   like 92182
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 92182
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 15 guest-localmigrate/x10 fail like 
92237
 test-amd64-amd64-xl-rtds  6 xen-boot fail   like 92345
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 92345
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 92345
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 92345
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 92345

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-credit2  12 migrate-support-check fail in 93928 never pass
 test-armhf-armhf-xl-credit2 13 saverestore-support-check fail in 93928 never 
pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  10 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 10 guest-start  fail never pass
 test-armhf-armhf-libvirt-raw 10 guest-start  fail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 xen  2bc9bd9483b254a80b7f83408f45aa1c6ef17ef3
baseline version:
 xen  c70ab649fcde2f0c3d750d35f5e2b77d619ba80b

Last test of basis92345  2016-04-22 10:56:14 Z   19 days
Failing since 93905  2016-05-09 11:39:53 Z2 days3 attempts
Testing same since93928  2016-05-09 20:11:22 Z1 days2 attempts


People who touched revisions under test:
  David Vrabel 
  Jan Beulich 
  Juergen Gross 
  Mike Meyer 
  Mike Meyer Mon Apr 4 15:02:59 2016 +0200 
  Olaf Hering 
  Roger Pau Monne 
  Roger Pau Monné 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvops   

[Xen-devel] [PATCH] Xen: don't warn about 2-byte wchar_t in efi

[Arnd Bergmann]

The XEN UEFI code has become available on the ARM architecture
recently, but now causes a link-time warning:

ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 
4-byte wchar_t; use of wchar_t values across objects may fail

This seems harmless, because the efi code only uses 2-byte
characters when interacting with EFI, so we don't pass on those
strings to elsewhere in the system, and we just need to
silence the warning.

It is not clear to me whether we actually need to build the file
with the -fshort-wchar flag, but if we do, then we should also
pass --no-wchar-size-warning to the linker, to avoid the warning.

Signed-off-by: Arnd Bergmann 
Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific 
UEFI runtime services")
---
 drivers/xen/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/Makefile b/drivers/xen/Makefile
index 415f2869054b..8feab810aed9 100644
--- a/drivers/xen/Makefile
+++ b/drivers/xen/Makefile
@@ -8,6 +8,7 @@ nostackp := $(call cc-option, -fno-stack-protector)
 CFLAGS_features.o  := $(nostackp)
 
 CFLAGS_efi.o   += -fshort-wchar
+LDFLAGS+= $(call ld-option, 
--no-wchar-size-warning)
 
 dom0-$(CONFIG_ARM64) += arm-device.o
 dom0-$(CONFIG_PCI) += pci.o
-- 
2.7.0


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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[David Vrabel]

On 11/05/16 13:21, Jan Beulich wrote:
 On 11.05.16 at 12:16,  wrote:
>> On 11/05/16 08:00, Juergen Gross wrote:
>>> Adding David as he removed _PAGE_IOMAP in kernel 3.18.
>>
>> Why don't we get the RW bits correct when making the pteval when we
>> already have the pfn, instead trying to fix it up afterwards.
> 
> While it looks like this would help in this specific situation, the next
> time something is found to access the M2P early, that would need
> another fix then. I.e. dealing with the underlying more general
> issue would seem preferable to me.

I'm more concerned with future regression caused by changes to the
generic x86 code to (for example) install a different early page fault
handler.

Can we fix this specific issue in the way I suggested (avoiding the
unnecessary m2p lookup entirely) and then discuss the merits of the page
fault handler approach as a separate topic?

David

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Paul Durrant]

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 11 May 2016 13:23
> To: Olaf Hering; xen-devel@lists.xen.org; Paul Durrant
> Subject: Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq
> server
> 
> On 11/05/16 13:18, Olaf Hering wrote:
> > Migrating a HVM guest from staging-4.4 to staging fails:
> >
> > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > char device redirected to /dev/pts/3 (label serial0)
> > xen: ioreq server create: Cannot allocate memory
> > qemu-system-x86_64: xen hardware virtual machine initialisation failed
> >
> > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4
> does not
> > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7
> fails to
> > configure the guest properly?
> 
> HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.  CC'ing
> Paul
> who did this work.

The problem is because the new QEMU will assume that the guest was provisioned 
with ioreq server pages. Somehow it needs to know to behave as a 'default' 
ioreq server (as qemu trad would) in which case the compatibility code in the 
hypervisor would DTRT. I guess it would be ok to just have QEMU fall back to 
the old 'default' HVM param mechanism if creation of an IOREQ server fails. The 
only other way out would be allow Xen to 'steal' the default server's pages if 
it doesn't exist.
The former obviously requires a patch to QEMU (but the compat code already 
exists as a compile-time option so it's probably a small-ish change) and the 
latter requires a patch to Xen. Which is more preferable at this stage?

  Paul

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

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Olaf Hering]

On Wed, May 11, Andrew Cooper wrote:

> On 11/05/16 13:18, Olaf Hering wrote:
> > Migrating a HVM guest from staging-4.4 to staging fails:
> >
> > # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> > char device redirected to /dev/pts/3 (label serial0)
> > xen: ioreq server create: Cannot allocate memory
> > qemu-system-x86_64: xen hardware virtual machine initialisation failed
> >
> > Looks like hvm_alloc_ioreq_gmfn finds no bit in
> > d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4 does 
> > not
> > know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7 fails to
> > configure the guest properly?
> 
> HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.  CC'ing Paul
> who did this work.

Migration from staging-4.4 to staging-4.6 fails in the same way. We did
not have a 4.6 based Xen, so noone noticed until now.

Olaf

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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Matt Fleming]

On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote:
> > +static int __init efi_remap_init(void)
> > +{
> > +   u64 mapsize;
> > +
> > +   pr_info("Remapping and enabling EFI services.\n");
> > +
> > +   mapsize = memmap.map_end - memmap.map;
> > +   memmap.map = (__force void *)ioremap_cache(memmap.phys_map,
> > +  mapsize);
> > +   if (!memmap.map) {
> > +   pr_err("Failed to remap EFI memory map\n");
> > +   return -ENOMEM;
> > +   }
> > +   memmap.map_end = memmap.map + mapsize;
> > +   efi.memmap = 
> > +
> > +   efi.systab = (__force void *)ioremap_cache(efi_system_table,
> > +  
> > sizeof(efi_system_table_t));
> > +   if (!efi.systab) {
> 
> Is there a reason why memmap.map isn't iounmap() in the error path?
> The original code didn't have it either, hence the question.

I suspect that is a bug.

In reality, if you can't access the EFI System Table because you fail
to map it I would guess you are going to crash very, very quickly
anyhow.

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

Re: [Xen-devel] [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

[Matt Fleming]

On Fri, 06 May, at 04:32:06PM, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> Add a new function to parse DT parameters for Xen specific UEFI just
> like the way for normal UEFI. Then it could reuse the existing codes.
> 
> If Xen supports EFI, initialize runtime services.
 
This commit log would benefit from a little expansion. I'd like to see
information that answers the following questions,

 - How do the Xen DT paramters differ from bare metal?
 - What existing code is reused with your patch?
 - How are Xen runtime services different from bare metal?
 - Why is it OK to force enable EFI runtime services for Xen?

I think it would also be good to explicitly state that we do not
expect to find both Xen EFI DT parameters and bare metal EFI DT
parameters when performing the search; the two should be mutually
exclusive.

> CC: Matt Fleming 
> Signed-off-by: Shannon Zhao 
> ---
> Drop using of EFI_PARAVIRT. Discussion can be found from [1].
> [1] https://lkml.org/lkml/2016/4/29/8
> ---
>  arch/arm/include/asm/efi.h |  2 +
>  arch/arm/xen/enlighten.c   | 16 
>  arch/arm64/include/asm/efi.h   |  2 +
>  drivers/firmware/efi/arm-runtime.c | 70 +++-
>  drivers/firmware/efi/efi.c | 81 
> ++
>  5 files changed, 137 insertions(+), 34 deletions(-)
> 
> diff --git a/arch/arm/include/asm/efi.h b/arch/arm/include/asm/efi.h
> index e0eea72..5ba4343 100644
> --- a/arch/arm/include/asm/efi.h
> +++ b/arch/arm/include/asm/efi.h
> @@ -52,9 +52,11 @@ static inline void efi_set_pgd(struct mm_struct *mm)
>  
>  void efi_virtmap_load(void);
>  void efi_virtmap_unload(void);
> +int xen_arm_enable_runtime_services(void);
>  
>  #else
>  #define efi_init()
> +#define xen_arm_enable_runtime_services() (0)
>  #endif /* CONFIG_EFI */
>  
>  /* arch specific definitions used by the stub code */
> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> index 13e3e9f..3362870 100644
> --- a/arch/arm/xen/enlighten.c
> +++ b/arch/arm/xen/enlighten.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -261,6 +262,13 @@ static int __init fdt_find_hyper_node(unsigned long 
> node, const char *uname,
>   !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
>   hyper_node.version = s + strlen(hyper_node.prefix);
>  
> + if (IS_ENABLED(CONFIG_XEN_EFI)) {
> + /* Check if Xen supports EFI */
> + if ((of_get_flat_dt_subnode_by_name(node, "uefi") > 0) &&
> + !efi_runtime_disabled())
> + set_bit(EFI_RUNTIME_SERVICES, );
> + }
> +
>   return 0;
>  }
>  

The above comment could do with including similar information to the
commit log as to why we want to force enable runtime services. For x86
we have this,

 *
 * When EFI_PARAVIRT is in force then we could not map runtime
 * service memory region because we do not have direct access to it.
 * However, runtime services are available through proxy functions
 * (e.g. in case of Xen dom0 EFI implementation they call special
 * hypercall which executes relevant EFI functions) and that is why
 * they are always enabled.
 */

We need something similar here.

> @@ -338,6 +346,7 @@ static int __init xen_guest_init(void)
>  {
>   struct xen_add_to_physmap xatp;
>   struct shared_info *shared_info_page = NULL;
> + int ret;
>  
>   if (!xen_domain())
>   return 0;
> @@ -352,6 +361,13 @@ static int __init xen_guest_init(void)
>   return -ENODEV;
>   }
>  
> + if (IS_ENABLED(CONFIG_XEN_EFI) && efi_enabled(EFI_BOOT) &&
> + efi_enabled(EFI_RUNTIME_SERVICES)) {
> + ret = xen_arm_enable_runtime_services();
> + if (ret)
> + return ret;
> + }
> +

Is it ever possible to have EFI_RUNTIME_SERVICES set but
efi_enabled(EFI_BOOT) and IS_ENABLED(CONFIG_XEN_EFI) be false inside
this function? If the answer is "no", I'd suggest just reducing this
down to,

/*
 * The fdt parsing code will have set EFI_RUNTIME_SERVICES if
 * it found Xen EFI parameters. Force enable runtime services.
 */ 
if (efi_enabled(EFI_RUNTIME_SERVICES)) {
ret = xen_arm_enable_runtime_services();
if (ret)
return ret;
}

But first, see my comments below.

> @@ -39,6 +40,33 @@ static struct mm_struct efi_mm = {
>   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
>  };
>  
> +static int __init efi_remap_init(void)
> +{
> + u64 mapsize;
> +
> + pr_info("Remapping and enabling EFI services.\n");
> +
> + mapsize = memmap.map_end - memmap.map;
> + memmap.map = (__force void *)ioremap_cache(memmap.phys_map,
> + 

Re: [Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Andrew Cooper]

On 11/05/16 13:18, Olaf Hering wrote:
> Migrating a HVM guest from staging-4.4 to staging fails:
>
> # cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
> char device redirected to /dev/pts/3 (label serial0)
> xen: ioreq server create: Cannot allocate memory
> qemu-system-x86_64: xen hardware virtual machine initialisation failed
>
> Looks like hvm_alloc_ioreq_gmfn finds no bit in
> d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4 does not
> know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7 fails to
> configure the guest properly?

HVM_PARAM_NR_IOREQ_SERVER_PAGES was introduced in 4.6 iirc.  CC'ing Paul
who did this work.

~Andrew

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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Jan Beulich]

>>> On 11.05.16 at 12:16,  wrote:
> On 11/05/16 08:00, Juergen Gross wrote:
>> Adding David as he removed _PAGE_IOMAP in kernel 3.18.
> 
> Why don't we get the RW bits correct when making the pteval when we
> already have the pfn, instead trying to fix it up afterwards.

While it looks like this would help in this specific situation, the next
time something is found to access the M2P early, that would need
another fix then. I.e. dealing with the underlying more general
issue would seem preferable to me.

Jan


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

[Xen-devel] live migrating hvm from 4.4 to 4.7 fails in ioreq server

[Olaf Hering]

Migrating a HVM guest from staging-4.4 to staging fails:

# cat /var/log/xen/qemu-dm-fv-x64-sles12sp1-clean--incoming.log
char device redirected to /dev/pts/3 (label serial0)
xen: ioreq server create: Cannot allocate memory
qemu-system-x86_64: xen hardware virtual machine initialisation failed

Looks like hvm_alloc_ioreq_gmfn finds no bit in
d->arch.hvm_domain.ioreq_gmfn.mask.  Is there a slim change that 4.4 does not
know about HVM_PARAM_NR_IOREQ_SERVER_PAGES, and as a result 4.7 fails to
configure the guest properly?

domU.cfg looks like this:

name="x"
memory=256
serial="pty"
builder="hvm"
boot="cd"
disk=[
'file:/disk0.raw,hda,w',
'file:/some.iso,hdc:cdrom,r',
]
vif=[
'bridge=br0'
]
keymap="de"
vfb = [
'type=vnc,vncunused=1,keymap=de'
]
usb=1
usbdevice='tablet'


Olaf

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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Jan Beulich]

>>> On 11.05.16 at 12:10,  wrote:
> On 11/05/16 12:03, Jan Beulich wrote:
> On 11.05.16 at 11:57,  wrote:
>>> On 11/05/16 09:15, Jan Beulich wrote:
>>> On 11.05.16 at 09:00,  wrote:
> Having a Xen specific pte flag seems to be much more intrusive than
> having an early boot page fault handler consisting of just one line
> being capable to mimic the default handler in just one aspect (see
> attached patch - only compile tested).

 Well, this simple handler may serve the purpose here, but what's
 the effect of having it in place on actual #PF (resulting e.g. from
 a bug somewhere)? I.e. what diagnostic information will be
 available to the developer in that case, now that the hypervisor
 won't help out anymore?
>>>
>>> Good point. As fixup_exception() is returning 0 in this case we can
>>> set the #PF handler to NULL again and retry the failing instruction.
>>> This will then lead to the same hypervisor handled case as today.
>> 
>> And how would you mean to set the #PF handler to this tiny one
>> again for the next M2P access? You simply can't have both, I'm afraid.
> 
> Why would I need another #PF handler after a crash? I meant something
> like:
> 
> +dotraplinkage void notrace
> +xen_do_page_fault(struct pt_regs *regs, unsigned long error_code)
> +{
> +   if (!fixup_exception(regs, X86_TRAP_PF))
> +   set_intr_gate_notrace(X86_TRAP_PF, NULL);
> +}

Ah, right, that should work (albeit looks a bit, well, odd).

Jan


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

Re: [Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

[George Dunlap]

On 11/05/16 12:14, George Dunlap wrote:
> At the moment, the xendomains init script will only create a lockfile
> if when started, it actually does something -- either tries to restore
> a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
> to create a domain as a result of XENDOMAINS_AUTO.
> 
> RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
> on systems which actually have an actively running component; and they
> use the existence of /var/lock/subsys/${SERVICE} to determine which
> systems are running.
> 
> This means that at the moment, on RedHat-based SYSV systems (such as
> CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
> to "true", but don't happen to start a VM, then your running VMs will
> not be suspended on shutdown.
> 
> Since the lockfile doesn't really have any other effect than to
> prevent duplicate starting, just create it unconditionally every time
> we start the xendomains script.
> 
> The other option would have been to touch the lockfile if
> XENDOMAINS_RESTORE was true regardless of whether there were any
> domains to be restored.  But this would mean that if you started with
> the xendomains script active but XENDOMAINS_RESTORE set to "false",
> and then changed it to "true", then xendomains would still not run the
> next time you shut down.  This seems to me to violate the principle of
> least surprise.
> 
> Signed-off-by: George Dunlap 
> ---
> CC: Ian Jackson 
> CC: Wei Liu 
> CC: Olaf Hering 

Forgot the release justification.

This is a bug in xendomains under RHEL sysv init systems -- albeit one
that's been there from the beginning.  Creating the lockfile
unconditionally shouldn't cause any problems as far as I can tell.

 -George

> ---
>  tools/hotplug/Linux/xendomains.in | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/hotplug/Linux/xendomains.in 
> b/tools/hotplug/Linux/xendomains.in
> index 727cd42..334d244 100644
> --- a/tools/hotplug/Linux/xendomains.in
> +++ b/tools/hotplug/Linux/xendomains.in
> @@ -255,12 +255,13 @@ start()
>   return;
>  fi
>  
> +mkdir -p $(dirname "$LOCKFILE")
> +touch $LOCKFILE
> +
>  saved_domains=" "
>  if [ "$XENDOMAINS_RESTORE" = "true" ] &&
> contains_something "$XENDOMAINS_SAVE"
>  then
> - mkdir -p $(dirname "$LOCKFILE")
> - touch $LOCKFILE
>   echo -n "Restoring Xen domains:"
>   saved_domains=`ls $XENDOMAINS_SAVE`
>  for dom in $XENDOMAINS_SAVE/*; do
> @@ -286,7 +287,6 @@ start()
>  
>  if contains_something "$XENDOMAINS_AUTO"
>  then
> - touch $LOCKFILE
>   echo -n "Starting auto Xen domains:"
>   # We expect config scripts for auto starting domains to be in
>   # XENDOMAINS_AUTO - they could just be symlinks to files elsewhere
> 


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

[Xen-devel] [PATCH for-4.7 2/2] tools/xendomains: Create lockfile on start unconditionally

[George Dunlap]

At the moment, the xendomains init script will only create a lockfile
if when started, it actually does something -- either tries to restore
a previously saved domain as a result of XENDOMAINS_RESTORE, or tries
to create a domain as a result of XENDOMAINS_AUTO.

RedHat-based SYSV init systems try to only call "${SERVICE} shutdown"
on systems which actually have an actively running component; and they
use the existence of /var/lock/subsys/${SERVICE} to determine which
systems are running.

This means that at the moment, on RedHat-based SYSV systems (such as
CentOS 6), if you enable xendomains, and have XENDOMAINS_RESTORE set
to "true", but don't happen to start a VM, then your running VMs will
not be suspended on shutdown.

Since the lockfile doesn't really have any other effect than to
prevent duplicate starting, just create it unconditionally every time
we start the xendomains script.

The other option would have been to touch the lockfile if
XENDOMAINS_RESTORE was true regardless of whether there were any
domains to be restored.  But this would mean that if you started with
the xendomains script active but XENDOMAINS_RESTORE set to "false",
and then changed it to "true", then xendomains would still not run the
next time you shut down.  This seems to me to violate the principle of
least surprise.

Signed-off-by: George Dunlap 
---
CC: Ian Jackson 
CC: Wei Liu 
CC: Olaf Hering 
---
 tools/hotplug/Linux/xendomains.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/hotplug/Linux/xendomains.in 
b/tools/hotplug/Linux/xendomains.in
index 727cd42..334d244 100644
--- a/tools/hotplug/Linux/xendomains.in
+++ b/tools/hotplug/Linux/xendomains.in
@@ -255,12 +255,13 @@ start()
return;
 fi
 
+mkdir -p $(dirname "$LOCKFILE")
+touch $LOCKFILE
+
 saved_domains=" "
 if [ "$XENDOMAINS_RESTORE" = "true" ] &&
contains_something "$XENDOMAINS_SAVE"
 then
-   mkdir -p $(dirname "$LOCKFILE")
-   touch $LOCKFILE
echo -n "Restoring Xen domains:"
saved_domains=`ls $XENDOMAINS_SAVE`
 for dom in $XENDOMAINS_SAVE/*; do
@@ -286,7 +287,6 @@ start()
 
 if contains_something "$XENDOMAINS_AUTO"
 then
-   touch $LOCKFILE
echo -n "Starting auto Xen domains:"
# We expect config scripts for auto starting domains to be in
# XENDOMAINS_AUTO - they could just be symlinks to files elsewhere
-- 
2.1.4


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

[Xen-devel] [PATCH for-4.7 1/2] hotplug: Fix xendomains lock path for RHEL-based systems

[George Dunlap]

Commit c996572 changed the LOCKFILE path from a check between two
hardcoded paths (/var/lock/subsys/ or /var/lock) to using the
XEN_LOCK_DIR variable designated at configure time.  Since
XEN_LOCK_DIR doesn't (and shouldn't) have the 'subsys' postfix, this
effectively moves all the lock files by default to /var/lock instead.

Unfortunately, this breaks xendomains on RedHat-based SYSV init
systems.  RedHat-based SYSV init systems try to only call "${SERVICE}
shutdown" on systems which actually have an actively running
component; and they use the existence of /var/lock/subsys/${SERVICE}
to determine which systems are running.

Changing XEN_LOCK_DIR to /var/lock/subsys is not suitable, as only
system services like xendomains should create lockfiles there; other
locks (such as the console locks) should be created in /var/lock
instead.

Instead, re-instate the check for the subsys/ subdirectory of the lock
directory in the xendomains script.

Signed-off-by: George Dunlap 
---

Release justification: This is a regression in functionality (although
it's been there for the entire 4.6 cycle now).


CC: Ian Jackson 
CC: Wei Liu 
CC: Olaf Hering 
---
 tools/hotplug/Linux/xendomains.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/tools/hotplug/Linux/xendomains.in 
b/tools/hotplug/Linux/xendomains.in
index 9f88649..727cd42 100644
--- a/tools/hotplug/Linux/xendomains.in
+++ b/tools/hotplug/Linux/xendomains.in
@@ -49,7 +49,13 @@ if [ ! -e /dev/xen/privcmd ] && [ ! -e /proc/xen/privcmd ]; 
then
exit 0
 fi
 
-LOCKFILE=${XEN_LOCK_DIR}/xendomains
+# RHEL-based systems only shutdown a service if they find a lockfile
+# in /var/lock/subsys
+if [[ -d ${XEN_LOCK_DIR}/subsys ]] ; then
+LOCKFILE=${XEN_LOCK_DIR}/subsys/xendomains
+else
+LOCKFILE=${XEN_LOCK_DIR}/xendomains
+fi
 
 XENDOM_CONFIG=@CONFIG_DIR@/@CONFIG_LEAF_DIR@/xendomains
 
-- 
2.1.4


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

[Xen-devel] Announcing Xen Project 4.7 RC and Test Day Schedule

[Lars Kurth]

Dear Community members,

Yesterday, we created Xen 4.7 RC2 and will release a new release 
candidate every Wednesday, until we declare a release candidate as the 
final candidate and cut the Xen 4.7 release. We will also hold a Test 
Day [1] every Friday for the release candidate that was released the 
Wednesday prior to the Test Day. This means we will have Test Days on 
May 13th, 20th, 27th and June 3rd. Your testing is still valuable on 
other days, so please feel free to send Test Reports as outlined below 
at any time.

= Getting, Building and Installing a Release Candidate =

Release candidates are available from our git repository at

git://xenbits.xen.org/xen.git (tag 4.7.0-)

where  is rc1, rc2, rc3, etc. and as tarball from

http://bits.xensource.com/oss-xen/release/4.7.0-/xen-4.7.0-.tar.gz 
http://bits.xensource.com/oss-xen/release/4.7.0-/xen-4.7.0-.tar.gz.sig

Detailed build and Install instructions can be found on the Test Day 
Wiki [2].

= Testing new Features, Test and Bug Reports =

You can find Test Instructions for new features on our Test Day Wiki [2] 
and instructions for general tests on Testing Xen [3]. The following 
pages provide information on how to report successful tests [4] and how 
to report bugs and issues [5].

Happy Testing!

Best Regards
Lars

[1] http://wiki.xenproject.org/wiki/Xen_Project_Test_Days
[2] http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Installing
[3] http://wiki.xenproject.org/wiki/Testing_Xen
[4] 
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Reporting_success
[5] 
http://wiki.xenproject.org/wiki/Xen_4.7_RC_test_instructions#Reporting_Bugs_.28.26_Issues.29
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [xen-unstable-coverity test] 94026: all pass - PUSHED

[osstest service owner]

flight 94026 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94026/

Perfect :-)
All tests in this flight passed
version targeted for testing:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47
baseline version:
 xen  f8c66c2ad2efdb281e4ebf15bf329d73c4f02ce7

Last test of basis93837  2016-05-08 09:18:41 Z3 days
Testing same since94026  2016-05-11 09:19:01 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Dario Faggioli 
  George Dunlap 
  Ian Jackson 
  Jan Beulich 
  Juergen Gross 
  Ross Lagerwall 
  Tim Deegan 
  Wei Liu 

jobs:
 coverity-amd64   pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-coverity
+ revision=c79fc6c4bee28b40948838a760b4aaadf6b5cd47
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push 
xen-unstable-coverity c79fc6c4bee28b40948838a760b4aaadf6b5cd47
+ branch=xen-unstable-coverity
+ revision=c79fc6c4bee28b40948838a760b4aaadf6b5cd47
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-coverity
+ qemuubranch=qemu-upstream-unstable-coverity
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-coverity
+ prevxenbranch=xen-4.6-testing
+ '[' xc79fc6c4bee28b40948838a760b4aaadf6b5cd47 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : 

Re: [Xen-devel] [PATCH v3 2/3] xen: write information about supported backends

[Anthony PERARD]

On Wed, May 11, 2016 at 10:36:28AM +0200, Juergen Gross wrote:
> On 10/05/16 18:21, Anthony PERARD wrote:
> > On Fri, May 06, 2016 at 11:42:45AM +0200, Juergen Gross wrote:
> >> -static int xen_config_dev_mkdir(char *dev, int p)
> >> -{
> >> -struct xs_permissions perms[2] = {{
> >> -.id= 0, /* set owner: dom0 */
> >> -},{
> >> -.id= xen_domid,
> >> -.perms = p,
> >> -}};
> >> -
> > 
> > The function looks like it as been tailored to mkdir for config of
> > backends. So it does not seems out of place.
> 
> It has been tailored for config of _devices_ by the backend.
> 
> I still think it would fit better now into xen_backend.c, OTOH in case
> you like it better in xen_devconfig.c I won't argue against it.

I guess the function looks generic enough. So I'm now fine with moving it
to xen_backend.c.

-- 
Anthony PERARD

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

Re: [Xen-devel] [PATCH v3 3/3] xen: add pvUSB backend

[Anthony PERARD]

On Fri, May 06, 2016 at 11:42:46AM +0200, Juergen Gross wrote:
> Add a backend for para-virtualized USB devices for xen domains.
> 
> The backend is using host-libusb to forward USB requests from a
> domain via libusb to the real device(s) passed through.
> 
> Signed-off-by: Juergen Gross 

Acked-by: Anthony PERARD 

Thanks,

-- 
Anthony PERARD

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

[Xen-devel] [xen-unstable-smoke test] 94022: tolerable all pass - PUSHED

[osstest service owner]

flight 94022 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94022/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  a6abcd8f758d968f6eb4d93ab37db4388eb9df7e
baseline version:
 xen  c79fc6c4bee28b40948838a760b4aaadf6b5cd47

Last test of basis94004  2016-05-10 21:02:07 Z0 days
Testing same since94022  2016-05-11 08:02:05 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=a6abcd8f758d968f6eb4d93ab37db4388eb9df7e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke 
a6abcd8f758d968f6eb4d93ab37db4388eb9df7e
+ branch=xen-unstable-smoke
+ revision=a6abcd8f758d968f6eb4d93ab37db4388eb9df7e
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' xa6abcd8f758d968f6eb4d93ab37db4388eb9df7e = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[David Vrabel]

On 11/05/16 08:00, Juergen Gross wrote:
> On 11/05/16 08:35, Jan Beulich wrote:
> On 11.05.16 at 07:49,  wrote:
>>> On 10/05/16 18:35, Boris Ostrovsky wrote:
 On 05/10/2016 11:43 AM, Juergen Gross wrote:
> On 10/05/16 17:35, Jan Beulich wrote:
> On 10.05.16 at 17:19,  wrote:
>>> On 10/05/16 15:57, Jan Beulich wrote:
>>> On 10.05.16 at 15:39,  wrote:
> I didn't finish unwrapping the stack yesterday. Here it is:
>
> setup_arch -> dmi_scan_machine -> dmi_walk_early -> early_ioremap
 Ah, that makes sense. Yet why would early_ioremap() involve an
 M2P lookup? As said, MMIO addresses shouldn't be subject to such
 lookups.
>>> early_ioremap()->
>>>   __early_ioremap()->
>>> __early_set_fixmap()->
>>>   set_pte()->
>>> xen_set_pte_init()->
>>>   mask_rw_pte()->
>>> pte_pfn()->
>>>   pte_val()->
>>> xen_pte_val()->
>>>   pte_mfn_to_pfn()
>> Well, I understand (also from Boris' first reply) that's how it is,
>> but not why it is so. I.e. the call flow above doesn't answer my
>> question.
> On x86 early_ioremap() and early_memremap() share a common sub-function
> __early_ioremap(). This together with pvops requires a common set_pte()
> implementation leading to the mfn validation in the end.

 Do we make any assumptions about where DMI data lives?
>>>
>>> I don't think so.
>>>
>>> So the basic problem is the page fault due to the sparse m2p map before
>>> the #PF handler is registered.
>>>
>>> What do you think about registering a minimal #PF handler in
>>> xen_arch_setup() being capable to handle this problem? This should be
>>> doable without major problems. I can do a patch.
>>
>> To me that would feel like working around the issue instead of
>> admitting that the removal of _PAGE_IOMAP was a mistake.
> 
> Hmm, I don't think so.
> 
> Having a Xen specific pte flag seems to be much more intrusive than
> having an early boot page fault handler consisting of just one line
> being capable to mimic the default handler in just one aspect (see
> attached patch - only compile tested).
> 
> Adding David as he removed _PAGE_IOMAP in kernel 3.18.

Why don't we get the RW bits correct when making the pteval when we
already have the pfn, instead trying to fix it up afterwards.

Something like this:

diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index 478a2de..d187368 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -430,6 +430,22 @@ __visible pte_t xen_make_pte(pteval_t pte)
 }
 PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);

+__visible __init pte_t xen_make_pte_init(pteval_t pte)
+{
+   unsigned long pfn = pte_mfn(pte);
+
+#ifdef CONFIG_X86_64
+   pte = mask_rw_pte(pte);
+#endif
+   pte = pte_pfn_to_mfn(pte);
+
+   if (pte_mfn(pte) == INVALID_P2M_ENTRY)
+   pte = __pte_ma(0);
+
+   return native_make_pte(pte);
+}
+PV_CALLEE_SAVE_REGS_THUNK(xen_make_pte);
+
 __visible pgd_t xen_make_pgd(pgdval_t pgd)
 {
pgd = pte_pfn_to_mfn(pgd);
@@ -1562,7 +1578,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
pte)
return pte;
 }
 #else /* CONFIG_X86_64 */
-static pte_t __init mask_rw_pte(pte_t *ptep, pte_t pte)
+static pte_t __init mask_rw_pte(pte_t pte)
 {
unsigned long pfn;

@@ -1577,7 +1593,7 @@ static pte_t __init mask_rw_pte(pte_t *ptep, pte_t
pte)
 * page tables for mapping the p2m list, too, and page tables MUST be
 * mapped read-only.
 */
-   pfn = pte_pfn(pte);
+   pfn = pte_mfn(pte);
if (pfn >= xen_start_info->first_p2m_pfn &&
pfn < xen_start_info->first_p2m_pfn + xen_start_info->nr_p2m_frames)
pte = __pte_ma(pte_val_ma(pte) & ~_PAGE_RW);
@@ -1602,11 +1618,10 @@ static pte_t __init mask_rw_pte(pte_t *ptep,
pte_t pte)
  */
 static void __init xen_set_pte_init(pte_t *ptep, pte_t pte)
 {
+#ifdef CONFIG_X86_32
if (pte_mfn(pte) != INVALID_P2M_ENTRY)
pte = mask_rw_pte(ptep, pte);
-   else
-   pte = __pte_ma(0);
-
+#endif
native_set_pte(ptep, pte);
 }

@@ -2407,6 +2422,7 @@ static void __init xen_post_allocator_init(void)
pv_mmu_ops.alloc_pud = xen_alloc_pud;
pv_mmu_ops.release_pud = xen_release_pud;
 #endif
+   pv_mmu_ops.make_pte = xen_make_pte;

 #ifdef CONFIG_X86_64
pv_mmu_ops.write_cr3 = _write_cr3;
@@ -2455,7 +2471,7 @@ static const struct pv_mmu_ops xen_mmu_ops
__initconst = {
.pte_val = PV_CALLEE_SAVE(xen_pte_val),
.pgd_val = PV_CALLEE_SAVE(xen_pgd_val),

-   .make_pte = PV_CALLEE_SAVE(xen_make_pte),
+   .make_pte = PV_CALLEE_SAVE(xen_make_pte_init),
.make_pgd = PV_CALLEE_SAVE(xen_make_pgd),

 #ifdef CONFIG_X86_PAE


___
Xen-devel mailing list

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Juergen Gross]

On 11/05/16 12:03, Jan Beulich wrote:
 On 11.05.16 at 11:57,  wrote:
>> On 11/05/16 09:15, Jan Beulich wrote:
>> On 11.05.16 at 09:00,  wrote:
 Having a Xen specific pte flag seems to be much more intrusive than
 having an early boot page fault handler consisting of just one line
 being capable to mimic the default handler in just one aspect (see
 attached patch - only compile tested).
>>>
>>> Well, this simple handler may serve the purpose here, but what's
>>> the effect of having it in place on actual #PF (resulting e.g. from
>>> a bug somewhere)? I.e. what diagnostic information will be
>>> available to the developer in that case, now that the hypervisor
>>> won't help out anymore?
>>
>> Good point. As fixup_exception() is returning 0 in this case we can
>> set the #PF handler to NULL again and retry the failing instruction.
>> This will then lead to the same hypervisor handled case as today.
> 
> And how would you mean to set the #PF handler to this tiny one
> again for the next M2P access? You simply can't have both, I'm afraid.

Why would I need another #PF handler after a crash? I meant something
like:

+dotraplinkage void notrace
+xen_do_page_fault(struct pt_regs *regs, unsigned long error_code)
+{
+   if (!fixup_exception(regs, X86_TRAP_PF))
+   set_intr_gate_notrace(X86_TRAP_PF, NULL);
+}


Juergen

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

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

[Peng Fan]

On Wed, May 11, 2016 at 11:03:06AM +0100, Julien Grall wrote:
>
>
>On 11/05/2016 10:57, Peng Fan wrote:
>>Hi Julien,
>
>Hi Peng,
>
>>On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote:
>>>
>>>[...]
>>>
diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..bebd82f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,12 +443,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  lpae_t pte, *p;
  int i;

-/* Map the destination in the boot misc area. */
-dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
-write_pte(xen_second + second_table_offset(dest_va), pte);
-flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
-
  /* Calculate virt-to-phys offset for the new location */
  phys_offset = xen_paddr - (unsigned long) _start;

@@ -498,6 +492,11 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  /* Map the destination in the boot misc area. */
  dest_va = BOOT_RELOC_VIRT_START;
  pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
+xen_second[second_table_offset(dest_va)] = pte;
+
+/* Map the destination in the boot misc area. */
+dest_va = BOOT_RELOC_VIRT_START;
+pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
>>>
>>>Why do you need to recompute "pte" and "dest_va"? They will be the same for
>>>"boot_second" and "xen_second".
>>
>>I just change "write_pte(xen_second + second_table_offset(dest_va), pte);" to
>>"xen_second[second_table_offset(dest_va)] = pte;".
>>
>>The pte and dest_va are not changed.
>
>So you could do some like:
>
>/* Comment */
>dest_va = BOOT...
>pte = ...
>/* Comment */
>xen_second[...] = pte
>/* Comment */
>write_pte(boot_second...);

This looks better. Will use this in V2.

Thanks,
Peng.

>
>Regards,
>
>-- 
>Julien Grall

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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Jan Beulich]

>>> On 11.05.16 at 11:57,  wrote:
> On 11/05/16 09:15, Jan Beulich wrote:
> On 11.05.16 at 09:00,  wrote:
>>> Having a Xen specific pte flag seems to be much more intrusive than
>>> having an early boot page fault handler consisting of just one line
>>> being capable to mimic the default handler in just one aspect (see
>>> attached patch - only compile tested).
>> 
>> Well, this simple handler may serve the purpose here, but what's
>> the effect of having it in place on actual #PF (resulting e.g. from
>> a bug somewhere)? I.e. what diagnostic information will be
>> available to the developer in that case, now that the hypervisor
>> won't help out anymore?
> 
> Good point. As fixup_exception() is returning 0 in this case we can
> set the #PF handler to NULL again and retry the failing instruction.
> This will then lead to the same hypervisor handled case as today.

And how would you mean to set the #PF handler to this tiny one
again for the next M2P access? You simply can't have both, I'm afraid.

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

[Julien Grall]

On 11/05/2016 10:57, Peng Fan wrote:

Hi Julien,


Hi Peng,


On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote:


[...]


diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..bebd82f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,12 +443,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  lpae_t pte, *p;
  int i;

-/* Map the destination in the boot misc area. */
-dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
-write_pte(xen_second + second_table_offset(dest_va), pte);
-flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
-
  /* Calculate virt-to-phys offset for the new location */
  phys_offset = xen_paddr - (unsigned long) _start;

@@ -498,6 +492,11 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  /* Map the destination in the boot misc area. */
  dest_va = BOOT_RELOC_VIRT_START;
  pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
+xen_second[second_table_offset(dest_va)] = pte;
+
+/* Map the destination in the boot misc area. */
+dest_va = BOOT_RELOC_VIRT_START;
+pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);


Why do you need to recompute "pte" and "dest_va"? They will be the same for
"boot_second" and "xen_second".


I just change "write_pte(xen_second + second_table_offset(dest_va), pte);" to
"xen_second[second_table_offset(dest_va)] = pte;".

The pte and dest_va are not changed.


So you could do some like:

/* Comment */
dest_va = BOOT...
pte = ...
/* Comment */
xen_second[...] = pte
/* Comment */
write_pte(boot_second...);

Regards,

--
Julien Grall

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

Re: [Xen-devel] [REVERT] blktap2: Use RING_COPY_REQUEST

[Jan Beulich]

>>> On 02.05.16 at 12:16,  wrote:
> On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
>> Short of getting any feedback on the previous discussion item
>> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html 
>> here's a formal revert request: Please revert commit 19f6c522a6
>> from the staging tree (afaict it didn't get mirrored to any of the
>> stable trees yet), as the changes it does are not necessary and
>> possibly misleading.
> 
> FWIW your analysis in the other thread makes sense to me. There doesn't
> seem to be interaction between untrusted frontend and backend.

Since there was no further follow-up: Can the above be taken as
an ack (and a release ack for one)?

Jan


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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

[Juergen Gross]

On 11/05/16 09:15, Jan Beulich wrote:
 On 11.05.16 at 09:00,  wrote:
>> Having a Xen specific pte flag seems to be much more intrusive than
>> having an early boot page fault handler consisting of just one line
>> being capable to mimic the default handler in just one aspect (see
>> attached patch - only compile tested).
> 
> Well, this simple handler may serve the purpose here, but what's
> the effect of having it in place on actual #PF (resulting e.g. from
> a bug somewhere)? I.e. what diagnostic information will be
> available to the developer in that case, now that the hypervisor
> won't help out anymore?

Good point. As fixup_exception() is returning 0 in this case we can
set the #PF handler to NULL again and retry the failing instruction.
This will then lead to the same hypervisor handled case as today.


Juergen

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

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

[Peng Fan]

Hi Julien,

On Wed, May 11, 2016 at 10:31:49AM +0100, Julien Grall wrote:
>Hi Peng,
>
>I would rename the title: "xen/arm: mm: remove unnecessary tlb flush in
>setup_pagetables".

Thanks. Will fix in V2.

>
>On 11/05/2016 08:59, Peng Fan wrote:
>>Before relocating xen to high address, need to build
>>the mapping BOOT_RELOC_VIRT_START to xen_paddr into
>>boot_pgtable and xen_pgtable.
>>
>>In setup_pagetables, relocate_xen will switch the root
>>page table from boot_pgtable to xen_pgtable/cpu0_pgtable.
>>
>>Before relocate_xen:
>>If touching xen_pgtable, no need to flush_xen_data_tlb_range_va_local.
>>We only need to flush tlb when touch boot_pgtable.
>>And no need to use write_pte for xen_pgtable, we can simply use
>>"xen_second[second_table_offset(dest_va)] = pte;"
>>
>>Also move the piece code near DTB/Fixmap/XEN_VIRT_START to
>>be more easier to understand.
>
>The commit message is rather hard to understand. Can you please rework it
>say:
>  - CPU0 is using the boot pages table and xen_second is not part of them =>
>No need to flush the TLB
>  - Clean up the code (i.e the code movement)
>

Sorry for my bad english. Will refine the commit log in V2.

>However, I would prefer to see 2 patches, one for removing the tlb flush, the
>other to move the code.

Will fix in V2.

>
>[...]
>
>>diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
>>index 94ea054..bebd82f 100644
>>--- a/xen/arch/arm/mm.c
>>+++ b/xen/arch/arm/mm.c
>>@@ -443,12 +443,6 @@ void __init setup_pagetables(unsigned long 
>>boot_phys_offset, paddr_t xen_paddr)
>>  lpae_t pte, *p;
>>  int i;
>>
>>-/* Map the destination in the boot misc area. */
>>-dest_va = BOOT_RELOC_VIRT_START;
>>-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
>>-write_pte(xen_second + second_table_offset(dest_va), pte);
>>-flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
>>-
>>  /* Calculate virt-to-phys offset for the new location */
>>  phys_offset = xen_paddr - (unsigned long) _start;
>>
>>@@ -498,6 +492,11 @@ void __init setup_pagetables(unsigned long 
>>boot_phys_offset, paddr_t xen_paddr)
>>  /* Map the destination in the boot misc area. */
>>  dest_va = BOOT_RELOC_VIRT_START;
>>  pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
>>+xen_second[second_table_offset(dest_va)] = pte;
>>+
>>+/* Map the destination in the boot misc area. */
>>+dest_va = BOOT_RELOC_VIRT_START;
>>+pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
>
>Why do you need to recompute "pte" and "dest_va"? They will be the same for
>"boot_second" and "xen_second".

I just change "write_pte(xen_second + second_table_offset(dest_va), pte);" to
"xen_second[second_table_offset(dest_va)] = pte;".

The pte and dest_va are not changed.

>
>Also, I think the code is still confusing in the current state because of the
>comments "Map the destination in the boot misc area.". They need to be
>updated to differentiate xen_second vs boot_second.

Yeah. This confused me when I first read this piece code. I can update
the comments in V2.

Thanks,
Peng.

>
>>  write_pte(boot_second + second_table_offset(dest_va), pte);
>>  flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
>>  #ifdef CONFIG_ARM_64
>>
>
>Regards,
>
>-- 
>Julien Grall

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

Re: [Xen-devel] [PATCH v9 12/27] xsplice: Implement support for applying/reverting/replacing patches.

[Martin Pohlack]

On 27.04.2016 05:39, Konrad Rzeszutek Wilk wrote:
[...]
> +/* "Mask" NMIs. */
> +arch_xsplice_mask();

You mask here ...

> +barrier(); /* MUST do it after get_cpu_maps. */
> +cpus = num_online_cpus() - 1;
> +
> +if ( cpus )
> +{
> +dprintk(XENLOG_DEBUG, XSPLICE "%s: CPU%u - IPIing the other %u 
> CPUs\n",
> +p->name, cpu, cpus);
> +smp_call_function(reschedule_fn, NULL, 0);
> +}
> +
> +timeout = xsplice_work.timeout + NOW();
> +if ( xsplice_spin(_work.semaphore, timeout, cpus, "CPU") )
> +goto abort;

... and potentially abort here, but the abort path does not unmask, so
you lose the NMI handler.

> +
> +/* All CPUs are waiting, now signal to disable IRQs. */
> +atomic_set(_work.semaphore, 0);
> +/*
> + * MUST have a barrier after semaphore so that the other CPUs don't
> + * leak out of the 'Wait for all CPUs to rendezvous' loop and 
> increment
> + * 'semaphore' before we set it to zero.
> + */
> +smp_wmb();
> +xsplice_work.ready = 1;
> +
> +if ( !xsplice_spin(_work.semaphore, timeout, cpus, "IRQ") )
> +{
> +local_irq_save(flags);
> +/* Do the patching. */
> +xsplice_do_action();
> +/* Serialize and flush out the CPU via CPUID instruction (on 
> x86). */
> +arch_xsplice_post_action();
> +local_irq_restore(flags);
> +}
> +arch_xsplice_unmask();
> +
> + abort:
> +per_cpu(work_to_do, cpu) = 0;
> +xsplice_work.do_work = 0;
> +
> +/* put_cpu_maps has an barrier(). */
> +put_cpu_maps();
> +
> +printk(XENLOG_INFO XSPLICE "%s finished %s with rc=%d\n",
> +   p->name, names[xsplice_work.cmd], p->rc);
> +}
> +else
[...]

Martin
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v3 5/6] build: convert perfc{, _arrays} to Kconfig

[Jan Beulich]

>>> On 10.05.16 at 23:05,  wrote:
> Convert the 'perfc' and 'perfc_arrays' options to Kconfig as
> CONFIG_PERF_COUNTERS and CONFIG_PERF_ARRAYS to minimize code changes.

I don't understand the "to minimize code changes" part.

> @@ -12,18 +10,15 @@ lto   ?= n
>  
>  include $(XEN_ROOT)/Config.mk
>  
> -# Hardcoded configuration implications and dependencies.
> -# Do this is a neater way if it becomes unwieldy.
> -ifeq ($(perfc_arrays),y)
> -perfc := y
> -endif
> -
>  ifneq ($(origin kexec),undefined)
>  $(error "You must use 'make menuconfig' to enable/disable kexec now.")
>  endif
>  ifneq ($(origin crash_debug),undefined)
>  $(error "You must use 'make menuconfig' to enable/disable crash_debug now.")
>  endif
> +ifneq ($(origin perfc),undefined)
> +$(error "You must use 'make menuconfig' to enable/disable perfc now.")
> +endif

I'm pretty sure I've asked before: Why do you add something
here for crash_debug and perfc, but not for debug, verbose,
and frame_pointer?

> --- a/xen/arch/x86/x86_64/asm-offsets.c
> +++ b/xen/arch/x86/x86_64/asm-offsets.c
> @@ -151,7 +151,7 @@ void __dummy__(void)
>  OFFSET(TRAPBOUNCE_eip, struct trap_bounce, eip);
>  BLANK();
>  
> -#if PERF_COUNTERS
> +#if CONFIG_PERF_COUNTERS

Same here - I'm pretty sure I've already asked for this to become
#ifdef.

Jan


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

Re: [Xen-devel] [PATCH v3 2/6] build: convert crash_debug to Kconfig

[Jan Beulich]

>>> On 10.05.16 at 23:05,  wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -1,6 +1,13 @@
>  
>  menu "Debugging Options"
>  
> +config CRASH_DEBUG
> + bool "Crash Debugging Support"
> + depends on X86
> + ---help---
> +   If you want to be able to attach gdb to Xen to be able to debug
> +   Xen if it crashes then say Y.
> +
>  config DEBUG
>   bool "Developer Checks"
>   ---help---

Is this really meant to be independent of DEBUG (or EXPERT), as it's
being placed ahead of DEBUG?

Jan


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

[Xen-devel] [qemu-upstream-unstable baseline-only test] 44403: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 44403 qemu-upstream-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/44403/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 capture-logs !broken [st=!broken!]
 build-armhf-xsm   4 capture-logs !broken [st=!broken!]
 build-armhf-pvops 4 capture-logs !broken [st=!broken!]
 build-armhf   3 host-install(3) broken REGR. vs. 44360
 build-armhf-xsm   3 host-install(3) broken REGR. vs. 44360
 build-armhf-pvops 3 host-install(3) broken REGR. vs. 44360
 test-amd64-amd64-i386-pvgrub 10 guest-start   fail REGR. vs. 44360

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 44360

Tests which did not succeed, but are not blocking:
 build-armhf-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-midway1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-rtds  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-vhd   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass

version targeted for testing:
 qemuu62b3d206425c245ed0a020390a64640d40d97471
baseline version:
 qemuuae69b059498e8a563c6d64c4aa4cb95e53d76680

Last test of basis44360  2016-04-23 20:21:58 Z   17 days
Testing same since44403  2016-05-11 00:50:27 Z0 days1 attempts


People who touched revisions under test:
  Gerd Hoffmann 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopsbroken  
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm blocked 
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-xl-xsm  pass
 test-armhf-armhf-xl-xsm  blocked 
 test-amd64-i386-xl-xsm   pass
 

Re: [Xen-devel] [PATCH v3 3/6] build: convert verbose to Kconfig

[Jan Beulich]

>>> On 10.05.16 at 23:05,  wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,4 +15,11 @@ config DEBUG
> option is intended for development purposes only, and not for
> production use.
>  
> +config VERBOSE_DEBUG
> + bool "Verbose debug messages"
> + default DEBUG
> + ---help---
> +   Guest output from HYPERVISOR_console_io and hypervisor parsing
> +   ELF images (dom0) is logged in the Xen ring buffer.

The "depends on DEBUG || EXPERT" did get lost here (or, looking at
the following patch, a respective "if" framing them all).

Jan


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

Re: [Xen-devel] [PATCH] xen/arm: mm: optimize setup_pagetables

[Julien Grall]

Hi Peng,

I would rename the title: "xen/arm: mm: remove unnecessary tlb flush in 
setup_pagetables".


On 11/05/2016 08:59, Peng Fan wrote:

Before relocating xen to high address, need to build
the mapping BOOT_RELOC_VIRT_START to xen_paddr into
boot_pgtable and xen_pgtable.

In setup_pagetables, relocate_xen will switch the root
page table from boot_pgtable to xen_pgtable/cpu0_pgtable.

Before relocate_xen:
If touching xen_pgtable, no need to flush_xen_data_tlb_range_va_local.
We only need to flush tlb when touch boot_pgtable.
And no need to use write_pte for xen_pgtable, we can simply use
"xen_second[second_table_offset(dest_va)] = pte;"

Also move the piece code near DTB/Fixmap/XEN_VIRT_START to
be more easier to understand.


The commit message is rather hard to understand. Can you please rework 
it say:
  - CPU0 is using the boot pages table and xen_second is not part of 
them => No need to flush the TLB

  - Clean up the code (i.e the code movement)

However, I would prefer to see 2 patches, one for removing the tlb 
flush, the other to move the code.


[...]


diff --git a/xen/arch/arm/mm.c b/xen/arch/arm/mm.c
index 94ea054..bebd82f 100644
--- a/xen/arch/arm/mm.c
+++ b/xen/arch/arm/mm.c
@@ -443,12 +443,6 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  lpae_t pte, *p;
  int i;

-/* Map the destination in the boot misc area. */
-dest_va = BOOT_RELOC_VIRT_START;
-pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
-write_pte(xen_second + second_table_offset(dest_va), pte);
-flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
-
  /* Calculate virt-to-phys offset for the new location */
  phys_offset = xen_paddr - (unsigned long) _start;

@@ -498,6 +492,11 @@ void __init setup_pagetables(unsigned long 
boot_phys_offset, paddr_t xen_paddr)
  /* Map the destination in the boot misc area. */
  dest_va = BOOT_RELOC_VIRT_START;
  pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);
+xen_second[second_table_offset(dest_va)] = pte;
+
+/* Map the destination in the boot misc area. */
+dest_va = BOOT_RELOC_VIRT_START;
+pte = mfn_to_xen_entry(xen_paddr >> PAGE_SHIFT, WRITEALLOC);


Why do you need to recompute "pte" and "dest_va"? They will be the same 
for "boot_second" and "xen_second".


Also, I think the code is still confusing in the current state because 
of the comments "Map the destination in the boot misc area.". They need 
to be updated to differentiate xen_second vs boot_second.



  write_pte(boot_second + second_table_offset(dest_va), pte);
  flush_xen_data_tlb_range_va_local(dest_va, SECOND_SIZE);
  #ifdef CONFIG_ARM_64



Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 10/10] vt-d: propagate error up to ME phantom function mapping and unmapping

[Jan Beulich]

>>> On 11.05.16 at 10:35,  wrote:
> On May 10, 2016 5:29 PM, Jan Beulich  wrote:
>> >>> On 06.05.16 at 10:54,  wrote:
>> > @@ -1430,7 +1430,12 @@ int domain_context_mapping_one(
>> >  unmap_vtd_domain_page(context_entries);
>> >
>> >  if ( !seg )
>> > -me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
>> > +{
>> > +ret = me_wifi_quirk(domain, bus, devfn, MAP_ME_PHANTOM_FUNC);
>> > +
>> > +if ( !rc )
>> > +rc = ret;
>> > +}
>> 
>> Is there any use in calling this function if an earlier error occurred?
>> If not,
> 
> It is  no use.

With this I don't understand ...

> We may need to consider this call tree:
>$ 
> me_wifi_quirk()--domain_context_mapping_one()--domain_context_mapping()--reass
> ign_device_ownership()--...
> 
> Then, what about dropping this patch? Leave it as is,
>  or remove ' __must_check' annotation and propagate error up to the above 
> call tree only?

... this. If calling the function is pointless if an earlier error occurred,
why don't you just check rc to be zero alongside the !seg check?

Jan


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