Re: [Xen-devel] [PATCH v2 09/16] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI

[Shannon Zhao]

On 2016/1/18 22:38, Stefano Stabellini wrote:
> On Fri, 15 Jan 2016, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> When booting with ACPI, it could get the event-channel irq through
>> HVM_PARAM_CALLBACK_IRQ.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  arch/arm/xen/enlighten.c | 30 +-
>>  1 file changed, 29 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 6d90a62..4e78c49 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -29,6 +29,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include 
>>  
>> @@ -270,7 +271,34 @@ static int __init xen_guest_init(void)
>>  if (!xen_domain())
>>  return 0;
>>  
>> -xen_events_irq = irq_of_parse_and_map(xen_node, 0);
>> +if (!acpi_disabled) {
>> +#ifdef CONFIG_ACPI
> 
> I think it would be best to move the acpi specific and DT specific
> initializations out of xen_guest_init. Then at the beginning of
> xen_guest_init, call only the one that applies.  The acpi init function
> could be ifdef'ed CONFIG_ACPI. Making sure that acpi_disabled is 1 when
> !CONFIG_ACPI, we could even avoid all ifdef's from xen_guest_init.
> 
Sure, will fix. Thanks.

> The rest is good, thanks.
> 
> 
>> +struct xen_hvm_param a;
>> +int interrupt, trigger, polarity;
>> +
>> +a.domid = DOMID_SELF;
>> +a.index = HVM_PARAM_CALLBACK_IRQ;
>> +xen_events_irq = 0;
>> +if (!HYPERVISOR_hvm_op(HVMOP_get_param, )) {
>> +if ((a.value >> 56) == 3) {
>> +interrupt = a.value & 0xff;
>> +trigger = ((a.value >> 8) & 0x1)
>> +  ? ACPI_EDGE_SENSITIVE
>> +  : ACPI_LEVEL_SENSITIVE;
>> +polarity = ((a.value >> 8) & 0x2)
>> +  ? ACPI_ACTIVE_LOW
>> +  : ACPI_ACTIVE_HIGH;
>> +xen_events_irq = acpi_register_gsi(NULL,
>> +   interrupt,
>> +   trigger,
>> +   polarity);
>> +}
>> +}
>> +
>> +#endif
>> +} else {
>> +xen_events_irq = irq_of_parse_and_map(xen_node, 0);
>> +}
>> +
>>  if (!xen_events_irq) {
>>  pr_err("Xen event channel interrupt not found\n");
>>  return -ENODEV;
> 
> .
> 

-- 
Shannon


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

Re: [Xen-devel] [PATCH v2 10/16] ARM: XEN: Move xen_early_init() before efi_init()

[Shannon Zhao]

On 2016/1/18 22:59, Stefano Stabellini wrote:
> On Fri, 15 Jan 2016, Shannon Zhao wrote:
>> From: Shannon Zhao 
>>
>> Move xen_early_init() before efi_init(), then when calling efi_init()
>> could initialize Xen specific UEFI.
>>
>> Check if it runs on Xen hypervisor through the flat dts.
>>
>> Signed-off-by: Shannon Zhao 
>> ---
>>  arch/arm/xen/enlighten.c  | 56 
>> ++-
>>  arch/arm64/kernel/setup.c |  2 +-
>>  2 files changed, 42 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 4e78c49..5d0fe68 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -19,6 +19,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -52,8 +53,6 @@ struct xen_memory_region 
>> xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
>>  
>>  static __read_mostly unsigned int xen_events_irq;
>>  
>> -static __initdata struct device_node *xen_node;
>> -
>>  int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
>> unsigned long addr,
>> xen_pfn_t *gfn, int nr,
>> @@ -222,6 +221,33 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
>>  return IRQ_HANDLED;
>>  }
>>  
>> +static __initdata struct {
>> +const char *compat;
>> +const char *prefix;
>> +const char *version;
>> +bool found;
>> +} xen_node = {"xen,xen", "xen,xen-", NULL, false};
>> +
>> +static int __init fdt_find_xen_node(unsigned long node, const char *uname,
>> +int depth, void *data)
>> +{
>> +const void *s = NULL;
>> +int len;
>> +
>> +if (depth != 1 || strcmp(uname, "hypervisor") != 0)
>> +return 0;
>> +
>> +if (of_flat_dt_is_compatible(node, xen_node.compat))
>> +xen_node.found = true;
>> +
>> +s = of_get_flat_dt_prop(node, "compatible", );
>> +if (strlen(xen_node.prefix) + 3  < len &&
>> +!strncmp(xen_node.prefix, s, strlen(xen_node.prefix)))
>> +xen_node.version = s + strlen(xen_node.prefix);
>> +
>> +return 0;
>> +}
>> +
>>  /*
>>   * see Documentation/devicetree/bindings/arm/xen.txt for the
>>   * documentation of the Xen Device Tree format.
>> @@ -229,26 +255,18 @@ static irqreturn_t xen_arm_callback(int irq, void *arg)
>>  #define GRANT_TABLE_PHYSADDR 0
>>  void __init xen_early_init(void)
>>  {
>> -int len;
>> -const char *s = NULL;
>> -const char *version = NULL;
>> -const char *xen_prefix = "xen,xen-";
>> -
>> -xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
>> -if (!xen_node) {
>> +of_scan_flat_dt(fdt_find_xen_node, NULL);
>> +if (!xen_node.found) {
>>  pr_debug("No Xen support\n");
>>  return;
>>  }
>> -s = of_get_property(xen_node, "compatible", );
>> -if (strlen(xen_prefix) + 3  < len &&
>> -!strncmp(xen_prefix, s, strlen(xen_prefix)))
>> -version = s + strlen(xen_prefix);
>> -if (version == NULL) {
>> +
>> +if (xen_node.version == NULL) {
>>  pr_debug("Xen version not found\n");
>>  return;
>>  }
> 
> This is going to access data within the fdt, after it has been
> unflattened (by the unflatten_device_tree call). Is that allowed?
> 
> If that's not allowed, then you could copy the version string to
> xen_node.version, rather than just copying the pointer. Otherwise you
> could move the version check entirely within fdt_find_xen_node and
> remove the version field from xen_node.
> 
A little confused. Since here we move xen_early_init before efi_init and
before unflatten_device_tree as well, at this moment in xen_early_init
the fdt is flattened. The xen_node.version is only set in
fdt_find_xen_node and accessed in xen_early_init.

> 
>> -pr_info("Xen %s support found\n", version);
>> +pr_info("Xen %s support found\n", xen_node.version);
>>  
>>  xen_domain_type = XEN_HVM_DOMAIN;
>>  
>> @@ -296,6 +314,14 @@ static int __init xen_guest_init(void)
>>  }
>>  #endif
>>  } else {
>> +struct device_node *xen_node;
>> +
>> +xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
>> +if (!xen_node) {
>> +pr_debug("No Xen support\n");
>> +return -ENODEV;
>> +}
> 
> It makes sense to move this into a DT specific init function called from
> xen_guest_init. Also, given that at this point we know that a Xen node
> should be present, it makes sense to return EFAULT on error, instead of
> ENODEV. The error message could be changed to something like: "Xen
> support was detected before, but it has disappeared" and should be
> pr_err.
> 
OK, thanks.
> 
>>  xen_events_irq = irq_of_parse_and_map(xen_node, 0);
>>  }
>>  
>> diff --git a/arch/arm64/kernel/setup.c 

[Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Chunyan Liu]

Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
usbdev-attach and usbdev-detach.

To attach a usb device to guest through pvusb, one could follow
following example:

 #xl usbctrl-attach test_vm version=1 ports=8

 #xl usb-list test_vm
 will show the usb controllers and port usage under the domain.

 #xl usbdev-attach test_vm hostbus=1 hostaddr=2
 will find the first usable controller:port, and attach usb
 device whose busnum is 1 and devnum is 6.
 One could also specify which  and which .

 #xl usbdev-detach test_vm 0 1
 will detach USB device under controller 0 port 1.

 #xl usbctrl-detach test_vm dev_id
 will destroy the controller with specified dev_id. Dev_id
 can be traced in usb-list info.

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
changes:
* update docs to reuse documentation in xl.cfg
* remove backend patch information from usb-list

 docs/man/xl.pod.1 |  35 +
 tools/libxl/xl.h  |   5 ++
 tools/libxl/xl_cmdimpl.c  | 190 ++
 tools/libxl/xl_cmdtable.c |  25 ++
 4 files changed, 255 insertions(+)

diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 4279c7c..7e0a380 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1345,6 +1345,41 @@ List pass-through pci devices for a domain.
 
 =back
 
+=head1 USB PASS-THROUGH
+
+=over 4
+
+=item B I I
+
+Create a new USB controller in the domain specified by I,
+I describes the device to attach, using the same format
+as the B string in the domain config file. See L for
+more information.
+
+=item B I I
+
+Destroy a USB controller from the specified domain.
+B is devid of the USB controller.
+
+=item B I I
+
+Hot-plug a new pass-through USB device to the domain specified by
+I, I describes the device to attach, using
+the same format as the B string in the domain config file.
+See L for more information.
+
+=item B I 

[Xen-devel] [PATCH V13 3/5] libxl: add pvusb API

[Chunyan Liu]

Add pvusb APIs, including:
 - attach/detach (create/destroy) virtual usb controller.
 - attach/detach usb device
 - list usb controller and usb devices
 - some other helper functions

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Signed-off-by: George Dunlap 
---
changes:
* address error handlings

 tools/libxl/Makefile |2 +-
 tools/libxl/libxl.c  |   34 +-
 tools/libxl/libxl.h  |   77 ++
 tools/libxl/libxl_device.c   |   13 +-
 tools/libxl/libxl_internal.h |   22 +-
 tools/libxl/libxl_osdeps.h   |   13 +
 tools/libxl/libxl_pvusb.c| 1567 ++
 tools/libxl/libxl_types.idl  |   46 +
 tools/libxl/libxl_types_internal.idl |1 +
 tools/libxl/libxl_utils.c|   18 +
 tools/libxl/libxl_utils.h|5 +
 11 files changed, 1785 insertions(+), 13 deletions(-)
 create mode 100644 tools/libxl/libxl_pvusb.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 2abae0c..e25ffa6 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -104,7 +104,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o 
libxl_pci.o \
libxl_stream_read.o libxl_stream_write.o \
libxl_save_callout.o _libxl_save_msgs_callout.o \
libxl_qmp.o libxl_event.o libxl_fork.o \
-   libxl_dom_suspend.o $(LIBXL_OBJS-y)
+   libxl_dom_suspend.o libxl_pvusb.o $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
 
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 43d5709..920c135 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -3204,7 +3204,7 @@ void libxl__device_disk_local_initiate_detach(libxl__egc 
*egc,
 aodev->dev = device;
 aodev->callback = local_device_detach_cb;
 aodev->force = 0;
-libxl__initiate_device_remove(egc, aodev);
+libxl__initiate_device_generic_remove(egc, aodev);
 return;
 }
 
@@ -4172,8 +4172,10 @@ out:
  * libxl_device_vkb_destroy
  * libxl_device_vfb_remove
  * libxl_device_vfb_destroy
+ * libxl_device_usbctrl_remove
+ * libxl_device_usbctrl_destroy
  */
-#define DEFINE_DEVICE_REMOVE(type, removedestroy, f)\
+#define DEFINE_DEVICE_REMOVE_EXT(type, remtype, removedestroy, f)\
 int libxl_device_##type##_##removedestroy(libxl_ctx *ctx,   \
 uint32_t domid, libxl_device_##type *type,  \
 const libxl_asyncop_how *ao_how)\
@@ -4193,13 +4195,19 @@ out:
 aodev->dev = device;\
 aodev->callback = device_addrm_aocomplete;  \
 aodev->force = f;   \
-libxl__initiate_device_remove(egc, aodev);  \
+libxl__initiate_device_##remtype##_remove(egc, aodev);  \
 \
 out:\
-if (rc) return AO_CREATE_FAIL(rc);\
+if (rc) return AO_CREATE_FAIL(rc);  \
 return AO_INPROGRESS;   \
 }
 
+#define DEFINE_DEVICE_REMOVE(type, removedestroy, f) \
+DEFINE_DEVICE_REMOVE_EXT(type, generic, removedestroy, f)
+
+#define DEFINE_DEVICE_REMOVE_CUSTOM(type, removedestroy, f)  \
+DEFINE_DEVICE_REMOVE_EXT(type, type, removedestroy, f)
+
 /* Define all remove/destroy functions and undef the macro */
 
 /* disk */
@@ -4223,6 +4231,10 @@ DEFINE_DEVICE_REMOVE(vfb, destroy, 1)
 DEFINE_DEVICE_REMOVE(vtpm, remove, 0)
 DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
 
+/* usbctrl */
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, remove, 0)
+DEFINE_DEVICE_REMOVE_CUSTOM(usbctrl, destroy, 1)
+
 /* channel/console hotunplug is not implemented. There are 2 possibilities:
  * 1. add support for secondary consoles to xenconsoled
  * 2. dynamically add/remove qemu chardevs via qmp messages. */
@@ -4236,6 +4248,8 @@ DEFINE_DEVICE_REMOVE(vtpm, destroy, 1)
  * libxl_device_disk_add
  * libxl_device_nic_add
  * libxl_device_vtpm_add
+ * libxl_device_usbctrl_add
+ * libxl_device_usbdev_add
  */
 
 #define DEFINE_DEVICE_ADD(type) \
@@ -4267,6 +4281,12 @@ DEFINE_DEVICE_ADD(nic)
 /* vtpm */
 DEFINE_DEVICE_ADD(vtpm)
 
+/* usbctrl */
+DEFINE_DEVICE_ADD(usbctrl)
+
+/* usb */
+DEFINE_DEVICE_ADD(usbdev)
+
 #undef DEFINE_DEVICE_ADD
 
 
/**/
@@ -4432,7 +4452,7 @@ static int remove_device(libxl__egc *egc, libxl__ao *ao,
 aodev->dev = dev;
 aodev->action = 

[Xen-devel] [PATCH V13 2/5] libxl_utils: add internal function to read sysfs file contents

[Chunyan Liu]

Add a new function libxl_read_sysfs_file_contents to handle sysfs file
specially. It would be used in later pvusb work.

Signed-off-by: Chunyan Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl_internal.h |  4 +++
 tools/libxl/libxl_utils.c| 74 
 2 files changed, 78 insertions(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 9e94835..d1eb18f 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -4039,6 +4039,10 @@ void libxl__bitmap_copy_best_effort(libxl__gc *gc, 
libxl_bitmap *dptr,
 
 int libxl__count_physical_sockets(libxl__gc *gc, int *sockets);
 
+_hidden int libxl__read_sysfs_file_contents(libxl__gc *gc,
+const char *filename,
+void **data_r,
+int *datalen_r);
 
 #define LIBXL_QEMU_USER_PREFIX "xen-qemuuser"
 #define LIBXL_QEMU_USER_BASE   LIBXL_QEMU_USER_PREFIX"-domid"
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index e42422a..e64f301 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -396,6 +396,80 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
 return e;
 }
 
+int libxl__read_sysfs_file_contents(libxl__gc *gc, const char *filename,
+void **data_r, int *datalen_r)
+{
+FILE *f = 0;
+uint8_t *data = 0;
+int datalen = 0;
+int e;
+struct stat stab;
+ssize_t rs;
+
+f = fopen(filename, "r");
+if (!f) {
+if (errno == ENOENT) return ENOENT;
+LOGE(ERROR, "failed to open %s", filename);
+goto xe;
+}
+
+if (fstat(fileno(f), )) {
+LOGE(ERROR, "failed to fstat %s", filename);
+goto xe;
+}
+
+if (!S_ISREG(stab.st_mode)) {
+LOGE(ERROR, "%s is not a plain file", filename);
+errno = ENOTTY;
+goto xe;
+}
+
+if (stab.st_size > INT_MAX) {
+LOG(ERROR, "file %s is far too large", filename);
+errno = EFBIG;
+goto xe;
+}
+
+datalen = stab.st_size;
+
+if (stab.st_size && data_r) {
+data = libxl__malloc(gc, datalen);
+
+/* For sysfs file, datalen is always PAGE_SIZE. 'read'
+ * will return the number of bytes of the actual content,
+ * rs <= datalen is expected.
+ */
+rs = fread(data, 1, datalen, f);
+if (rs < datalen) {
+if (ferror(f)) {
+LOGE(ERROR, "failed to read %s", filename);
+goto xe;
+}
+
+datalen = rs;
+data = libxl__realloc(gc, data, datalen);
+}
+}
+
+if (fclose(f)) {
+f = 0;
+LOGE(ERROR, "failed to close %s", filename);
+goto xe;
+}
+
+if (data_r) *data_r = data;
+if (datalen_r) *datalen_r = datalen;
+
+return 0;
+
+ xe:
+e = errno;
+assert(e != ENOENT);
+if (f) fclose(f);
+return e;
+}
+
+
 #define READ_WRITE_EXACTLY(rw, zero_is_eof, constdata)\
   \
   int libxl_##rw##_exactly(libxl_ctx *ctx, int fd, \
-- 
2.1.4


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

[Xen-devel] [PATCH V13 0/5] xen pvusb toolstack work

[Chunyan Liu]

This patch series is to add pvusb toolstack work, supporting hot add|remove
USB device to|from guest and specify USB device in domain configuration file.

Changes to V12:
* update error handlings in libxl pvusb API (patch 3/5)
* adjust order of patch 4/5 and 5/5, and in 5/5, reuse documentation
  generated in 4/5.

V12:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html

V11:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html

V10:
http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html

V9:
http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html

V8:
http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html

V7:
http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html

V6:
http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html

V5:
http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html

V4:
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html

Related Discussion Threads:
http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html
http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html

  <<< pvusb work introduction >>>

1. Overview

There are two general methods for passing through individual host
devices to a guest. The first is via an emulated USB device
controller; the second is PVUSB.

Additionally, there are two ways to add USB devices to a guest: via
the config file at domain creation time, and via hot-plug while the VM
is running.

* Emulated USB

In emulated USB, the device model (qemu) presents an emulated USB
controller to the guest. The device model process then grabs control
of the device from domain 0 and and passes the USB commands between
the guest OS and the host USB device.

This method is only available to HVM domains, and is not available for
domains running with device model stubdomains.

* PVUSB

PVUSB uses a paravirtialized front-end/back-end interface, similar to
the traditional Xen PV network and disk protocols. In order to use
PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or
your USB driver domain).

2. Specifying a host USB device

QEMU qmp commands allows USB devices to be specified either by their
bus address (in the form bus.device) or their device tag (in the form
vendorid:deviceid).

Each way of specifying has its advantages:

Specifying by device tag will always get the same device,
regardless of where the device ends up in the USB bus topology.
However, if there are two identical devices, it will not allow you to
specify which one.

Specifying by bus address will always allow you to choose a
specific device, even if you have duplicates. However, the bus address
may change depending on which port you plugged the device into, and
possibly also after a reboot.

To avoid duplication of vendorid:deviceid, we'll use bus address to
specify host USB device in xl toolstack.

You can use lsusb to list the USB devices on the system:

Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0
Hub
Bus 003 Device 002: ID f617:0905
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0
Hub
Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra
Fast Media Reader
Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse

To pass through the Logitec mouse, for instance, you could specify
1.6 (remove leading zeroes).

Note: USB hubs can not be assigned to guest.

3. PVUSB toolstack

* Specify USB device in xl config file

You can just specify usb devices, like:
usbdev=['1.6']

Then it will create a USB controller automatically and attach the USB
device to the first available USB controller:port.

or, you can explicitly specify usb controllers and usb devices, like:
usbctrl=['verison=1, ports=4', 'version=2, ports=8', ]
usbdev=['1.6, controller=0, port=1']

Then it will create two USB controllers as you specified.
And if controller and port are specified in usb config, then it will
attach the USB device to that controller:port. About the controller
and port value:
Each USB controller has a index (or called devid) based on 0. The 1st
controller has index 0, the 2nd controller has index 1, ...
Under controller, each port has a port number based on 1. In above
configuration, the 1st controller will have port 1,2,3,4.

* Hot-Plug USB device

To attach a USB device, you should first create a USB controller.
e.g.
xl usb-ctrl-attach domain [version=1|2] [ports=value]
By default, it will create a USB2.0 controller with 8 ports.

Then you could attach a USB device.
e.g.
xl usb-attach domain 1.6 [controller=index port=number]
By default, it will find the 1st available controller:port to attach
the USB device.

You could view USB device status of the domain by usb-list.
e.g.
xl usb-list domain
It will list USB controllers and USB devices under each controller.

You could detach a USB device with usb-detach command.
e.g.
xl 

[Xen-devel] [PATCH V13 4/5] domcreate: support pvusb in configuration file

[Chunyan Liu]

Add code to support pvusb in domain config file. One could specify
usbctrl and usb in domain's configuration file and create domain,
then usb controllers will be created and usb device would be attached
to guest automatically.

One could specify usb controllers and usb devices in config file
like this:
usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: George Dunlap 
---
Changes:
* adjust patch order of this patch and next patch, so that
  next patch can use docs generated in this patch.

 docs/man/xl.cfg.pod.5|  84 +
 tools/libxl/libxl_create.c   |  73 +++--
 tools/libxl/libxl_device.c   |   4 ++
 tools/libxl/libxl_internal.h |   8 
 tools/libxl/xl_cmdimpl.c | 107 ++-
 5 files changed, 272 insertions(+), 4 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 8899f75..99ef9ca 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -722,6 +722,90 @@ Note this may be overridden by rdm_policy option in PCI 
device configuration.
 
 =back
 
+=item 

[Xen-devel] [PATCH V13 1/5] libxl: export some functions for pvusb use

[Chunyan Liu]

Signed-off-by: Chunyan Liu 
Signed-off-by: Simon Cao 
Reviewed-by: Wei Liu 
Acked-by: Ian Jackson 
---
 tools/libxl/libxl.c  | 5 ++---
 tools/libxl/libxl_internal.h | 3 +++
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 00d9ec4..43d5709 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2036,7 +2036,7 @@ out:
 }
 
 /* common function to get next device id */
-static int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
+int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device)
 {
 char *dompath, **l;
 unsigned int nb;
@@ -2055,8 +2055,7 @@ static int libxl__device_nextid(libxl__gc *gc, uint32_t 
domid, char *device)
 return nextid;
 }
 
-static int libxl__resolve_domid(libxl__gc *gc, const char *name,
-uint32_t *domid)
+int libxl__resolve_domid(libxl__gc *gc, const char *name, uint32_t *domid)
 {
 if (!name)
 return 0;
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 4c01a82..9e94835 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1176,6 +1176,9 @@ _hidden int libxl__init_console_from_channel(libxl__gc 
*gc,
  libxl__device_console *console,
  int dev_num,
  libxl_device_channel *channel);
+_hidden int libxl__device_nextid(libxl__gc *gc, uint32_t domid, char *device);
+_hidden int libxl__resolve_domid(libxl__gc *gc, const char *name,
+ uint32_t *domid);
 
 /*
  * For each aggregate type which can be used as an input we provide:
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v4 09/10] arm/uart: Rename dt-uart.c to arm-uart.c

[Shannon Zhao]

On 2016/1/19 16:39, Jan Beulich wrote:
 On 19.01.16 at 04:36,  wrote:
>> > 
>> > On 2016/1/18 18:40, Jan Beulich wrote:
>> > On 16.01.16 at 06:01,  wrote:
> >>> > From: Shannon Zhao 
> >>> > 
> >>> > Since we will add ACPI initialization for UART in this file later,
> >>> > rename it with a generic name.
> >>> > 
> >>> > Signed-off-by: Shannon Zhao 
> >>> > ---
> >>> > v4: split the original patch to renaming this and adding ACPI parts.
> >>> > ---
> >>> >  MAINTAINERS |   2 +-
> >>> >  xen/drivers/char/Makefile   |   2 +-
> >>> >  xen/drivers/char/arm-uart.c | 107 
> >>> > 
> >>> >  xen/drivers/char/dt-uart.c  | 107 
> >>> > 
> >>> >  4 files changed, 109 insertions(+), 109 deletions(-)
> >>> >  create mode 100644 xen/drivers/char/arm-uart.c
> >>> >  delete mode 100644 xen/drivers/char/dt-uart.c
>>> >> Looks like this really is a rename with little actual changes to
>>> >> the file, 
>> > Yes, but the only change to this file is also to change its name because
>> > it's mentioned in the file header. This intends to make that consistent.
>> > 
>> > + * xen/drivers/char/arm-uart.c
> I understand that, but without using git's ability to represent the
> rename such that the diff between the files is visible it is hard to
> tell what exactly you changed in the file.
Yes, from the git diffstat it's hard to tell the truth. I will add some
words in the commit message.

Thanks,
-- 
Shannon


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

Re: [Xen-devel] [PATCH v4 09/10] arm/uart: Rename dt-uart.c to arm-uart.c

[Jan Beulich]

>>> On 19.01.16 at 09:43,  wrote:

> 
> On 2016/1/19 16:39, Jan Beulich wrote:
> On 19.01.16 at 04:36,  wrote:
>>> > 
>>> > On 2016/1/18 18:40, Jan Beulich wrote:
>>> > On 16.01.16 at 06:01,  wrote:
>> >>> > From: Shannon Zhao 
>> >>> > 
>> >>> > Since we will add ACPI initialization for UART in this file later,
>> >>> > rename it with a generic name.
>> >>> > 
>> >>> > Signed-off-by: Shannon Zhao 
>> >>> > ---
>> >>> > v4: split the original patch to renaming this and adding ACPI 
>> >>> > parts.
>> >>> > ---
>> >>> >  MAINTAINERS |   2 +-
>> >>> >  xen/drivers/char/Makefile   |   2 +-
>> >>> >  xen/drivers/char/arm-uart.c | 107 
> 
>> >>> >  xen/drivers/char/dt-uart.c  | 107 
>> >>> > 
>> >>> >  4 files changed, 109 insertions(+), 109 deletions(-)
>> >>> >  create mode 100644 xen/drivers/char/arm-uart.c
>> >>> >  delete mode 100644 xen/drivers/char/dt-uart.c
 >> Looks like this really is a rename with little actual changes to
 >> the file, 
>>> > Yes, but the only change to this file is also to change its name because
>>> > it's mentioned in the file header. This intends to make that consistent.
>>> > 
>>> > + * xen/drivers/char/arm-uart.c
>> I understand that, but without using git's ability to represent the
>> rename such that the diff between the files is visible it is hard to
>> tell what exactly you changed in the file.
> Yes, from the git diffstat it's hard to tell the truth. I will add some
> words in the commit message.

That's not the point; the point is that if you already use git to
create the patch, you should also use the needed option to
make git represent the patch in a way the change-and-rename
gets reflected suitably. If you weren't using git to create the
patch I'd be fine with the actual change(s) just being mentioned
in the commit message.

Jan


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

Re: [Xen-devel] [PATCH v2 2/5] libxl: make GC_FREE reachable in libxl_get_scheduler()

[Dario Faggioli]

On Tue, 2016-01-19 at 00:57 -0500, Chester Lin wrote:
> Coverity CID 1343309
> 
> Make GC_FREE reachable in all cases in libxl_get_scheduler() by
> eliminating the error-path return and instead storing the error code
> in
> the returned variable.
> 
> To make this semantically consistent, change the return type of
> libxl_get_scheduler() from libxl_scheduler to int, and make a note of
> the interpretation of the return value in libxl.h.  N.B. This change
> breaks neither the API nor the ABI of libxl.
>
Not that I feel too strong about this, but I would reword this last
sentence a bit. In fact, ABI, AFAIK, we don't care. API, someone could
argue that it does actually break it, it's just the case that we don't
think it breaks it in any ways that we should care.

And maybe we should also add a note about the libxl_scheduler enum
being (and needing to continue to do so) consistent with what
xc_sched_id returns, like it's been done in another patch of this
series?

Anyway, that's all up for the tools maintainers to judge... The patch
seems to me to do what was asked during v1 review, so:

> Suggested-by: Ian Campbell 
> Signed-off-by: Chester Lin 
> 
Reviewed-by: Dario Faggioli 

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



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

Re: [Xen-devel] [PATCH V6 5/5] x86/hvm: pkeys, add pkeys support for cpuid handling

[Wei Liu]

On Tue, Jan 19, 2016 at 03:30:59PM +0800, Huaitong Han wrote:
> This patch adds pkeys support for cpuid handing.
> 
> Pkeys hardware support is CPUID.7.0.ECX[3]:PKU. software support is
> CPUID.7.0.ECX[4]:OSPKE and it reflects the support setting of CR4.PKE.
> 

I will (again) defer this to x86 maintainers.

Wei.

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

Re: [Xen-devel] [PATCH v3 4/4] x86/PV: enable the emulated PIT

[Ian Campbell]

On Mon, 2016-01-18 at 18:03 +, Andrew Cooper wrote:
> On 18/01/16 17:58, Roger Pau Monné wrote:
> > El 18/01/16 a les 11.41, Andrew Cooper ha escrit:
> > > On 18/01/16 09:44, Jan Beulich wrote:
> > > > > > > On 18.01.16 at 10:29,  wrote:
> > > > > On 18/01/2016 07:43, Jan Beulich wrote:
> > > > > > > > > On 15.01.16 at 18:45,  wrote:
> > > > > > > Changes since v2:
> > > > > > >  - Change 'if ( (a && b) || (!a && c) )' into 'if ( a ? b : c
> > > > > > > )'.
> > > > > > Thanks, but after some more thinking about it I'm afraid there
> > > > > > are
> > > > > > a few more aspects to consider here:
> > > > > > 
> > > > > > > --- a/xen/arch/x86/domain.c
> > > > > > > +++ b/xen/arch/x86/domain.c
> > > > > > > @@ -542,8 +542,9 @@ int arch_domain_create(struct domain *d,
> > > > > > > unsigned int 
> > > > > domcr_flags,
> > > > > > > d->domain_id, config->emulation_flags);
> > > > > > >  return -EINVAL;
> > > > > > >  }
> > > > > > > -if ( config->emulation_flags != 0 &&
> > > > > > > - (!is_hvm_domain(d) || config->emulation_flags
> > > > > > > != XEN_X86_EMU_ALL) 
> > > > > )
> > > > > > > +if ( is_hvm_domain(d) ? (config->emulation_flags !=
> > > > > > > XEN_X86_EMU_ALL &&
> > > > > > > + config->emulation_flags != 0) :
> > > > > > > + (config->emulation_flags != XEN_X86_EMU_PIT) )
> > > > > > >  {
> > > > > > For one I think it would be a good idea to allow zero for PV
> > > > > > domains,
> > > > > > and perhaps even default new DomU-s to have the PIT flag clear.
> > > > > > (Also - indentation.)
> > > > > > 
> > > > > > Which gets us to the second, broader issue: These flags
> > > > > > shouldn't
> > > > > > be forced to a particular value during migration, but instead
> > > > > > they
> > > > > > should be part of the state getting migrated. Incoming domains
> > > > > > then would - if the field is missing due to coming from an
> > > > > > older
> > > > > > hypervisor - have the flag default to 1.
> > > > > There is sadly another ratsnest here.
> > > > I've been afraid of that.
> > > > 
> > > > > These values are needed for domain creation, which means that
> > > > > putting
> > > > > them anywhere in the migration stream is already too late, as the
> > > > > domain
> > > > > has been created before the stream header is read.
> > > > Is that an inherent requirement, or just a result of current code
> > > > structure?
> > > Depends.  As far as libxc/libxl migration levels go, current code
> > > structure.
> > > 
> > > Whatever (eventually) gets used to set these values will however be
> > > present in the xl configuration, which is at the very start of the
> > > stream, and is what is used to create the new domain.
> > > 
> > > We really don't want the libxc migrate code to be making the
> > > DOMCTL_createdomain hypercall itself; it opens up a whole new attack
> > > surface via cunningly-crafted save image.  The best we can do is have
> > > a
> > > sanity check later on.
> > > 
> > > >  I ask because migrating the emulation flags is going to
> > > > be a requirement for relaxing the current (almost) all-or-nothing
> > > > policy on those flags.
> > > > 
> > > > > In principle, the best which could occur is that a value gets
> > > > > stashed in
> > > > > the stream and used as a sanity check.  That will at least catch
> > > > > the
> > > > > case when they are different.
> > > > That'd be a minimal first step.
> > > This is a substantial quantity of work to do properly.  As the
> > > emulation
> > > flags are just one in a very long list of fields handed like this, I
> > > don't think this issue should block the series.
> > You certainly are more familiar with the migration code than me, but
> > wouldn't it be enough to add a new field to libxl_domain_build_info
> > (uint32_t emulation_flags), and teach
> > libxl_domain_build_info_gen_json/libxl__domain_build_info_parse_json
> >  how to properly parse it?
> 
> That would let it be configured from an xl.cfg file, and would normally
> be moved in the migration stream.  However, there is a specific option
> in xl to restore but using a brand new configuration file.
> 
> What it doesn't do it check that the settings for the domain in the
> stream match the settings of the domid being restored into.

That would be the responsibility of the user who has chosen to override the
configuration in this way.

Ian.


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

Re: [Xen-devel] Load calculation refresh in credit2 (was in Re: Questions about the use of idle_vcpu[])

[Dario Faggioli]

On Mon, 2016-01-18 at 14:12 +, George Dunlap wrote:
> [Changing the title to align with the current topic]
> 
> Load balancing only happens on a reset event; and the frequency of
> reset
> events will be CREDIT_INIT / (% utilization); so for a system at 1%
> utilization that would be once every second.  Is that the kind of
> number
> you were seeing?  Or were you actually seeing idle runqueues not
> having
> anything pushed to them *during* a balance for some reason?
> 
As I said, I need to recheck... but yes, this could be the cause of my
"issue".

In fact, since I was reading the load from the toolstack (that was one
of the purposes of the whole thing), it's quite likely that I was
seeing non-updated values because the load balance hadn't run since a
while.

I'll keep this in mind when revisiting that work, and try to cook a
patch that avoid setting the timer when the idle vcpu is returned, and
see how it goes.

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



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

Re: [Xen-devel] [PATCH v2 5/5] libxl: Add explicit cast to libxl_psr_cat_set_cbm

[Dario Faggioli]

On Tue, 2016-01-19 at 00:58 -0500, Chester Lin wrote:
> Fixes Coverity CID 1343299. The call to xc_psr_cat_set_domain_data()
> expects type xc_psr_cat_type but is provided libxl_psr_cbm_type which
> is defined in IDL.
> 
> The two enums are deliberately identical and IDL only exists so that
> libxl clients don't need to include libxc headers directly.
> 
I see...

> --- a/tools/libxl/libxl_psr.c
> +++ b/tools/libxl/libxl_psr.c
> @@ -310,7 +310,9 @@ int libxl_psr_cat_set_cbm(libxl_ctx *ctx,
> uint32_t domid,
>  libxl_for_each_set_bit(socketid, *target_map) {
>  if (socketid >= nr_sockets)
>  break;
> -if (xc_psr_cat_set_domain_data(ctx->xch, domid, type,
> socketid, cbm)) {
> +r = xc_psr_cat_set_domain_data(ctx->xch, domid,
> (xc_psr_cat_type) type,
> +   socketid, cbm);
> +if (r) {
>
Is the cast in the function call better than a local variable of
xc_psr_cat_type initialized with 'type'? Or would Coverity keep
complaining in such a case?

If yes to either of the questions, this patch is:

Reviewed-by: Dario Faggioli 

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



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

Re: [Xen-devel] [PATCH v4 09/10] arm/uart: Rename dt-uart.c to arm-uart.c

[Jan Beulich]

>>> On 19.01.16 at 04:36,  wrote:

> 
> On 2016/1/18 18:40, Jan Beulich wrote:
> On 16.01.16 at 06:01,  wrote:
>>> > From: Shannon Zhao 
>>> > 
>>> > Since we will add ACPI initialization for UART in this file later,
>>> > rename it with a generic name.
>>> > 
>>> > Signed-off-by: Shannon Zhao 
>>> > ---
>>> > v4: split the original patch to renaming this and adding ACPI parts.
>>> > ---
>>> >  MAINTAINERS |   2 +-
>>> >  xen/drivers/char/Makefile   |   2 +-
>>> >  xen/drivers/char/arm-uart.c | 107 
>>> > 
>>> >  xen/drivers/char/dt-uart.c  | 107 
>>> > 
>>> >  4 files changed, 109 insertions(+), 109 deletions(-)
>>> >  create mode 100644 xen/drivers/char/arm-uart.c
>>> >  delete mode 100644 xen/drivers/char/dt-uart.c
>> Looks like this really is a rename with little actual changes to
>> the file, 
> Yes, but the only change to this file is also to change its name because
> it's mentioned in the file header. This intends to make that consistent.
> 
> + * xen/drivers/char/arm-uart.c

I understand that, but without using git's ability to represent the
rename such that the diff between the files is visible it is hard to
tell what exactly you changed in the file.

Jan


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

Re: [Xen-devel] [PATCH v2 11/16] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

[Shannon Zhao]

On 2016/1/18 23:07, Stefano Stabellini wrote:
> On Mon, 18 Jan 2016, Mark Rutland wrote:
>> > On Fri, Jan 15, 2016 at 02:55:24PM +0800, Shannon Zhao wrote:
>>> > > From: Shannon Zhao 
>>> > > 
>>> > > When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
>>> > > a /hypervisor node in DT. So check if it needs to enable ACPI.
>>> > > 
>>> > > Signed-off-by: Shannon Zhao 
>>> > > ---
>>> > >  arch/arm64/kernel/acpi.c | 12 
>>> > >  1 file changed, 8 insertions(+), 4 deletions(-)
>>> > > 
>>> > > diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>>> > > index d1ce8e2..4e92be0 100644
>>> > > --- a/arch/arm64/kernel/acpi.c
>>> > > +++ b/arch/arm64/kernel/acpi.c
>>> > > @@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned 
>>> > > long node,
>>> > >  {
>>> > > /*
>>> > >  * Return 1 as soon as we encounter a node at depth 1 that is
>>> > > -* not the /chosen node.
>>> > > +* not the /chosen node, or /hypervisor node when running on 
>>> > > Xen.
>>> > >  */
>>> > > -   if (depth == 1 && (strcmp(uname, "chosen") != 0))
>>> > > -   return 1;
>>> > > +   if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
>>> > > +   if (!xen_initial_domain() || (strcmp(uname, 
>>> > > "hypervisor") != 0))
>>> > > +   return 1;
>>> > > +   }
>>> > > +
>>> > > return 0;
>>> > >  }
>> > 
>> > As this is changing the semantic of an "empty" DT, we should consider
>> > now if there's anything else that might also need to exist in an "empty"
>> > DT. We don't want to change this again in future if we don't have to,
>> > given the compatiblity nightmare that's sure to result.
>> > 
>> > We should also consider if the "hypervisor" node name is sufficient (I
>> > think it is, but let's not assume anything).
>>From Xen point of view I think it is enough: real hardware is described
> in ACPI anyway and anything hypervisor related can be done via
> hypercalls once Xen support is discovered, for which the hypervisor node
> is sufficient.

Yes, I think the hypervisor node is sufficient for current Xen ACPI support.

-- 
Shannon


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

Re: [Xen-devel] [PATCH] xen: Improvements to clean and distclean targets

[Jan Beulich]

>>> On 18.01.16 at 19:19,  wrote:
> On 18/01/16 16:57, Jan Beulich wrote:
> On 18.01.16 at 17:45,  wrote:
>>> On 18/01/16 16:41, Jan Beulich wrote:
>>> On 18.01.16 at 17:27,  wrote:
> * Move '*~' and 'core' into the find rule.
 I don't understand this part: Where in the build process do such get
 generated? I'm tempted to instead recommend to just drop those
 from the rm invocation...
>>> No idea about 'core' files, but *~ are emacs backup files.
>> But emacs should clean up after itself; this shouldn't be the job
>> of our clean rule.
> 
> Why? the point is to have a one-revision old version of the file to hand.

I guess there may be different strategies here: My editor also
creates such named files, but deletes them as the program gets
shut down. I.e. the one-revision old backup exists as long as the
program is running. I can see benefits from the alternative
model, but still it shouldn't be our scripts to clean up such backups.
After all - what if another program used another name patter for
its backups? Would we go clean those up then too?

Jan



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

Re: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core logic handling

[Wu, Feng]

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, January 18, 2016 5:04 PM
> To: Wu, Feng 
> Cc: andrew.coop...@citrix.com; dario.faggi...@citrix.com;
> george.dun...@eu.citrix.com; Tian, Kevin ; xen-
> de...@lists.xen.org; k...@xen.org
> Subject: RE: RE: [Xen-devel] [PATCH v10 6/7] vmx: VT-d posted-interrupt core
> logic handling
> 
> >>> On 18.01.16 at 09:45,  wrote:
> > It has been pending for such a long time, and Dario and Kevin both
> reviewed
> > it, it is pending on your comments, could you tell when you will look at it?
> 
> I can't really, and I don't think I've seen e.g. Dario give his
> Reviewed-by. 

I didn't say Dario gave his reviewed-by, but he did reviewed this patch
and said: " This patch looks fine to me now. " with some minor
issues, I have addressed the minor issues and just want to get your
feedbacks before posting version 11 (Thanks for your comments in
the following email).

Thanks,
Feng


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

Re: [Xen-devel] [PATCH] build: specify minimum versions of make and binutils

[Jan Beulich]

>>> On 18.01.16 at 18:21,  wrote:
> On 1/18/16 11:03 AM, Jan Beulich wrote:
> On 18.01.16 at 17:53,  wrote:
>>> To help people avoid having to figure out what versions of make and
>>> binutils need to be supported document them explicitly. The version of
>>> binutils that had to be supported was mentioned in
>>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.html 
>>> as 2.17. Knowing that Jan got these versions from SLES10 I looked up the
>>> version of GNU make from the same vintage (mid-2006) and landed on 3.81.
>> 
>> I'm afraid that same SLE10 has been using binutils 2.16.9.
>> and make 3.80. While (still building Xen there once in a while) I'd probably
>> not be in big trouble if we decided we don't want to support that old an
>> environment anymore, I don't think we can just go and document higher
>> versions than we so far allowed. We'd first need to settle on where to
>> draw the line nowadays (which then likely would mean a gcc minimal
>> version bum too).
> 
> Not a problem. I was just trying to take the situation from a guessing
> game to be explicitly called out. I was documenting what my logic was
> behind the version numbers I selected. I wasn't able to compare dates
> with binutils because their repo goes from 2003 to 2011 [1]. So I went
> back to SLES10's release date [2] and the GCC 4.1.0 release date [3] to
> compare it with GNU make [4].
> 
> Honestly I'd be happy if we just drew a line in the sand so that its
> clear what I need to test against when I submit patches. I don't really
> care where the line is.

Then how about 2.16.1 and 3.80 respectively as the initial line?

Jan


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

[Xen-devel] [qemu-mainline test] 78421: tolerable FAIL - PUSHED

[osstest service owner]

flight 78421 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78421/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install   fail REGR. vs. 78223
 test-armhf-armhf-xl-rtds15 guest-start/debian.repeat fail blocked in 78223

Tests which did not succeed, but are not blocking:
 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-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   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-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail 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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop 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-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-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-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   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-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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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

version targeted for testing:
 qemuu19b6d84316892c8086e0115d6f09cb01abb86cfc
baseline version:
 qemuu5a57acb66f19ee52723aa05b8afbbc41c3e9ec99

Last test of basis78223  2016-01-16 03:55:39 Z3 days
Testing same since78421  2016-01-18 09:47:22 Z0 days1 attempts


People who touched revisions under test:
  Cao jin 
  Daniel P. Berrange 
  Fam Zheng 
  Michael S. Tsirkin 
  P J P 
  Paolo Bonzini 
  Peter Maydell 
  Prasad J Pandit 
  Shmulik Ladkani 
  Zhu Lingshan 

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-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl  

Re: [Xen-devel] [PATCH v2 1/5] libxl: tidy libxl_get_scheduler() according to CODING_STYLE

[Dario Faggioli]

On Tue, 2016-01-19 at 00:57 -0500, Chester Lin wrote:
> To more closely follow the guidelines in CODING_STYLE, store the
> result
> of xc_sched_id() in the local variable r, and the check the result of
> the call in a separate statement.  Change the type of the output
> parameter given to xc_sched_id() from libxl_scheduler to int to match
> the libxc interface.
> 
> Additionally, change the error log statement to more accurately
> reflect
> the failure.  This is the only functional change introduced by this
> patch.
> 
> Suggested-by: Ian Campbell 
> Signed-off-by: Chester Lin 
> 
Reviewed-by: Dario Faggioli 

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



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

Re: [Xen-devel] [PATCH v2 1/4] xen/elfnotes: check phys_entry against UNSET_ADDR32

[Wei Liu]

On Fri, Jan 15, 2016 at 03:59:40PM +0100, Roger Pau Monne wrote:
> And introduce UNSET_ADDR32.
> 
> Signed-off-by: Roger Pau Monné 
> Acked-by: Jan Beulich 
> ---
> Cc: Ian Jackson 
> Cc: Ian Campbell 
> Cc: Wei Liu 
> ---
> Changes since v1:
>  - Fix commit title.
> ---
>  tools/libxc/xc_dom_elfloader.c | 2 +-
>  xen/common/libelf/libelf-dominfo.c | 1 +
>  xen/include/xen/libelf.h   | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/xc_dom_elfloader.c b/tools/libxc/xc_dom_elfloader.c
> index 2ae575e..5039f3f 100644
> --- a/tools/libxc/xc_dom_elfloader.c
> +++ b/tools/libxc/xc_dom_elfloader.c
> @@ -57,7 +57,7 @@ static char *xc_dom_guest_type(struct xc_dom_image *dom,
>  uint64_t machine = elf_uval(elf, elf->ehdr, e_machine);
>  
>  if ( dom->container_type == XC_DOM_HVM_CONTAINER &&
> - dom->parms.phys_entry != UNSET_ADDR )
> + dom->parms.phys_entry != UNSET_ADDR32 )
>  return "hvm-3.0-x86_32";
>  

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH] INSTALL: fix typo

[Ian Campbell]

On Mon, 2016-01-18 at 17:17 -0600, Doug Goldstein wrote:
> There's a case of a missing T in the word 'the'.
> 
> Signed-off-by: Doug Goldstein 

cked + pplied, hanks.

Ian.

> ---
>  INSTALL | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/INSTALL b/INSTALL
> index 3d2e86a..95fa94d 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -275,7 +275,7 @@ Building the python tools may fail unless certain
> options are passed to
>  setup.py. Config.mk contains additional info how to use this variable.
>  PYTHON_PREFIX_ARG=
>  
> -he hypervisor may be build with XSM/Flask support, which can be changed
> +The hypervisor may be build with XSM/Flask support, which can be changed
>  by running:
>  make -C xen menuconfig
>  and enabling XSM/Flask in the 'Common Features' menu.

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

Re: [Xen-devel] [PATCH v3 4/4] x86/PV: enable the emulated PIT

[Andrew Cooper]

On 19/01/16 09:24, Ian Campbell wrote:
> On Mon, 2016-01-18 at 18:03 +, Andrew Cooper wrote:
>> On 18/01/16 17:58, Roger Pau Monné wrote:
>>> El 18/01/16 a les 11.41, Andrew Cooper ha escrit:
 On 18/01/16 09:44, Jan Beulich wrote:
 On 18.01.16 at 10:29,  wrote:
>> On 18/01/2016 07:43, Jan Beulich wrote:
>> On 15.01.16 at 18:45,  wrote:
 Changes since v2:
  - Change 'if ( (a && b) || (!a && c) )' into 'if ( a ? b : c
 )'.
>>> Thanks, but after some more thinking about it I'm afraid there
>>> are
>>> a few more aspects to consider here:
>>>
 --- a/xen/arch/x86/domain.c
 +++ b/xen/arch/x86/domain.c
 @@ -542,8 +542,9 @@ int arch_domain_create(struct domain *d,
 unsigned int 
>> domcr_flags,
 d->domain_id, config->emulation_flags);
  return -EINVAL;
  }
 -if ( config->emulation_flags != 0 &&
 - (!is_hvm_domain(d) || config->emulation_flags
 != XEN_X86_EMU_ALL) 
>> )
 +if ( is_hvm_domain(d) ? (config->emulation_flags !=
 XEN_X86_EMU_ALL &&
 + config->emulation_flags != 0) :
 + (config->emulation_flags != XEN_X86_EMU_PIT) )
  {
>>> For one I think it would be a good idea to allow zero for PV
>>> domains,
>>> and perhaps even default new DomU-s to have the PIT flag clear.
>>> (Also - indentation.)
>>>
>>> Which gets us to the second, broader issue: These flags
>>> shouldn't
>>> be forced to a particular value during migration, but instead
>>> they
>>> should be part of the state getting migrated. Incoming domains
>>> then would - if the field is missing due to coming from an
>>> older
>>> hypervisor - have the flag default to 1.
>> There is sadly another ratsnest here.
> I've been afraid of that.
>
>> These values are needed for domain creation, which means that
>> putting
>> them anywhere in the migration stream is already too late, as the
>> domain
>> has been created before the stream header is read.
> Is that an inherent requirement, or just a result of current code
> structure?
 Depends.  As far as libxc/libxl migration levels go, current code
 structure.

 Whatever (eventually) gets used to set these values will however be
 present in the xl configuration, which is at the very start of the
 stream, and is what is used to create the new domain.

 We really don't want the libxc migrate code to be making the
 DOMCTL_createdomain hypercall itself; it opens up a whole new attack
 surface via cunningly-crafted save image.  The best we can do is have
 a
 sanity check later on.

>  I ask because migrating the emulation flags is going to
> be a requirement for relaxing the current (almost) all-or-nothing
> policy on those flags.
>
>> In principle, the best which could occur is that a value gets
>> stashed in
>> the stream and used as a sanity check.  That will at least catch
>> the
>> case when they are different.
> That'd be a minimal first step.
 This is a substantial quantity of work to do properly.  As the
 emulation
 flags are just one in a very long list of fields handed like this, I
 don't think this issue should block the series.
>>> You certainly are more familiar with the migration code than me, but
>>> wouldn't it be enough to add a new field to libxl_domain_build_info
>>> (uint32_t emulation_flags), and teach
>>> libxl_domain_build_info_gen_json/libxl__domain_build_info_parse_json
>>>  how to properly parse it?
>> That would let it be configured from an xl.cfg file, and would normally
>> be moved in the migration stream.  However, there is a specific option
>> in xl to restore but using a brand new configuration file.
>>
>> What it doesn't do it check that the settings for the domain in the
>> stream match the settings of the domid being restored into.
> That would be the responsibility of the user who has chosen to override the
> configuration in this way.

It is the responsibility of Xen to ensure there are no exploitable holes
due to partial or misconfiguration.

In particular, this PIT emulation patch fixes an accidental NULL pointer
dereference in Xen, due to the accidental disabling of the PIT in PV guests.

~Andrew

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

Re: [Xen-devel] [PATCH] xen: Improvements to clean and distclean targets

[Ian Campbell]

On Tue, 2016-01-19 at 11:06 +0100, Juergen Gross wrote:
> On 19/01/16 10:38, Ian Campbell wrote:
> > On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote:
> > > > > > On 18.01.16 at 19:19,  wrote:
> > > > On 18/01/16 16:57, Jan Beulich wrote:
> > > > > > > > On 18.01.16 at 17:45,  wrote:
> > > > > > On 18/01/16 16:41, Jan Beulich wrote:
> > > > > > > > > > On 18.01.16 at 17:27, 
> > > > > > > > > > wrote:
> > > > > > > > * Move '*~' and 'core' into the find rule.
> > > > > > > I don't understand this part: Where in the build process do
> > > > > > > such
> > > > > > > get
> > > > > > > generated? I'm tempted to instead recommend to just drop
> > > > > > > those
> > > > > > > from the rm invocation...
> > > > > > No idea about 'core' files, but *~ are emacs backup files.
> > > > > But emacs should clean up after itself; this shouldn't be the job
> > > > > of our clean rule.
> > > > 
> > > > Why? the point is to have a one-revision old version of the file to
> > > > hand.
> > > 
> > > I guess there may be different strategies here: My editor also
> > > creates such named files, but deletes them as the program gets
> > > shut down. I.e. the one-revision old backup exists as long as the
> > > program is running. I can see benefits from the alternative
> > > model, but still it shouldn't be our scripts to clean up such
> > > backups.
> > > After all - what if another program used another name patter for
> > > its backups? Would we go clean those up then too?
> > 
> > IMHO these files should be in .gitignore (so they don't clutter "git
> > status", AFAICT this is already done correctly) but it's not really
> > necessary for "make clean" (or distclean) to get rid of them, that's up
> > to
> > either the editor or the user. IOW I'd be happy removing the existing
> > rules.
> 
> What about adding a "make gitclean" which will remove all files ignored
> by git? It could use .gitignore (or even "git clean -dffq"). This way
> "make [dist]clean" could be limited to the files created by the build
> process on purpose.

IMHO people should just use "git clean" in whichever way suits them if this
is they want.

Ian.

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

[Xen-devel] [linux-mingo-tip-master test] 78486: regressions - FAIL

[osstest service owner]

flight 78486 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78486/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 60684
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 60684

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-xsm   9 debian-installfail REGR. vs. 60684
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 60684
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 60684

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  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-amd64-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-xl-qemut-win7-amd64 16 guest-stop 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-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-qemuu-nested-intel 13 xen-boot/l1 fail never pass

version targeted for testing:
 linux2c49cb1212410cedb2e3f31bf6be97a98ce5b827
baseline version:
 linux69f75ebe3b1d1e636c4ce0a0ee248edacc69cbe0

Last test of basis60684  2015-08-13 04:21:46 Z  159 days
Failing since 60712  2015-08-15 18:33:48 Z  156 days  108 attempts
Testing same since78486  2016-01-19 04:20:47 Z0 days1 attempts

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  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 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-xl-qemut-stubdom-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
 test-amd64-amd64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-xl-xsm  pass
 test-amd64-i386-xl-xsm   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
 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   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-credit2

Re: [Xen-devel] [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Shannon Zhao]

On 2016/1/19 1:34, Stefano Stabellini wrote:
> On Mon, 18 Jan 2016, Mark Rutland wrote:
>> On Fri, Jan 15, 2016 at 02:55:25PM +0800, Shannon Zhao wrote:
>>> From: Shannon Zhao 
>>>
>>> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
>>> scan this to get the UEFI information.
>>>
>>> Signed-off-by: Shannon Zhao 
>>> ---
>>>  Documentation/devicetree/bindings/arm/xen.txt | 42 
>>> +++
>>>  1 file changed, 42 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
>>> b/Documentation/devicetree/bindings/arm/xen.txt
>>> index 0f7b9c2..fbc17ae 100644
>>> --- a/Documentation/devicetree/bindings/arm/xen.txt
>>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
>>> @@ -15,6 +15,36 @@ the following properties:
>>>  - interrupts: the interrupt used by Xen to inject event notifications.
>>>A GIC node is also required.
>>>  
>>> +To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT "uefi" 
>>> node
>>> +under /hypervisor with following parameters:
>>
>> s/pupulates/populates/
>>
>>> +
>>> +
>>> +Name  | Size   | Description
>>> +
>>> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI 
>>> System
>>> + || Table.
>>> +
>>> +xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI 
>>> memory
>>> + || map.
>>> +
>>> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
>>> +  || pointed to in previous entry.
>>> +
>>> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the 
>>> UEFI
>>> +  || memory map.
>>> +
>>> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor format.
>>> +
>>> +
>>> +Below is the format of the mmap descriptor.
>>> +typedef struct {
>>> +   u32 type;
>>> +   u32 pad;
>>> +   u64 phys_addr;
>>> +   u64 virt_addr;
>>> +   u64 num_pages;
>>> +   u64 attribute;
>>> +} efi_memory_desc_t;
>>
>> I don't think we should describe this here, as it duplicates the UEFI
>> spec, and is techincally incorrect the above is only guaranteed to be
>> the prefix of each memory descriptor -- that's why the
>> uefi-mmap-desc-size property exists.
>>
Oh, this format is suggested to describe here at previous patch set.

>> We don't do this in Documentation/arm/uefi.txt, and I don't see why we
>> should do so here.
>>
>> Does Xen handle arbitrary size memory map descriptors? I'm not sure what
>> new information might be passed in future additions to the descriptor
>> format, and I'm not sure what should happen in the Dom0 case.
> 
> Xen passes to Dom0 the memory map in the same format as the native
> memory map.
> 
> 
>>>  Example (assuming #address-cells = <2> and #size-cells = <2>):
>>>  
>>> @@ -22,4 +52,16 @@ hypervisor {
>>> compatible = "xen,xen-4.3", "xen,xen";
>>> reg = <0 0xb000 0 0x2>;
>>> interrupts = <1 15 0xf08>;
>>> +   uefi {
>>> +   xen,uefi-system-table = <0x>;
>>> +   xen,uefi-mmap-start = <0x>;
>>> +   xen,uefi-mmap-size = <0x>;
>>> +   xen,uefi-mmap-desc-size = <0x>;
>>> +   xen,uefi-mmap-desc-ver = <0x>;
>>> +};
>>>  };
>>> +
>>> +These "xen,uefi-*" parameters are similar to those in 
>>> Documentation/arm/uefi.txt
>>> +which are used by normal UEFI. But to Xen ARM virtual platforms, it needs 
>>> to
>>> +introduce a Xen specific UEFI and it doesn't want to mix with normal UEFI.
>>> +Therefore, it defines these parameters under /hypervisor node.
>>
>> Could we please describe what that actual difference is?
>>
>> I know that the OS must handle a system table differently under Xen, but
>> this doesn't describe what it should do.
> 
> For a reference, the hypercall interface is described in not so many words 
> here:
> 
> include/xen/interface/platform.h
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob_plain;f=xen/include/public/platform.h;hb=HEAD
> 
> However it is clear that platform.h also contains some x86 specific
> calls, for example xenpf_set_processor_pminfo. It might be a good idea
> to list the calls that are available on ARM64.
> 
As Stefano said, I think the difference is that for Xen Dom0 the runtime
services are worked through hypercalls not the RuntimeServices 

Re: [Xen-devel] [PATCH v3 4/4] x86/PV: enable the emulated PIT

[Ian Campbell]

On Tue, 2016-01-19 at 10:09 +, Andrew Cooper wrote:
> On 19/01/16 09:24, Ian Campbell wrote:
> > On Mon, 2016-01-18 at 18:03 +, Andrew Cooper wrote:
> > > On 18/01/16 17:58, Roger Pau Monné wrote:
> > > > El 18/01/16 a les 11.41, Andrew Cooper ha escrit:
> > > > > On 18/01/16 09:44, Jan Beulich wrote:
> > > > > > > > > On 18.01.16 at 10:29,  wrote:
> > > > > > > On 18/01/2016 07:43, Jan Beulich wrote:
> > > > > > > > > > > On 15.01.16 at 18:45,  wrote:
> > > > > > > > > Changes since v2:
> > > > > > > > >  - Change 'if ( (a && b) || (!a && c) )' into 'if ( a ? b
> > > > > > > > > : c
> > > > > > > > > )'.
> > > > > > > > Thanks, but after some more thinking about it I'm afraid
> > > > > > > > there
> > > > > > > > are
> > > > > > > > a few more aspects to consider here:
> > > > > > > > 
> > > > > > > > > --- a/xen/arch/x86/domain.c
> > > > > > > > > +++ b/xen/arch/x86/domain.c
> > > > > > > > > @@ -542,8 +542,9 @@ int arch_domain_create(struct domain
> > > > > > > > > *d,
> > > > > > > > > unsigned int 
> > > > > > > domcr_flags,
> > > > > > > > > d->domain_id, config-
> > > > > > > > > >emulation_flags);
> > > > > > > > >  return -EINVAL;
> > > > > > > > >  }
> > > > > > > > > -if ( config->emulation_flags != 0 &&
> > > > > > > > > - (!is_hvm_domain(d) || config-
> > > > > > > > > >emulation_flags
> > > > > > > > > != XEN_X86_EMU_ALL) 
> > > > > > > )
> > > > > > > > > +if ( is_hvm_domain(d) ? (config->emulation_flags 
> > > > > > > > > !=
> > > > > > > > > XEN_X86_EMU_ALL &&
> > > > > > > > > + config->emulation_flags != 0) :
> > > > > > > > > + (config->emulation_flags !=
> > > > > > > > > XEN_X86_EMU_PIT) )
> > > > > > > > >  {
> > > > > > > > For one I think it would be a good idea to allow zero for
> > > > > > > > PV
> > > > > > > > domains,
> > > > > > > > and perhaps even default new DomU-s to have the PIT flag
> > > > > > > > clear.
> > > > > > > > (Also - indentation.)
> > > > > > > > 
> > > > > > > > Which gets us to the second, broader issue: These flags
> > > > > > > > shouldn't
> > > > > > > > be forced to a particular value during migration, but
> > > > > > > > instead
> > > > > > > > they
> > > > > > > > should be part of the state getting migrated. Incoming
> > > > > > > > domains
> > > > > > > > then would - if the field is missing due to coming from an
> > > > > > > > older
> > > > > > > > hypervisor - have the flag default to 1.
> > > > > > > There is sadly another ratsnest here.
> > > > > > I've been afraid of that.
> > > > > > 
> > > > > > > These values are needed for domain creation, which means that
> > > > > > > putting
> > > > > > > them anywhere in the migration stream is already too late, as
> > > > > > > the
> > > > > > > domain
> > > > > > > has been created before the stream header is read.
> > > > > > Is that an inherent requirement, or just a result of current
> > > > > > code
> > > > > > structure?
> > > > > Depends.  As far as libxc/libxl migration levels go, current code
> > > > > structure.
> > > > > 
> > > > > Whatever (eventually) gets used to set these values will however
> > > > > be
> > > > > present in the xl configuration, which is at the very start of
> > > > > the
> > > > > stream, and is what is used to create the new domain.
> > > > > 
> > > > > We really don't want the libxc migrate code to be making the
> > > > > DOMCTL_createdomain hypercall itself; it opens up a whole new
> > > > > attack
> > > > > surface via cunningly-crafted save image.  The best we can do is
> > > > > have
> > > > > a
> > > > > sanity check later on.
> > > > > 
> > > > > >  I ask because migrating the emulation flags is going to
> > > > > > be a requirement for relaxing the current (almost) all-or-
> > > > > > nothing
> > > > > > policy on those flags.
> > > > > > 
> > > > > > > In principle, the best which could occur is that a value gets
> > > > > > > stashed in
> > > > > > > the stream and used as a sanity check.  That will at least
> > > > > > > catch
> > > > > > > the
> > > > > > > case when they are different.
> > > > > > That'd be a minimal first step.
> > > > > This is a substantial quantity of work to do properly.  As the
> > > > > emulation
> > > > > flags are just one in a very long list of fields handed like
> > > > > this, I
> > > > > don't think this issue should block the series.
> > > > You certainly are more familiar with the migration code than me,
> > > > but
> > > > wouldn't it be enough to add a new field to libxl_domain_build_info
> > > > (uint32_t emulation_flags), and teach
> > > > libxl_domain_build_info_gen_json/libxl__domain_build_info_parse_jso
> > > > n
> > > >  how to properly parse it?
> > > That would let it be configured from an xl.cfg file, and would
> > > normally
> > > be moved in the migration stream.  However, there is a specific
> > > option
> > > in xl to restore but using a brand new 

Re: [Xen-devel] [PATCHv5 1/3] rwlock: Add per-cpu reader-writer lock infrastructure

[Malcolm Crossley]

On 11/01/16 15:06, Malcolm Crossley wrote:
> On 22/12/15 11:56, George Dunlap wrote:
>> On 18/12/15 16:08, Malcolm Crossley wrote:
>>> 
>>> +
>>> +#ifndef NDEBUG
>>> +#define PERCPU_RW_LOCK_UNLOCKED(owner) { RW_LOCK_UNLOCKED, 0, owner }
>>> +static inline void _percpu_rwlock_owner_check(percpu_rwlock_t 
>>> **per_cpudata,
>>> + percpu_rwlock_t *percpu_rwlock)
>>> +{
>>> +ASSERT(per_cpudata == percpu_rwlock->percpu_owner);
>>> +}
>>> +#else
>>> +#define PERCPU_RW_LOCK_UNLOCKED(owner) { RW_LOCK_UNLOCKED, 0 }
>>> +#define _percpu_rwlock_owner_check(data, lock) ((void)0)
>>> +#endif
>>> +
>>> +#define DEFINE_PERCPU_RWLOCK_RESOURCE(l, owner) \
>>> +percpu_rwlock_t l = PERCPU_RW_LOCK_UNLOCKED(_per_cpu_var(owner))
>>> +#define percpu_rwlock_resource_init(l, owner) \
>>> +(*(l) = 
>>> (percpu_rwlock_t)PERCPU_RW_LOCK_UNLOCKED(_per_cpu_var(owner)))
>>> +
>>> +static inline void _percpu_read_lock(percpu_rwlock_t **per_cpudata,
>>> + percpu_rwlock_t *percpu_rwlock)
>>
>> Is there a particular reason you chose to only use the "owner" value in
>> the struct to verify that the "per_cpudata" argument passed matched the
>> one you expected, rather than just getting rid of the "per_cpudata"
>> argument altogether and always using the pointer in the struct?
> 
> Initially I was aiming to add percpu aspects to the rwlock without increasing
> the size of the rwlock structure itself, this was to keep data cache usage and
> memory allocations the same.
> It became clear that having a global writer_activating barrier would cause the
> read_lock to enter the slow path far too often. So I put the writer_activating
> variable in the percpu_rwlock_t, as writer_activating is just a bool then the
> additional data overhead should be small. Always having a 8 byte pointer may
> add a lot of overhead to data structures contain multiple rwlocks and thus
> cause additional allocation overhead.
>>
>> (i.e., _percpu_read_lock(percpu_rwlock_t *percpu_rwlock) { ...
>> per_cpudata = percpu_rwlock->percpu_owner; ... })
>>
>> I'm not an expert in this sort of micro-optimization, but it seems like
>> you're trading off storing a pointer in your rwlock struct for storing a
>> pointer at every call site.  Since you have to read writer_activating
>> for every lock or unlock anyway,
> 
> writer_activating is not read on the read_unlock path. As these are rwlocks
> then I'm assuming the read lock/unlock paths are more critical for 
> performance.
> So I'd prefer to not do a read of the percpu_rwlock structure if it's not
> required (i.e. on the read unlock path)
> Furthermore, the single byte for the writer_activating variable is likely
> to have been read into cache by accesses to other parts of the data structure
> near the percpu_rwlock_t. If we add additional 8 bytes to the percpu_rwlock_t
> then this may not happen and it may also adjust the cache line alignment 
> aswell.
> 
>> it doesn't seem like you'd actually be
>> saving that many memory fetches; but having only one copy in the cache,
>> rather than one copy per call site, would on the whole reduce both the
>> cache footprint and the total memory used (if only by a few bytes).
> 
> If you put the owner pointer in the percpu_rwlock_t then wouldn't you have
> a copy per instance of percpu_rwlock_t? Surely this would use more cache than
> the handful of call site references to a global variable.
> 
>>
>> It also makes the code cleaner to have only one argument, rather than
>> two which must match; but since in all the places you use it you end up
>> using a wrapper to give you a single argument anyway, I don't think that
>> matters in this case.  (i.e., if there's a good reason for having it at
>> the call site instead if in the struct, I'm fine with this approach).
> 
> If you agree with my reasoning for the cache overhead and performance of the
> read unlock path being better with passing the percpu_data as an argument then
> I propose we keep the patches as is.
> 
Ping? I believe this is the last point of discussion before the patches can go 
in.

Malcolm

>>
>> Everything else looks good, thanks.
>>
>>  -George
>>
> 
> 


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

Re: [Xen-devel] [PATCH v5 1/6] remus: don't do failover if we don't have an consistent state

[Ian Campbell]

On Tue, 2016-01-19 at 15:17 +0800, Wen Congyang wrote:
> We will have an consistent state when a CHECKPOINT_END record

"a consistent ..." (and in the subject too).

> is received. After the first CHECKPOINT_END record is received,
> we will buffer all records until the next CHECKPOINT_END record
> is received. So if the checkpoint() callback returns
> XGR_CHECKPOINT_FAILOVER,
> we only can do failover if ctx->restore.buffer_all_records is
> true.
> 
> Signed-off-by: Wen Congyang 
> ---

Please can you get into the habit of writing a delta from the previous
version here. e.g. in this case:

v5: New patch.

Putting it after the --- means it doesn't go into the actual commit ("git
am" will strip it) but it is very useful for reviewers to know what changed
in each iteration.

See also 
http://wiki.xen.org/wiki/Submitting_Xen_Patches#Review.2C_Rinse_.26_Repeat

>  tools/libxc/xc_sr_restore.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
> index 05159bb..9fe2829 100644
> --- a/tools/libxc/xc_sr_restore.c
> +++ b/tools/libxc/xc_sr_restore.c
> @@ -493,7 +493,11 @@ static int handle_checkpoint(struct xc_sr_context
> *ctx)
>  break;
>  
>  case XGR_CHECKPOINT_FAILOVER:
> -rc = BROKEN_CHANNEL;
> +if ( ctx->restore.buffer_all_records )
> +rc = BROKEN_CHANNEL;
> +else
> +/* We don't have an consistent state */

"a" not "an" again.

I can s/an/a/ in all 3 places upon commit, so no need to resend for just
those.

Acked-by: Ian Campbell 

I'll give Andy a chance to comment before committing though.

> +rc = -1;
>  goto err;
>  
>  default: /* Other fatal error */

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

Re: [Xen-devel] [PATCH v2 12/16] ARM: Xen: Document UEFI support on Xen ARM virtual platforms

[Mark Rutland]

On Tue, Jan 19, 2016 at 06:25:25PM +0800, Shannon Zhao wrote:
> 
> 
> On 2016/1/19 1:34, Stefano Stabellini wrote:
> > On Mon, 18 Jan 2016, Mark Rutland wrote:
> >> On Fri, Jan 15, 2016 at 02:55:25PM +0800, Shannon Zhao wrote:
> >>> From: Shannon Zhao 
> >>>
> >>> Add a "uefi" node under /hypervisor node in FDT, then Linux kernel could
> >>> scan this to get the UEFI information.
> >>>
> >>> Signed-off-by: Shannon Zhao 
> >>> ---
> >>>  Documentation/devicetree/bindings/arm/xen.txt | 42 
> >>> +++
> >>>  1 file changed, 42 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/arm/xen.txt 
> >>> b/Documentation/devicetree/bindings/arm/xen.txt
> >>> index 0f7b9c2..fbc17ae 100644
> >>> --- a/Documentation/devicetree/bindings/arm/xen.txt
> >>> +++ b/Documentation/devicetree/bindings/arm/xen.txt
> >>> @@ -15,6 +15,36 @@ the following properties:
> >>>  - interrupts: the interrupt used by Xen to inject event notifications.
> >>>A GIC node is also required.
> >>>  
> >>> +To support UEFI on Xen ARM virtual platforms, Xen pupulates the FDT 
> >>> "uefi" node
> >>> +under /hypervisor with following parameters:
> >>
> >> s/pupulates/populates/
> >>
> >>> +
> >>> +
> >>> +Name  | Size   | Description
> >>> +
> >>> +xen,uefi-system-table | 64-bit | Guest physical address of the UEFI 
> >>> System
> >>> +   || Table.
> >>> +
> >>> +xen,uefi-mmap-start   | 64-bit | Guest physical address of the UEFI 
> >>> memory
> >>> +   || map.
> >>> +
> >>> +xen,uefi-mmap-size| 32-bit | Size in bytes of the UEFI memory map
> >>> +  || pointed to in previous entry.
> >>> +
> >>> +xen,uefi-mmap-desc-size   | 32-bit | Size in bytes of each entry in the 
> >>> UEFI
> >>> +  || memory map.
> >>> +
> >>> +xen,uefi-mmap-desc-ver| 32-bit | Version of the mmap descriptor 
> >>> format.
> >>> +
> >>> +
> >>> +Below is the format of the mmap descriptor.
> >>> +typedef struct {
> >>> + u32 type;
> >>> + u32 pad;
> >>> + u64 phys_addr;
> >>> + u64 virt_addr;
> >>> + u64 num_pages;
> >>> + u64 attribute;
> >>> +} efi_memory_desc_t;
> >>
> >> I don't think we should describe this here, as it duplicates the UEFI
> >> spec, and is techincally incorrect the above is only guaranteed to be
> >> the prefix of each memory descriptor -- that's why the
> >> uefi-mmap-desc-size property exists.
> >>
> Oh, this format is suggested to describe here at previous patch set.

We can describe it by referring to the definition in the UEFI
specification (i.e. state the properties represent the return values of
EFI_BOOT_SERVICES.GetMemoryMap()).

If that's necessary at all, fix that in the usual
Documentation/arm/uefi.txt, and state here that the format and meaning
of each property here follows its unprefixed cousin, with the caveat
that Xen-specific assumptions also apply (e.g. runtime services must be
indirected via hypercalls).

Anything else is redundant and risks being wrong.

> >> We don't do this in Documentation/arm/uefi.txt, and I don't see why we
> >> should do so here.
> >>
> >> Does Xen handle arbitrary size memory map descriptors? I'm not sure what
> >> new information might be passed in future additions to the descriptor
> >> format, and I'm not sure what should happen in the Dom0 case.
> > 
> > Xen passes to Dom0 the memory map in the same format as the native
> > memory map.

Does Xen parse or modify the EFI memory map in any way?

Does it pass the raw values returned by EFI_BOOT_SERVICES.GetMemoryMap()
through to the xen,uefi-* properties, or does is make any static
assumptions about what the values will be?

I'm trying to get a feeling for what the behaviour will be if/when a
version of the EFI spec expands the memory map format.

> >>>  Example (assuming #address-cells = <2> and #size-cells = <2>):
> >>>  
> >>> @@ -22,4 +52,16 @@ hypervisor {
> >>>   compatible = "xen,xen-4.3", "xen,xen";
> >>>   reg = <0 0xb000 0 0x2>;
> >>>   interrupts = <1 15 0xf08>;
> >>> + uefi {
> >>> + xen,uefi-system-table = <0x>;
> >>> + xen,uefi-mmap-start = <0x>;
> >>> + xen,uefi-mmap-size = <0x>;
> >>> + xen,uefi-mmap-desc-size = <0x>;
> >>> + xen,uefi-mmap-desc-ver = <0x>;
> >>> +   

Re: [Xen-devel] [PATCH v5 2/6] remus: don't call stream_continue() when doing failover

[Ian Campbell]

On Tue, 2016-01-19 at 15:17 +0800, Wen Congyang wrote:
> stream_continue() is used for migration to read emulator
> xenstore data and emulator context. For remus, if we do
> failover, we have read it in the checkpoint cycle, and
> we only need to complete the stream.
> 
> Signed-off-by: Wen Congyang 
> Reviewed-by: Andrew Cooper 

Acked-by: Ian Campbell 


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

[Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

[Malcolm Crossley]

The average is calculated over the period of time from the last
xenpm report of the average CPU frequency.

Reporting the average CPU frequency helps confirm the level of turbo
boost being achieved per CPU.

Signed-off-by: Malcolm Crossley 
---
 tools/misc/xenpm.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 08f2242..40cdd55 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -45,6 +45,8 @@ void show_help(void)
 "xenpm command list:\n\n"
 " get-cpuidle-states[cpuid]   list cpu idle info of CPU 
 or all\n"
 " get-cpufreq-states[cpuid]   list cpu freq info of CPU 
 or all\n"
+" get-cpufreq-average   [cpuid]   average cpu frequency since 
last invocation\n"
+" for CPU  or all\n"
 " get-cpufreq-para  [cpuid]   list cpu freq parameter of 
CPU  or all\n"
 " set-scaling-maxfreq   [cpuid]   set max cpu frequency  
on CPU \n"
 " or all CPUs\n"
@@ -296,6 +298,9 @@ static int get_pxstat_by_cpuid(xc_interface *xc_handle, int 
cpuid, struct xc_px_
 return ret;
 }
 
+
+static int *avgfreq;
+
 /* show cpu actual average freq information on CPU cpuid */
 static int get_avgfreq_by_cpuid(xc_interface *xc_handle, int cpuid, int 
*avgfreq)
 {
@@ -343,10 +348,44 @@ void pxstat_func(int argc, char *argv[])
 show_pxstat_by_cpuid(xc_handle, cpuid);
 }
 
+static int show_cpufreq_by_cpuid(xc_interface *xc_handle, int cpuid)
+{
+int ret = 0;
+
+ret = get_avgfreq_by_cpuid(xc_handle, cpuid, [cpuid]);
+if ( ret )
+return ret;
+
+printf("cpu id   : %d\n", cpuid);
+printf("average cpu frequency: %d\n", avgfreq[cpuid]);
+printf("\n");
+return 0;
+}
+
+void cpufreq_func(int argc, char *argv[])
+{
+int cpuid = -1;
+
+if ( argc > 0 )
+parse_cpuid(argv[0], );
+
+avgfreq = calloc(max_cpu_nr, sizeof(*avgfreq));
+if ( cpuid < 0 )
+{
+/* show average frequency on all cpus */
+int i;
+for ( i = 0; i < max_cpu_nr; i++ )
+if ( show_cpufreq_by_cpuid(xc_handle, i) == -ENODEV )
+break;
+}
+else
+show_cpufreq_by_cpuid(xc_handle, cpuid);
+free(avgfreq);
+}
+
 static uint64_t usec_start, usec_end;
 static struct xc_cx_stat *cxstat, *cxstat_start, *cxstat_end;
 static struct xc_px_stat *pxstat, *pxstat_start, *pxstat_end;
-static int *avgfreq;
 static uint64_t *sum, *sum_cx, *sum_px;
 
 static void signal_int_handler(int signo)
@@ -1129,6 +1168,7 @@ struct {
 { "help", help_func },
 { "get-cpuidle-states", cxstat_func },
 { "get-cpufreq-states", pxstat_func },
+{ "get-cpufreq-average", cpufreq_func },
 { "start", start_gather_func },
 { "get-cpufreq-para", cpufreq_para_func },
 { "set-scaling-maxfreq", scaling_max_freq_func },
-- 
1.7.12.4


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

Re: [Xen-devel] [PATCH v6 2/5] build: Hook the schedulers into Kconfig

[Dario Faggioli]

On Fri, 2016-01-15 at 11:01 -0600, Jonathan Creekmore wrote:
> Allow the schedulers to be independently enabled or disabled at
> compile-time. To match existing behavior, all four schedulers are
> compiled in by default, although the Credit2, RTDS, and ARINC653 are
> marked EXPERIMENTAL to match their not currently supported status.
> 
> CC: George Dunlap 
> CC: Dario Faggioli 
> Signed-off-by: Jonathan Creekmore 
> Reviewed-by: Doug Goldstein 
> 
> ---
> 
> diff --git a/xen/common/Kconfig b/xen/common/Kconfig
> index eadfc3b..7cc99c7 100644
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> 
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 9f8b214..4df71ee 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile

The above changes looks fine to me, but I really speak almost no
Kconfig. :-/

On the rest of the patch, I only have one comment.

> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index d121896..2f98a48 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -65,10 +65,18 @@ DEFINE_PER_CPU(struct schedule_data,
> schedule_data);
>  DEFINE_PER_CPU(struct scheduler *, scheduler);
>  
>  static const struct scheduler *schedulers[] = {
> +#ifdef CONFIG_SCHED_CREDIT
>  _credit_def,
> +#endif
>
If I understood correctly, Credit is always going to be there, so I
guess these #ifdef could go away?

However, since this is just killed later, I don't think it should block
the patch (series). So:

Acked-by: Dario Faggioli 

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



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

Re: [Xen-devel] [PATCH v3 4/4] x86/PV: enable the emulated PIT

[Andrew Cooper]

On 19/01/16 10:28, Ian Campbell wrote:
> On Tue, 2016-01-19 at 10:09 +, Andrew Cooper wrote:
>> On 19/01/16 09:24, Ian Campbell wrote:
>>> On Mon, 2016-01-18 at 18:03 +, Andrew Cooper wrote:
 On 18/01/16 17:58, Roger Pau Monné wrote:
> El 18/01/16 a les 11.41, Andrew Cooper ha escrit:
>> On 18/01/16 09:44, Jan Beulich wrote:
>> On 18.01.16 at 10:29,  wrote:
 On 18/01/2016 07:43, Jan Beulich wrote:
 On 15.01.16 at 18:45,  wrote:
>> Changes since v2:
>>  - Change 'if ( (a && b) || (!a && c) )' into 'if ( a ? b
>> : c
>> )'.
> Thanks, but after some more thinking about it I'm afraid
> there
> are
> a few more aspects to consider here:
>
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -542,8 +542,9 @@ int arch_domain_create(struct domain
>> *d,
>> unsigned int 
 domcr_flags,
>> d->domain_id, config-
>>> emulation_flags);
>>  return -EINVAL;
>>  }
>> -if ( config->emulation_flags != 0 &&
>> - (!is_hvm_domain(d) || config-
>>> emulation_flags
>> != XEN_X86_EMU_ALL) 
 )
>> +if ( is_hvm_domain(d) ? (config->emulation_flags 
>> !=
>> XEN_X86_EMU_ALL &&
>> + config->emulation_flags != 0) :
>> + (config->emulation_flags !=
>> XEN_X86_EMU_PIT) )
>>  {
> For one I think it would be a good idea to allow zero for
> PV
> domains,
> and perhaps even default new DomU-s to have the PIT flag
> clear.
> (Also - indentation.)
>
> Which gets us to the second, broader issue: These flags
> shouldn't
> be forced to a particular value during migration, but
> instead
> they
> should be part of the state getting migrated. Incoming
> domains
> then would - if the field is missing due to coming from an
> older
> hypervisor - have the flag default to 1.
 There is sadly another ratsnest here.
>>> I've been afraid of that.
>>>
 These values are needed for domain creation, which means that
 putting
 them anywhere in the migration stream is already too late, as
 the
 domain
 has been created before the stream header is read.
>>> Is that an inherent requirement, or just a result of current
>>> code
>>> structure?
>> Depends.  As far as libxc/libxl migration levels go, current code
>> structure.
>>
>> Whatever (eventually) gets used to set these values will however
>> be
>> present in the xl configuration, which is at the very start of
>> the
>> stream, and is what is used to create the new domain.
>>
>> We really don't want the libxc migrate code to be making the
>> DOMCTL_createdomain hypercall itself; it opens up a whole new
>> attack
>> surface via cunningly-crafted save image.  The best we can do is
>> have
>> a
>> sanity check later on.
>>
>>>  I ask because migrating the emulation flags is going to
>>> be a requirement for relaxing the current (almost) all-or-
>>> nothing
>>> policy on those flags.
>>>
 In principle, the best which could occur is that a value gets
 stashed in
 the stream and used as a sanity check.  That will at least
 catch
 the
 case when they are different.
>>> That'd be a minimal first step.
>> This is a substantial quantity of work to do properly.  As the
>> emulation
>> flags are just one in a very long list of fields handed like
>> this, I
>> don't think this issue should block the series.
> You certainly are more familiar with the migration code than me,
> but
> wouldn't it be enough to add a new field to libxl_domain_build_info
> (uint32_t emulation_flags), and teach
> libxl_domain_build_info_gen_json/libxl__domain_build_info_parse_jso
> n
>  how to properly parse it?
 That would let it be configured from an xl.cfg file, and would
 normally
 be moved in the migration stream.  However, there is a specific
 option
 in xl to restore but using a brand new configuration file.

 What it doesn't do it check that the settings for the domain in the
 stream match the settings of the domid being restored into.
>>> That would be the responsibility of the user who has chosen to override
>>> the
>>> configuration in this way.
>> It is the responsibility of Xen to ensure there are no exploitable holes
>> due to partial or misconfiguration.
> Indeed, but it only needs to check things and fail, not work in the face of
> a bogus save file + cfg 

Re: [Xen-devel] [PATCH v5 3/6] remus: resume immediately if libxl__xc_domain_save_done() completes

[Ian Campbell]

On Tue, 2016-01-19 at 15:17 +0800, Wen Congyang wrote:
> For example: if the secondary host is down, and we fail to send the data
> to
> the secondary host. xc_domain_save() returns 0. So in the function
> libxl__xc_domain_save_done(), rc is 0 (the helper program exits
> normally),
> and retval is 0 (it is xc_domain_save()'s return value). In such case, we
> just need to complete the stream.
> 
> Signed-off-by: Wen Congyang 
> Reviewed-by: Andrew Cooper 
> ---
>  tools/libxl/libxl.h  |  4 
>  tools/libxl/libxl_stream_write.c | 14 --
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 7114491..df6c7a3 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1215,6 +1215,10 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t
> domid, int suspend_cancel,
>  const libxl_asyncop_how *ao_how)
>  LIBXL_EXTERNAL_CALLERS_ONLY;
>  
> +/*
> + * This function doesn't return until something is wrong, and we need to
> + * do failover from secondary.

This function runs on the primary, doesn't it? and failover would be from
primary to secondary.

So I think a more accurate wording would be:

/*
 * This function doesn't return unless something has gone wrong with the
 * replication to the secondary. If this function returns then the caller 
 * should resume the (primary) domain.
 */

I'm happy to edit the text on commit if you agree with the proposed
wording. The code looks good.

Thanks,
Ian.


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

Re: [Xen-devel] [PATCH v4 2/5] remus: resume immediately if libxl__xc_domain_save_done() completes

[Ian Campbell]

On Tue, 2016-01-19 at 09:01 +0800, Wen Congyang wrote:
> On 01/19/2016 12:51 AM, Ian Campbell wrote:
> > On Mon, 2016-01-18 at 13:40 +0800, Wen Congyang wrote:
> > > For example: if the secondary host is down, and we fail to send the
> > > data to
> > > the secondary host. xc_domain_save() returns 0. So in the function
> > > libxl__xc_domain_save_done(), rc is 0(the helper program exits
> > > normally),
> > > and retval is 0(it is xc_domain_save()'s return value). In such case,
> > > we
> > > just need to complete the stream.
> > 
> > What if the secondary host isn't actually down but just communication
> > has
> > failed for some reason? Won't both primary and secondary start their
> > respective versions of the domain? What are the consequences of that?
> > (Corruption?)
> > 
> > I suppose this is a consequence of the lack of STONITH or splitbrain
> > handling within Remus. Are there any plans to address this?
> 
> IIRC, Shriram Rajagopalan has some ideas about it(check the external 
> heartbeat?).
> There is no way to avoid splitbrain unless we have more than two hosts(at 
> least
> three hosts). If we want to avoid splitbrain, we may need to destroy both 
> primary
> and secondary guests.

I think there's plenty of existing systems for taking care of this side of
fault-tolerance/HA (e.g. linux-ha, Pacemaker, Corosync, etc), we don't need
(or want) to reinvent that particular wheel here.

I think we just need a story on how one would integrate with such a system
in order to say that Remus is properly usable in real world scenarios (i.e.
before we can remove the "proof-of-concept" wording from the man page).

That might just be a documentation exercise, or it might require some hooks
etc adding to (lib)xl in order to allow such integrations, I'm not sure
what's needed.

IIRC Ian expressed a similar sentiment when Remus support was first added
to libxl.

Ian.

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

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

[Ian Campbell]

On Tue, 2016-01-19 at 10:50 +, Malcolm Crossley wrote:
> The average is calculated over the period of time from the last
> xenpm report of the average CPU frequency.
> 
> Reporting the average CPU frequency helps confirm the level of turbo
> boost being achieved per CPU.
> 
> Signed-off-by: Malcolm Crossley 
> ---
>  tools/misc/xenpm.c | 42 +-
>  1 file changed, 41 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
> index 08f2242..40cdd55 100644
> --- a/tools/misc/xenpm.c
> +++ b/tools/misc/xenpm.c
> @@ -45,6 +45,8 @@ void show_help(void)
>  "xenpm command list:\n\n"
>  " get-cpuidle-states[cpuid]   list cpu idle info of
> CPU  or all\n"
>  " get-cpufreq-states[cpuid]   list cpu freq info of
> CPU  or all\n"
> +" get-cpufreq-average   [cpuid]   average cpu frequency
> since last invocation\n"
> +" for CPU  or
> all\n"
>  " get-cpufreq-para  [cpuid]   list cpu freq
> parameter of CPU  or all\n"
>  " set-scaling-maxfreq   [cpuid]   set max cpu frequency
>  on CPU \n"
>  " or all CPUs\n"
> @@ -296,6 +298,9 @@ static int get_pxstat_by_cpuid(xc_interface
> *xc_handle, int cpuid, struct xc_px_
>  return ret;
>  }
>  
> +
> +static int *avgfreq;

Do we need the global array of them all when each element is used exactly
once entirely within show_cpufreq_by_cpuid in this mode?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH v10 2/3] Differentiate IO/mem resources tracked by ioreq server

[Yu Zhang]

Currently in ioreq server, guest write-protected ram pages are
tracked in the same rangeset with device mmio resources. Yet
unlike device mmio, which can be in big chunks, the guest write-
protected pages may be discrete ranges with 4K bytes each. This
patch uses a seperate rangeset for the guest ram pages.

To differentiate the ioreq type between the write-protected memory
ranges and the mmio ranges when selecting an ioreq server, the p2m
type is retrieved by calling get_page_from_gfn(). And we do not
need to worry about the p2m type change during the ioreq selection
process.

Note: Previously, a new hypercall or subop was suggested to map
write-protected pages into ioreq server. However, it turned out
handler of this new hypercall would be almost the same with the
existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
already a type parameter in this hypercall. So no new hypercall
defined, only a new type is introduced.

Acked-by: Wei Liu 
Acked-by: Ian Campbell 
Reviewed-by: Kevin Tian 
Signed-off-by: Shuai Ruan 
Signed-off-by: Yu Zhang 
---
 tools/libxc/include/xenctrl.h| 31 
 tools/libxc/xc_domain.c  | 61 
 xen/arch/x86/hvm/hvm.c   | 27 +++---
 xen/include/asm-x86/hvm/domain.h |  2 +-
 xen/include/public/hvm/hvm_op.h  |  1 +
 5 files changed, 117 insertions(+), 5 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 079cad0..036c72d 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2023,6 +2023,37 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface 
*xch,
 int is_mmio,
 uint64_t start,
 uint64_t end);
+/**
+ * This function registers a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_map_wp_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
+
+/**
+ * This function deregisters a range of write-protected memory for emulation.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id to be serviced
+ * @parm id the IOREQ Server id.
+ * @parm start start of range
+ * @parm end end of range (inclusive).
+ * @return 0 on success, -1 on failure.
+ */
+int xc_hvm_unmap_wp_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end);
 
 /**
  * This function registers a PCI device for config space emulation.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 99e0d48..4f43695 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1544,6 +1544,67 @@ int xc_hvm_unmap_io_range_from_ioreq_server(xc_interface 
*xch, domid_t domid,
 return rc;
 }
 
+int xc_hvm_map_wp_mem_range_to_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
+if ( arg == NULL )
+return -1;
+
+hypercall.op = __HYPERVISOR_hvm_op;
+hypercall.arg[0] = HVMOP_map_io_range_to_ioreq_server;
+hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
+
+arg->domid = domid;
+arg->id = id;
+arg->type = HVMOP_IO_RANGE_WP_MEM;
+arg->start = start;
+arg->end = end;
+
+rc = do_xen_hypercall(xch, );
+
+xc_hypercall_buffer_free(xch, arg);
+return rc;
+}
+
+int xc_hvm_unmap_wp_mem_range_from_ioreq_server(xc_interface *xch,
+domid_t domid,
+ioservid_t id,
+xen_pfn_t start,
+xen_pfn_t end)
+{
+DECLARE_HYPERCALL;
+DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
+int rc;
+
+arg = 

[Xen-devel] [PATCH v10 0/3] Refactor ioreq server for better performance.

[Yu Zhang]

XenGT leverages ioreq server to track and forward the accesses to
GPU I/O resources, e.g. the PPGTT(per-process graphic translation
tables). Currently, ioreq server uses rangeset to track the BDF/
PIO/MMIO ranges to be emulated. To select an ioreq server, the 
rangeset is searched to see if the I/O range is recorded. However,
traversing the link list inside rangeset could be time consuming
when number of ranges is too high. On HSW platform, number of PPGTTs
for each vGPU could be several hundred. On BDW, this value could
be several thousand.  This patch series refactored rangeset to base
it on red-back tree, so that the searching would be more efficient. 

Besides, this patchset also splits the tracking of MMIO and guest
ram ranges into different rangesets. And to accommodate more ranges,
a new parameter , max_ranges, is introduced in hvm configuration file.

Changes in v10: 
1> Add a new patch to configure the range limit inside ioreq server.
2> Commit message changes. 
3> The previous patch "[1/3] Remove identical relationship between
   ioreq type and rangeset type." has already been merged, and is not
   included in this series now.

Changes in v9: 
1> Change order of patch 2 and patch3.
2> Intruduce a const static array before hvm_ioreq_server_alloc_rangesets().
3> Coding style changes.

Changes in v8: 
Use a clearer API name to map/unmap the write-protected memory in
ioreq server.

Changes in v7: 
1> Coding style changes;
2> Fix a typo in hvm_select_ioreq_server().

Changes in v6: 
Break the identical relationship between ioreq type and rangeset
index inside ioreq server.

Changes in v5:
1> Use gpfn, instead of gpa to track guest write-protected pages;
2> Remove redundant conditional statement in routine find_range().

Changes in v4:
Keep the name HVMOP_IO_RANGE_MEMORY for MMIO resources, and add
a new one, HVMOP_IO_RANGE_WP_MEM, for write-protected memory.

Changes in v3:
1> Use a seperate rangeset for guest ram pages in ioreq server;
2> Refactor rangeset, instead of introduce a new data structure.

Changes in v2:
1> Split the original patch into 2;
2> Take Paul Durrant's comments:
  a> Add a name member in the struct rb_rangeset, and use the 'q'
debug key to dump the ranges in ioreq server;
  b> Keep original routine names for hvm ioreq server;
  c> Commit message changes - mention that a future patch to change
the maximum ranges inside ioreq server.

Yu Zhang (3):
  Refactor rangeset structure for better performance.
  Differentiate IO/mem resources tracked by ioreq server
  tools: introduce parameter max_ranges.

 docs/man/xl.cfg.pod.5| 17 +
 tools/libxc/include/xenctrl.h| 31 +++
 tools/libxc/xc_domain.c  | 61 ++
 tools/libxl/libxl_dom.c  |  3 ++
 tools/libxl/libxl_types.idl  |  1 +
 tools/libxl/xl_cmdimpl.c |  4 ++
 xen/arch/x86/hvm/hvm.c   | 34 ++---
 xen/common/rangeset.c| 82 +---
 xen/include/asm-x86/hvm/domain.h |  2 +-
 xen/include/public/hvm/hvm_op.h  |  1 +
 xen/include/public/hvm/params.h  |  5 ++-
 11 files changed, 212 insertions(+), 29 deletions(-)

-- 
1.9.1


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

[Xen-devel] [PATCH 3/3] tools: introduce parameter max_ranges.

[Yu Zhang]

A new parameter - max_ranges is added to set the upper limit of ranges
to be tracked inside one ioreq server rangeset.

Ioreq server uses a group of rangesets to track the I/O or memory
resources to be emulated. The default value of this limit is set to
256. Yet there are circumstances under which the limit should exceed
the default one. E.g. in XenGT, when tracking the per-process graphic
translation tables on intel broadwell platforms, the number of page
tables concerned will be several thousand(normally in this case, 8192
could be a big enough value). Users who set his item explicitly are
supposed to know the specific scenarios that necessitate this
configuration.

Signed-off-by: Yu Zhang 
---
 docs/man/xl.cfg.pod.5   | 17 +
 tools/libxl/libxl_dom.c |  3 +++
 tools/libxl/libxl_types.idl |  1 +
 tools/libxl/xl_cmdimpl.c|  4 
 xen/arch/x86/hvm/hvm.c  |  7 ++-
 xen/include/public/hvm/params.h |  5 -
 6 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index 8899f75..562563d 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -962,6 +962,23 @@ FIFO-based event channel ABI support up to 131,071 event 
channels.
 Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
 x86).
 
+=item 

[Xen-devel] [PATCH v10 1/3] Refactor rangeset structure for better performance.

[Yu Zhang]

This patch refactors struct rangeset to base it on the red-black
tree structure, instead of on the current doubly linked list. By
now, ioreq leverages rangeset to keep track of the IO/memory
resources to be emulated. Yet when number of ranges inside one
ioreq server is very high, traversing a doubly linked list could
be time consuming. With this patch, the time complexity for
searching a rangeset can be improved from O(n) to O(log(n)).
Interfaces of rangeset still remain the same, and no new APIs
introduced.

Reviewed-by: Paul Durrant 
Signed-off-by: Shuai Ruan 
Signed-off-by: Yu Zhang 
---
 xen/common/rangeset.c | 82 +--
 1 file changed, 60 insertions(+), 22 deletions(-)

diff --git a/xen/common/rangeset.c b/xen/common/rangeset.c
index 6c6293c..d15d8d5 100644
--- a/xen/common/rangeset.c
+++ b/xen/common/rangeset.c
@@ -10,11 +10,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /* An inclusive range [s,e] and pointer to next range in ascending order. */
 struct range {
-struct list_head list;
+struct rb_node node;
 unsigned long s, e;
 };
 
@@ -24,7 +25,7 @@ struct rangeset {
 struct domain   *domain;
 
 /* Ordered list of ranges contained in this set, and protecting lock. */
-struct list_head range_list;
+struct rb_root   range_tree;
 
 /* Number of ranges that can be allocated */
 long nr_ranges;
@@ -45,41 +46,78 @@ struct rangeset {
 static struct range *find_range(
 struct rangeset *r, unsigned long s)
 {
-struct range *x = NULL, *y;
+struct rb_node *node;
+struct range   *x;
+struct range   *prev = NULL;
 
-list_for_each_entry ( y, >range_list, list )
+node = r->range_tree.rb_node;
+while ( node != NULL )
 {
-if ( y->s > s )
-break;
-x = y;
+x = container_of(node, struct range, node);
+if ( (s >= x->s) && (s <= x->e) )
+return x;
+if ( s < x->s )
+node = node->rb_left;
+else
+{
+prev = x;
+node = node->rb_right;
+}
 }
 
-return x;
+return prev;
 }
 
 /* Return the lowest range in the set r, or NULL if r is empty. */
 static struct range *first_range(
 struct rangeset *r)
 {
-if ( list_empty(>range_list) )
-return NULL;
-return list_entry(r->range_list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_first(>range_tree);
+if ( node != NULL )
+return container_of(node, struct range, node);
+
+return NULL;
 }
 
 /* Return range following x in ascending order, or NULL if x is the highest. */
 static struct range *next_range(
 struct rangeset *r, struct range *x)
 {
-if ( x->list.next == >range_list )
-return NULL;
-return list_entry(x->list.next, struct range, list);
+struct rb_node *node;
+
+node = rb_next(>node);
+if ( node != NULL )
+return container_of(node, struct range, node);
+
+return NULL;
 }
 
 /* Insert range y after range x in r. Insert as first range if x is NULL. */
 static void insert_range(
 struct rangeset *r, struct range *x, struct range *y)
 {
-list_add(>list, (x != NULL) ? >list : >range_list);
+struct rb_node **node;
+struct rb_node *parent = NULL;
+
+if ( x == NULL )
+node = >range_tree.rb_node;
+else
+{
+node = >node.rb_right;
+parent = >node;
+}
+
+while ( *node != NULL )
+{
+parent = *node;
+node = >rb_left;
+}
+
+/* Add new node and rebalance the red-black tree. */
+rb_link_node(>node, parent, node);
+rb_insert_color(>node, >range_tree);
 }
 
 /* Remove a range from its list and free it. */
@@ -88,7 +126,7 @@ static void destroy_range(
 {
 r->nr_ranges++;
 
-list_del(>list);
+rb_erase(>node, >range_tree);
 xfree(x);
 }
 
@@ -319,7 +357,7 @@ bool_t rangeset_contains_singleton(
 bool_t rangeset_is_empty(
 const struct rangeset *r)
 {
-return ((r == NULL) || list_empty(>range_list));
+return ((r == NULL) || RB_EMPTY_ROOT(>range_tree));
 }
 
 struct rangeset *rangeset_new(
@@ -332,7 +370,7 @@ struct rangeset *rangeset_new(
 return NULL;
 
 rwlock_init(>lock);
-INIT_LIST_HEAD(>range_list);
+r->range_tree = RB_ROOT;
 r->nr_ranges = -1;
 
 BUG_ON(flags & ~RANGESETF_prettyprint_hex);
@@ -410,7 +448,7 @@ void rangeset_domain_destroy(
 
 void rangeset_swap(struct rangeset *a, struct rangeset *b)
 {
-LIST_HEAD(tmp);
+struct rb_node *tmp;
 
 if ( a < b )
 {
@@ -423,9 +461,9 @@ void rangeset_swap(struct rangeset *a, struct rangeset *b)
 write_lock(>lock);
 }
 
-list_splice_init(>range_list, );
-list_splice_init(>range_list, >range_list);
-list_splice(, >range_list);
+tmp = a->range_tree.rb_node;
+a->range_tree.rb_node = 

Re: [Xen-devel] [PATCH] xen: Improvements to clean and distclean targets

[Ian Campbell]

On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote:
> > > > On 18.01.16 at 19:19,  wrote:
> > On 18/01/16 16:57, Jan Beulich wrote:
> > > > > > On 18.01.16 at 17:45,  wrote:
> > > > On 18/01/16 16:41, Jan Beulich wrote:
> > > > > > > > On 18.01.16 at 17:27,  wrote:
> > > > > > * Move '*~' and 'core' into the find rule.
> > > > > I don't understand this part: Where in the build process do such
> > > > > get
> > > > > generated? I'm tempted to instead recommend to just drop those
> > > > > from the rm invocation...
> > > > No idea about 'core' files, but *~ are emacs backup files.
> > > But emacs should clean up after itself; this shouldn't be the job
> > > of our clean rule.
> > 
> > Why? the point is to have a one-revision old version of the file to
> > hand.
> 
> I guess there may be different strategies here: My editor also
> creates such named files, but deletes them as the program gets
> shut down. I.e. the one-revision old backup exists as long as the
> program is running. I can see benefits from the alternative
> model, but still it shouldn't be our scripts to clean up such backups.
> After all - what if another program used another name patter for
> its backups? Would we go clean those up then too?

IMHO these files should be in .gitignore (so they don't clutter "git
status", AFAICT this is already done correctly) but it's not really
necessary for "make clean" (or distclean) to get rid of them, that's up to
either the editor or the user. IOW I'd be happy removing the existing
rules.

Removing "core" is even odder -- it implies people have been running
segfaulting binaries directory out of the source tree, which is a little
odd for tools/* but very odd for xen/*. I suppose one could argue that if
some host binary run by the build system segfaults (and causes a build
failure) that make clean ought to clean it up, that's a very edge case IMHO
and, if arguing for doing it at all, would argue either for only doing "rm
core" in directories which have such host build tools or doing it in a
central/common location, but not spread around every subdirectory on the
off chance there might be such a segfaulting binary in the future.

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

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

Re: [Xen-devel] [PATCH] x86: Convert shadow-paging to Kconfig

[Ian Campbell]

On Mon, 2016-01-18 at 18:40 +, Andrew Cooper wrote:
> Signed-off-by: Andrew Cooper 

Does this have any impact on migration of either PV or HVM guests? What
about nested virt?

Are things which are defined in xen/arch/*/Rules.mk in this way
overrideable from the old top-level .config or does one need to dive deeper
to modify them? If it's not configurable from top-level .config today then
I think it either needs a "depends EXPERT" or for the changelog to make a
convincing argument why this should be made user selectable.

Lastly, Tim is maintainer of the shadow code and should have been CC-d,
also George as maintainer of the mm stuff might have an interest. Both CC-s 
added.

> ---
> CC: Jan Beulich 
> CC: Doug Goldstein 
> ---
>  xen/arch/x86/Kconfig| 14 ++
>  xen/arch/x86/Rules.mk   |  4 
>  xen/arch/x86/mm/shadow/Makefile |  2 +-
>  3 files changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 4781b34..9869630 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -27,6 +27,20 @@ menu "Architecture Features"
>  
>  source "arch/Kconfig"
>  
> +config SHADOW_PAGING
> +bool "Shadow Paging"
> +default y
> +---help---
> +  Shadow paging is a software alternative to hardware paging
> support
> +  (Intel EPT, AMD NPT) for use with HVM guests.
> +
> +  It is required to run HVM guests for first-generation hardware
> +  virtualisation (Intel VT-x, AMD SVM) which did not include
> hardware
> +  paging support.  Under a small number of specific workloads,
> shadow
> +  paging may also be deliberately used as a performance
> improvement.
> +
> +  If unsure, say Y.
> +
>  config BIGMEM
>   bool "big memory support"
>   default n
> diff --git a/xen/arch/x86/Rules.mk b/xen/arch/x86/Rules.mk
> index a108d24..a1cdae0 100644
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -22,13 +22,9 @@ $(call as-insn-check,CFLAGS,CC,".equ \"x\"$$(comma)1",
> \
>   -U__OBJECT_LABEL__ -DHAVE_GAS_QUOTED_SYM \
>   '-D__OBJECT_LABEL__=$(subst
> $(BASEDIR)/,,$(CURDIR))/$$@')
>  
> -shadow-paging ?= y
> -
>  CFLAGS += -mno-red-zone -mno-sse -fpic
>  CFLAGS += -fno-asynchronous-unwind-tables
>  # -fvisibility=hidden reduces -fpic cost, if it's available
>  ifneq ($(call cc-option,$(CC),-fvisibility=hidden,n),n)
>  CFLAGS += -DGCC_HAS_VISIBILITY_ATTRIBUTE
>  endif
> -
> -CFLAGS-$(shadow-paging) += -DCONFIG_SHADOW_PAGING
> diff --git a/xen/arch/x86/mm/shadow/Makefile
> b/xen/arch/x86/mm/shadow/Makefile
> index a07bc0c..df194ad 100644
> --- a/xen/arch/x86/mm/shadow/Makefile
> +++ b/xen/arch/x86/mm/shadow/Makefile
> @@ -1,4 +1,4 @@
> -ifeq ($(shadow-paging),y)
> +ifdef CONFIG_SHADOW_PAGING
>  obj-y += common.o guest_2.o guest_3.o guest_4.o
>  else
>  obj-y += none.o

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

Re: [Xen-devel] [PATCH v10 2/3] Differentiate IO/mem resources tracked by ioreq server

[Paul Durrant]

> -Original Message-
> From: Yu Zhang [mailto:yu.c.zh...@linux.intel.com]
> Sent: 19 January 2016 09:28
> To: xen-devel@lists.xen.org
> Cc: Paul Durrant; Stefano Stabellini; Keir (Xen.org); jbeul...@suse.com;
> Andrew Cooper; Wei Liu; Kevin Tian; zhiyuan...@intel.com
> Subject: [PATCH v10 2/3] Differentiate IO/mem resources tracked by ioreq
> server
> 
> Currently in ioreq server, guest write-protected ram pages are
> tracked in the same rangeset with device mmio resources. Yet
> unlike device mmio, which can be in big chunks, the guest write-
> protected pages may be discrete ranges with 4K bytes each. This
> patch uses a seperate rangeset for the guest ram pages.
> 
> To differentiate the ioreq type between the write-protected memory
> ranges and the mmio ranges when selecting an ioreq server, the p2m
> type is retrieved by calling get_page_from_gfn(). And we do not
> need to worry about the p2m type change during the ioreq selection
> process.
> 
> Note: Previously, a new hypercall or subop was suggested to map
> write-protected pages into ioreq server. However, it turned out
> handler of this new hypercall would be almost the same with the
> existing pair - HVMOP_[un]map_io_range_to_ioreq_server, and there's
> already a type parameter in this hypercall. So no new hypercall
> defined, only a new type is introduced.
> 
> Acked-by: Wei Liu 
> Acked-by: Ian Campbell 
> Reviewed-by: Kevin Tian 
> Signed-off-by: Shuai Ruan 
> Signed-off-by: Yu Zhang 

Reviewed-by: Paul Durrant 

> ---
>  tools/libxc/include/xenctrl.h| 31 
>  tools/libxc/xc_domain.c  | 61
> 
>  xen/arch/x86/hvm/hvm.c   | 27 +++---
>  xen/include/asm-x86/hvm/domain.h |  2 +-
>  xen/include/public/hvm/hvm_op.h  |  1 +
>  5 files changed, 117 insertions(+), 5 deletions(-)
> 
> diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
> index 079cad0..036c72d 100644
> --- a/tools/libxc/include/xenctrl.h
> +++ b/tools/libxc/include/xenctrl.h
> @@ -2023,6 +2023,37 @@ int
> xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch,
>  int is_mmio,
>  uint64_t start,
>  uint64_t end);
> +/**
> + * This function registers a range of write-protected memory for emulation.
> + *
> + * @parm xch a handle to an open hypervisor interface.
> + * @parm domid the domain id to be serviced
> + * @parm id the IOREQ Server id.
> + * @parm start start of range
> + * @parm end end of range (inclusive).
> + * @return 0 on success, -1 on failure.
> + */
> +int xc_hvm_map_wp_mem_range_to_ioreq_server(xc_interface *xch,
> +domid_t domid,
> +ioservid_t id,
> +xen_pfn_t start,
> +xen_pfn_t end);
> +
> +/**
> + * This function deregisters a range of write-protected memory for
> emulation.
> + *
> + * @parm xch a handle to an open hypervisor interface.
> + * @parm domid the domain id to be serviced
> + * @parm id the IOREQ Server id.
> + * @parm start start of range
> + * @parm end end of range (inclusive).
> + * @return 0 on success, -1 on failure.
> + */
> +int xc_hvm_unmap_wp_mem_range_from_ioreq_server(xc_interface
> *xch,
> +domid_t domid,
> +ioservid_t id,
> +xen_pfn_t start,
> +xen_pfn_t end);
> 
>  /**
>   * This function registers a PCI device for config space emulation.
> diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
> index 99e0d48..4f43695 100644
> --- a/tools/libxc/xc_domain.c
> +++ b/tools/libxc/xc_domain.c
> @@ -1544,6 +1544,67 @@ int
> xc_hvm_unmap_io_range_from_ioreq_server(xc_interface *xch, domid_t
> domid,
>  return rc;
>  }
> 
> +int xc_hvm_map_wp_mem_range_to_ioreq_server(xc_interface *xch,
> +domid_t domid,
> +ioservid_t id,
> +xen_pfn_t start,
> +xen_pfn_t end)
> +{
> +DECLARE_HYPERCALL;
> +DECLARE_HYPERCALL_BUFFER(xen_hvm_io_range_t, arg);
> +int rc;
> +
> +arg = xc_hypercall_buffer_alloc(xch, arg, sizeof(*arg));
> +if ( arg == NULL )
> +return -1;
> +
> +hypercall.op = __HYPERVISOR_hvm_op;
> +hypercall.arg[0] = HVMOP_map_io_range_to_ioreq_server;
> +hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
> +
> +arg->domid = domid;
> +arg->id = id;
> +

Re: [Xen-devel] [PATCH] tools/toollog: Drop XTL_NEW_LOGGER()

[Wei Liu]

On Thu, Jan 14, 2016 at 08:13:45PM +, Andrew Cooper wrote:
> XTL_NEW_LOGGER() makes a number of unreasonable assumptions about the symbols
> visible in its scope, and as such is only usable by its sole caller.
> 
> Remove it.
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [RFC/WIP] xen: clk: introudce pvclk for device passthrough

[Ian Campbell]

On Tue, 2016-01-19 at 10:43 +0800, Peng Fan wrote:
> Hello Ian,
> 
> On Mon, Jan 18, 2016 at 12:41:59PM +, Ian Campbell wrote:
> > On Mon, 2016-01-18 at 11:24 +, David Vrabel wrote:
> > > On 16/01/16 05:22, Peng Fan wrote:
> > > > This patch was just a initial patch, not sure whether this way
> > > > is ok from you side for handlding clk when doing platform device
> > > > passhthrough. Any comments are appreciated, and your comments may
> > > > give me a better direction.
> > > 
> > > There's no documentation on the interface, which makes it difficult
> > > to
> > > review.  At a first look it looks very specific to the particular
> > > Linux
> > > implementation of a clk subsystem.
> > > 
> > > > --- /dev/null
> > > > +++ b/include/xen/interface/io/clkif.h
> > > > @@ -0,0 +1,41 @@
> > > > +/*
> > > > + * The code contained herein is licensed under the GNU General
> > > > Public
> > > > + * License. You may obtain a copy of the GNU General Public
> > > > License
> > > > + * Version 2 or later at the following locations:
> > > > + *
> > > > + * http://www.opensource.org/licenses/gpl-license.html
> > > > + * http://www.gnu.org/copyleft/gpl.html
> > > > + */
> > > 
> > > ABIs should be under a more permissive license so they can be used by
> > > other (non-GPLv2) operating systems.
> > 
> > ... along the same lines proposals for new ABIs should be made in the
> > form
> > of patches to xen.git:xen/include/public/io/ before being submitted as
> > an
> > implementation for one particular os.
> 
> I had no idea about this before. Do you mean that before I implement
> pvclk for linux, I need to first post the clkif part to xen devel?
> 
> If it is, I'll split the interface part and send this part to
> xen-de...@lists.xenproject.org for review.

Yes, please.

xen.git contains the canonical definition of all Xen PV protocols, copies
are then taking into OSes for implementation purposes.

> 
> > 
> > 
> > > > +   unsigned long rate;
> > > > +   char clk_name[32];
> > > 
> > > Where does the frontend get these names from?  31 character names
> > > seems
> > > rather limiting.
> > 
> > Indeed.
> > 
> > At a guess I would assume they come from the device-tree given to the
> > guest
> > and tie into the host device tree.
> 
> Yeah. the clk_name is got from DomU dts, and in Dom0 there is also a same
> name.
> 
> > 
> > I think a better model might be for each clk to have it's own
> > subdirectory
> > under the overall clock bus node, e.g. something like:
> > 
> > /local/domain/<...>/clk/0/nr-clks = 4
> > /local/domain/<...>/clk/0/clk-0/ ...
> > /local/domain/<...>/clk/0/clk-1/ ...
> > /lo
> > cal/domain/<...>/clk/0/clk-2/ ...
> > /local/domain/<...>/clk/0/clk-3/ ...
> > 
> > and for each subdirectory to contain the a node containing the
> > corresponding firmware table identifier (so path in the DT case), which
> > the toolstack knows, so it can setup the f/e and b/e to correspond as
> > necessary, and the f/e device needn't necessarily use the same name as
> > the backend/host).
> > 
> > The request would then include the index and not the name (and as David
> > observes the response only needs the id).
> 
> For now, I have not began the userspace libxl part for pvclk, I use the
> libxl pvusb code for test (:

Sure, but eventually this will need implementing in the toolstack and the
protocol design should be what is most suitable for the usecase, not what
happens to be most convenient for testing via some quick hack.

> The id acctually means what operation is needed, such as CLK_PREPARE,
> CLK_UNPREPARE, CLK_SET_RATE, CLK_GET_RATE. I'll add more text to document
> this in V2.

Ah, then for consistency with other PV protocols I would suggest renaming
your "id" as "cmd" and adding an "id" field which is simply echoed in the
response to allow the frontend to match responses to requests.

Note however that the important thing in my paragraphs above was the
decoupling of the naming from the f/e and b/e and avoiding the use of the
DT specific path in the ring requests.

The PV protocol should ideally be independent of DT (lets assume we will
want to use it for e.g. ACPI too), although there would probably in this
case need to be a binding from the DT world to the pvclk world to allow the
guest DT to remain consistent (i.e. so devices have something they can
point at which can be resolved into a pvclk).

> > 
> > I'd also like to see a description of the DT bindings, which I assume
> > must be needed such that the devices clocks property has something to
> > refer to. For example maybe it doesn't make sense for xenstore to
> > contain the path, but for the pvclk node in xenstore to contain the
> > index.
> 
> The DT bindings for xen pvclk, I use this:
> "
> clks: clks {
>   compatible = "xen,xen-clk";
>   #clock-cells = <1>;
>   clock-output-names = "uart2_root_clk";
>   };
> "
> the clock-output-names will be parsed and 

Re: [Xen-devel] [PATCH] xen: Improvements to clean and distclean targets

[Juergen Gross]

On 19/01/16 10:38, Ian Campbell wrote:
> On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote:
> On 18.01.16 at 19:19,  wrote:
>>> On 18/01/16 16:57, Jan Beulich wrote:
>>> On 18.01.16 at 17:45,  wrote:
> On 18/01/16 16:41, Jan Beulich wrote:
> On 18.01.16 at 17:27,  wrote:
>>> * Move '*~' and 'core' into the find rule.
>> I don't understand this part: Where in the build process do such
>> get
>> generated? I'm tempted to instead recommend to just drop those
>> from the rm invocation...
> No idea about 'core' files, but *~ are emacs backup files.
 But emacs should clean up after itself; this shouldn't be the job
 of our clean rule.
>>>
>>> Why? the point is to have a one-revision old version of the file to
>>> hand.
>>
>> I guess there may be different strategies here: My editor also
>> creates such named files, but deletes them as the program gets
>> shut down. I.e. the one-revision old backup exists as long as the
>> program is running. I can see benefits from the alternative
>> model, but still it shouldn't be our scripts to clean up such backups.
>> After all - what if another program used another name patter for
>> its backups? Would we go clean those up then too?
> 
> IMHO these files should be in .gitignore (so they don't clutter "git
> status", AFAICT this is already done correctly) but it's not really
> necessary for "make clean" (or distclean) to get rid of them, that's up to
> either the editor or the user. IOW I'd be happy removing the existing
> rules.

What about adding a "make gitclean" which will remove all files ignored
by git? It could use .gitignore (or even "git clean -dffq"). This way
"make [dist]clean" could be limited to the files created by the build
process on purpose.

Juergen

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

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

[Malcolm Crossley]

On 19/01/16 11:06, Ian Campbell wrote:
> On Tue, 2016-01-19 at 10:50 +, Malcolm Crossley wrote:
>> The average is calculated over the period of time from the last
>> xenpm report of the average CPU frequency.
>>
>> Reporting the average CPU frequency helps confirm the level of turbo
>> boost being achieved per CPU.
>>
>> Signed-off-by: Malcolm Crossley 
>> ---
>>  tools/misc/xenpm.c | 42 +-
>>  1 file changed, 41 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
>> index 08f2242..40cdd55 100644
>> --- a/tools/misc/xenpm.c
>> +++ b/tools/misc/xenpm.c
>> @@ -45,6 +45,8 @@ void show_help(void)
>>  "xenpm command list:\n\n"
>>  " get-cpuidle-states[cpuid]   list cpu idle info of
>> CPU  or all\n"
>>  " get-cpufreq-states[cpuid]   list cpu freq info of
>> CPU  or all\n"
>> +" get-cpufreq-average   [cpuid]   average cpu frequency
>> since last invocation\n"
>> +" for CPU  or
>> all\n"
>>  " get-cpufreq-para  [cpuid]   list cpu freq
>> parameter of CPU  or all\n"
>>  " set-scaling-maxfreq   [cpuid]   set max cpu frequency
>>  on CPU \n"
>>  " or all CPUs\n"
>> @@ -296,6 +298,9 @@ static int get_pxstat_by_cpuid(xc_interface
>> *xc_handle, int cpuid, struct xc_px_
>>  return ret;
>>  }
>>  
>> +
>> +static int *avgfreq;
> 
> Do we need the global array of them all when each element is used exactly
> once entirely within show_cpufreq_by_cpuid in this mode?
> 

The global array was already defined for when xenpm is used as a cpu frequency 
control daemon, I
just moved it so that the new functions could use the variable.

Do you want me to spin the patch using a local int variable instead?

Malcolm


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

Re: [Xen-devel] [PATCH v2 01/13] xsplice: Design document (v5).

[Wei Liu]

I skimmed this document and managed to do some non-technical nitpicks.
:-)

On Thu, Jan 14, 2016 at 04:46:59PM -0500, Konrad Rzeszutek Wilk wrote:
[...]
> +## Patching code
> +
> +The first mechanism to patch that comes in mind is in-place replacement.
> +That is replace the affected code with new code. Unfortunately the x86

"replacing" or "to replace"

> +ISA is variable size which places limits on how much space we have available
> +to replace the instructions. That is not a problem if the change is smaller
> +than the original opcode and we can fill it with nops. Problems will
> +appear if the replacement code is longer.
> +
> +The second mechanism is by replacing the call or jump to the
> +old function with the address of the new function.
> +
> +A third mechanism is to add a jump to the new function at the
> +start of the old function. N.B. The Xen hypervisor implements the third
> +mechanism.
> +
> +### Example of trampoline and in-place splicing
> +
> +As example we will assume the hypervisor does not have XSA-132 (see
> +*domctl/sysctl: don't leak hypervisor stack to toolstacks*
> +4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
> +the hypervisor with it. The original code looks as so:
> +
> +
> +   48 89 e0  mov%rsp,%rax  
> +   48 25 00 80 ff ff and$0x8000,%rax  
> +
> +
> +while the new patched hypervisor would be:
> +
> +
> +   48 c7 45 b8 00 00 00 00   movq   $0x0,-0x48(%rbp)  
> +   48 c7 45 c0 00 00 00 00   movq   $0x0,-0x40(%rbp)  
> +   48 c7 45 c8 00 00 00 00   movq   $0x0,-0x38(%rbp)  
> +   48 89 e0  mov%rsp,%rax  
> +   48 25 00 80 ff ff and$0x8000,%rax  
> +
> +
> +This is inside the arch_do_domctl. This new change adds 21 extra
> +bytes of code which alters all the offsets inside the function. To alter
> +these offsets and add the extra 21 bytes of code we might not have enough
> +space in .text to squeeze this in.
> +
> +As such we could simplify this problem by only patching the site
> +which calls arch_do_domctl:
> +
> +
> +:  
> + e8 4b b1 05 00  callq  82d08015fbb9   
> +
> +
> +with a new address for where the new `arch_do_domctl` would be (this
> +area would be allocated dynamically).
> +
> +Astute readers will wonder what we need to do if we were to patch `do_domctl`
> +- which is not called directly by hypervisor but on behalf of the guests via
> +the `compat_hypercall_table` and `hypercall_table`.
> +Patching the offset in `hypercall_table` for `do_domctl:
> +(82d080103079 :)

Blank line here please.

> +
> +
> + 82d08024d490:   79 30  
> + 82d08024d492:   10 80 d0 82 ff ff   
> +
> +

Blank line.

> +with the new address where the new `do_domctl` is possible. The other
> +place where it is used is in `hvm_hypercall64_table` which would need
> +to be patched in a similar way. This would require an in-place splicing
> +of the new virtual address of `arch_do_domctl`.
> +
> +In summary this example patched the callee of the affected function by
> + * allocating memory for the new code to live in,
> + * changing the virtual address in all the functions which called the old
> +   code (computing the new offset, patching the callq with a new callq).
> + * changing the function pointer tables with the new virtual address of
> +   the function (splicing in the new virtual address). Since this table
> +   resides in the .rodata section we would need to temporarily change the
> +   page table permissions during this part.
> +
> +
> +However it has severe drawbacks - the safety checks which have to make sure
> +the function is not on the stack - must also check every caller. For some
> +patches this could mean - if there were an sufficient large amount of
> +callers - that we would never be able to apply the update.
> +
> +### Example of different trampoline patching.
> +
> +An alternative mechanism exists where we can insert a trampoline in the
> +existing function to be patched to jump directly to the new code. This
> +lessens the locations to be patched to one but it puts pressure on the
> +CPU branching logic (I-cache, but it is just one unconditional jump).
> +
> +For this example we will assume that the hypervisor has not been compiled
> +with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
> +for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
> +in `xen_version` hypercall. This function is not called **anywhere** in
> +the hypervisor (it is called by the guest) but referenced in the
> +`compat_hypercall_table` and `hypercall_table` (and indirectly called
> +from that). Patching the offset in `hypercall_table` for the old
> +`do_xen_version` (82d080112f9e )
> +
> +
> + 82d08024b270   
> + ...  
> + 82d08024b2f8:   9e 2f 11 80 d0 82 ff ff  
> +
> +

Blank line.

> +with the new address where the new `do_xen_version` is possible. The other
> +place where it is used is in 

Re: [Xen-devel] [PATCH v4 10/11] dma: rename dma_*_writecombine() to dma_*_wc()

[Ingo Molnar]

* Luis R. Rodriguez  wrote:

> On Tue, Aug 25, 2015 at 9:21 PM, Ingo Molnar  wrote:
> >
> > * Andrew Morton  wrote:
> >
> >> > There's a catch-22 issue here either way, for instance this rename patch 
> >> > has
> >> > been being baked for probably 2 releases already but the difficulty has 
> >> > been
> >> > trying to find the appropriate time to merge it without conflict.
> >> >
> >> > If you do it in the beginning of the merge window, you have to ask 
> >> > yourself in
> >> > what tree it will be done. Since subsystems are topic specific that 
> >> > means that
> >> > subsystem will end up having a conflict at the end of the merge window.
> >>
> >> Yes it's a special case.  I think the best way of handling such things is 
> >> to get
> >> them in to Linus either right at the end of the merge window or the day 
> >> after he
> >> releases -rc1.  This is when most people's trees are mostly empty.
> >
> > Yes, that was the plan last time around as well - but the end of the merge 
> > window
> > is when we have the least maintainer bandwidth as well ...
> >
> > Anyway, I applied most of the patches (sans the rename), so the rename patch
> > should be a lot simpler to execute at the right moment this time around.
> 
> Ingo, should we try this again some time? I have some ideas on how to
> make these sorts of changes easier to manage in the future, it
> involves having an automatic git rebase option to use Coccinelle for
> you if a patch is annotated to have been completely done with
> Coccinelle, but future tooling is needed for that [0]. In the meantime
> I (or you) can simply run the script at any point in time to catch all
> the names as-is in the kernel / point in time we decide to merge this
> simple rename.
> 
> [0] http://kernelnewbies.org/KernelProjects/linux-oven

So beyond the rename, can we also keep the old names as compatibility helpers, 
with a #define mapping them to the new names?

If so then please (re-)send the changes.

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH v2 04/13] libxc: Implementation of XEN_XSPLICE_op in libxc (v4).

[Wei Liu]

On Thu, Jan 14, 2016 at 04:47:02PM -0500, Konrad Rzeszutek Wilk wrote:
[...]
> +int xc_xsplice_upload(xc_interface *xch,
> +  char *name,
> +  char *payload,
> +  uint32_t size)
> +{
> +int rc;
> +DECLARE_SYSCTL;
> +DECLARE_HYPERCALL_BOUNCE(payload, size, XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +DECLARE_HYPERCALL_BOUNCE(name, 0 /* adjust later */, 
> XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +xen_xsplice_name_t def_name = { .pad = { 0, 0, 0 } };
> +
> +if ( !name || !payload )
> +return -1;
> +
> +def_name.size = strlen(name);
> +if ( def_name.size > XEN_XSPLICE_NAME_SIZE )
> +return -1;
> +
> +HYPERCALL_BOUNCE_SET_SIZE(name, def_name.size );
> +
> +if ( xc_hypercall_bounce_pre(xch, name) )
> +return -1;
> +
> +if ( xc_hypercall_bounce_pre(xch, payload) )
> +return -1;
> +

xc_hypercall_bounce_pre can allocate memory so please clean up after
failure instead of returning -1 directly.

> +sysctl.cmd = XEN_SYSCTL_xsplice_op;
> +sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_UPLOAD;
> +sysctl.u.xsplice.pad = 0;
> +sysctl.u.xsplice.u.upload.size = size;
> +set_xen_guest_handle(sysctl.u.xsplice.u.upload.payload, payload);
> +
> +sysctl.u.xsplice.u.upload.name = def_name;
> +set_xen_guest_handle(sysctl.u.xsplice.u.upload.name.name, name);
> +
> +rc = do_sysctl(xch, );
> +
> +xc_hypercall_bounce_post(xch, payload);
> +xc_hypercall_bounce_post(xch, name);
> +
> +return rc;
> +}
> +
> +int xc_xsplice_get(xc_interface *xch,
> +   char *name,
> +   xen_xsplice_status_t *status)
> +{
> +int rc;
> +DECLARE_SYSCTL;
> +DECLARE_HYPERCALL_BOUNCE(name, 0 /*adjust later */, 
> XC_HYPERCALL_BUFFER_BOUNCE_IN);
> +xen_xsplice_name_t def_name = { .pad = { 0, 0, 0 } };
> +
> +if ( !name )
> +return -1;
> +
> +def_name.size = strlen(name);
> +if ( def_name.size > XEN_XSPLICE_NAME_SIZE )
> +return -1;
> +
> +HYPERCALL_BOUNCE_SET_SIZE(name, def_name.size );
> +
> +if ( xc_hypercall_bounce_pre(xch, name) )
> +return -1;
> +
> +sysctl.cmd = XEN_SYSCTL_xsplice_op;
> +sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_GET;
> +sysctl.u.xsplice.pad = 0;
> +
> +sysctl.u.xsplice.u.get.status.state = 0;
> +sysctl.u.xsplice.u.get.status.rc = 0;
> +
> +sysctl.u.xsplice.u.get.name = def_name;
> +set_xen_guest_handle(sysctl.u.xsplice.u.get.name.name, name);
> +
> +rc = do_sysctl(xch, );
> +
> +xc_hypercall_bounce_post(xch, name);
> +
> +memcpy(status, , sizeof(*status));
> +
> +return rc;
> +}
> +
> +int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
> +xen_xsplice_status_t *info,
> +char *name, uint32_t *len,
> +unsigned int *done,
> +unsigned int *left)


Can you please add some comment before this function to document what
each of the parameters means? I have to admit I fail to grok the
algorithm of this function.

> +{
> +int rc;
> +DECLARE_SYSCTL;
> +DECLARE_HYPERCALL_BOUNCE(info, 0 /* adjust later. */, 
> XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +DECLARE_HYPERCALL_BOUNCE(name, 0 /* adjust later. */, 
> XC_HYPERCALL_BUFFER_BOUNCE_OUT);
> +DECLARE_HYPERCALL_BOUNCE(len, 0 /* adjust later. */, 
> XC_HYPERCALL_BUFFER_BOUNCE_OUT);

Lines too long.

> +uint32_t max_batch_sz, nr;
> +uint32_t version = 0, retries = 0;
> +uint32_t adjust = 0;
> +
> +if ( !max || !info || !name || !len )
> +return -1;
> +
> +sysctl.cmd = XEN_SYSCTL_xsplice_op;
> +sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_LIST;
> +sysctl.u.xsplice.pad = 0;
> +sysctl.u.xsplice.u.list.version = 0;
> +sysctl.u.xsplice.u.list.idx = start;
> +sysctl.u.xsplice.u.list.pad = 0;
> +
> +max_batch_sz = max;
> +
> +*done = 0;
> +*left = 0;
> +do {
> +if ( adjust )
> +adjust = 0; /* Used when adjusting the 'max_batch_sz' or 
> 'retries'. */
> +
> +nr = min(max - *done, max_batch_sz);
> +
> +sysctl.u.xsplice.u.list.nr = nr;
> +/* Fix the size (may vary between hypercalls). */
> +HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info));
> +HYPERCALL_BOUNCE_SET_SIZE(name, nr * sizeof(*name) * 
> XEN_XSPLICE_NAME_SIZE);

Line too long.

> +HYPERCALL_BOUNCE_SET_SIZE(len, nr * sizeof(*len));
> +/* Move the pointer to proper offset into 'info'. */
> +(HYPERCALL_BUFFER(info))->ubuf = info + *done;
> +(HYPERCALL_BUFFER(name))->ubuf = name + (sizeof(*name) * 
> XEN_XSPLICE_NAME_SIZE * *done);
> +(HYPERCALL_BUFFER(len))->ubuf = len + *done;
> +/* Allocate memory. */
> +rc = xc_hypercall_bounce_pre(xch, info);
> +if ( rc )
> +return rc;
> +
> +rc = xc_hypercall_bounce_pre(xch, name);
> +if ( rc )
> +   

Re: [Xen-devel] [PATCH v2 05/13] xen-xsplice: Tool to manipulate xsplice payloads (v3)

[Wei Liu]

On Thu, Jan 14, 2016 at 04:47:03PM -0500, Konrad Rzeszutek Wilk wrote:
[...]
> +/* This value was choosen adhoc. It could be 42 too. */
> +#define MAX_LEN 11
> +static int list_func(int argc, char *argv[])
> +{
> +unsigned int idx, done, left, i;
> +xen_xsplice_status_t *info = NULL;
> +char *id = NULL;
> +uint32_t *len = NULL;
> +int rc = ENOMEM;
> +
> +if ( argc )
> +{
> +show_help();
> +return -1;
> +}
> +idx = left = 0;
> +info = malloc(sizeof(*info) * MAX_LEN);
> +if ( !info )
> +goto out;
> +id = malloc(sizeof(*id) * XEN_XSPLICE_NAME_SIZE * MAX_LEN);
> +if ( !id )
> +goto out;
> +len = malloc(sizeof(*len) * MAX_LEN);
> +if ( !len )
> +goto out;
> +
> +fprintf(stdout," ID | status\n"
> +   
> "+\n");
> +do {
> +done = 0;
> +memset(info, 'A', sizeof(*info) * MAX_LEN); /* Optional. */
> +memset(id, 'i', sizeof(*id) * MAX_LEN * XEN_XSPLICE_NAME_SIZE); /* 
> Optional. */

Line too long.

[...]
> +static int upload_func(int argc, char *argv[])
> +{
> +char *filename;
> +char id[XEN_XSPLICE_NAME_SIZE];
> +int fd = 0, rc;
> +struct stat buf;
> +unsigned char *fbuf;
> +ssize_t len;
> +DECLARE_HYPERCALL_BUFFER(char, payload);
> +

I don't think you need to declare hypercall buffer here in the utility.
It should be libxc's responsibility to bounce the buffer accordingly.


Wei.

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

Re: [Xen-devel] [PATCH v2 10/13] xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.

[Wei Liu]

On Thu, Jan 14, 2016 at 04:47:08PM -0500, Konrad Rzeszutek Wilk wrote:
> This change demonstrates how to generate an xSplice ELF payload.
> 
> The idea here is that we want to patch in the hypervisor
> the 'xen_version_extra' function with an function that will
> return 'Hello World'. The 'xl info | grep extraversion'
> will reflect the new value after the patching.
> 
> To generate this ELF payload file we need:
>  - C code of the new code.
>  - C code generating the .xsplice.func structure.
>  - The address of the old code (xen_extra_version). We
>do it by using 'nm' but that is a bit of hack.
> 
> The linker script file:
>  - Discards .debug* and .comments* sections.
>  - Changes the name of .data.local.xsplice_hello_world to
>.xsplice.func
>  - Figures out the size of the new code.
> 
> Also if you are curious on the input/output sections
> magic the linker does, add these to the GCC line:
>   -Wl,-M  -Wl,-t -Wl,-verbose
> which are: print linking map, provide trace and be verbose.
> 
> The use-case is simple:
> 
> $xen-xsplice load /usr/lib/xen/bin/xen_hello_world.xsplice
> $xen-xsplice list
>  ID | status
> +
> xen_hello_world   APPLIED
> $xl info | grep extra
> xen_extra  : Hello World
> $xen-xsplice revert xen_hello_world
> Performing revert: completed
> $xen-xsplice unload xen_hello_world
> Performing unload: completed
> $xl info | grep extra
> xen_extra  : -unstable
> 
> Note that it does not build under a 32-bit toolstack as
> there is no access to the hypervisor (xen-syms).
> 
> We also force it to be built every time - as the hypervisor
> may have been rebuilt.
> 
> Signed-off-by: Konrad Rzeszutek Wilk 
> ---
>  docs/misc/xsplice.markdown   | 50 
> 
>  tools/misc/Makefile  | 25 +-
>  tools/misc/xen_hello_world.c | 15 +
>  tools/misc/xsplice.h | 12 +++
>  tools/misc/xsplice.lds   | 11 ++

Please put the files of this test case into a dedicated directory.

Wei.

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

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

[Andrew Cooper]

On 19/01/16 10:50, Malcolm Crossley wrote:
> @@ -343,10 +348,44 @@ void pxstat_func(int argc, char *argv[])
>  show_pxstat_by_cpuid(xc_handle, cpuid);
>  }
>  
> +static int show_cpufreq_by_cpuid(xc_interface *xc_handle, int cpuid)
> +{
> +int ret = 0;
> +
> +ret = get_avgfreq_by_cpuid(xc_handle, cpuid, [cpuid]);
> +if ( ret )
> +return ret;
> +
> +printf("cpu id   : %d\n", cpuid);
> +printf("average cpu frequency: %d\n", avgfreq[cpuid]);
> +printf("\n");
> +return 0;
> +}
> +
> +void cpufreq_func(int argc, char *argv[])
> +{
> +int cpuid = -1;
> +
> +if ( argc > 0 )
> +parse_cpuid(argv[0], );
> +
> +avgfreq = calloc(max_cpu_nr, sizeof(*avgfreq));

You need a NULL check here.

~Andrew

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

[Xen-devel] [PATCHv2] xenpm: Add option to report average CPU frequency

[Malcolm Crossley]

The average is calculated over the period of time from the last
xenpm report of the average CPU frequency.

Reporting the average CPU frequency helps confirm the level of turbo
boost being achieved per CPU.

Signed-off-by: Malcolm Crossley 
---
 tools/misc/xenpm.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
index 08f2242..a2edee5 100644
--- a/tools/misc/xenpm.c
+++ b/tools/misc/xenpm.c
@@ -45,6 +45,8 @@ void show_help(void)
 "xenpm command list:\n\n"
 " get-cpuidle-states[cpuid]   list cpu idle info of CPU 
 or all\n"
 " get-cpufreq-states[cpuid]   list cpu freq info of CPU 
 or all\n"
+" get-cpufreq-average   [cpuid]   average cpu frequency since 
last invocation\n"
+" for CPU  or all\n"
 " get-cpufreq-para  [cpuid]   list cpu freq parameter of 
CPU  or all\n"
 " set-scaling-maxfreq   [cpuid]   set max cpu frequency  
on CPU \n"
 " or all CPUs\n"
@@ -343,6 +345,40 @@ void pxstat_func(int argc, char *argv[])
 show_pxstat_by_cpuid(xc_handle, cpuid);
 }
 
+static int show_cpufreq_by_cpuid(xc_interface *xc_handle, int cpuid)
+{
+int ret = 0;
+int average_cpufreq;
+
+ret = get_avgfreq_by_cpuid(xc_handle, cpuid, _cpufreq);
+if ( ret )
+return ret;
+
+printf("cpu id   : %d\n", cpuid);
+printf("average cpu frequency: %d\n", average_cpufreq);
+printf("\n");
+return 0;
+}
+
+void cpufreq_func(int argc, char *argv[])
+{
+int cpuid = -1;
+
+if ( argc > 0 )
+parse_cpuid(argv[0], );
+
+if ( cpuid < 0 )
+{
+/* show average frequency on all cpus */
+int i;
+for ( i = 0; i < max_cpu_nr; i++ )
+if ( show_cpufreq_by_cpuid(xc_handle, i) == -ENODEV )
+break;
+}
+else
+show_cpufreq_by_cpuid(xc_handle, cpuid);
+}
+
 static uint64_t usec_start, usec_end;
 static struct xc_cx_stat *cxstat, *cxstat_start, *cxstat_end;
 static struct xc_px_stat *pxstat, *pxstat_start, *pxstat_end;
@@ -1129,6 +1165,7 @@ struct {
 { "help", help_func },
 { "get-cpuidle-states", cxstat_func },
 { "get-cpufreq-states", pxstat_func },
+{ "get-cpufreq-average", cpufreq_func },
 { "start", start_gather_func },
 { "get-cpufreq-para", cpufreq_para_func },
 { "set-scaling-maxfreq", scaling_max_freq_func },
-- 
1.7.12.4


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

Re: [Xen-devel] [PATCH v2 1/5] libxl: tidy libxl_get_scheduler() according to CODING_STYLE

[Wei Liu]

Hi Chester

What we normally do for new version of patches is to send out a new
series prefixed with "PATCH v2", instead of replying to old version of
the patches.

Could you collect Dario's Reviewed-by tags and send this series as v2.

Thanks
Wei.

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

Re: [Xen-devel] [PATCH v3] xenstat: handle more than 1024 domains

[Ian Campbell]

On Fri, 2016-01-15 at 16:22 +, Ian Campbell wrote:
> On Fri, 2016-01-15 at 17:07 +0100, Juergen Gross wrote:
> > get_domain_ids() in libxenstat used by read_attributes_qdisk() is
> > limited to 1024 domains. Remove that limit.
> > 
> > Signed-off-by: Juergen Gross 
> > ---
> > V3: Obey 80 character line length limit as requested by Ian Campbell.
> > In order to not have to wrap so many lines just carve out the loop
> > body into a sub-function.
> 
> That's a completely reasonable way to avoid excess wrapping (and should
> probably be done more often!)
> 
> >  As this changes the patch structure, drop
> > the Reviewed-by tag of Wei.
> > 
> > Signed-off-by: Juergen Gross 
> 
> I took a look at the "git show -b" version, which was a lot easier to
> read:
> 
> Acked-by: Ian Campbell 

Now applied, thanks.



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

Re: [Xen-devel] [PATCH v7 2/2] public/io/netif.h: document control ring and toeplitz hashing

[Ian Campbell]

(Re-adding the list and full quoting since I think that was just a button-
o)

On Mon, 2016-01-18 at 16:24 +, Paul Durrant wrote:
> > -Original Message-
> [snip]
> > 
> > I noticed (after trimming the quotes unfortunately) that the request gained
> > a data[2] in v5 (as part of handling the table differently), so the req +
> > rsp are no longer the same size.
> > 
> > I'm not sure if that is worth worrying about. I don't think it would
> > simplify anything to include a padding bit, but it might be nice?
> > 
> 
> The ring macros take the max of the req and rsp so I'd like to leave out 
> explicit padding.
> 
> > > 
> > > + * NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING
> > > + * 
> > > + *
> > > + * This is sent by the frontend to set the content of the table mapping
> > > + * toeplitz hash value to queue number. The backend should calculate the
> > > + * hash from the packet header, use it as an index into the table (modulo
> > > + * the size of the table) and then steer the packet to the queue number
> > > + * found at that index.
> > > + *
> > > + * Request:
> > > + *
> > > + *  type= NETIF_CTRL_TYPE_SET_TOEPLITZ_MAPPING
> > > + *  data[0] = grant reference of page containing the mapping (sub-)table
> > > + *(assumed to start at beginning of grant)
> > > + *  data[1] = size of (sub-)table in entries
> > > + *  data[2] = offset, in entries, of sub-table within overall table
> > 
> > Adding data[2] seems reasonable to me, but if you wanted to avoid adding it
> > then saying data[1][8:0] == size and data[1][31:9] == offset would allow a
> > size of 512 (biggest possible in a single gref) and 8.3M for the offset.
> > 
> 
> Probably better to leave data[2] in there.
> 
> > Do the updates tend to come in large batches, or is setting single entries
> > or small runs of contiguous entries the norm? I suspect you are trying to
> > avoid copying 4K worth of data ofr each update when only a couple of
> > entries have changed, is that right?
> 
> Updates are fairly infrequent and, in my experience, only tend to modify a 
> handful of entries. For a small table (which basic RSS has now, at 127 
> entries) it's probably not worth the complexity of sending the diffs but if 
> we move onto newer RSS versions with larger tables in the future we have that 
> option.
> 
> > 
> > All the above are just suggestions, which you are free to ignore, so if you
> > prefer things as they are that's fine by me:
> > 
> 
> I think that it's good enough as it is. Thanks for the thorough review!

Right, applied then, thanks!


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

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

[Ian Campbell]

On Tue, 2016-01-19 at 11:10 +, Malcolm Crossley wrote:
> On 19/01/16 11:06, Ian Campbell wrote:
> > On Tue, 2016-01-19 at 10:50 +, Malcolm Crossley wrote:
> > > The average is calculated over the period of time from the last
> > > xenpm report of the average CPU frequency.
> > > 
> > > Reporting the average CPU frequency helps confirm the level of turbo
> > > boost being achieved per CPU.
> > > 
> > > Signed-off-by: Malcolm Crossley 
> > > ---
> > >  tools/misc/xenpm.c | 42 +-
> > >  1 file changed, 41 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
> > > index 08f2242..40cdd55 100644
> > > --- a/tools/misc/xenpm.c
> > > +++ b/tools/misc/xenpm.c
> > > @@ -45,6 +45,8 @@ void show_help(void)
> > >  "xenpm command list:\n\n"
> > >  " get-cpuidle-states[cpuid]   list cpu idle info
> > > of
> > > CPU  or all\n"
> > >  " get-cpufreq-states[cpuid]   list cpu freq info
> > > of
> > > CPU  or all\n"
> > > +" get-cpufreq-average   [cpuid]   average cpu
> > > frequency
> > > since last invocation\n"
> > > +" for CPU  or
> > > all\n"
> > >  " get-cpufreq-para  [cpuid]   list cpu freq
> > > parameter of CPU  or all\n"
> > >  " set-scaling-maxfreq   [cpuid]   set max cpu
> > > frequency
> > >  on CPU \n"
> > >  " or all CPUs\n"
> > > @@ -296,6 +298,9 @@ static int get_pxstat_by_cpuid(xc_interface
> > > *xc_handle, int cpuid, struct xc_px_
> > >  return ret;
> > >  }
> > >  
> > > +
> > > +static int *avgfreq;
> > 
> > Do we need the global array of them all when each element is used
> > exactly
> > once entirely within show_cpufreq_by_cpuid in this mode?
> > 
> 
> The global array was already defined for when xenpm is used as a cpu 
> frequency control daemon, I
> just moved it so that the new functions could use the variable.
> 
> Do you want me to spin the patch using a local int variable instead?

I was going to say yes please, but I see v2 already arrived with that
change ;-)

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

Re: [Xen-devel] [PATCH v2 1/5] libxl: tidy libxl_get_scheduler() according to CODING_STYLE

[Ian Campbell]

On Tue, 2016-01-19 at 11:28 +, Wei Liu wrote:
> Hi Chester
> 
> What we normally do for new version of patches is to send out a new
> series prefixed with "PATCH v2", instead of replying to old version of
> the patches.
> 
> Could you collect Dario's Reviewed-by tags and send this series as v2.

Please call the resend v3 to avoid any confusion.

http://wiki.xen.org/wiki/Submitting_Xen_Patches#Review.2C_Rinse_.26_Repeat 
also has some words on this topic.

Ian.

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

Re: [Xen-devel] [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[Wei Liu]

On Mon, Jan 18, 2016 at 01:46:29AM -0700, Jan Beulich wrote:
> >>> On 18.01.16 at 01:52,  wrote:
> > On 01/15/16 10:10, Jan Beulich wrote:
> >> >>> On 29.12.15 at 12:31,  wrote:
> >> > NVDIMM devices are detected and configured by software through
> >> > ACPI. Currently, QEMU maintains ACPI tables of vNVDIMM devices. This
> >> > patch extends the existing mechanism in hvmloader of loading passthrough
> >> > ACPI tables to load extra ACPI tables built by QEMU.
> >> 
> >> Mechanically the patch looks okay, but whether it's actually needed
> >> depends on whether indeed we want NV RAM managed in qemu
> >> instead of in the hypervisor (where imo it belongs); I didn' see any
> >> reply yet to that same comment of mine made (iirc) in the context
> >> of another patch.
> > 
> > One purpose of this patch series is to provide vNVDIMM backed by host
> > NVDIMM devices. It requires some drivers to detect and manage host
> > NVDIMM devices (including parsing ACPI, managing labels, etc.) that
> > are not trivial, so I leave this work to the dom0 linux. Current Linux
> > kernel abstract NVDIMM devices as block devices (/dev/pmemXX). QEMU
> > then mmaps them into certain range of dom0's address space and asks
> > Xen hypervisor to map that range of address space to a domU.
> > 

OOI Do we have a viable solution to do all these non-trivial things in
core hypervisor?  Are you proposing designing a new set of hypercalls
for NVDIMM?  

Wei.

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

Re: [Xen-devel] [PATCH OSSTEST] sg-report-job-history: alternate color of osstest column only when it changes

[Ian Campbell]

On Wed, 2016-01-06 at 11:08 +, Ian Campbell wrote:

ping?

> Currently the bgcolor of the osstest column alternates on each line,
> rather than only when it changes as the other revision columns do.
> 
> A given flight might touch multiple osstest revisions (although in
> practice they rarely do) but it seems reasonable to simply consider
> any change as a change.
> 
> Signed-off-by: Ian Campbell 
> ---
>  sg-report-job-history | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/sg-report-job-history b/sg-report-job-history
> index 0e2a3f9..e2e5806 100755
> --- a/sg-report-job-history
> +++ b/sg-report-job-history
> @@ -234,6 +234,7 @@ END
>  my @last_revs;
>  my @alt_revs;
>  my $alt_hosts;
> +my $alt_osstest;
>  foreach my $r (@test_rows) {
>  my $altcolour= report_altcolour($alternate);
>  print H "";
> @@ -254,16 +255,15 @@ END
>  my $hosts_colour = report_altchangecolour(\$alt_hosts,
> $hosts);
>  print H " $hosts_colour>".encode_entities($hosts)."\n";
>  $osstestverq->execute($r->{Flight}{flight});
> -print H
> -"",
> -(join ' ',
> +my $osstestrevs = join ' ',
>   map {
>  $_ = $_->{harness};
>  s/^([0-9a-f]{12})[0-9a-f]+\b/$1/;
>  "".encode_entities($_)."";
>   }
> - @{ $osstestverq->fetchall_arrayref({}) }),
> -"\n";
> + @{ $osstestverq->fetchall_arrayref({}) };
> +my $osstest_colour = report_altchangecolour(\$alt_osstest,
> $osstestrevs);
> +print H "$osstestrevs\n";
>  foreach my $i (0..$#rev_grid_cols) {
>  my $v= $r->{Revisions}[$i];
>   my $rev_colour = report_altchangecolour(\$alt_revs[$i],
> $v);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH] xenpm: Add option to report average CPU frequency

[Malcolm Crossley]

On 19/01/16 11:35, Ian Campbell wrote:
> On Tue, 2016-01-19 at 11:10 +, Malcolm Crossley wrote:
>> On 19/01/16 11:06, Ian Campbell wrote:
>>> On Tue, 2016-01-19 at 10:50 +, Malcolm Crossley wrote:
 The average is calculated over the period of time from the last
 xenpm report of the average CPU frequency.

 Reporting the average CPU frequency helps confirm the level of turbo
 boost being achieved per CPU.

 Signed-off-by: Malcolm Crossley 
 ---
  tools/misc/xenpm.c | 42 +-
  1 file changed, 41 insertions(+), 1 deletion(-)

 diff --git a/tools/misc/xenpm.c b/tools/misc/xenpm.c
 index 08f2242..40cdd55 100644
 --- a/tools/misc/xenpm.c
 +++ b/tools/misc/xenpm.c
 @@ -45,6 +45,8 @@ void show_help(void)
  "xenpm command list:\n\n"
  " get-cpuidle-states[cpuid]   list cpu idle info
 of
 CPU  or all\n"
  " get-cpufreq-states[cpuid]   list cpu freq info
 of
 CPU  or all\n"
 +" get-cpufreq-average   [cpuid]   average cpu
 frequency
 since last invocation\n"
 +" for CPU  or
 all\n"
  " get-cpufreq-para  [cpuid]   list cpu freq
 parameter of CPU  or all\n"
  " set-scaling-maxfreq   [cpuid]   set max cpu
 frequency
  on CPU \n"
  " or all CPUs\n"
 @@ -296,6 +298,9 @@ static int get_pxstat_by_cpuid(xc_interface
 *xc_handle, int cpuid, struct xc_px_
  return ret;
  }
  
 +
 +static int *avgfreq;
>>>
>>> Do we need the global array of them all when each element is used
>>> exactly
>>> once entirely within show_cpufreq_by_cpuid in this mode?
>>>
>>
>> The global array was already defined for when xenpm is used as a cpu 
>> frequency control daemon, I
>> just moved it so that the new functions could use the variable.
>>
>> Do you want me to spin the patch using a local int variable instead?
> 
> I was going to say yes please, but I see v2 already arrived with that
> change ;-)

It fixed Andrew's review comment at the same time and it makes for a smaller 
simpler patch.

Thanks for the review.

Malcolm
> 
> Ian.
> 


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

Re: [Xen-devel] [PATCH 4/4] hvmloader: add support to load extra ACPI tables from qemu

[Jan Beulich]

>>> On 19.01.16 at 12:37,  wrote:
> On Mon, Jan 18, 2016 at 01:46:29AM -0700, Jan Beulich wrote:
>> >>> On 18.01.16 at 01:52,  wrote:
>> > On 01/15/16 10:10, Jan Beulich wrote:
>> >> >>> On 29.12.15 at 12:31,  wrote:
>> >> > NVDIMM devices are detected and configured by software through
>> >> > ACPI. Currently, QEMU maintains ACPI tables of vNVDIMM devices. This
>> >> > patch extends the existing mechanism in hvmloader of loading passthrough
>> >> > ACPI tables to load extra ACPI tables built by QEMU.
>> >> 
>> >> Mechanically the patch looks okay, but whether it's actually needed
>> >> depends on whether indeed we want NV RAM managed in qemu
>> >> instead of in the hypervisor (where imo it belongs); I didn' see any
>> >> reply yet to that same comment of mine made (iirc) in the context
>> >> of another patch.
>> > 
>> > One purpose of this patch series is to provide vNVDIMM backed by host
>> > NVDIMM devices. It requires some drivers to detect and manage host
>> > NVDIMM devices (including parsing ACPI, managing labels, etc.) that
>> > are not trivial, so I leave this work to the dom0 linux. Current Linux
>> > kernel abstract NVDIMM devices as block devices (/dev/pmemXX). QEMU
>> > then mmaps them into certain range of dom0's address space and asks
>> > Xen hypervisor to map that range of address space to a domU.
>> > 
> 
> OOI Do we have a viable solution to do all these non-trivial things in
> core hypervisor?  Are you proposing designing a new set of hypercalls
> for NVDIMM?  

That's certainly a possibility; I lack sufficient detail to make myself
an opinion which route is going to be best.

Jan


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

Re: [Xen-devel] [PATCH 3/3] tools: introduce parameter max_ranges.

[Wei Liu]

On Tue, Jan 19, 2016 at 05:27:58PM +0800, Yu Zhang wrote:
> A new parameter - max_ranges is added to set the upper limit of ranges
> to be tracked inside one ioreq server rangeset.
> 
> Ioreq server uses a group of rangesets to track the I/O or memory
> resources to be emulated. The default value of this limit is set to
> 256. Yet there are circumstances under which the limit should exceed
> the default one. E.g. in XenGT, when tracking the per-process graphic
> translation tables on intel broadwell platforms, the number of page
> tables concerned will be several thousand(normally in this case, 8192
> could be a big enough value). Users who set his item explicitly are
> supposed to know the specific scenarios that necessitate this
> configuration.
> 
> Signed-off-by: Yu Zhang 
> ---
>  docs/man/xl.cfg.pod.5   | 17 +
>  tools/libxl/libxl_dom.c |  3 +++
>  tools/libxl/libxl_types.idl |  1 +
>  tools/libxl/xl_cmdimpl.c|  4 
>  xen/arch/x86/hvm/hvm.c  |  7 ++-
>  xen/include/public/hvm/params.h |  5 -
>  6 files changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> index 8899f75..562563d 100644
> --- a/docs/man/xl.cfg.pod.5
> +++ b/docs/man/xl.cfg.pod.5
> @@ -962,6 +962,23 @@ FIFO-based event channel ABI support up to 131,071 event 
> channels.
>  Other guests are limited to 4095 (64-bit x86 and ARM) or 1023 (32-bit
>  x86).
>  
> +=item 

[Xen-devel] [PATCH] docs: correct descriptions of gnttab_max_{, maptrack}_frames

[Ian Campbell]

gnttab_max_frames incorrectly referred to numbers of grant tab
operations and gnttab_max_maptrack_frames was confusingly worded.

Add the default for gnttab_max_frames while here (it's currently the
same on all arches since no arch uses the available arch override) and
adjust the default for gnttab_max_maptrack_frames to match the normal
form.

Signed-off-by: Ian Campbell 
---
v2: Use more prevalent form for specifying defaults.
---
 docs/misc/xen-command-line.markdown | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/docs/misc/xen-command-line.markdown 
b/docs/misc/xen-command-line.markdown
index 5ed0730..d267a04 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -740,13 +740,18 @@ Specify which console gdbstub should use. See **console**.
 ### gnttab\_max\_frames
 > `= `
 
-Specify the maximum number of frames per grant table operation.
+> Default: `32`
+
+Specify the maximum number of frames which any domain may use as part
+of its grant table.
 
 ### gnttab\_max\_maptrack\_frames
 > `= `
 
-Specify the maximum number of maptrack frames domain.
-The default value is 8 times **gnttab\_max\_frames**.
+> Default: `8 * gnttab_max_frames`
+
+Specify the maximum number of frames to use as part of a domains
+maptrack array.
 
 ### gnttab\_max\_nr\_frames
 > `= `
-- 
2.1.4


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

Re: [Xen-devel] [PATCH LIBVIRT] libxl: Support cmdline= in xl config files

[Ian Campbell]

I went to ping this but noticed that I had sent it to "jimfehlig" (i.e. no
domain), so no wonder there was no reply!

To: line fixed here, let me know if you would prefer a resend.

Ian.

On Wed, 2015-12-16 at 12:09 +, Ian Campbell wrote:
> ... and consolidate the cmdline/extra/root parsing to facilitate doing
> so.
> 
> The logic is the same as xl's parse_cmdline from the current xen.git master
> branch (e6f0e099d2c17de47fd86e817b1998db903cab61), except I was unable
> to figure out how/where to route the warning about ignoring
> root+extra if cmdline was specified.
> 
> Signed-off-by: Ian Campbell 
> ---
>  src/xenconfig/xen_xl.c | 62 ++
> 
>  1 file changed, 37 insertions(+), 25 deletions(-)
> 
> diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
> index 91cdff6..ba8b938 100644
> --- a/src/xenconfig/xen_xl.c
> +++ b/src/xenconfig/xen_xl.c
> @@ -58,11 +58,45 @@ extern int xlu_disk_parse(XLU_Config *cfg,
>    libxl_device_disk *disk);
>  #endif
>  
> +static int xenParseCmdline(virConfPtr conf, char **r_cmdline)
> +{
> +char *cmdline = NULL;
> +const char *root = NULL, *extra = NULL, *buf = NULL;
> +
> +if (xenConfigGetString(conf, "cmdline", , NULL) < 0)
> +return -1;
> +
> +if (xenConfigGetString(conf, "root", , NULL) < 0)
> +return -1;
> +
> +if (xenConfigGetString(conf, "extra", , NULL) < 0)
> +return -1;
> +
> +if (buf) {
> +if (VIR_STRDUP(cmdline, buf) < 0)
> +return -1;
> +/* root or extra are ignored in this case. */
> +} else {
> +if (root && extra) {
> +if (virAsprintf(, "root=%s %s", root, extra) < 0)
> +return -1;
> +} else if (root) {
> +if (virAsprintf(, "root=%s", root) < 0)
> +return -1;
> +} else if (extra) {
> +if (VIR_STRDUP(cmdline, extra) < 0)
> +return -1;
> +}
> +}
> +
> +*r_cmdline = cmdline;
> +return 0;
> +}
> +
>  static int
>  xenParseXLOS(virConfPtr conf, virDomainDefPtr def, virCapsPtr caps)
>  {
>  size_t i;
> -const char *extra, *root;
>  
>  if (def->os.type == VIR_DOMAIN_OSTYPE_HVM) {
>  const char *boot;
> @@ -84,19 +118,8 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def,
> virCapsPtr caps)
>  if (xenConfigCopyStringOpt(conf, "ramdisk", >os.initrd) <
> 0)
>  return -1;
>  
> -if (xenConfigGetString(conf, "extra", , NULL) < 0)
> -return -1;
> -
> -if (xenConfigGetString(conf, "root", , NULL) < 0)
> +if (xenParseCmdline(conf, >os.cmdline) < 0)
>  return -1;
> -
> -if (root) {
> -if (virAsprintf(>os.cmdline, "root=%s %s", root, extra)
> < 0)
> -return -1;
> -} else {
> -if (VIR_STRDUP(def->os.cmdline, extra) < 0)
> -return -1;
> -}
>  #endif
>  
>  if (xenConfigGetString(conf, "boot", , "c") < 0)
> @@ -132,19 +155,8 @@ xenParseXLOS(virConfPtr conf, virDomainDefPtr def,
> virCapsPtr caps)
>  if (xenConfigCopyStringOpt(conf, "ramdisk", >os.initrd) <
> 0)
>  return -1;
>  
> -if (xenConfigGetString(conf, "extra", , NULL) < 0)
> -return -1;
> -
> -if (xenConfigGetString(conf, "root", , NULL) < 0)
> +if (xenParseCmdline(conf, >os.cmdline) < 0)
>  return -1;
> -
> -if (root) {
> -if (virAsprintf(>os.cmdline, "root=%s %s", root, extra)
> < 0)
> -return -1;
> -} else {
> -if (VIR_STRDUP(def->os.cmdline, extra) < 0)
> -return -1;
> -}
>  }
>  
>  return 0;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxc: fix comment in xc__hypercall_bounce_pre

[Wei Liu]

Signed-off-by: Wei Liu 
---
Cc: Ian Campbell 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
---
 tools/libxc/xc_hcall_buf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/libxc/xc_hcall_buf.c b/tools/libxc/xc_hcall_buf.c
index 6e3c958..4fc 100644
--- a/tools/libxc/xc_hcall_buf.c
+++ b/tools/libxc/xc_hcall_buf.c
@@ -198,7 +198,7 @@ int xc__hypercall_bounce_pre(xc_interface *xch, 
xc_hypercall_buffer_t *b)
 abort();
 
 /*
- * Do need to bounce a NULL buffer.
+ * Don't need to bounce a NULL buffer.
  */
 if ( b->ubuf == NULL )
 {
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v2 16/16] ARM64: XEN: Initialize Xen specific UEFI runtime services

[Stefano Stabellini]

On Mon, 18 Jan 2016, Mark Rutland wrote:
> On Mon, Jan 18, 2016 at 05:45:24PM +, Stefano Stabellini wrote:
> > On Mon, 18 Jan 2016, Mark Rutland wrote:
> > > On Fri, Jan 15, 2016 at 02:55:29PM +0800, Shannon Zhao wrote:
> > > > +void __init xen_efi_runtime_setup(void)
> > > > +{
> > > > +   efi.get_time = xen_efi_get_time;
> > > > +   efi.set_time = xen_efi_set_time;
> > > > +   efi.get_wakeup_time  = xen_efi_get_wakeup_time;
> > > > +   efi.set_wakeup_time  = xen_efi_set_wakeup_time;
> > > > +   efi.get_variable = xen_efi_get_variable;
> > > > +   efi.get_next_variable= xen_efi_get_next_variable;
> > > > +   efi.set_variable = xen_efi_set_variable;
> > > > +   efi.query_variable_info  = xen_efi_query_variable_info;
> > > > +   efi.update_capsule   = xen_efi_update_capsule;
> > > > +   efi.query_capsule_caps   = xen_efi_query_capsule_caps;
> > > > +   efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
> > > > +   efi.reset_system = NULL;
> > > > +}
> > > 
> > > How do capsules work in the absence of an EFI system reset?
> > 
> > Actually I don't think that capsules are available in Xen on ARM64 yet,
> > see "TODO - disabled until implemented on ARM" in
> > xen/common/efi/runtime.c.
> > 
> > FYI system reset is available, but it is provided via a different
> > mechanism (HYPERVISOR_sched_op(xen_restart...)
> 
> Will that trigger Xen to do the right thing to trigger capsule updates
> when implemented in Xen? Or do we need a xen_efi_reset_system?

On ARM, to reboot the hardware, Xen calls the native PSCI system_reset
method. On x86, Xen calls efi_reset_system on EFI systems, and has
several fall backs if that doesn't work as expected (see
xen/arch/x86/shutdown.c:machine_restart).

But on a second look it doesn't look like that the capsule hypercalls
are implemented correctly even on x86 (there is an "XXX fall through for
now" comment in the code). I guess they are not available on Xen at all
unfortunately.


> Does that override PSCI?

It does not, HYPERVISOR_sched_op(xen_restart,) is in addition to it. It
ends up calling the same function within Xen as PSCI system_reset.


> In machine_restart we try efi_reboot first specifically to allow for
> capsule updates. Similarly drivers/firmware/efi/reboot.c registers
> efi_power_off late in order to override anything else, though that's
> best-effort at present.

That's very interesting. I think that Xen on ARM should follow what
Linux does and what Xen already does on x86 and try efi_reset_system
first on efi systems.

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

Re: [Xen-devel] [PATCH] docs: correct descriptions of gnttab_max_{, maptrack}_frames

[Ian Campbell]

On Tue, 2016-01-19 at 11:56 +, Ian Campbell wrote:

Should have been tagged, v2, sorry.

> gnttab_max_frames incorrectly referred to numbers of grant tab
> operations and gnttab_max_maptrack_frames was confusingly worded.
> 
> Add the default for gnttab_max_frames while here (it's currently the
> same on all arches since no arch uses the available arch override) and
> adjust the default for gnttab_max_maptrack_frames to match the normal
> form.
> 
> Signed-off-by: Ian Campbell 
> ---
> v2: Use more prevalent form for specifying defaults.
> ---
>  docs/misc/xen-command-line.markdown | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-
> line.markdown
> index 5ed0730..d267a04 100644
> --- a/docs/misc/xen-command-line.markdown
> +++ b/docs/misc/xen-command-line.markdown
> @@ -740,13 +740,18 @@ Specify which console gdbstub should use. See
> **console**.
>  ### gnttab\_max\_frames
>  > `= `
>  
> -Specify the maximum number of frames per grant table operation.
> +> Default: `32`
> +
> +Specify the maximum number of frames which any domain may use as part
> +of its grant table.
>  
>  ### gnttab\_max\_maptrack\_frames
>  > `= `
>  
> -Specify the maximum number of maptrack frames domain.
> -The default value is 8 times **gnttab\_max\_frames**.
> +> Default: `8 * gnttab_max_frames`
> +
> +Specify the maximum number of frames to use as part of a domains
> +maptrack array.
>  
>  ### gnttab\_max\_nr\_frames
>  > `= `

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

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

[osstest service owner]

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

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  0c2f1283486f953604a282188a06e2db143f475d
baseline version:
 xen  9fe43a2664cb6a36888220ae67732deafaa3f82b

Last test of basis78454  2016-01-18 21:02:24 Z0 days
Testing same since78511  2016-01-19 10:00:48 Z0 days1 attempts


People who touched revisions under test:
  Doug Goldstein 
  Ian Campbell 

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=0c2f1283486f953604a282188a06e2db143f475d
+ . ./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 
0c2f1283486f953604a282188a06e2db143f475d
+ branch=xen-unstable-smoke
+ revision=0c2f1283486f953604a282188a06e2db143f475d
+ . ./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-unstable
+ '[' x0c2f1283486f953604a282188a06e2db143f475d = 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/
+++ '[' 

Re: [Xen-devel] [PATCH v2 10/16] ARM: XEN: Move xen_early_init() before efi_init()

[Stefano Stabellini]

On Tue, 19 Jan 2016, Shannon Zhao wrote:
> On 2016/1/18 22:59, Stefano Stabellini wrote:
> > On Fri, 15 Jan 2016, Shannon Zhao wrote:
> >> From: Shannon Zhao 
> >>
> >> Move xen_early_init() before efi_init(), then when calling efi_init()
> >> could initialize Xen specific UEFI.
> >>
> >> Check if it runs on Xen hypervisor through the flat dts.
> >>
> >> Signed-off-by: Shannon Zhao 
> >> ---
> >>  arch/arm/xen/enlighten.c  | 56 
> >> ++-
> >>  arch/arm64/kernel/setup.c |  2 +-
> >>  2 files changed, 42 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
> >> index 4e78c49..5d0fe68 100644
> >> --- a/arch/arm/xen/enlighten.c
> >> +++ b/arch/arm/xen/enlighten.c
> >> @@ -19,6 +19,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>  #include 
> >>  #include 
> >> @@ -52,8 +53,6 @@ struct xen_memory_region 
> >> xen_extra_mem[XEN_EXTRA_MEM_MAX_REGIONS] __initdata;
> >>  
> >>  static __read_mostly unsigned int xen_events_irq;
> >>  
> >> -static __initdata struct device_node *xen_node;
> >> -
> >>  int xen_remap_domain_gfn_array(struct vm_area_struct *vma,
> >>   unsigned long addr,
> >>   xen_pfn_t *gfn, int nr,
> >> @@ -222,6 +221,33 @@ static irqreturn_t xen_arm_callback(int irq, void 
> >> *arg)
> >>return IRQ_HANDLED;
> >>  }
> >>  
> >> +static __initdata struct {
> >> +  const char *compat;
> >> +  const char *prefix;
> >> +  const char *version;
> >> +  bool found;
> >> +} xen_node = {"xen,xen", "xen,xen-", NULL, false};
> >> +
> >> +static int __init fdt_find_xen_node(unsigned long node, const char *uname,
> >> +  int depth, void *data)
> >> +{
> >> +  const void *s = NULL;
> >> +  int len;
> >> +
> >> +  if (depth != 1 || strcmp(uname, "hypervisor") != 0)
> >> +  return 0;
> >> +
> >> +  if (of_flat_dt_is_compatible(node, xen_node.compat))
> >> +  xen_node.found = true;
> >> +
> >> +  s = of_get_flat_dt_prop(node, "compatible", );
> >> +  if (strlen(xen_node.prefix) + 3  < len &&
> >> +  !strncmp(xen_node.prefix, s, strlen(xen_node.prefix)))
> >> +  xen_node.version = s + strlen(xen_node.prefix);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >>  /*
> >>   * see Documentation/devicetree/bindings/arm/xen.txt for the
> >>   * documentation of the Xen Device Tree format.
> >> @@ -229,26 +255,18 @@ static irqreturn_t xen_arm_callback(int irq, void 
> >> *arg)
> >>  #define GRANT_TABLE_PHYSADDR 0
> >>  void __init xen_early_init(void)
> >>  {
> >> -  int len;
> >> -  const char *s = NULL;
> >> -  const char *version = NULL;
> >> -  const char *xen_prefix = "xen,xen-";
> >> -
> >> -  xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> >> -  if (!xen_node) {
> >> +  of_scan_flat_dt(fdt_find_xen_node, NULL);
> >> +  if (!xen_node.found) {
> >>pr_debug("No Xen support\n");
> >>return;
> >>}
> >> -  s = of_get_property(xen_node, "compatible", );
> >> -  if (strlen(xen_prefix) + 3  < len &&
> >> -  !strncmp(xen_prefix, s, strlen(xen_prefix)))
> >> -  version = s + strlen(xen_prefix);
> >> -  if (version == NULL) {
> >> +
> >> +  if (xen_node.version == NULL) {
> >>pr_debug("Xen version not found\n");
> >>return;
> >>}
> > 
> > This is going to access data within the fdt, after it has been
> > unflattened (by the unflatten_device_tree call). Is that allowed?
> > 
> > If that's not allowed, then you could copy the version string to
> > xen_node.version, rather than just copying the pointer. Otherwise you
> > could move the version check entirely within fdt_find_xen_node and
> > remove the version field from xen_node.
> > 
> A little confused. Since here we move xen_early_init before efi_init and
> before unflatten_device_tree as well, at this moment in xen_early_init
> the fdt is flattened. The xen_node.version is only set in
> fdt_find_xen_node and accessed in xen_early_init.

You are right, sorry, I must have been confused. It might be good to
rename the xen_node variable that this patch introduced in xen_guest_init.



> >> -  pr_info("Xen %s support found\n", version);
> >> +  pr_info("Xen %s support found\n", xen_node.version);
> >>  
> >>xen_domain_type = XEN_HVM_DOMAIN;
> >>  
> >> @@ -296,6 +314,14 @@ static int __init xen_guest_init(void)
> >>}
> >>  #endif
> >>} else {
> >> +  struct device_node *xen_node;
> >> +
> >> +  xen_node = of_find_compatible_node(NULL, NULL, "xen,xen");
> >> +  if (!xen_node) {
> >> +  pr_debug("No Xen support\n");
> >> +  return -ENODEV;
> >> +  }
> > 
> > It makes sense to move this into a DT specific init function called from
> > xen_guest_init. Also, given that at this point we know that a Xen node
> > should be present, 

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

[osstest service owner]

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

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  1949868d640427dc91bfb23741d78eb1d86841c8
baseline version:
 xen  162a81abb1c55ff77a3fcc82c7971a766ca122f6

Last test of basis78522  2016-01-19 13:01:25 Z0 days
Failing since 78539  2016-01-19 16:01:48 Z0 days3 attempts
Testing same since78553  2016-01-19 20:02:25 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Haozhong Zhang 
  Ian Campbell 
  Jan Beulich 
  Malcolm Crossley 
  Roger Pau Monne 
  Roger Pau Monné 
  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=1949868d640427dc91bfb23741d78eb1d86841c8
+ . ./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 
1949868d640427dc91bfb23741d78eb1d86841c8
+ branch=xen-unstable-smoke
+ revision=1949868d640427dc91bfb23741d78eb1d86841c8
+ . ./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-unstable
+ '[' x1949868d640427dc91bfb23741d78eb1d86841c8 = 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 

Re: [Xen-devel] Questions about the use of idle_vcpu[]

[Tianyang Chen]

On 1/18/2016 11:07 AM, Meng Xu wrote:

On Mon, Jan 18, 2016 at 6:00 AM, Dario Faggioli
 wrote:


On Mon, 2016-01-18 at 10:47 +, George Dunlap wrote:

On Fri, Jan 15, 2016 at 1:04 AM, Tianyang Chen 


If an idle vcpu is picked, the ret.time is set accordingly in both
credit
and credit2 by checking whether snext is idle. if so, credit
returns -1 and
credit2 returns 2ms. However, there is no corresponding code in the
RTDS
scheduler to handle this. When an idle_vcpu is picked, the value of
ret.time
would be 0 and the scheduler would be invoked again. What is the
logic
behind this?


No real logic, as far as I can tell. :-)  The ret.time return value
tells the generic scheduling code when to set the next scheduler
timer.  According to the comment in xen/common/schedule.c:schedule(),
returning a negative value means "don't bother setting a timer"
(e.g.,
no time limit).  So credit1 does the right thing.


It does.



Then the RTDS is doing *incorrectly* right now. :-(



George: Thanks. After looking at idle_loop() it makes sense now. Even 
though an idle vcpu won't tell scheduler timer when to fire next time, 
do_tasklet() checks if all tasklets on the list are finished and then 
raise SCHEDULE_SOFTIRQ.






It looks like credit2's behavior will probably prevent the processor
from going into deeper power-saving states, and rtds' behavior might
cause it to essentially busy-wait.


RTDS behavior is broken in many respect, including this,

and in fact,
Meng and Tianyang are sending patches already to fix it (I'll let you
guys have my comments shortly :-P).



Right. Tianyang and I are working on changing it from quantum driven
model to event-driven (or called timer-driven) model. Tianyang sent
out the first-version patch, but that version has some problems. He is
working on the second version now.

Hi Dario,
Tianyang is working on the second version right now.
If you could have a quick look at our discussion in that thread and
points out the "serious" issues in the decision, that will be great!
We won't repeat the error again and again in the following versions.
As to the minor issues, we could refine it in the second version.
(I'm just thinking about how to save your time to have this done. For
the obvious things that I can handle, I will do it and avoid "wasting"
you time. For the design choices that we are unclear, we definitely
need your insights/commands. ;-) )

Dario: I had some discussion with Meng recently and the second version 
will soon come out. You can directly comment on it if that saves you 
some time.


Thanks,
Tianyang

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

Re: [Xen-devel] [PATCH v6 1/2] memory-hotplug: add automatic onlining policy for the newly added memory

[David Rientjes]

On Fri, 15 Jan 2016, Vitaly Kuznetsov wrote:

> Currently, all newly added memory blocks remain in 'offline' state unless
> someone onlines them, some linux distributions carry special udev rules
> like:
> 
> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", 
> ATTR{state}="online"
> 
> to make this happen automatically. This is not a great solution for virtual
> machines where memory hotplug is being used to address high memory pressure
> situations as such onlining is slow and a userspace process doing this
> (udev) has a chance of being killed by the OOM killer as it will probably
> require to allocate some memory.
> 
> Introduce default policy for the newly added memory blocks in
> /sys/devices/system/memory/auto_online_blocks file with two possible
> values: "offline" which preserves the current behavior and "online" which
> causes all newly added memory blocks to go online as soon as they're added.
> The default is "offline".
> 
> Reviewed-by: Daniel Kiper 
> Signed-off-by: Vitaly Kuznetsov 

Acked-by: David Rientjes 

Thanks for the very good documentation!

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

[Xen-devel] [PATCH] x86/HVM: memset CPU context save area

[Roger Pau Monne]

In order to prevent leaking data in the padding field. Also remove the
memset done to the fpu_regs in case of no FPU context present, since it's
already taken care by the memset of the whole CPU context structure. The
same applies to setting ctxt.flags to 0 in case there's no FPU context.

Signed-off-by: Roger Pau Monné 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/hvm.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 8f98956..674feea 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1732,6 +1732,8 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 if ( v->pause_flags & VPF_down )
 continue;
 
+memset(, 0, sizeof(ctxt));
+
 /* Architecture-specific vmcs/vmcb bits */
 hvm_funcs.save_cpu_ctxt(v, );
 
@@ -1798,11 +1800,6 @@ static int hvm_save_cpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 memcpy(ctxt.fpu_regs, v->arch.fpu_ctxt, sizeof(ctxt.fpu_regs));
 ctxt.flags = XEN_X86_FPU_INITIALISED;
 }
-else
-{
- memset(ctxt.fpu_regs, 0, sizeof(ctxt.fpu_regs));
- ctxt.flags = 0;
-}
 
 ctxt.rax = v->arch.user_regs.eax;
 ctxt.rbx = v->arch.user_regs.ebx;
-- 
1.9.5 (Apple Git-50.3)


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

[Xen-devel] [xen-unstable-smoke test] 78539: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 
78522

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  eb68c40ba5d0212adc176290f09e4ee133c96e83
baseline version:
 xen  162a81abb1c55ff77a3fcc82c7971a766ca122f6

Last test of basis78522  2016-01-19 13:01:25 Z0 days
Testing same since78539  2016-01-19 16:01:48 Z0 days1 attempts


People who touched revisions under test:
  Haozhong Zhang 
  Jan Beulich 
  Roger Pau Monné 
  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 fail
 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


Not pushing.


commit eb68c40ba5d0212adc176290f09e4ee133c96e83
Author: Roger Pau Monné 
Date:   Tue Jan 19 16:08:39 2016 +0100

x86/HVM: add padding to struct hvm_hw_cpu

So that the size of the structure is the same on 32 and 64bit.

Signed-off-by: Roger Pau Monné 
Reviewed-by: Andrew Cooper 

commit 805b7484b85e77b15c68e837b3d7b77053182d37
Author: Haozhong Zhang 
Date:   Tue Jan 19 16:07:59 2016 +0100

svm: remove redundant TSC scaling in svm_set_tsc_offset()

Now every caller passes an already scaled offset to
svm_set_tsc_offset(), so it's not necessary to recalculate a scaled TSC
offset in svm_set_tsc_offset().

Signed-off-by: Haozhong Zhang 
Reviewed-by: Boris Ostrovsky 

commit eab8a90be723d742d607aff2005ea0ab521bfd6a
Author: Haozhong Zhang 
Date:   Tue Jan 19 16:07:39 2016 +0100

x86/time: scale host TSC in pvclock properly

This patch makes the pvclock return the scaled host TSC and
corresponding scaling parameters to HVM domains if guest TSC is not
emulated and TSC scaling is enabled.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Boris Ostrovsky 

commit 52fd9a46f6e9eb050a6b402ce3b04fa57907acc5
Author: Haozhong Zhang 
Date:   Tue Jan 19 16:07:15 2016 +0100

x86/hvm: scale host TSC when setting/getting guest TSC

The existing hvm_[set|get]_guest_tsc_fixed() calculate the guest TSC by
adding the TSC offset to the host TSC. When the TSC scaling is enabled,
the host TSC should be scaled first. This patch adds the scaling logic
to those two functions.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Boris Ostrovsky 

commit c2ba8c24f34426c993afa841bf94d933d2461cd9
Author: Roger Pau Monné 
Date:   Tue Jan 19 16:06:31 2016 +0100

elfnotes: check phys_entry against UNSET_ADDR32

And introduce UNSET_ADDR32.

Signed-off-by: Roger Pau Monné 
Acked-by: Jan Beulich 
Acked-by: Wei Liu 
(qemu changes not included)

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

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Ian Jackson]

Chunyan Liu writes ("[PATCH V13 5/5] xl: add pvusb commands"):
> Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
> usbdev-attach and usbdev-detach.

Thanks for swapping this with the other patch.  It is better now.

> +=item B I I

However, I think you need to explictly state that the user may (and
indeed, must) pass multiple settings as separate arguments.  AFAICT
the parser here doesn't do the ,-splitting.

> +I describes the device to attach, using the same format
> +as the B string in the domain config file. See L for
> +more information.

And this, therefore, is not quite true.

To be clear, I think that you should fix the documentation to match
the code.

Thanks,
Ian.

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

Re: [Xen-devel] [PATCH OSSTEST] sg-report-job-history: alternate color of osstest column only when it changes

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH OSSTEST] sg-report-job-history: alternate 
color of osstest column only when it changes"):
> On Wed, 2016-01-06 at 11:08 +, Ian Campbell wrote:
> 
> ping?

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH] build: specify minimum versions of make and binutils

[Doug Goldstein]

On 1/19/16 2:48 AM, Jan Beulich wrote:
 On 18.01.16 at 18:21,  wrote:
>> On 1/18/16 11:03 AM, Jan Beulich wrote:
>> On 18.01.16 at 17:53,  wrote:
 To help people avoid having to figure out what versions of make and
 binutils need to be supported document them explicitly. The version of
 binutils that had to be supported was mentioned in
 http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00609.html 
 as 2.17. Knowing that Jan got these versions from SLES10 I looked up the
 version of GNU make from the same vintage (mid-2006) and landed on 3.81.
>>>
>>> I'm afraid that same SLE10 has been using binutils 2.16.9.
>>> and make 3.80. While (still building Xen there once in a while) I'd probably
>>> not be in big trouble if we decided we don't want to support that old an
>>> environment anymore, I don't think we can just go and document higher
>>> versions than we so far allowed. We'd first need to settle on where to
>>> draw the line nowadays (which then likely would mean a gcc minimal
>>> version bum too).
>>
>> Not a problem. I was just trying to take the situation from a guessing
>> game to be explicitly called out. I was documenting what my logic was
>> behind the version numbers I selected. I wasn't able to compare dates
>> with binutils because their repo goes from 2003 to 2011 [1]. So I went
>> back to SLES10's release date [2] and the GCC 4.1.0 release date [3] to
>> compare it with GNU make [4].
>>
>> Honestly I'd be happy if we just drew a line in the sand so that its
>> clear what I need to test against when I submit patches. I don't really
>> care where the line is.
> 
> Then how about 2.16.1 and 3.80 respectively as the initial line?
> 
> Jan
> 

Sounds great to me. Would you like me to resubmit or do you want to make
that change. I'm ok if you throw away my patch and author it yourself.
Whatever is easiest for you (or whoever commits it).

-- 
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] tools/toollog: Drop XTL_NEW_LOGGER()

[Andrew Cooper]

On 19/01/16 17:36, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH] tools/toollog: Drop XTL_NEW_LOGGER()"):
>> Ian Campbell writes ("Re: [PATCH] tools/toollog: Drop XTL_NEW_LOGGER()"):
>>> The underlying issue with all of these is the _undocumented_ nature of the
>>> assumptions, which is certainly a bug, however those assumptions are not in
>>> themselves "unreasonable" as was claimed.
>> Maybe I should submit a counter-patch providing documentation.
> I think this macro is useful because if you wanted to write (say)
> xtl_logger_syslog, you would want to use it to help you with some
> boilerplate.

WTF? Even documented, the behaviour of this macro is insane, which is
why I am trying to kill it.  After this, I will also be fixing the gross
pointer abuse which exists in the xentoollog internals, before the ABI
becomes fixed in 4.7.

There should be no place for code like this, and certainly not in the
clean API/ABI we are trying to create out of the mess which is libxc.

Irrespective of whether you disagree with my opinions here, xentoollog.h
is specified to be C99 -strict, meaning no GNUisms.

~Andrew

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

Re: [Xen-devel] [PATCH 2/2] libxl: fix UUID usage on FreeBSD

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix UUID usage on 
FreeBSD"):
> On Fri, 2016-01-15 at 16:11 +0100, Roger Pau Monné wrote:
> > Yes, we can remove the uuid_t from libxl_uuid, but this is AFAICT a
> > structure that belongs to the stable API.
> 
> Oh b*m, so it is.

I think we may have to bite this bullet.  Perhaps we could make an
#ifdef that softened the blow on systems with sane uuid_t.

Given that we have discovered that uuid_t is sometimes insane, I think
we really really want to avoid it.

> Or can we get rid of uuid_raw (which is not touched, and is less likely to
> be given that it is only on a subset of platforms) and have libxl
> _internal_ stuff convert to a byte array.

We don't want to do any byteswapping.  That way lies utter madness.
At the libxl API/ABI uuids should be represented as sequences of 16
octets in network byte order (BE).

Ian.

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

Re: [Xen-devel] [xen-unstable-smoke test] 78539: regressions - FAIL

[Roger Pau Monné]

El 19/01/16 a les 18.43, osstest service owner ha escrit:
> flight 78539 xen-unstable-smoke real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/78539/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 
> 78522

This is my fault:

Jan 19 16:49:13.681214 (XEN) HVM3 restore: CPU 0
Jan 19 16:49:36.461176 (XEN) HVM3 restore: failed to load entry 2/0

It should be fixed by
<1453225373-81485-1-git-send-email-roger@citrix.com>

Roger.


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

Re: [Xen-devel] [xen-unstable-smoke test] 78539: regressions - FAIL [and 3 more messages]

[Ian Jackson]

Roger Pau Monne writes ("[Xen-devel] [PATCH] x86/HVM: memset CPU context save 
area"):
> In order to prevent leaking data in the padding field. Also remove the
> memset done to the fpu_regs in case of no FPU context present, since it's
> already taken care by the memset of the whole CPU context structure. The
> same applies to setting ctxt.flags to 0 in case there's no FPU context.
> 
> Signed-off-by: Roger Pau Monné 
...
> Reported-by: Jan Beulich 

Andrew Cooper writes ("Re: [Xen-devel] [PATCH] x86/HVM: memset CPU context save 
area"):
> Reviewed-by: Andrew Cooper 

Thanks, applied.

Roger Pau Monné writes ("Re: [Xen-devel] [xen-unstable-smoke test] 78539: 
regressions - FAIL"):
> El 19/01/16 a les 18.43, osstest service owner ha escrit:
> > flight 78539 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/78539/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. 
> > vs. 78522
> 
> This is my fault:
> 
> Jan 19 16:49:13.681214 (XEN) HVM3 restore: CPU 0
> Jan 19 16:49:36.461176 (XEN) HVM3 restore: failed to load entry 2/0
> 
> It should be fixed by
> <1453225373-81485-1-git-send-email-roger@citrix.com>

Thanks for the heads-up.

Ian.

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

Re: [Xen-devel] [PATCH] tools/toollog: Drop XTL_NEW_LOGGER()

[Ian Jackson]

Andrew Cooper writes ("Re: [PATCH] tools/toollog: Drop XTL_NEW_LOGGER()"):
> On 19/01/16 17:36, Ian Jackson wrote:
> > I think this macro is useful because if you wanted to write (say)
> > xtl_logger_syslog, you would want to use it to help you with some
> > boilerplate.
> 
> WTF? Even documented, the behaviour of this macro is insane, which is
> why I am trying to kill it.  After this, I will also be fixing the gross
> pointer abuse which exists in the xentoollog internals, before the ABI
> becomes fixed in 4.7.

I think the behaviour of this macro is perfectly sane.

I think your reference to `gross pointer abuse' is to the casting from
the specific to the generic struct.  This is a completely standard
technique for oopy stuff in C.  Here is a whole library (quite a nice
neat library, in fact) that uses it:
   http://www.lysator.liu.se/liboop/
   http://www.lysator.liu.se/liboop/ref.html

> Irrespective of whether you disagree with my opinions here, xentoollog.h
> is specified to be C99 -strict, meaning no GNUisms.

Specified where ?

Anyway, there is no requirement to use this macro.  If someone wants
to write a strict C99 xtl logger then they can do it by hand.  (I
predict that no-one will want to do that.)  So there is clearly no
actual reason why this macro ought to be pure C99.

Ian.

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   like 78311

Tests which did not succeed, but are not blocking:
 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-amd64-i386-libvirt-xsm  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 12 migrate-support-checkfail   never pass
 test-amd64-i386-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-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail 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  c03fbecc7cd463900d0291034e873f00062a75db
baseline version:
 libvirt  8fd68675e2b5eed5b2aae636544a0a80f9fc70e9

Last test of basis78311  2016-01-17 04:19:52 Z2 days
Testing same since78488  2016-01-19 04:22:02 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Martin Kletzander 
  Michal Privoznik 
  Wido den Hollander 

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
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd 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
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=libvirt
+ revision=c03fbecc7cd463900d0291034e873f00062a75db
+ . ./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 ']'
++ 

Re: [Xen-devel] [PATCH V13 4/5] domcreate: support pvusb in configuration file

[Ian Jackson]

Chunyan Liu writes ("[PATCH V13 4/5] domcreate: support pvusb in configuration 
file"):
> Add code to support pvusb in domain config file. One could specify
> usbctrl and usb in domain's configuration file and create domain,
> then usb controllers will be created and usb device would be attached
> to guest automatically.
> 
> One could specify usb controllers and usb devices in config file
> like this:
> usbctrl=['version=2,ports=4', 'version=1, ports=4', ]
> usbdev=['hostbus=2, hostaddr=1, controller=0,port=1', ]
> 
> Signed-off-by: Chunyan Liu 
> Signed-off-by: Simon Cao 
> Reviewed-by: George Dunlap 

Acked-by: Ian Jackson 

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

[Xen-devel] [xen-unstable-smoke test] 78548: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 12 guest-saverestore fail REGR. vs. 
78522

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  ef17887d848dae0ca46231b47bf30d3c1d4aa87d
baseline version:
 xen  162a81abb1c55ff77a3fcc82c7971a766ca122f6

Last test of basis78522  2016-01-19 13:01:25 Z0 days
Failing since 78539  2016-01-19 16:01:48 Z0 days2 attempts
Testing same since78548  2016-01-19 18:03:08 Z0 days1 attempts


People who touched revisions under test:
  Boris Ostrovsky 
  Haozhong Zhang 
  Ian Campbell 
  Jan Beulich 
  Malcolm Crossley 
  Roger Pau Monné 
  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 fail
 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


Not pushing.


commit ef17887d848dae0ca46231b47bf30d3c1d4aa87d
Author: Ian Campbell 
Date:   Tue Jan 19 11:56:50 2016 +

docs: correct descriptions of gnttab_max_{, maptrack}_frames

gnttab_max_frames incorrectly referred to numbers of grant tab
operations and gnttab_max_maptrack_frames was confusingly worded.

Add the default for gnttab_max_frames while here (it's currently the
same on all arches since no arch uses the available arch override) and
adjust the default for gnttab_max_maptrack_frames to match the normal
form.

Signed-off-by: Ian Campbell 
Acked-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

commit aa037dc9d3e09850f8a0e4ba9fba8e487f8a64cc
Author: Malcolm Crossley 
Date:   Tue Jan 19 11:27:56 2016 +

xenpm: Add option to report average CPU frequency

The average is calculated over the period of time from the last
xenpm report of the average CPU frequency.

Reporting the average CPU frequency helps confirm the level of turbo
boost being achieved per CPU.

Signed-off-by: Malcolm Crossley 
Acked-by: Ian Campbell 

commit 1e72eebd21a5bdb799fa1fbc0eb60c4b58e30af8
Author: Wei Liu 
Date:   Tue Jan 19 12:03:05 2016 +

libxc: fix comment in xc__hypercall_bounce_pre

Signed-off-by: Wei Liu 

commit 38a048a3c6f44008a83ac77aecac01a7bce0e7d1
Author: Boris Ostrovsky 
Date:   Thu Jan 7 17:19:07 2016 -0500

libxc: Defer initialization of start_page for HVM guests

With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
builder if supported") location of ramdisk may not be available to
HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
guest supports unmapped initrd.

So let's move ramdisk info initialization (along with a few other
operations that are not directly related to allocating magic/special
pages) from alloc_magic_pages_hvm() to bootlate_hvm().

Since we now split allocation and mapping of the start_info segment
let's stash it, along with cmdline length, in xc_dom_image so that we
can check whether we are mapping correctly-sized range.

We can also stop using xc_dom_image.start_info_pfn and leave it for
PV(H) guests only.

Signed-off-by: Boris Ostrovsky 
Acked-by: Roger Pau Monné 

Re: [Xen-devel] [PATCH] x86/HVM: memset CPU context save area

[Roger Pau Monné]

El 19/01/16 a les 18.42, Roger Pau Monne ha escrit:
> In order to prevent leaking data in the padding field. Also remove the
> memset done to the fpu_regs in case of no FPU context present, since it's
> already taken care by the memset of the whole CPU context structure. The
> same applies to setting ctxt.flags to 0 in case there's no FPU context.
> 
> Signed-off-by: Roger Pau Monné 

Forgot to add:

Reported-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH] x86/HVM: memset CPU context save area

[Andrew Cooper]

On 19/01/16 17:42, Roger Pau Monne wrote:
> In order to prevent leaking data in the padding field. Also remove the
> memset done to the fpu_regs in case of no FPU context present, since it's
> already taken care by the memset of the whole CPU context structure. The
> same applies to setting ctxt.flags to 0 in case there's no FPU context.
>
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Jan Beulich 
> Cc: Andrew Cooper 

Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] Error booting Xen

[Harmandeep Kaur]

On Tue, Jan 19, 2016 at 10:38 PM, Dario Faggioli
 wrote:
> On Tue, 2016-01-19 at 17:02 +, Andrew Cooper wrote:
>> On 19/01/16 16:47, Jan Beulich wrote:
>> > > > > On 19.01.16 at 17:27,  wrote:
>> > > Adding 'xsave=0' is working for now. Thank you
>> > > all for your help :)
>> > But that means we actually should get to the bottom of your
>> > problem!
>>
>> There was some discussion on IRC.  `xrstror` was repeatedly taking
>> the
>> same fault; i.e. the fixup code wasn't fixing up suitably.
>>
> Yes, indeed.
>
>> As a first candidate, I expect 83ae0bb2 is a likely candidate.
>> Harmandeep is using a Skylake processor.
>>
> Yes, she is on Skylake. But she's also using master, so,
> AFAICT, 83ae0bb2 is not there.
>
> She will be trying to use staging (and kill xsave=0) soon, and will let
> us know.

I tried booting staging branch but results were identical. Following
line repeats endlessly.
(XEN) traps.c:3290: GPF (): 82d0801c1cce -> 82d080252e5c

$ 'addr2line -e xen-syms 82d0801c1cce' returns
'xen/xen/arch/x86/xstate.c:387' which again points to
xsave. Also, adding 'xsave=0' makes it boot just fine.

Full boot log here, http://paste2.org/1DCge9Fb

Thanks and regards,
Harmandeep

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

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

Re: [Xen-devel] [PATCH 3/3] tools: introduce parameter max_ranges.

[Tian, Kevin]

> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Tuesday, January 19, 2016 11:19 PM
> 
> On Tue, 2016-01-19 at 15:04 +, Wei Liu wrote:
> 
> This patch doesn't seem to have been CCd to the tools maintainers, adding
> Ian too, I think everyone else was picked up along the way.
> 
> Please use ./scripts/get_maintainers.pl in the future.
> 
> > On Tue, Jan 19, 2016 at 02:47:40PM +, Paul Durrant wrote:
> > [...]
> > > > ranges so perhaps the parameter name could be
> > > > 'max_wp_memory_ranges'?
> > > > >
> > > >
> > > > What does "WP" mean? "Write Protected"?
> > > >
> > >
> > > Yes.
> > >
> > > > Is this parameter closely related to IOREQ server? Should it contain
> > > > "ioreq" somehow?
> > > >
> > >
> > > It is closely related but ioreq server is an implementation detail so
> > > do we want to expose it as a tunable? The concept we need to capture
> > > is that the toolstack can tune the limit of the maximum number of
> > > pages in the VM that can be set such that writes are emulated (but
> > > reads are as for normal ram). Or I guess we could get very specific
> > > and call it something like 'max_gtt_shadows'?
> >
> > I would prefer generic concept in this case ("wp"). Let's wait a bit for
> > other people to voice their opinion.
> >
> > Whichever one we pick it the meaning of the acronym needs to be clearly
> > documented...
> 
> I've got no ideas for a better name, "max_ranges" is clearly too generic
> though.
> 
> One thought -- does XenGT require some other configuration option to enable
> it or maybe a privilege which the target domain must necessarily have?
> Could we use something like one of those to cause the t/stack to just DTRT
> without the user having to micromanage the amount of pages which are
> allowed to have this property?
> 

Using "wp" is clear to me.

As a feature this write-protection has nothing to be GPU virtualization 
specific.
In the future the same mediated pass-through idea used in XenGT may be
used on other I/O devices which need to shadow some structure w/ requirement
to write-protect guest memory. So it's not good to tie this to either XenGT
or GTT.

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

Re: [Xen-devel] [PATCH v5 1/6] remus: don't do failover if we don't have an consistent state

[Wen Congyang]

On 01/19/2016 06:48 PM, Ian Campbell wrote:
> On Tue, 2016-01-19 at 15:17 +0800, Wen Congyang wrote:
>> We will have an consistent state when a CHECKPOINT_END record
> 
> "a consistent ..." (and in the subject too).
> 
>> is received. After the first CHECKPOINT_END record is received,
>> we will buffer all records until the next CHECKPOINT_END record
>> is received. So if the checkpoint() callback returns
>> XGR_CHECKPOINT_FAILOVER,
>> we only can do failover if ctx->restore.buffer_all_records is
>> true.
>>
>> Signed-off-by: Wen Congyang 
>> ---
> 
> Please can you get into the habit of writing a delta from the previous
> version here. e.g. in this case:
> 
> v5: New patch.
> 
> Putting it after the --- means it doesn't go into the actual commit ("git
> am" will strip it) but it is very useful for reviewers to know what changed
> in each iteration.
> 
> See also 
> http://wiki.xen.org/wiki/Submitting_Xen_Patches#Review.2C_Rinse_.26_Repeat
> 
>>  tools/libxc/xc_sr_restore.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/libxc/xc_sr_restore.c b/tools/libxc/xc_sr_restore.c
>> index 05159bb..9fe2829 100644
>> --- a/tools/libxc/xc_sr_restore.c
>> +++ b/tools/libxc/xc_sr_restore.c
>> @@ -493,7 +493,11 @@ static int handle_checkpoint(struct xc_sr_context
>> *ctx)
>>  break;
>>  
>>  case XGR_CHECKPOINT_FAILOVER:
>> -rc = BROKEN_CHANNEL;
>> +if ( ctx->restore.buffer_all_records )
>> +rc = BROKEN_CHANNEL;
>> +else
>> +/* We don't have an consistent state */
> 
> "a" not "an" again.
> 
> I can s/an/a/ in all 3 places upon commit, so no need to resend for just
> those.

OK, thanks for your help

Wen Congyang

> 
> Acked-by: Ian Campbell 
> 
> I'll give Andy a chance to comment before committing though.
> 
>> +rc = -1;
>>  goto err;
>>  
>>  default: /* Other fatal error */
> 
> 
> .
> 




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

Re: [Xen-devel] [PATCH v5 3/6] remus: resume immediately if libxl__xc_domain_save_done() completes

[Wen Congyang]

On 01/19/2016 06:55 PM, Ian Campbell wrote:
> On Tue, 2016-01-19 at 15:17 +0800, Wen Congyang wrote:
>> For example: if the secondary host is down, and we fail to send the data
>> to
>> the secondary host. xc_domain_save() returns 0. So in the function
>> libxl__xc_domain_save_done(), rc is 0 (the helper program exits
>> normally),
>> and retval is 0 (it is xc_domain_save()'s return value). In such case, we
>> just need to complete the stream.
>>
>> Signed-off-by: Wen Congyang 
>> Reviewed-by: Andrew Cooper 
>> ---
>>  tools/libxl/libxl.h  |  4 
>>  tools/libxl/libxl_stream_write.c | 14 --
>>  2 files changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
>> index 7114491..df6c7a3 100644
>> --- a/tools/libxl/libxl.h
>> +++ b/tools/libxl/libxl.h
>> @@ -1215,6 +1215,10 @@ int libxl_domain_resume(libxl_ctx *ctx, uint32_t
>> domid, int suspend_cancel,
>>  const libxl_asyncop_how *ao_how)
>>  LIBXL_EXTERNAL_CALLERS_ONLY;
>>  
>> +/*
>> + * This function doesn't return until something is wrong, and we need to
>> + * do failover from secondary.
> 
> This function runs on the primary, doesn't it? and failover would be from
> primary to secondary.

Yes, it runs on the primary

> 
> So I think a more accurate wording would be:
> 
> /*
>  * This function doesn't return unless something has gone wrong with the
>  * replication to the secondary. If this function returns then the caller 
>  * should resume the (primary) domain.
>  */
> 
> I'm happy to edit the text on commit if you agree with the proposed
> wording. The code looks good.

I agree with that.

Thanks
Wen Congyang

> 
> Thanks,
> Ian.
> 
> 
> 
> .
> 




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

Re: [Xen-devel] [PATCH V13 5/5] xl: add pvusb commands

[Jim Fehlig]

On 01/19/2016 11:11 AM, Ian Jackson wrote:
> Chunyan Liu writes ("[PATCH V13 5/5] xl: add pvusb commands"):
>> Add pvusb commands: usbctrl-attach, usbctrl-detach, usb-list,
>> usbdev-attach and usbdev-detach.
> Thanks for swapping this with the other patch.  It is better now.
>
>> +=item B I I
> However, I think you need to explictly state that the user may (and
> indeed, must) pass multiple settings as separate arguments.  AFAICT
> the parser here doesn't do the ,-splitting.

I just noticed this is the case with network devices as well. E.g.

#xl network-attach hvm-domU mac=00:16:3e:xx:yy:zz,bridge=br0
libxl: error: libxl_device.c:1095:device_hotplug_child_death_cb: script: Could
not find bridge device xenbr0

main_networkattach() in tools/libxl/xl_cmdimpl.c doesn't split on the ',', so
everything after mac=00:16:3e:xx:yy:zz is ignored. I'd need advice on how to fix
this though. Based on xl-network-configuration doc and Xen tool's long history
of network-attach supporting that syntax, I'd say main_networkattach() should be
changed to split on ','. I could also change the docs. Do tools maintainers have
a preference, or alternative option?

Regards,
Jim


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

Re: [Xen-devel] [PATCH 0/4] add support for vNVDIMM

[Tian, Kevin]

> From: Zhang, Haozhong
> Sent: Tuesday, December 29, 2015 7:32 PM
> 
> This patch series is the Xen part patch to provide virtual NVDIMM to
> guest. The corresponding QEMU patch series is sent separately with the
> title "[PATCH 0/2] add vNVDIMM support for Xen".
> 
> * Background
> 
>  NVDIMM (Non-Volatile Dual In-line Memory Module) is going to be
>  supported on Intel's platform. NVDIMM devices are discovered via ACPI
>  and configured by _DSM method of NVDIMM device in ACPI. Some
>  documents can be found at
>  [1] ACPI 6: http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
>  [2] NVDIMM Namespace: http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
>  [3] DSM Interface Example:
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>  [4] Driver Writer's Guide:
> http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf
> 
>  The upstream QEMU (commits 5c42eef ~ 70d1fb9) has added support to
>  provide virtual NVDIMM in PMEM mode, in which NVDIMM devices are
>  mapped into CPU's address space and are accessed via normal memory
>  read/write and three special instructions (clflushopt/clwb/pcommit).
> 
>  This patch series and the corresponding QEMU patch series enable Xen
>  to provide vNVDIMM devices to HVM domains.
> 
> * Design
> 
>  Supporting vNVDIMM in PMEM mode has three requirements.
> 

Although this design is about vNVDIMM, some background of how pNVDIMM
is managed in Xen would be helpful to understand the whole design since
in PMEM mode you need map pNVDIMM into GFN addr space so there's
a matter of how pNVDIMM is allocated.

Thanks
Kevin

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. 
vs. 65543
 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail 
REGR. vs. 65543

version targeted for testing:
 ovmf c3bcc1083ef0d7d3eb48620b5381d59276e167ad
baseline version:
 ovmf 5ac96e3a28dd26eabee421919f67fa7c443a47f1

Last test of basis65543  2015-12-08 08:45:15 Z   42 days
Failing since 65593  2015-12-08 23:44:51 Z   42 days   42 attempts
Testing same since78537  2016-01-19 15:53:14 Z0 days1 attempts


People who touched revisions under test:
  "Samer El-Haj-Mahmoud" 
  "Yao, Jiewen" 
  Andrew Fish 
  Ard Biesheuvel 
  Cecil Sheng 
  Chao Zhang 
  Dandan Bi 
  Daocheng Bu 
  Daryl McDaniel 
  Eric Dong 
  Eric Dong 
  Eugene Cohen 
  Feng Tian 
  Fu Siyuan 
  Hao Wu 
  Hess Chen 
  Heyi Guo 
  Jaben Carsey 
  Jeff Fan 
  Jiaxin Wu 
  Jim Dailey 
  Jordan Justen 
  Larry Hauch 
  Laszlo Ersek 
  Leekha Shaveta 
  Liming Gao 
  Mark Rutland 
  Michael Kinney 
  Michael Thomas 
  Paulo Alcantara 
  Qin Long 
  Qiu Shumin 
  Ruiyu Ni 
  Samer El-Haj-Mahmoud 
  Samer El-Haj-Mahmoud 
  Star Zeng 
  Tapan Shah 
  Yao Jiewen 
  Yao, Jiewen 
  Ye Ting 
  Yonghong Zhu 
  Zhang Lubo 

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
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  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
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


Not pushing.

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

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

[Xen-devel] [linux-linus test] 78487: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail REGR. vs. 59254
 test-armhf-armhf-xl-cubietruck  6 xen-bootfail REGR. vs. 59254
 test-armhf-armhf-xl   6 xen-boot  fail REGR. vs. 59254
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 59254
 test-amd64-i386-rumpuserxen-i386 10 guest-start   fail REGR. vs. 59254
 test-armhf-armhf-xl-xsm   6 xen-boot  fail REGR. vs. 59254
 test-armhf-armhf-xl-credit2   6 xen-boot  fail REGR. vs. 59254

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-vhd  9 debian-di-install   fail baseline untested
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 59254
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 59254
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 59254
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 59254

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-amd64-i386-libvirt-xsm  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-amd64-amd64-libvirt-xsm 12 migrate-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-amd64-i386-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-qemuu-nested-intel 13 xen-boot/l1 fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 13 xen-boot/l1   fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail 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-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass

version targeted for testing:
 linuxa200dcb34693084e56496960d855afdeaaf9578f
baseline version:
 linux45820c294fe1b1a9df495d57f40585ef2d069a39

Last test of basis59254  2015-07-09 04:20:48 Z  195 days
Failing since 59348  2015-07-10 04:24:05 Z  194 days  128 attempts
Testing same since78487  2016-01-19 04:22:03 Z1 days1 attempts


3880 people touched revisions under test,
not listing them all

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
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass