[Xen-devel] [qemu-mainline baseline-only test] 66974: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66974 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66974/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw 10 guest-start   fail REGR. vs. 66966

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66966
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 66966

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

version targeted for testing:
 qemuu28b874429ba16e71e0caa46453f3a3e31efb3c51
baseline version:
 qemuu2bb15bddf2607110820d5ce5aa43baac27292fb3

Last test of basis66966  2016-08-11 01:50:59 Z2 days
Testing same since66974  2016-08-12 09:50:38 Z0 days1 attempts


People who touched revisions under test:
  Amit Shah 
  Cao jin 
  Cornelia Huck 
  Cédric Le Goater 
  Daniel P. Berrange 
  David Gibson 
  Denis V. Lunev 
  Evgeny Yakovlev 
  Gonglei 
  Ilya Maximets 
  Kevin Wolf 
  Laurent Vivier 
  Liang Li 
  Marc-André Lureau 
  Michael S. Tsirkin 
  Paolo Bonzini 
  Peter Maydell 
  Pranith Kumar 
  Prerna Saxena 
  Radim Krčmář 
  Stefan Hajnoczi 
  Thomas Huth 

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 

Re: [Xen-devel] Unable to add disk on ARM64

[Peng Fan]

Hi Julien, Roger

On Fri, Aug 12, 2016 at 04:57:06PM +0200, Roger Pau Monné wrote:
>On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote:
>> On 12/08/2016 14:24, Peng Fan wrote:
>> > Hi,
>> 
>> Hello Peng,
>> 
>> I have CCed Roger who is more familiar than me with the hotplug scripts.
>> 
>> > I am using xen master branch on i.MX8 ARM64.
>> > 
>> > My xl configuration:
>> > 
>> > kernel = "/root/xen/Image"
>> > memory = "128"
>> > name = "DomU"
>> > vcpus = 1
>> > serial="pty"
>> > disk = [ 'phy:/dev/loop0,xvda,w' ]
>> > extra = "console=hvc0 root=/dev/xvda debug=/bin/sh"
>> > 
>> > 
>> > And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux.
>> > 
>> > But I met the following error:
>> > libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to 
>> > execute: /etc/xen/scripts/block add ^M^M
>> > Device /dev/loop0 is mounted in the privileged domain,^M^M
>> > and so cannot be mounted by a guest.^M^M
>> > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
>> > /etc/xen/scripts/block add [800] exited with error status 1^M^M
>> > libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch 
>> > w=0xfee100: deregister unregistered^M^M
>> > libxl: error: libxl_devi
>> > ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is 
>> > mounted in the privileged domain,^M^M
>> > and so cannot be mounted by a guest.^M^M
>> 
>> From my understanding, you have mounted /dev/loop0 in Dom0, is that correct?
>> However, we don't support sharing the same mounting point by default (Roger
>> can you confirm).

No I only do "losetup /dev/loop0 DomU-rootfs". And I not mount it.

>
>It seems like the hotplug script has detected that you have the device 
>already attached to Dom0, can you paste the output of `xenstore-ls -fp` 
>when this happens?

I add xenstore-ls -fp in /etc/xen/scripts/block.
"
test -b "$dev" || fatal "$dev is not a block device."

xenstore-ls -fp  ---> Here
claim_lock "block"
check_device_sharing "$dev" "$mode" ---> seems fail in this function
"

I use busybox, not sure whether it supports the xen scripts well or not.
such as "losetup -a" is not supported by busybox.

Log:

device_hotplug: calling hotplug script: /etc/xen/scripts/block add
libxl: debug: libxl_device.c:1135:device_hotplug: extra args:
libxl: debug: libxl_device.c:1143:device_hotplug: env:
libxl: debug: libxl_device.c:1150:device_hotplug:   script: 
/etc/xen/scripts/block
libxl: debug: libxl_device.c:1150:device_hotplug:   XENBUS_TYPE: vbd
libxl: debug: libxl_device.c:1150:device_hotplug:   XENBUS_PATH: 
backend/vbd/1/51712
libxl: debug: libxl_device.c:1150:device_hotplug:   XENBUS_BASE_PATH: 
backend
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: 
/etc/xen/scripts/block add 
/tool = ""   (n0)
/tool/xenstored = ""   (n0)
/local = ""   (n0)
/local/domain = ""   (n0)
/local/domain/0 = ""   (n0)
/local/domain/0/domid = "0"   (n0)
/local/domain/0/name = "Domain-0"   (n0)
/local/domain/0/backend = ""   (n0)
/local/domain/0/backend/vbd = ""   (n0)
/local/domain/0/backend/vbd/1 = ""   (n0)
/local/domain/0/backend/vbd/1/51712 = ""   (n0,r1)
/local/domain/0/backend/vbd/1/51712/frontend = 
"/local/domain/1/device/vbd/51712"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/params = "/dev/loop0"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/script = "/etc/xen/scripts/block"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/frontend-id = "1"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/online = "1"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/removable = "0"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/bootable = "1"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/state = "2"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/dev = "xvda"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/type = "phy"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/mode = "w"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/device-type = "disk"   (n0,r1)
/local/domain/0/backend/vbd/1/51712/discard-enable = "1"   (n0,r1)
/local/domain/1 = ""   (n0,r1)
/local/domain/1/vm = "/vm
/63997893-f587-4bdc-9bf3-dd5c7614bb51"   (n0,r1)
/local/domain/1/name = "DomU"   (n0,r1)
/local/domain/1/cpu = ""   (n0,r1)
/local/domain/1/cpu/0 = ""   (n0,r1)
/local/domain/1/cpu/0/availability = "online"   (n0,r1)
/local/domain/1/memory = ""   (n0,r1)
/local/domain/1/memory/static-max = "131072"   (n0,r1)
/local/domain/1/memory/target = "131072"   (n0,r1)
/local/domain/1/memory/videoram = "0"   (n0,r1)
/local/domain/1/device = ""   (n0,r1)
/local/domain/1/device/suspend = ""   (n0,r1)
/local/domain/1/device/suspend/event-channel = ""   (n1)
/local/domain/1/device/vbd = ""   (n0,r1)
/local/domain/1/device/vbd/51712 = ""   (n1,r0)
/local/domain/1/device/vbd/51712/backend = 
"/local/domain/0/backend/vbd/1/51712"   (n1,r0)
/local/domain/1/device/vbd/51712/backend-id = "0"   (n1,r0)
/local/domain/1/device/vbd/51712/state = "1"   (n1,r0)

[Xen-devel] [PULL 1/2] Xen: fix converity warning of xen_pt_config_init()

[Stefano Stabellini]

From: Cao jin 

emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect.
Since the remaining message is enough for debugging, so just remove it.
Also tweaked the message a little.

Signed-off-by: Cao jin 
Signed-off-by: Stefano Stabellini 
Acked-by: Stefano Stabellini 
---
 hw/xen/xen_pt_config_init.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 9869ffd..6f18366 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -2049,9 +2049,8 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error 
**errp)
 for (j = 0; regs->size != 0; j++, regs++) {
 xen_pt_config_reg_init(s, reg_grp_entry, regs, );
 if (err) {
-error_append_hint(, "Failed to initialize %d/%zu"
-" reg 0x%x in grp_type = 0x%x (%d/%zu)",
-j, ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
+error_append_hint(, "Failed to init register %d"
+" offsets 0x%x in grp_type = 0x%x (%d/%zu)", j,
 regs->offset, xen_pt_emu_reg_grps[i].grp_type,
 i, ARRAY_SIZE(xen_pt_emu_reg_grps));
 error_propagate(errp, err);
-- 
1.9.1


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

[Xen-devel] [PULL 2/2] xen: handle inbound migration of VMs without ioreq server pages

[Stefano Stabellini]

From: Paul Durrant 

VMs created on older versions on Xen will not have been provisioned with
pages to support creation of non-default ioreq servers. In this case
the ioreq server API is not supported and QEMU's only option is to fall
back to using the default ioreq server pages as it did prior to
commit 3996e85c ("Xen: Use the ioreq-server API when available").

This patch therefore changes the code in xen_common.h to stop considering
a failure of xc_hvm_create_ioreq_server() as a hard failure but simply
as an indication that the guest is too old to support the ioreq server
API. Instead a boolean is set to cause reversion to old behaviour such
that the default ioreq server is then used.

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Acked-by: Anthony PERARD 
Acked-by: Stefano Stabellini 
---
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 3 files changed, 92 insertions(+), 40 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 640c31e..bd39287 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -107,6 +107,44 @@ static inline int xen_get_vmport_regs_pfn(xc_interface 
*xc, domid_t dom,
 
 #endif
 
+static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
+domid_t dom,
+xen_pfn_t *ioreq_pfn,
+xen_pfn_t *bufioreq_pfn,
+evtchn_port_t
+*bufioreq_evtchn)
+{
+unsigned long param;
+int rc;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
+return -1;
+}
+
+*ioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
+return -1;
+}
+
+*bufioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
+  );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+return -1;
+}
+
+*bufioreq_evtchn = param;
+
+return 0;
+}
+
 /* Xen before 4.5 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450
 
@@ -154,10 +192,9 @@ static inline void xen_unmap_pcidev(xc_interface *xc, 
domid_t dom,
 {
 }
 
-static inline int xen_create_ioreq_server(xc_interface *xc, domid_t dom,
-  ioservid_t *ioservid)
+static inline void xen_create_ioreq_server(xc_interface *xc, domid_t dom,
+   ioservid_t *ioservid)
 {
-return 0;
 }
 
 static inline void xen_destroy_ioreq_server(xc_interface *xc, domid_t dom,
@@ -171,35 +208,8 @@ static inline int xen_get_ioreq_server_info(xc_interface 
*xc, domid_t dom,
 xen_pfn_t *bufioreq_pfn,
 evtchn_port_t *bufioreq_evtchn)
 {
-unsigned long param;
-int rc;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
-return -1;
-}
-
-*ioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
-return -1;
-}
-
-*bufioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
-  );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
-return -1;
-}
-
-*bufioreq_evtchn = param;
-
-return 0;
+return xen_get_default_ioreq_server_info(xc, dom, ioreq_pfn, bufioreq_pfn,
+ bufioreq_evtchn);
 }
 
 static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom,
@@ -212,6 +222,8 @@ static inline int xen_set_ioreq_server_state(xc_interface 
*xc, domid_t dom,
 /* Xen 4.5 */
 #else
 
+static bool use_default_ioreq_server;
+
 static inline void xen_map_memory_section(xc_interface *xc, domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
@@ -220,6 +232,10 @@ static inline void xen_map_memory_section(xc_interface 
*xc, domid_t dom,
 ram_addr_t size = int128_get64(section->size);
 hwaddr end_addr = start_addr + size - 1;
 
+if (use_default_ioreq_server) {
+return;
+}
+
 trace_xen_map_mmio_range(ioservid, start_addr, 

[Xen-devel] [PULL 0/2] xen-20160812-tag-2

[Stefano Stabellini]

The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51:

  Merge remote-tracking branch 
'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 
17:53:35 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag-2

for you to fetch changes up to b7665c6027c972c23668ee74b878b5c617218514:

  xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
16:38:30 -0700)


Xen 2016/08/12, fixed commit message


Cao jin (1):
  Xen: fix converity warning of xen_pt_config_init()

Paul Durrant (1):
  xen: handle inbound migration of VMs without ioreq server pages

 hw/xen/xen_pt_config_init.c |   5 +-
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 4 files changed, 94 insertions(+), 43 deletions(-)

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

Re: [Xen-devel] [PULL 0/2] xen-20160812-tag

[Stefano Stabellini]

Sorry, please disregard this pull request, I forgot to add my acked-by to
one of the commits. I'll resend shortly.

On Fri, 12 Aug 2016, Stefano Stabellini wrote:
> The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51:
> 
>   Merge remote-tracking branch 
> 'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 
> 17:53:35 +0100)
> 
> are available in the git repository at:
> 
> 
>   git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag
> 
> for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9:
> 
>   xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
> 15:16:15 -0700)
> 
> 
> Xen 2016/08/12
> 
> 
> Cao jin (1):
>   Xen: fix converity warning of xen_pt_config_init()
> 
> Paul Durrant (1):
>   xen: handle inbound migration of VMs without ioreq server pages
> 
>  hw/xen/xen_pt_config_init.c |   5 +-
>  include/hw/xen/xen_common.h | 125 
> +++-
>  trace-events|   1 +
>  xen-hvm.c   |   6 +--
>  4 files changed, 94 insertions(+), 43 deletions(-)
> 

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

[Xen-devel] [PULL 0/2] xen-20160812-tag

[Stefano Stabellini]

The following changes since commit 28b874429ba16e71e0caa46453f3a3e31efb3c51:

  Merge remote-tracking branch 
'remotes/amit-migration/tags/migration-for-2.7-7' into staging (2016-08-11 
17:53:35 +0100)

are available in the git repository at:


  git://xenbits.xen.org/people/sstabellini/qemu-dm.git tags/xen-20160812-tag

for you to fetch changes up to f7ca8a4fdcb478fdb0503c2d39b0b85160c913d9:

  xen: handle inbound migration of VMs without ioreq server pages (2016-08-12 
15:16:15 -0700)


Xen 2016/08/12


Cao jin (1):
  Xen: fix converity warning of xen_pt_config_init()

Paul Durrant (1):
  xen: handle inbound migration of VMs without ioreq server pages

 hw/xen/xen_pt_config_init.c |   5 +-
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 4 files changed, 94 insertions(+), 43 deletions(-)

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

[Xen-devel] [PULL 1/2] Xen: fix converity warning of xen_pt_config_init()

[Stefano Stabellini]

From: Cao jin 

emu_regs is a pointer, ARRAY_SIZE doesn't return what we expect.
Since the remaining message is enough for debugging, so just remove it.
Also tweaked the message a little.

Signed-off-by: Cao jin 
---
 hw/xen/xen_pt_config_init.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/xen/xen_pt_config_init.c b/hw/xen/xen_pt_config_init.c
index 9869ffd..6f18366 100644
--- a/hw/xen/xen_pt_config_init.c
+++ b/hw/xen/xen_pt_config_init.c
@@ -2049,9 +2049,8 @@ void xen_pt_config_init(XenPCIPassthroughState *s, Error 
**errp)
 for (j = 0; regs->size != 0; j++, regs++) {
 xen_pt_config_reg_init(s, reg_grp_entry, regs, );
 if (err) {
-error_append_hint(, "Failed to initialize %d/%zu"
-" reg 0x%x in grp_type = 0x%x (%d/%zu)",
-j, ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs),
+error_append_hint(, "Failed to init register %d"
+" offsets 0x%x in grp_type = 0x%x (%d/%zu)", j,
 regs->offset, xen_pt_emu_reg_grps[i].grp_type,
 i, ARRAY_SIZE(xen_pt_emu_reg_grps));
 error_propagate(errp, err);
-- 
1.9.1


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

[Xen-devel] [PULL 2/2] xen: handle inbound migration of VMs without ioreq server pages

[Stefano Stabellini]

From: Paul Durrant 

VMs created on older versions on Xen will not have been provisioned with
pages to support creation of non-default ioreq servers. In this case
the ioreq server API is not supported and QEMU's only option is to fall
back to using the default ioreq server pages as it did prior to
commit 3996e85c ("Xen: Use the ioreq-server API when available").

This patch therefore changes the code in xen_common.h to stop considering
a failure of xc_hvm_create_ioreq_server() as a hard failure but simply
as an indication that the guest is too old to support the ioreq server
API. Instead a boolean is set to cause reversion to old behaviour such
that the default ioreq server is then used.

Signed-off-by: Paul Durrant 
Signed-off-by: Stefano Stabellini 
Acked-by: Anthony PERARD 
Acked-by: Stefano Stabellini 
---
 include/hw/xen/xen_common.h | 125 +++-
 trace-events|   1 +
 xen-hvm.c   |   6 +--
 3 files changed, 92 insertions(+), 40 deletions(-)

diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 640c31e..bd39287 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -107,6 +107,44 @@ static inline int xen_get_vmport_regs_pfn(xc_interface 
*xc, domid_t dom,
 
 #endif
 
+static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
+domid_t dom,
+xen_pfn_t *ioreq_pfn,
+xen_pfn_t *bufioreq_pfn,
+evtchn_port_t
+*bufioreq_evtchn)
+{
+unsigned long param;
+int rc;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
+return -1;
+}
+
+*ioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
+return -1;
+}
+
+*bufioreq_pfn = param;
+
+rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
+  );
+if (rc < 0) {
+fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
+return -1;
+}
+
+*bufioreq_evtchn = param;
+
+return 0;
+}
+
 /* Xen before 4.5 */
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 450
 
@@ -154,10 +192,9 @@ static inline void xen_unmap_pcidev(xc_interface *xc, 
domid_t dom,
 {
 }
 
-static inline int xen_create_ioreq_server(xc_interface *xc, domid_t dom,
-  ioservid_t *ioservid)
+static inline void xen_create_ioreq_server(xc_interface *xc, domid_t dom,
+   ioservid_t *ioservid)
 {
-return 0;
 }
 
 static inline void xen_destroy_ioreq_server(xc_interface *xc, domid_t dom,
@@ -171,35 +208,8 @@ static inline int xen_get_ioreq_server_info(xc_interface 
*xc, domid_t dom,
 xen_pfn_t *bufioreq_pfn,
 evtchn_port_t *bufioreq_evtchn)
 {
-unsigned long param;
-int rc;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_IOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_IOREQ_PFN\n");
-return -1;
-}
-
-*ioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_PFN, );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_PFN\n");
-return -1;
-}
-
-*bufioreq_pfn = param;
-
-rc = xc_get_hvm_param(xc, dom, HVM_PARAM_BUFIOREQ_EVTCHN,
-  );
-if (rc < 0) {
-fprintf(stderr, "failed to get HVM_PARAM_BUFIOREQ_EVTCHN\n");
-return -1;
-}
-
-*bufioreq_evtchn = param;
-
-return 0;
+return xen_get_default_ioreq_server_info(xc, dom, ioreq_pfn, bufioreq_pfn,
+ bufioreq_evtchn);
 }
 
 static inline int xen_set_ioreq_server_state(xc_interface *xc, domid_t dom,
@@ -212,6 +222,8 @@ static inline int xen_set_ioreq_server_state(xc_interface 
*xc, domid_t dom,
 /* Xen 4.5 */
 #else
 
+static bool use_default_ioreq_server;
+
 static inline void xen_map_memory_section(xc_interface *xc, domid_t dom,
   ioservid_t ioservid,
   MemoryRegionSection *section)
@@ -220,6 +232,10 @@ static inline void xen_map_memory_section(xc_interface 
*xc, domid_t dom,
 ram_addr_t size = int128_get64(section->size);
 hwaddr end_addr = start_addr + size - 1;
 
+if (use_default_ioreq_server) {
+return;
+}
+
 trace_xen_map_mmio_range(ioservid, start_addr, 

[Xen-devel] [xen-unstable test] 100466: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt-raw  7 host-ping-check-xen  fail REGR. vs. 100431
 test-amd64-amd64-xl-qemuu-ovmf-amd64 14 guest-saverestore.2 fail REGR. vs. 
100431

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   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-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  20aa9381db781ee050355635efd14a9a37e1d94d
baseline version:
 xen  072e6709978143145a1c1b98c7f014dc4d87907f

Last test of basis   100431  2016-08-12 07:34:23 Z0 days
Testing same since   100466  2016-08-12 15:15:07 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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-oldkern  pass
 

Re: [Xen-devel] [PATCH] xen: handle inbound migration of VMs without ioreq server pages

[Stefano Stabellini]

On Fri, 12 Aug 2016, Paul Durrant wrote:
> > -Original Message-
> > From: Stefano Stabellini [mailto:sstabell...@kernel.org]
> > Sent: 11 August 2016 21:07
> > To: Paul Durrant
> > Cc: Anthony Perard; xen-de...@lists.xenproject.org; qemu-
> > de...@nongnu.org; Stefano Stabellini
> > Subject: RE: [PATCH] xen: handle inbound migration of VMs without ioreq
> > server pages
> > 
> > On Tue, 9 Aug 2016, Paul Durrant wrote:
> > > > -Original Message-
> > > > From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> > > > Sent: 09 August 2016 16:19
> > > > To: Paul Durrant
> > > > Cc: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org; Stefano
> > > > Stabellini
> > > > Subject: Re: [PATCH] xen: handle inbound migration of VMs without
> > ioreq
> > > > server pages
> > > >
> > > > On Mon, Aug 01, 2016 at 10:16:25AM +0100, Paul Durrant wrote:
> > > > > VMs created on older versions on Xen will not have been provisioned
> > with
> > > > > pages to support creation of non-default ioreq servers. In this case
> > > > > the ioreq server API is not supported and QEMU's only option is to 
> > > > > fall
> > > > > back to using the default ioreq server pages as it did prior to
> > > > > commit 3996e85c ("Xen: Use the ioreq-server API when available").
> > > > >
> > > > > This patch therefore changes the code in xen_common.h to stop
> > > > considering
> > > > > a failure of xc_hvm_create_ioreq_server() as a hard failure but simply
> > > > > as an indication that the guest is too old to support the ioreq server
> > > > > API. Instead a boolean is set to cause reversion to old behaviour such
> > > > > that the default ioreq server is then used.
> > > > >
> > > > > Signed-off-by: Paul Durrant 
> > > > > Cc: Stefano Stabellini 
> > > > > Cc: Anthony Perard 
> > > >
> > > > There are just two lines too long:
> > > >
> > > > WARNING: line over 80 characters
> > > > #31: FILE: include/hw/xen/xen_common.h:110:
> > > > +static inline int xen_get_default_ioreq_server_info(xc_interface *xc,
> > > > domid_t dom,
> > > >
> > > > WARNING: line over 80 characters
> > > > #34: FILE: include/hw/xen/xen_common.h:113:
> > > > +evtchn_port_t 
> > > > *bufioreq_evtchn)
> > > >
> > > > With that fixed: Acked-by: Anthony PERARD
> > 
> > > >
> > > > Thanks,
> > > >
> > >
> > > Ok, I'll post v2 with those fixes and your ack. Thanks,
> > 
> > Thank you for fixing this bug and Thanks Anthony for the review.
> > 
> > I was about to commit it but my sense of style rebelled: I really don't
> > like all the if statements. Too many! Sorry for coming in so late in
> > commenting on a patch, I realize that it is unfair.
> > 
> > Would you be up for rewriting the fix so that instead of introducing
> > 
> > if (use_default_ioreq_server) {
> > return;
> > }
> > 
> > in many functions, we turn xc_hvm_* calls into function pointers calls
> > that get set to the right behavior depending on the success of
> > xc_hvm_create_ioreq_server?
> > 
> > 
> > The call sites would be something like:
> > 
> > ioreq_server->unmap_io_range_from_ioreq_server(xc, dom, ioservid, 0,
> > start_addr, end_addr);
> > 
> > At boot time, if xc_hvm_create_ioreq_server returns error:
> > 
> > ioreq_server = empty_stubs_functions;
> > 
> > else
> > 
> > ioreq_server = useful_functions;
> > 
> > 
> > What do you guys think?
> 
> Personally I don't think it's worth it. This is not a performance critical 
> codepath but if you insist I will re-factor the code.

All right, given that Anthony already acked it, it's two vs. one. I'll
commit it as is.

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

Re: [Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Stefano Stabellini]

On Fri, 12 Aug 2016, Lars Kurth wrote:
> COPYING file:
> The motivation of this change is to make it easier for new
> contributors to conduct a license and patent review, WITHOUT
> changing any licenses.
> - Remove references to BSD-style licenses as we have more
>   common license exceptions and replace with "other license
>   stanzas"
> - List the most common situations under which code is licensed
>   under licenses other than GPLv2 (section "Licensing Exceptions")
> - List the most common non-GPLv2 licenses that are in use in
>   this repository based on a recent FOSSology scan (section
>   "Licensing Exceptions")
> - List other license related conventions within the project
>   to make it easier to conduct a license review.
> - Clarify the incoming license as its omission has confused
>   past contributors (section "Contributions")
> 
> CONTRIBUTION file:
> The motivation of this file is to make it easier for contributors
> to find contribution related resources. Add information on existing
> license related conventions to avoid unintentional future licensing
> issues. Provide templates for copyright headers for the most commonly
> used licenses in this repository.
> 
> Signed-off-by: Lars Kurth 

Acked-by: Stefano Stabellini 


> Changed since v1:
>   * Fixed typos
>   * Used GPL / LGPL license header spelling out version instead of v
>   
> ---
>  CONTRIBUTING | 210 
> +++
>  COPYING  |  64 ++
>  2 files changed, 260 insertions(+), 14 deletions(-)
>  create mode 100644 CONTRIBUTING
> 
> diff --git a/CONTRIBUTING b/CONTRIBUTING
> new file mode 100644
> index 000..67ecdb7
> --- /dev/null
> +++ b/CONTRIBUTING
> @@ -0,0 +1,210 @@
> +
> +CONTRIBUTING
> +
> +
> +INBOUND LICENSE
> +---
> +
> +Contributions are governed by the license that applies to relevant 
> +specific file or by the license specified in the COPYING file, that
> +governs the license of its containing directory and its subdirectories.
> +
> +Most of the Xen Project code is licensed under GPLv2, but a number of 
> +directories are primarily licensed under different licenses. 
> +
> +Most notably:
> + - tools/blktap2  : BSD-Modified
> + - tools/libxc: LGPL v2.1
> + - tools/libxl: LGPL v2.1
> + - xen/include/public : MIT license
> +
> +When creating new components and directories that contain a 
> +significant amount of files that are licensed under licenses other 
> +than GPLv2 or the license specified in the COPYING file, please 
> +create a new COPYING file in that directory containing a copy of the 
> +license text and a rationale for using a different license. This helps 
> +ensure that the license of this new component/directory is maintained 
> +consistently with the original intention.
> +
> +When importing code from other upstream projects into this repository, 
> +please create a README.source file in the directory the code is imported 
> +to, listing the original source of the code. An example can be found at 
> +m4/README.source
> +
> +The COMMON COPYRIGHT NOTICES section of this document contains 
> +sample copyright notices for the most common licenses used within 
> +this repository.
> +
> +Developer's Certificate of Origin
> +-
> +
> +All patches to the Xen Project code base must include the line 
> +"Signed-off-by: your_name " at the end of the change 
> +description. This is required and indicates that you certify the patch 
> +under the "Developer's Certificate of Origin" which states:
> +
> +  Developer's Certificate of Origin 1.1
> +
> +  By making a contribution to this project, I certify that:
> +
> +  (a) The contribution was created in whole or in part by me and I
> +  have the right to submit it under the open source license
> +  indicated in the file; or
> +
> +  (b) The contribution is based upon previous work that, to the best
> +  of my knowledge, is covered under an appropriate open source
> +  license and I have the right under that license to submit that
> +  work with modifications, whether created in whole or in part
> +  by me, under the same open source license (unless I am
> +  permitted to submit under a different license), as indicated
> +  in the file; or
> +
> +  (c) The contribution was provided directly to me by some other
> +  person who certified (a), (b) or (c) and I have not modified
> +  it.
> +
> +  (d) I understand and agree that this project and the contribution
> +  are public and that a record of the contribution (including all
> +  personal information I submit with it, including my sign-off) is
> +  maintained indefinitely and may be redistributed consistent with
> +  this project or the open source license(s) involved.
> +
> +GOVERNANCE AND WORKFLOW
> +---
> +
> +The following documents provide a general 

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Luis R. Rodriguez]

On Fri, Aug 12, 2016 at 10:23:34PM +0200, Greg KH wrote:
> On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> > Alright, how's this new description:
> > 
> > diff --git a/init/Kconfig b/init/Kconfig
> > index cac3f096050d..73e4890c24c4 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -53,6 +53,34 @@ config CROSS_COMPILE
> >   need to set this unless you want the configured kernel build
> >   directory to select the cross-compiler automatically.
> >  
> > +config BUILD_AVOID_BITROT
> > +   bool "Always force building specially annotated targets"
> > +   default n
> > +   help
> > + If enabled then the the special table-* Makefile targets will always
> > + be forced to be compiled even if their respective CONFIG_ option has
> > + been disabled, but its objects will only be linked in if the same
> > + respective CONFIG_ option has been enabled. This helps avoid code
> > + bit rot issues, use for these targets should be carefully considred
> > + by maintainers. You can safely enable this option at the expense of
> > + increasing compile time. Enabling this option helps avoid code bit
> > + rot by taking advantage of the facilities provided and enabled by
> > + using linker tables documented under:
> 
> As a kernel developer I have _no_ idea what this is trying to say at
> all, sorry.

Hmm, wow OK, sorry, and I thought I was being too verbose...

OK so first, linker tables allow for the ability to help simplify initialization
sequences so that you no longer have to add the respective static inline in
header files to do nothing, instead you simply get your init routine for your
feature pegged into the linker table or not at link time. If enabling your
feature does not require structural changes, you could then safely enable
compiling this feature all the time, and only allow linking when the feature
was enabled. We don't have an easy way to express this in our build system,
the new targets added lets you accomplish this.

> What is a "specially annotated target"?

The ones listed below, table-obj-y and table-lib-y

> Who is forcing it to be built?

It would be up to maintainers for each subsystem/feature to decide if they want
to use the new targets or not within their subsystem.

> What does it mean if it isn't built?

If you have CONFIG_BUILD_AVOID_BITROT enabled and some code using the special
targets do not get built it means the dependencies it has were not met.

> > +
> > + include/linux/tables.h
> > +
> > + The special targets supported are:
> > +
> > +   o table-obj-y
> > +   o table-lib-y
> 
> What does this mean to me as a developer?

It mean you can count on a bit more build test coverage by
CONFIG_BUILD_AVOID_BITROT users. Using table-obj-y is functionally
equivalent to doing:

extra-y += foo.o
obj-y += foo.o

The above new targets are just short hand annotations for the same.  We could
actually use another shorthand prefix other than table-, however linker tables
help making more of these type of targets possible. For instance, on 
initialiation
sequences you no longer have to add each line for each feature onto a set 
routine,
rather you just get the initialization routine linked in or not. This lets us 
avoid
cluttering C code and header code with #idefs, and as a side consequences also
allows more targets to be compiled without implicating functionality.

As a developer you should take care to to use table-obj-y, or table-lib-y only 
if
you are certain the target does not require structural changes.

> What does it mean to a user
> who wants to figure out if it should be enabled or not?

It depends on their build system capability and their goals. If they wish
to be able to report build bugs and have a decent build system they can
enable this. Otherwise they should disable it.

> > + Say Y if you have a decent build machine and would like to help test
> > + building code for more subsystems. Say N if you do you not have a
> > + good build machine or only want to compile what you've enabled for
> > + your kernel.
> 
> How does this test different subsystems?

By enabling this feature you compile kconfig symbols that typically are
disabled by most users and which have been identified by maintainers as
needing more build testing love. The extra kconfig symbols built are
only built if the dependencies for them are met.

Maintainers for subsystems would have to identify if they have key pieces of
software that typically get disabled, and that enabling them would not incur or
require structural changes, which can use more build test love.

> How does disabling it not test them?

By disabling this feature you only compile kconfig symbols you have
enabled for your kernel.

> Why would I care either way?

You would care if you aware of certain kconfig symbols that do not
get much build test love.

> > +
> > + Enabling this option never increases the size of your kernel.
> 
> Then what does it do?  

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Stefano Stabellini]

On Fri, 12 Aug 2016, Jan Beulich wrote:
> > +Let me express this as an algorithm.
> > +
> > +  treshhold=2/3;
> > +  active='number of active members'; (7 for the Hypervisor project; 
> > IanC is inactive)
> > +  favour='number of +1 and +2 votes' 
> > +  against='number of -1 and -2 votes'
> > +  strong-against='number -2 votes'; just added this as a sanity check
> > +
> > +One open question is what to do with 0-votes. We could introduce a 
> > rule discounting 
> > +0 votes (let's call it 0-rule). If someone votes 0, we assume they 
> > really don't care
> > +about the outcome and are considered inactive for the purpose of the 
> > vote. 
> > +
> > +In that case:
> > +
> > +  active -= 0-votes;
> > +
> > +Without the 0-rule: 
> > +- to pass: favour/active >= treshhold 
> > +  to pass: with active==7, favour >= 5
> > +  in other words, 3 (0,-1,-2)-votes block the proposal as we cant 
> > achieve favour>=5
> > +
> > +With the 0-rule, let's consider 1, 2 or 3 0-votes
> > +1=>6: to pass: favour >=4
> > +  in other words, 3 (-1,-2)-votes block the proposal
> > +2=>5: to pass: favour >=4
> > +  in other words, 2 (-1,-2)-vote blocks the proposal
> > +3=>4: to pass: favour >=3
> > +  in other words, 2 (-1,-2)-vote blocks the proposal
> > +
> > +Looking at the arithmetic, it does probably make sense to go for the 
> > 0-rule. If we
> > +do, there ought to be more votes in favour of a proposal, than 0-votes.
> > +
> > +On the other hand, not having the 0-rule forces everyone to form an 
> > opinion, 
> > +otherise we will find it hard to make decisions. But in some cases, 
> > forming an
> > +opinion costs significant mental capacity.
> > +
> > +It would also allow us to remove the complexity of differentiating 
> > between
> > +active and non-active leadership team members by assuming that no 
> > vote, equals
> > +a "0" vote. 
> > +
> > +Opinions?
> 
> I'm in favor of the "with 0-rule" variant.

I am also in favor of the 0-rule

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

[Xen-devel] [distros-debian-jessie test] 66973: tolerable all pass

[Platform Team regression test user]

flight 66973 distros-debian-jessie real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66973/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 saverestore-support-check fail 
never pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub 11 migrate-support-check fail 
never pass

baseline version:
 flight   66922

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-jessie-netboot-pvgrub pass
 test-amd64-i386-i386-jessie-netboot-pvgrub   pass
 test-amd64-i386-amd64-jessie-netboot-pygrub  pass
 test-armhf-armhf-armhf-jessie-netboot-pygrub pass
 test-amd64-amd64-i386-jessie-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

[Xen-devel] [seabios baseline-only test] 66971: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66971 seabios real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66971/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66956
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66956
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66956

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass

version targeted for testing:
 seabios  19e8ea6312f3f60c34c2c20f95fb81306b320f74
baseline version:
 seabios  8bc6d9f8e9bd1c211660f9ec91c237821d7f4089

Last test of basis66956  2016-08-09 19:20:46 Z3 days
Testing same since66971  2016-08-11 20:26:15 Z1 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Stefan Berger 

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-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-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  fail
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


commit 19e8ea6312f3f60c34c2c20f95fb81306b320f74
Author: Kevin O'Connor 
Date:   Tue Aug 9 13:24:51 2016 -0400

tpm: Append to TPM2 log the hashes used for PCR extension

Modify the function that writes the TPM logs to take the same digest
passed to tpm_extend.  Update the tpm2 acpi log header to describe the
digest format.

Signed-off-by: Stefan Berger 
Signed-off-by: Kevin O'Connor 

commit a99de5c35df0419ed630437c31031e145351dbc8
Author: Stefan Berger 
Date:   Fri Aug 5 11:07:11 2016 -0400

tpm: Extend tpm20_extend to support extending to multiple PCR banks

Extend the tpm20_extend function to support extending a hash to
multiple PCR banks. The sha1 hash that's being extended into the
sha256 bank for example, will be filled with zero-bytes to the
size of a sha256 hash.

Signed-off-by: Stefan Berger 
Signed-off-by: Kevin O'Connor 

commit 3b97efad61e39cf430286b6cb85db64069c0a951
Author: Stefan Berger 
Date:   Fri Aug 5 11:07:10 2016 -0400

tpm: Refactor tpml_digest_values_sha1 structure

Refactor the tpml_digest_values_sha1 structure so we can later cast it
to the more general tpml_digest_values structure. Move the count member
into this structure.

Signed-off-by: Stefan Berger 

commit 0fb23c327d553049500d251ae9376c3e2ce1f2d1
Author: Stefan Berger 
Date:   Fri Aug 5 

Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Stefano Stabellini]

On Fri, 12 Aug 2016, Lars Kurth wrote:
> On 11/08/2016 19:59, "Stefano Stabellini"  wrote:
> 
> >On Thu, 11 Aug 2016, Lars Kurth wrote:
> >> On 11/08/2016 01:51, "Stefano Stabellini" 
> >>wrote:
> >> 
> >> >> +Developer's Certificate of Origin
> >> >> +-
> >> >> +
> >> >> +All patches to the Xen Project code base must include the the line
> >> >  ^ double
> >>"the"
> >> 
> >> Thanks: will fix. And also fixed in the wiki page where I copied this
> >>from.
> >> 
> >> 
> >> >> +GOVERNANCE AND WORKFLOW
> >> >> +---
> >> >> +
> >> >> +The following documents provide a general overview of governance and
> >> >> +contribution guidelines for the Xen Project:
> >> >> + - https://xenproject.org/governance.html
> >> >> + - https://xenproject.org/help/contribution-guidelines.html
> >> >
> >> >It might be worth considering importing the governance as a file in the
> >> >Xen repository.
> >> 
> >> After discussing with a few committers, I think storing this in a git
> >>repo
> >> is a good idea: possibly as markup. It should not be in xen.git though,
> >> but probably in a new governance.git tree, for which I am maintainer.
> >
> >That's a good idea. It would make far easier to review changes to it in
> >the future. I'd suggest markdown, which is actually quite nice to use
> >and has already been used for a few design docs, including pv calls and
> >xsplice.
> 
> See 
> https://lists.xenproject.org/archives/html/xen-devel/2016-08/msg01667.html
> Lars

That was quick! Well done!

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

[Xen-devel] [ovmf baseline-only test] 66972: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66972 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66972/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 926059304e8377fc37bb848d06d9419f419d93ff
baseline version:
 ovmf af90df3cb099ed8e009579b7b55e7142dc0fc410

Last test of basis66965  2016-08-10 21:19:32 Z2 days
Testing same since66972  2016-08-11 23:52:02 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 
  Laszlo Ersek 
  Liming Gao 
  Thomas Huth 

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



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.

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

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

Re: [Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.

[Konrad Rzeszutek Wilk]

On Fri, Aug 12, 2016 at 05:00:47PM +0200, Julien Grall wrote:
> Hi Konrad,
> 
> On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote:
> > The initial support for ARM64 - and livepatching
> > works:
> 
> As it is a very RFC I only gave a quick look. I have few comments on it (see
> below).
> 
> > 
> > (XEN) livepatch: xen_hello_world: Applying 1 functions
> > (XEN) hi_func: Hi! (called 1 times)
> > (XEN) Hook executing.
> > (XEN) livepatch: xen_hello_world finished APPLY with rc=0
> > (XEN) livepatch.c:1687: livepatch: load_payload_fnc: rc=0 (p->rc=0)
> > (XEN) livepatch: Hello World
> > (XEN) 'x' pressed - Dumping all livepatch patches
> > (XEN) build-id: e144bafc4ee8635eee5bed8e3988b484765c46c8
> > (XEN)  name=xen_hello_world state=APPLIED(2) 00318000 
> > (.data=00319000, .rodata=0031a000) using 3 pages.
> > (XEN) xen_extra_version patch 00233fac(12) with 
> > 00318000 (16)
> > (XEN) build-id=c4b842c276be43adbe4db788598b1e11bce04dc6
> > (XEN) depend-on=9affa110481e8e13606c61b21e5f6a357a3c8ef9
> > 
> > ARM32 still has some issues.
> > 
> > The are some TODOs left to be done:
> > 
> > General:
> > - Bubble ALT_ORIG_PTR macro for both x86/ARM.
> > - Unify the ELF RELA checks - they are the same on x86/ARM[32,64].
> > - Makefile generating .livepatch.depends needs to ingest the
> >  -O argument based on architecture
> > - Test cases should move to common/ ? [Needs Jan's Ack]
> 
> In general, I would be in favor of sharing as much as possible the code.
> 
> > ARM32 issues:
> > - vm_init_type: Assertion 'is_xen_heap_mfn(ma >> PAGE_SHIFT)' failed at 
> > xen/include/asm/mm.h:23
> 
> xen/include/asm/mm.h:23 points to the beginning of struct page_info. Did you
> mean to write instead 233?

Probably. 
> 
> This would point to maddr_virt. This would mean someone is trying to get the
> virtual address of MFN that is not in the xenheap (only the xenheap is
> mapped on ARM32). Do you have the full call stack?

No :-( I need to rebuild it and put it on the board. Maybe in a week?

> 
> [...]
> 
> > 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> 
> [...]
> 
> > diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
> > index aba1320..67749ed 100644
> > --- a/xen/arch/arm/livepatch.c
> > +++ b/xen/arch/arm/livepatch.c
> > @@ -6,66 +6,100 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include "livepatch.h"
> > +
> > +#include 
> > +
> > +void *vmap_of_xen_text;
> > 
> >  void arch_livepatch_quiesce(void)
> >  {
> > +mfn_t text_mfn;
> > +unsigned int text_order;
> > +
> > +if ( vmap_of_xen_text )
> > +return;
> > +
> > +text_mfn = _mfn(virt_to_mfn(_stext));
> > +text_order = get_order_from_bytes(_end - _start);
> > +
> > +/*
> > + * The text section is read-only. So re-map Xen to be able to patch
> > + * the code.
> > + */
> > +vmap_of_xen_text = __vmap(_mfn, 1 << text_order, 1, 1, 
> > PAGE_HYPERVISOR,
> > +  VMAP_DEFAULT);
> 
> Shouldn't we return an error if we fail to re-map the region?
> 
> Otherwise the patch may silently be ignored (see arch_livepatch_apply_jmp).

We do actually bail out of patching if vmap_of_xen_text is NULL.
But let me add a return (-ENOMEM) to this so that we don't attempt to do any
patching and print a nice message.
> 
> >  }
> > 
> >  void arch_livepatch_revive(void)
> >  {
> > +/* Nuke the instruction cache */
> > +invalidate_icache();
> 
> I was about to say that this is not enough. But you called
> clean_and_invalidate_* every time you rewrite the jump. It might be worth to
> add a comment here, explain that the cache has been cleaned before hand.
> 
> However, I can't find any data cache flush for the payload. Did I miss
> anything?

No just didn't occur to me - as we patch the .text not the .data.

I will take a look at the existing code and see if I can find out how
to do the data cache flush.
> 
> Lastly, before I forgot, you will need to invalidate the branch predictor
> for ARMv7 as it may be architecturally visible to the software (see B2.2.4
> in ARM DDI 0406C.b).

OK.
> 
> > +
> > +if ( vmap_of_xen_text )
> > +vunmap(vmap_of_xen_text);
> > +
> > +vmap_of_xen_text = NULL;
> >  }
> > 
> >  int arch_livepatch_verify_func(const struct livepatch_func *func)
> >  {
> > -return -ENOSYS;
> > -}
> > +/* No NOP patching yet. */
> > +if ( !func->new_size )
> > +return -EOPNOTSUPP;
> > 
> > -void arch_livepatch_apply_jmp(struct livepatch_func *func)
> > -{
> > -}
> > +if ( func->old_size < PATCH_INSN_SIZE )
> > +return -EINVAL;
> > 
> > -void arch_livepatch_revert_jmp(const struct livepatch_func *func)
> > -{
> > +return 0;
> >  }
> > 
> >  void arch_livepatch_post_action(void)
> >  {
> > +/* arch_livepatch_revive has nuked the instruction cache. */
> >  }
> > 
> >  void arch_livepatch_mask(void)
> >  {
> > +/* TODO: No NMI on ARM? */
> 
> All interrupts can 

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Jiri Kosina]

On Fri, 12 Aug 2016, Greg KH wrote:

> > + Enabling this option never increases the size of your kernel.
> 
> Then what does it do?  Just burn electricity for no reason?

I think that this whole thing could be without loss of generality 
reformulated in a "allows for participating in compile-testing code 
efforts, without actually having to have all the compile-tested code 
present in the resulting kernel".

-- 
Jiri Kosina
SUSE Labs


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

Re: [Xen-devel] [PATCH 1/2] build-id: fix minor quirks

[Konrad Rzeszutek Wilk]

On Fri, Aug 12, 2016 at 08:45:02AM -0600, Jan Beulich wrote:
> The initial size check in xen_build_id_check() came too late (after the
> first access to the structure), but was mostly redundant with checks
> done in all callers; convert it to a properly placed ASSERT(). The
> "mostly" part being addressed too: xen_build_init() was off by one.
> 
> And then there was a stray semicolon.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Konrad Rzeszutek Wilk 

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

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Greg KH]

On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> Alright, how's this new description:
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index cac3f096050d..73e4890c24c4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -53,6 +53,34 @@ config CROSS_COMPILE
> need to set this unless you want the configured kernel build
> directory to select the cross-compiler automatically.
>  
> +config BUILD_AVOID_BITROT
> + bool "Always force building specially annotated targets"
> + default n
> + help
> +   If enabled then the the special table-* Makefile targets will always
> +   be forced to be compiled even if their respective CONFIG_ option has
> +   been disabled, but its objects will only be linked in if the same
> +   respective CONFIG_ option has been enabled. This helps avoid code
> +   bit rot issues, use for these targets should be carefully considred
> +   by maintainers. You can safely enable this option at the expense of
> +   increasing compile time. Enabling this option helps avoid code bit
> +   rot by taking advantage of the facilities provided and enabled by
> +   using linker tables documented under:

As a kernel developer I have _no_ idea what this is trying to say at
all, sorry.

What is a "specially annotated target"?  Who is forcing it to be built?
What does it mean if it isn't built?

> +
> +   include/linux/tables.h
> +
> +   The special targets supported are:
> +
> + o table-obj-y
> + o table-lib-y

What does this mean to me as a developer?  What does it mean to a user
who wants to figure out if it should be enabled or not?

> +
> +   Say Y if you have a decent build machine and would like to help test
> +   building code for more subsystems. Say N if you do you not have a
> +   good build machine or only want to compile what you've enabled for
> +   your kernel.

How does this test different subsystems?  How does disabling it not test
them?  Why would I care either way?

> +
> +   Enabling this option never increases the size of your kernel.

Then what does it do?  Just burn electricity for no reason?

totally confused...

greg k-h

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

[Xen-devel] [linux-3.14 baseline-only test] 66970: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66970 linux-3.14 real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66970/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 66862
 build-amd64-rumpuserxen   6 xen-buildfail   like 66862
 build-i386-rumpuserxen6 xen-buildfail   like 66862
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66862
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66862
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66862

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

version targeted for testing:
 linuxb8b6a72089869dee41bd9f29e86bbcf6501e5524
baseline version:
 linuxda99423b3cd3e48c42c0d64b79aba58d828f9648

Last test of basis66862  2016-07-29 20:17:38 Z   13 days
Testing same since66970  2016-08-11 09:50:48 Z1 days1 attempts


People who touched revisions under test:
  Alexander Klein 
  Alexey Brodkin 
  Alexey Brodkin 
  Amr Bekhit 
  Andrew Morton 
  Andrey Grodzovsky 
  Benjamin Herrenschmidt 
  Brian King 
  Cameron Gutman 
  David S. Miller 
  David Vrabel 
  Dmitri Epshtein 
  Dmitry Torokhov 
  Greg Kroah-Hartman 
  Ilya Dryomov 
  Jeff Mahoney 
  Jiri Slaby 
  Kangjie Lu 
  Kangjie Lu 
  Linus Torvalds 
  Linus Walleij 
  Marc Kleine-Budde 
  Marcin Wojtas 
  Martin K. Petersen 
  Oliver Hartkopp 
  Ping Cheng 
  Ping Cheng 
  Ryusuke Konishi 
  Takashi Iwai 
  Taras Kondratiuk 
  Theodore Ts'o 
  Tony Lindgren 
  Torsten Hilbrich 
  Tyler Hicks 
  Ulf Hansson 
  Ursula Braun 
  Vegard Nossum 
  Vineet Gupta 
  Willy Tarreau 
  Wolfgang Grandegger 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   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
 

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

[osstest service owner]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  6 xen-boot fail REGR. vs. 100421
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 100421
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 100421

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

version targeted for testing:
 qemuu60ac136102098a70b97ab0c07bc7bf53131c
baseline version:
 qemuu28b874429ba16e71e0caa46453f3a3e31efb3c51

Last test of basis   100421  2016-08-11 19:44:22 Z1 days
Testing same since   100454  2016-08-12 12:41:10 Z0 days1 attempts


People who touched revisions under test:
  Peter Maydell 
  Pranith Kumar 

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   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-xsm  

Re: [Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999

[Sander Eikelenboom]

Friday, August 12, 2016, 7:29:37 PM, you wrote:

> Hi,

> On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote :
>> L.S.,
>> 
>> I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV 
>> guests and dom0 are uneffected). The clock is always set to 31/12/1999 on 
>> boot 
>> of the guest, instead of the system clock time.
>> 
>> Bisecting seems to point out commit:
>> 463a86304cae92e10277b47180ac59cf93982e5b char/genrtc: x86: remove remnants 
>> of asm/rtc.h
>> 

> Isn't that solved by http://patchwork.ozlabs.org/patch/657465/ ?


Ah yes that solves it (i only looked in your git-tree to see if there was a 
patch already), sorry for the noise !

--

Sander


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

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Kees Cook]

Just some minor typos in descriptions I noticed below...

On Fri, Aug 12, 2016 at 10:35 AM, Borislav Petkov  wrote:
> On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
>> Alright, how's this new description:
>>
>> diff --git a/init/Kconfig b/init/Kconfig
>> index cac3f096050d..73e4890c24c4 100644
>> --- a/init/Kconfig
>> +++ b/init/Kconfig
>> @@ -53,6 +53,34 @@ config CROSS_COMPILE
>> need to set this unless you want the configured kernel build
>> directory to select the cross-compiler automatically.
>>
>> +config BUILD_AVOID_BITROT
>> + bool "Always force building specially annotated targets"
>> + default n
>> + help
>> +   If enabled then the the special table-* Makefile targets will always

"the the" -> "the"

>> +   be forced to be compiled even if their respective CONFIG_ option has
>
> "will always be compiled" is already absolute.
>
>> +   been disabled, but its objects will only be linked in if the same
>> +   respective CONFIG_ option has been enabled. This helps avoid code
>> +   bit rot issues, use for these targets should be carefully considred

"considered"

>
> s/This helps avoid code bit rot issues, u/U/
>
> The bit-rot thing comes again below.
>
>> +   by maintainers. You can safely enable this option at the expense of
>> +   increasing compile time. Enabling this option helps avoid code bit
>> +   rot by taking advantage of the facilities provided and enabled by
>> +   using linker tables documented under:
>> +
>> +   include/linux/tables.h
>> +
>> +   The special targets supported are:
>> +
>> + o table-obj-y
>> + o table-lib-y
>> +
>> +   Say Y if you have a decent build machine and would like to help test
>> +   building code for more subsystems. Say N if you do you not have a
>> +   good build machine or only want to compile what you've enabled for
>> +   your kernel.
>> +
>> +   Enabling this option never increases the size of your kernel.
>> +
>
> Other than those minor formulation nits, yeah, nice!
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --

-Kees

-- 
Kees Cook
Nexus Security

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

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

[osstest service owner]

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

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  a55ad65d3a30d5b3a026a7481ce05f28065920f0
baseline version:
 xen  20aa9381db781ee050355635efd14a9a37e1d94d

Last test of basis   100457  2016-08-12 13:01:26 Z0 days
Testing same since   100468  2016-08-12 16:00:59 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Razvan Cojocaru 
  Tamas K Lengyel 
  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=a55ad65d3a30d5b3a026a7481ce05f28065920f0
+ . ./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 
a55ad65d3a30d5b3a026a7481ce05f28065920f0
+ branch=xen-unstable-smoke
+ revision=a55ad65d3a30d5b3a026a7481ce05f28065920f0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xa55ad65d3a30d5b3a026a7481ce05f28065920f0 = 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 

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Borislav Petkov]

On Fri, Aug 12, 2016 at 07:04:52PM +0200, Luis R. Rodriguez wrote:
> Alright, how's this new description:
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index cac3f096050d..73e4890c24c4 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -53,6 +53,34 @@ config CROSS_COMPILE
> need to set this unless you want the configured kernel build
> directory to select the cross-compiler automatically.
>  
> +config BUILD_AVOID_BITROT
> + bool "Always force building specially annotated targets"
> + default n
> + help
> +   If enabled then the the special table-* Makefile targets will always
> +   be forced to be compiled even if their respective CONFIG_ option has

"will always be compiled" is already absolute.

> +   been disabled, but its objects will only be linked in if the same
> +   respective CONFIG_ option has been enabled. This helps avoid code
> +   bit rot issues, use for these targets should be carefully considred

s/This helps avoid code bit rot issues, u/U/

The bit-rot thing comes again below.

> +   by maintainers. You can safely enable this option at the expense of
> +   increasing compile time. Enabling this option helps avoid code bit
> +   rot by taking advantage of the facilities provided and enabled by
> +   using linker tables documented under:
> +
> +   include/linux/tables.h
> +
> +   The special targets supported are:
> +
> + o table-obj-y
> + o table-lib-y
> +
> +   Say Y if you have a decent build machine and would like to help test
> +   building code for more subsystems. Say N if you do you not have a
> +   good build machine or only want to compile what you've enabled for
> +   your kernel.
> +
> +   Enabling this option never increases the size of your kernel.
> +

Other than those minor formulation nits, yeah, nice!

Thanks.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

Re: [Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999

[Alexandre Belloni]

Hi,

On 12/08/2016 at 19:23:36 +0200, Sander Eikelenboom wrote :
> L.S.,
> 
> I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV 
> guests and dom0 are uneffected). The clock is always set to 31/12/1999 on 
> boot 
> of the guest, instead of the system clock time.
> 
> Bisecting seems to point out commit:
> 463a86304cae92e10277b47180ac59cf93982e5b char/genrtc: x86: remove remnants of 
> asm/rtc.h
> 

Isn't that solved by http://patchwork.ozlabs.org/patch/657465/ ?

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

[Xen-devel] [PATCH 3/4] [STUBDOM] Added COPYING files and README.source files

[Lars Kurth]

Added a COPYING file as a boilerplate to explain license oddities in
this directory

Added a vtpm/COPYING file which contains MIT licensed files only

Added a vtpmmgr/README.source file which contains many BSD-3-Clause
files that originally came from tools/vtpm_manager

Signed-off-by: Lars Kurth 
---
 stubdom/COPYING   | 31 +++
 stubdom/vtpm/COPYING  | 26 ++
 stubdom/vtpmmgr/README.source | 23 +++
 3 files changed, 80 insertions(+)
 create mode 100644 stubdom/COPYING
 create mode 100644 stubdom/vtpm/COPYING
 create mode 100644 stubdom/vtpmmgr/README.source

diff --git a/stubdom/COPYING b/stubdom/COPYING
new file mode 100644
index 000..a5071b3
--- /dev/null
+++ b/stubdom/COPYING
@@ -0,0 +1,31 @@
+Most files in this directory are covered by version 2 of the 
+GNU General Public License except where explicitly stated.
+See the main COPYING file in xen.git for more information.
+
+Notable exceptions are in the following directories
+
+vtpm
+ 
+Exclusively contains code licensed under a MIT license
+Also see vtpm/COPYING
+
+vtpmmgr
+===
+Contains a significant portion of files which are licensed
+under a BSD-3-Clause license. These files were imported from
+elsewhere and are copyrighted as follows:
+
+Copyright (c) 2005, Intel Corp.
+All rights reserved.
+
+See README.source for a complete list of files
+
+Otherwise, this directory contains several files licensed under
+GPLv2+, or without copyright headers. 
+
+*.patch and *.diff files
+
+This directory contains a number of *.patch and *.diff files. 
+These files describe changes to source files and are thus 
+licensed under the license from which the *.patch and *.diff
+were generated.
diff --git a/stubdom/vtpm/COPYING b/stubdom/vtpm/COPYING
new file mode 100644
index 000..80780b8
--- /dev/null
+++ b/stubdom/vtpm/COPYING
@@ -0,0 +1,26 @@
+This copyright applies to all files within this subdirectory and its
+subdirectories, unless explicitly stated otherwise within individual 
+source files.
+
+All other files in the Xen source distribution are covered by version
+2 of the GNU General Public License except where explicitly stated.
+See the main COPYING file in xen.git for more information.
+
+=
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to
+deal in the Software without restriction, including without limitation the
+rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+sell copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THIS SOFTWARE AND ITS DOCUMENTATION ARE PROVIDED AS IS AND WITHOUT
+ANY EXPRESS OR IMPLIED WARRANTIES WHATSOEVER. ALL WARRANTIES
+INCLUDING, BUT NOT LIMITED TO, PERFORMANCE, MERCHANTABILITY, FITNESS
+FOR A PARTICULAR  PURPOSE, AND NONINFRINGEMENT ARE HEREBY
+DISCLAIMED. USERS ASSUME THE ENTIRE RISK AND LIABILITY OF USING THE
+SOFTWARE.
\ No newline at end of file
diff --git a/stubdom/vtpmmgr/README.source b/stubdom/vtpmmgr/README.source
new file mode 100644
index 000..1b45997
--- /dev/null
+++ b/stubdom/vtpmmgr/README.source
@@ -0,0 +1,23 @@
+About
+=
+This documents the upstream sources for files in this directory.
+
+The following files are based off of the original 
+tools/vtpm_manager code base in xen.git, which has since been 
+deleted: 
+
+init.c
+log.c
+log.h
+marshal.h
+tcg.h
+tpm.c
+tpm.h
+tpm2.c
+tpm2.h
+tpm2_marshal.h
+uuid.h
+vtpm_cmd_handler.c
+vtpm_manager.h
+vtpmmgr.c
+vtpmmgr.h
\ No newline at end of file
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH 4/4] blktap2: Added COPYING file

[Lars Kurth]

Blktap2 has some complexity, as some files do not have (c) headers
and the directory did not have a COPYING file. At this stage, we
have not verified the intention of (c) holders. We may do this in
future, if the need arises.

Signed-off-by: Lars Kurth 
---
 tools/blktap2/COPYING | 72 +++
 1 file changed, 72 insertions(+)
 create mode 100644 tools/blktap2/COPYING

diff --git a/tools/blktap2/COPYING b/tools/blktap2/COPYING
new file mode 100644
index 000..f3d7a10
--- /dev/null
+++ b/tools/blktap2/COPYING
@@ -0,0 +1,72 @@
+Most files in this directory are covered by a BSD-3-Clause
+license as stated in the text below, unless explicitly otherwise 
+stated.
+
+New contributions to existing files in this directory are 
+governed by the license that applies to the relevant specific 
+file. New contributions to the files listed in [1] are to be
+taken under a BSD-3-Clause license. We believe that most 
+(if not all) of the existing copyright holders intended 
+to make their contribution under BSD-3 even for the files 
+with no copyright headers. But this has not been verified.
+
+New files are to be taken under BSD-3-Clause, unless otherwise
+explicitly stated in the copyright header.
+
+If you want to deal in this code you may do so under GPLv2, 
+at least.
+
+Files without (c) headers
+=
+The following source files did not have a (c) notice at the 
+time this COPYING notice was added to the source tree:
+
+[1]
+./drivers/aes.h
+./drivers/blk_linux.c
+./drivers/blk_netbsd.c
+./drivers/block-remus.c
+./drivers/bswap.h
+./drivers/check_gcrypt
+./drivers/md5.h
+./drivers/xmsnap
+./include/list.h
+
+QCOW files 
+==
+The following files are dually licensed under an MIT and GPLv2
+license
+
+[2]
+./drivers/img2qcow.c
+./drivers/qcow2raw.c
+./drivers/qcow-create.c
+
+=
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions 
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder Inc. nor the names of its 
+   contributors may be used to endorse or promote products derived 
+   from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
+OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
+LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
+DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 
+THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH 0/4] Clarify License information : m4, stubdom, tools/blktap2, xen/crypto

[Lars Kurth]

This series contains some of the easier license clean-up cases, which can be 
fixed
by adding COPYING files or README.source files. The series specially contains:

xen/crypto and xen/include/crypto
Added a README.source file
Does not need a COPYING file: all files are imported 

m4
Updated README.source to include ax_compare_version.m4
Does not need a COPYING file: all files are GPLv2  
Exceptions are exclusively from imported files: GPLv2+ 
and Laurikari (https://enterprise.dejacode.com/license_library/Demo/laurikari/)

stubdom
Added a COPYING file as a boilerplate to explain license oddities in this 
directory
Added a vtpm/COPYING file which contains MIT licensed files only
Added a vtpmmgr/README.source file which contains many BSD-3-Clause files only,
that originally came from tools/vtpm_manager

tools/blktap2
Added a COPYING file 
There is some complexity here, but I believe it is not necessary to fix this at 
this
stage, as for some time we were discussing to remove blktap2.

-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH 2/4] Added source of ax_compare_version.m4 to import log

[Lars Kurth]

In addition:
- fixed a reference, which was incorrect

Signed-off-by: Lars Kurth 
---
 m4/README.source | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/m4/README.source b/m4/README.source
index 21850a6..be7bc5a 100644
--- a/m4/README.source
+++ b/m4/README.source
@@ -3,6 +3,13 @@ About
 This documents the upstream sources for the different slew of different
 m4 sources we have picked up or developed.
 
+ax_compare_version.m4
+=
+This file was fetched from 
+http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_compare_version.m4
+
+Also see http://www.gnu.org/software/autoconf-archive/ax_compare_version.html
+
 pkg.m4
 ==
 The pkg-config m4 macro library comes from the upstream pkg-config
@@ -13,7 +20,7 @@ on how to use this read the pkg-config(1) man page.
 Do not modify this file yourself, if you want to evolve it send
 patches upstream and then synch back here.
 
-Tree: git://anongit.freedesktop.org/pkg-config
+[0]: git://anongit.freedesktop.org/pkg-config
 
 The last synch was from commit:
 
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [PATCH 1/4] Add information on sources for vmac.* and rijndael.*

[Lars Kurth]

I added these, as I came across the sources during
a license scan.

Signed-off-by: Lars Kurth 
---
 xen/crypto/README.source | 17 +
 xen/include/crypto/README.source | 17 +
 2 files changed, 34 insertions(+)
 create mode 100644 xen/crypto/README.source
 create mode 100644 xen/include/crypto/README.source

diff --git a/xen/crypto/README.source b/xen/crypto/README.source
new file mode 100644
index 000..894045d
--- /dev/null
+++ b/xen/crypto/README.source
@@ -0,0 +1,17 @@
+About
+=
+This documents the upstream sources for files in this directory.
+
+rijndael.c
+==
+This file comes from 
+http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/
+
+vmac.c
+==
+This file was developed by Ted Krovetz and Wei Dai (more details 
+are in the files). 
+
+See
+- https://en.wikipedia.org/wiki/VMAC
+- http://www.fastcrypto.org/vmac/vmac.c
diff --git a/xen/include/crypto/README.source b/xen/include/crypto/README.source
new file mode 100644
index 000..68de1cd
--- /dev/null
+++ b/xen/include/crypto/README.source
@@ -0,0 +1,17 @@
+About
+=
+This documents the upstream sources for files in this directory.
+
+rijndael.h
+==
+This file comes from 
+http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/crypto/
+
+vmac.h
+==
+This file was developed by Ted Krovetz and Wei Dai (more details 
+are in the files). 
+
+See
+- https://en.wikipedia.org/wiki/VMAC
+- http://www.fastcrypto.org/vmac/vmac.h
-- 
2.5.4 (Apple Git-61)


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

[Xen-devel] [Linux 4.8-rc1 Bisected] Clock on boot Xen HVM guest starts at 31/12/1999

[Sander Eikelenboom]

L.S.,

I'm seeing an issue when using a Linux 4.8-rc1 kernel in a Xen HVM guest (PV 
guests and dom0 are uneffected). The clock is always set to 31/12/1999 on boot 
of the guest, instead of the system clock time.

Bisecting seems to point out commit:
463a86304cae92e10277b47180ac59cf93982e5b char/genrtc: x86: remove remnants of 
asm/rtc.h

--
Sander


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

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Luis R. Rodriguez]

On Fri, Aug 12, 2016 at 05:51:21PM +0200, Borislav Petkov wrote:
> On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote:
> > Even so, you don't link the compiled extra code so the only penalty
> > here is when compiling, nothing more. And if you are compiling typically
> > the cost here is just a few seconds.
> 
> Yeah, so let's make it clear that this is similar to COMPILE_TEST and
> people with fast machines and who don't mind building a couple more
> seconds longer, should enable it.

Sure, I'll also move it under COMPILE_TEST, and default it to n.

> You don't want to be doing bit-rotting tests on small, weak machines,
> which barely get done with the build as it is. I have a 32-bit atom
> which takes hours to build a kernel. Enabling that there is not making
> the kernel build any more fun.
> 
> > > ... or you simply don't want to have stuff which is forcibly enabled on 
> > > you even
> > > if you're never going to need it
> > > ...
> > 
> > Which seems to be the same as the reason I noted ?
> 
> No, the reason is we don't force stuff down people's throats just
> because we think we know better. Other people do that.
> 
> Instead, we help them make an informed decision by describing the
> feature as precisely as possible.
> 
> > I can remove the grumpy maintainer description :)
> 
> Yap :-)

Alright, how's this new description:

diff --git a/init/Kconfig b/init/Kconfig
index cac3f096050d..73e4890c24c4 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -53,6 +53,34 @@ config CROSS_COMPILE
  need to set this unless you want the configured kernel build
  directory to select the cross-compiler automatically.
 
+config BUILD_AVOID_BITROT
+   bool "Always force building specially annotated targets"
+   default n
+   help
+ If enabled then the the special table-* Makefile targets will always
+ be forced to be compiled even if their respective CONFIG_ option has
+ been disabled, but its objects will only be linked in if the same
+ respective CONFIG_ option has been enabled. This helps avoid code
+ bit rot issues, use for these targets should be carefully considred
+ by maintainers. You can safely enable this option at the expense of
+ increasing compile time. Enabling this option helps avoid code bit
+ rot by taking advantage of the facilities provided and enabled by
+ using linker tables documented under:
+
+ include/linux/tables.h
+
+ The special targets supported are:
+
+   o table-obj-y
+   o table-lib-y
+
+ Say Y if you have a decent build machine and would like to help test
+ building code for more subsystems. Say N if you do you not have a
+ good build machine or only want to compile what you've enabled for
+ your kernel.
+
+ Enabling this option never increases the size of your kernel.
+
 config COMPILE_TEST
bool "Compile also drivers which will not load"
depends on !UML

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

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Borislav Petkov]

On Fri, Aug 12, 2016 at 05:28:05PM +0200, Luis R. Rodriguez wrote:
> Even so, you don't link the compiled extra code so the only penalty
> here is when compiling, nothing more. And if you are compiling typically
> the cost here is just a few seconds.

Yeah, so let's make it clear that this is similar to COMPILE_TEST and
people with fast machines and who don't mind building a couple more
seconds longer, should enable it.

You don't want to be doing bit-rotting tests on small, weak machines,
which barely get done with the build as it is. I have a 32-bit atom
which takes hours to build a kernel. Enabling that there is not making
the kernel build any more fun.

> > ... or you simply don't want to have stuff which is forcibly enabled on you 
> > even
> > if you're never going to need it
> > ...
> 
> Which seems to be the same as the reason I noted ?

No, the reason is we don't force stuff down people's throats just
because we think we know better. Other people do that.

Instead, we help them make an informed decision by describing the
feature as precisely as possible.

> I can remove the grumpy maintainer description :)

Yap :-)

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

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

Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

[Konrad Rzeszutek Wilk]

On Fri, Aug 12, 2016 at 09:51:39AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote:
> > On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote:
> > > Hey Ross,
> > > 
> > > I am running in a symbol dependency issue that I am not exactly
> > > sure how to solve.
> > > 
> > > I have an payload that introduces a new function (xen_foobar) which
> > > will patch over xen_extra_version().
> > > 
> > snip
> > > 
> > > As livepatch_symbols_lookup_by_name only looks for symbols that
> > > have the ->new_symbol set. And xen_foobar does not. So the loading is
> > > aborted.
> > > 
> > > Which makes sense - we don't want to match the symbols as they haven't
> > > really been "finally loaded" in.
> > > 
> > > But what if the xen_foobar is applied. In that case we should
> > > change the xen_foobar to be new_symbol=1?
> > 
> > I think you're confused about the purpose of new_symbol. The purpose is to
> > ensure that you link against the correct symbol from the base hypervisor or
> > the live patch that first introduced it. So, new_symbol=0 is when a symbol
> > overrides an existing symbol. new_symbol=1 is set when a symbol is new
> 
> But it does not (overrides the existing symbol).
> 
> The patch (xen_foobar) introduces a new function called xen_foobar
> which is patching xen_extra_version.
> 
> That is:
> 
> static char foobar_patch_this_fnc[] = "xen_extra_version";
> 
> struct livepatch_func __section(".livepatch.funcs") livepatch_xen_foobar = { 
> .version = LIVEPATCH_PAYLOAD_VERSION,
> .name = foobar_patch_this_fnc,
> .new_addr = xen_foobar,
> .old_addr = xen_extra_version,
> .new_size = NEW_CODE_SZ,
> .old_size = OLD_CODE_SZ,
> };
> 
> > introduced in a live patch.
> 
> And this loop:
> 
> for ( j = 0; j < payload->nfuncs; j++ ) 
> { 
>   
> if ( symtab[i].value == (unsigned long)payload->funcs[j].new_addr 
> ) 
> { 
>   
> found = 1;
>   
> break;
>   
> } 
>   
> }
> 
> Will force new_symbol=0 for xen_foobar.
> 
> > 
> > Since all the linking happens during load and not apply, it is perfectly OK
> > to link against a symbol that hasn't been applied -- the dependencies are
> > there to ensure that you can't apply a patch which links against unapplied
> > symbols.
> > 
> > The assumption is that when overriding an existing symbol, the symbol in the
> > payload has the same name as the one it is overriding. You're having issues
> > above because you're breaking this assumption.
> 
> Yes :-)
> 
> > 
> > > 
> > > This following patch does that, but I am wondering if there is a better
> > > way?
> > 
> > The patch is misusing new_symbol for something completely different from how
> > it was intended so I hope there is a better way :-P
> 
> Well for my use-case I think I can just s/xen_foobar/xen_extra_version/ and we
> should be OK.

Ah no.

It does work for xen_foo (so it replaces xen_extra_version with its own 
'xen_extra_version'.

But when I introduce xen_foobar_nop and it tries to look for 'xen_extra_version'
it picks the hypervisor one (which has been patched over) instead
of the livepatched version.

This may require some extra lookup in the applied_list for the symbols
before consulting and trying to match up the symbols in the built-in list.

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

Re: [Xen-devel] [RFC v3 07/13] tables.h: add linker table support

[Luis R. Rodriguez]

On Fri, Aug 12, 2016 at 09:25:07AM +0200, Borislav Petkov wrote:
> On Fri, Aug 12, 2016 at 08:50:11AM +0200, Luis R. Rodriguez wrote:
> > On Fri, Aug 12, 2016 at 07:23:03AM +0200, Borislav Petkov wrote:
> > > On Fri, Aug 12, 2016 at 05:51:29AM +0200, Luis R. Rodriguez wrote:
> > > > OK I've added CONFIG_BUILD_AVOID_BITROT.
> > > 
> > > What does that do?
> > 
> > 
> > Enabling it allows the forced compilation chosen by maintainers.
> > Otherwise forced compilations with the new special targets are
> > ignored.
> 
> Nice.
> 
> > I've gone with table-obj-y and table-lib-y as we have
> > to support both lib-y and obj-y respective targets.
> > 
> > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> > index 33e2966dd741..7893e3b8da82 100644
> > --- a/lib/Kconfig.debug
> > +++ b/lib/Kconfig.debug
> > @@ -1895,6 +1895,30 @@ config PROVIDE_OHCI1394_DMA_INIT
> >  
> >   See Documentation/debugging-via-ohci1394.txt for more information.
> >  
> > +config BUILD_AVOID_BITROT
> > +   bool "Always force building specially annotated"
> 
>  ...annotated targets"
> 
> > +   default y
> > +   help
> > + If enabled then the the special table-* Makefile targets will always
> > + be forced to be compiled even if their respective CONFIG_ option has
> > + been disabled, but its objects will only be linked in if the same
> > + respective CONFIG_ option has been enabled. This helps avoid code
> > + bit rot issues, use for these targets should be carefully considred
> > + by maintainers. You can safely enable this option at the expense of
> > + increasing compile time slightly. Enabling this option helps avoid
> 
> s/slightly//
> 
> :-)
> 
> > + code bit rot by taking advantage of the facilities provided and
> > + enabled by using linker tables documented under:
> > +
> > + include/linux/tables.h
> > +
> > + The special targets supported are:
> > +
> > +   o table-obj-y
> > +   o table-lib-y
> > +
> > + Say Y unless you are a grumpy maintainer and don't trust other
> > + maintainer's judgements on what code should always get compiled.
> 
> ... or you're running a tiny-config setup

Even so, you don't link the compiled extra code so the only penalty
here is when compiling, nothing more. And if you are compiling typically
the cost here is just a few seconds.

> ... or you're an embedded, resource-constrained person

For the compilation of th kernel ?

> ... or you simply don't want to have stuff which is forcibly enabled on you 
> even
> if you're never going to need it
> ...

Which seems to be the same as the reason I noted ?

> I got a million o'those :-)

I can remove the grumpy maintainer description :)

 Luis

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

Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

[Andrew Cooper]

On 12/08/16 16:21, Jan Beulich wrote:
 On 12.08.16 at 17:02,  wrote:
>> On 12/08/16 15:47, Jan Beulich wrote:
>>> Besides being more logical this also allows verifying correct recording
>>> of alignments in .o files.
>>>
>>> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
>>> value (as it now verifies correct tool chain behavior), but I've left
>>> it in nevertheless.
>>>
>>> Signed-off-by: Jan Beulich 
>>>
>>> --- a/xen/arch/x86/hvm/hvm.c
>>> +++ b/xen/arch/x86/hvm/hvm.c
>>> @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re
>>>   */
>>>  #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
>>>  unsigned long __section(".bss.page_aligned")
>>> +__attribute__((aligned(PAGE_SIZE)))
>> Can I talk you into introducing #define __aligned(x)
>> __attribute__((aligned(x))) in compiler.h ?
> Sure, I was on the edge of introducing it while putting this together
> anyway, but then thought it's maybe not worth it.

I have been meaning to do it for a while, and clean up the existing
opencoded uses in the tree.

~Andrew

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

Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

[Jan Beulich]

>>> On 12.08.16 at 17:02,  wrote:
> On 12/08/16 15:47, Jan Beulich wrote:
>> Besides being more logical this also allows verifying correct recording
>> of alignments in .o files.
>>
>> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
>> value (as it now verifies correct tool chain behavior), but I've left
>> it in nevertheless.
>>
>> Signed-off-by: Jan Beulich 
>>
>> --- a/xen/arch/x86/hvm/hvm.c
>> +++ b/xen/arch/x86/hvm/hvm.c
>> @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re
>>   */
>>  #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
>>  unsigned long __section(".bss.page_aligned")
>> +__attribute__((aligned(PAGE_SIZE)))
> 
> Can I talk you into introducing #define __aligned(x)
> __attribute__((aligned(x))) in compiler.h ?

Sure, I was on the edge of introducing it while putting this together
anyway, but then thought it's maybe not worth it.

> Otherwise, Reviewed-by: Andrew Cooper 

Thanks, Jan


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

Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU

[Dario Faggioli]

On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote:
> On 12/08/16 05:07, Dario Faggioli wrote:

> Let me know if you want me to check this in as-is or if you think you
> might send a follow-up patch adding an ASSERT.
> 
Done, and it actually explodes like this:

(XEN) [4.870128] Xen call trace:
(XEN) [4.870130][] spinlock.c#check_lock+0x42/0x46
(XEN) [4.870133][] _spin_is_locked+0x11/0x4d
(XEN) [4.870139][] 
sched_credit.c#_csched_cpu_pick+0x1a9/0x632
(XEN) [4.870142][] 
sched_credit.c#csched_tick+0x1fd/0x385
(XEN) [4.870146][] timer.c#execute_timer+0x47/0x62
(XEN) [4.870148][] 
timer.c#timer_softirq_action+0xdb/0x22c
(XEN) [4.870151][] softirq.c#__do_softirq+0x7f/0x8a
(XEN) [4.870153][] do_softirq+0x13/0x15
(XEN) [4.870157][] entry.o#process_softirqs+0x21/0x30
(XEN) [4.870159] 
(XEN) [5.619096] 
(XEN) [5.621085] 
(XEN) [5.626536] Panic on CPU 0:
(XEN) [5.629826] Xen BUG at spinlock.c:48
(XEN) [5.633895] 

And if I look at csched_tick(), it indeed is the case that we
call csched_vcpu_acct() **without** holding the runq lock.

It in turns calls things like burn_credits(), accesses current, and
other stuff, which I'm having a little bit of an hard time convincing
myself it is safe... Although it must be, if there have been no issues
after all these years. :-O

csched_runq_sort(), called later, still by csched_tick(), acquires the
lock by itself, and we can't acquire it in csched_tick(), because
__csched_vcpu_acct_start() acquires the private lock, and we'd violate
the nesting rule.

In summary, this is looking more complicated than it seemed, and I'll
have to look at this again on Tuesday (it's public holiday, here, on
Monday).

Gosh, how much I hate this scheduler!! :-/

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
https://lists.xen.org/xen-devel

Re: [Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON

[Wei Liu]

On Fri, Aug 12, 2016 at 04:02:11PM +0200, Samuel Thibault wrote:
> Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote:
> > BUILD_BUG_ON should not appear in a public-facing header, otherwise it
> > risks clashing with macro with the same name in other code bases. I
> > encountered such issue when trying to add BUILD_BUG_ON to a private
> > header in Xen's gnttab library.
> > 
> > Ideally BUILD_BUG_ON should be moved to a private header, but there is
> > actually no user of it in mini-os tree, just remove it.
> > 
> > Signed-off-by: Wei Liu 
> 
> Acked-by: Samuel Thibault 
> 

Actually some stuff in stubdom depends on mini-os leaking BUILD_BUG_ON,
while some actively work around the leaking of some other macros.

I will hold off putting in this patch for now.

Wei.

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

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

[osstest service owner]

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

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  20aa9381db781ee050355635efd14a9a37e1d94d
baseline version:
 xen  072e6709978143145a1c1b98c7f014dc4d87907f

Last test of basis   100417  2016-08-11 15:01:47 Z1 days
Testing same since   100457  2016-08-12 13:01:26 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 

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



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

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

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

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


Pushing revision :

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

[Xen-devel] [PATCH v2 2/2] x86emul: introduce SrcImm16

[Jan Beulich]

... and use it for RET, LRET, and ENTER processing to limit the amount
of "manual" insn bytes fetching. Note that for the RET and LRET paths
the change utilizes that SrcImplicit (aka SrcNone) table entries leave
src.val as zero.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -39,6 +39,7 @@
 #define SrcMem16(4<<3) /* Memory operand (16-bit). */
 #define SrcImm  (5<<3) /* Immediate operand. */
 #define SrcImmByte  (6<<3) /* 8-bit sign-extended immediate operand. */
+#define SrcImm16(7<<3) /* 16-bit zero-extended immediate operand. */
 #define SrcMask (7<<3)
 /* Generic ModRM decode. */
 #define ModRM   (1<<6)
@@ -143,11 +144,11 @@ static uint8_t opcode_table[256] = {
 DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov,
 /* 0xC0 - 0xC7 */
 ByteOp|DstMem|SrcImm|ModRM, DstMem|SrcImmByte|ModRM,
-ImplicitOps, ImplicitOps,
+DstImplicit|SrcImm16, ImplicitOps,
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 ByteOp|DstMem|SrcImm|ModRM|Mov, DstMem|SrcImm|ModRM|Mov,
 /* 0xC8 - 0xCF */
-ImplicitOps, ImplicitOps, ImplicitOps, ImplicitOps,
+DstImplicit|SrcImm16, ImplicitOps, DstImplicit|SrcImm16, ImplicitOps,
 ImplicitOps, DstImplicit|SrcImmByte, ImplicitOps, ImplicitOps,
 /* 0xD0 - 0xD7 */
 ByteOp|DstMem|SrcImplicit|ModRM, DstMem|SrcImplicit|ModRM,
@@ -1996,6 +1997,11 @@ x86_emulate(
 case 4: src.val = insn_fetch_type(int32_t); break;
 }
 break;
+case SrcImm16:
+src.type  = OP_IMM;
+src.bytes = 2;
+src.val   = insn_fetch_type(uint16_t);
+break;
 }
 
 /* Decode and fetch the destination operand: register or memory. */
@@ -2788,16 +2794,14 @@ x86_emulate(
 break;
 
 case 0xc2: /* ret imm16 (near) */
-case 0xc3: /* ret (near) */ {
-int offset = (b == 0xc2) ? insn_fetch_type(uint16_t) : 0;
+case 0xc3: /* ret (near) */
 op_bytes = ((op_bytes == 4) && mode_64bit()) ? 8 : op_bytes;
-if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + offset),
+if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val),
   , op_bytes, ctxt, ops)) != 0 ||
  (rc = ops->insn_fetch(x86_seg_cs, dst.val, NULL, 0, ctxt)) )
 goto done;
 _regs.eip = dst.val;
 break;
-}
 
 case 0xc4: /* les */ {
 unsigned long sel;
@@ -2819,7 +2823,6 @@ x86_emulate(
 goto les;
 
 case 0xc8: /* enter imm16,imm8 */ {
-uint16_t size = insn_fetch_type(uint16_t);
 uint8_t depth = insn_fetch_type(uint8_t) & 31;
 int i;
 
@@ -2848,7 +2851,7 @@ x86_emulate(
 goto done;
 }
 
-sp_pre_dec(size);
+sp_pre_dec(src.val);
 break;
 }
 
@@ -2876,17 +2879,15 @@ x86_emulate(
 break;
 
 case 0xca: /* ret imm16 (far) */
-case 0xcb: /* ret (far) */ {
-int offset = (b == 0xca) ? insn_fetch_type(uint16_t) : 0;
+case 0xcb: /* ret (far) */
 if ( (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),
   , op_bytes, ctxt, ops)) ||
- (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + offset),
+ (rc = read_ulong(x86_seg_ss, sp_post_inc(op_bytes + src.val),
   , op_bytes, ctxt, ops)) ||
  (rc = load_seg(x86_seg_cs, src.val, 1, , ctxt, ops)) ||
  (rc = commit_far_branch(, dst.val)) )
 goto done;
 break;
-}
 
 case 0xcc: /* int3 */
 src.val = EXC_BP;



x86emul: introduce SrcImm16

... and use it for RET, LRET, and ENTER processing to limit the amount
of "manual" insn bytes fetching. Note that for the RET and LRET paths
the change utilizes that SrcImplicit (aka SrcNone) table entries leave
src.val as zero.

Signed-off-by: Jan Beulich 
Reviewed-by: Andrew Cooper 

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -39,6 +39,7 @@
 #define SrcMem16(4<<3) /* Memory operand (16-bit). */
 #define SrcImm  (5<<3) /* Immediate operand. */
 #define SrcImmByte  (6<<3) /* 8-bit sign-extended immediate operand. */
+#define SrcImm16(7<<3) /* 16-bit zero-extended immediate operand. */
 #define SrcMask (7<<3)
 /* Generic ModRM decode. */
 #define ModRM   (1<<6)
@@ -143,11 +144,11 @@ static uint8_t opcode_table[256] = {
 DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov, DstReg|SrcImm|Mov,
 /* 0xC0 - 0xC7 */
 ByteOp|DstMem|SrcImm|ModRM, DstMem|SrcImmByte|ModRM,
-ImplicitOps, ImplicitOps,
+DstImplicit|SrcImm16, ImplicitOps,
 DstReg|SrcMem|ModRM|Mov, DstReg|SrcMem|ModRM|Mov,
 ByteOp|DstMem|SrcImm|ModRM|Mov, DstMem|SrcImm|ModRM|Mov,
 /* 0xC8 - 0xCF */
-

[Xen-devel] [PATCH v2 1/2] x86emul: fold SrcImmByte fetching

[Jan Beulich]

There's no need for having identical code spelled out twice.

Signed-off-by: Jan Beulich 
---
v2: Add braces (with quite a bit of reluctance).

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1979,9 +1979,14 @@ x86_emulate(
 goto done;
 break;
 case SrcImm:
+if ( !(d & ByteOp) )
+src.bytes = op_bytes != 8 ? op_bytes : 4;
+else
+{
+case SrcImmByte:
+src.bytes = 1;
+}
 src.type  = OP_IMM;
-src.bytes = (d & ByteOp) ? 1 : op_bytes;
-if ( src.bytes == 8 ) src.bytes = 4;
 /* NB. Immediates are sign-extended as necessary. */
 switch ( src.bytes )
 {
@@ -1990,11 +1995,6 @@ x86_emulate(
 case 4: src.val = insn_fetch_type(int32_t); break;
 }
 break;
-case SrcImmByte:
-src.type  = OP_IMM;
-src.bytes = 1;
-src.val   = insn_fetch_type(int8_t);
-break;
 }
 
 /* Decode and fetch the destination operand: register or memory. */



x86emul: fold SrcImmByte fetching

There's no need for having identical code spelled out twice.

Signed-off-by: Jan Beulich 
---
v2: Add braces (with quite a bit of reluctance).

--- a/xen/arch/x86/x86_emulate/x86_emulate.c
+++ b/xen/arch/x86/x86_emulate/x86_emulate.c
@@ -1979,9 +1979,14 @@ x86_emulate(
 goto done;
 break;
 case SrcImm:
+if ( !(d & ByteOp) )
+src.bytes = op_bytes != 8 ? op_bytes : 4;
+else
+{
+case SrcImmByte:
+src.bytes = 1;
+}
 src.type  = OP_IMM;
-src.bytes = (d & ByteOp) ? 1 : op_bytes;
-if ( src.bytes == 8 ) src.bytes = 4;
 /* NB. Immediates are sign-extended as necessary. */
 switch ( src.bytes )
 {
@@ -1990,11 +1995,6 @@ x86_emulate(
 case 4: src.val = insn_fetch_type(int32_t); break;
 }
 break;
-case SrcImmByte:
-src.type  = OP_IMM;
-src.bytes = 1;
-src.val   = insn_fetch_type(int8_t);
-break;
 }
 
 /* Decode and fetch the destination operand: register or memory. */
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

[Wei Liu]

On Fri, Aug 12, 2016 at 08:51:14AM -0600, Tamas K Lengyel wrote:
> On Aug 12, 2016 05:24, "Julien Grall"  wrote:
> >
> > Hello Tamas,
> >
> >
> > On 10/08/2016 17:00, Tamas K Lengyel wrote:
> >>
> >> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> >> index ef614be..97948fd 100644
> >> --- a/tools/libxl/libxl_types.idl
> >> +++ b/tools/libxl/libxl_types.idl
> >> @@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [
> >>  ("policy",  libxl_rdm_reserve_policy),
> >>  ])
> >>
> >> +# Consistent with the values defined for HVM_PARAM_ALTP2M
> >> +libxl_altp2m_mode = Enumeration("altp2m_mode", [
> >> +(0, "disabled"),
> >> +(1, "mixed"),
> >> +(2, "external_only"),
> >> +], init_val = "LIBXL_ALTP2M_MODE_DISABLED")
> >> +
> >>  libxl_domain_build_info = Struct("domain_build_info",[
> >>  ("max_vcpus",   integer),
> >>  ("avail_vcpus", libxl_bitmap),
> >> @@ -512,7 +519,7 @@ libxl_domain_build_info =
> Struct("domain_build_info",[
> >> ("mmio_hole_memkb",  MemKB),
> >> ("timer_mode",
>  libxl_timer_mode),
> >> ("nested_hvm",
>  libxl_defbool),
> >> -   ("altp2m",
>  libxl_defbool),
> >> +   ("altp2m",
>  libxl_altp2m_mode),
> >
> >
> > Should we move altp2m directly outside of the structure "hvm" to avoid
> yet another change when altp2m will be supported on ARM? (see [1])
> >
> > Regards,
> >
> > [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00147.html
> >
> > --
> > Julien Grall
> 
> Hi Julien,
> We can do that here if preferred by the tools maintainers though I'm on the
> opinion that it should be adjusted in the ARM altp2m series once it
> actually becomes available there.
> 

I agree. We shouldn't mix things together.

Wei.

> Tamas

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

Re: [Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

[Andrew Cooper]

On 12/08/16 15:47, Jan Beulich wrote:
> Besides being more logical this also allows verifying correct recording
> of alignments in .o files.
>
> The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
> value (as it now verifies correct tool chain behavior), but I've left
> it in nevertheless.
>
> Signed-off-by: Jan Beulich 
>
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re
>   */
>  #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
>  unsigned long __section(".bss.page_aligned")
> +__attribute__((aligned(PAGE_SIZE)))

Can I talk you into introducing #define __aligned(x)
__attribute__((aligned(x))) in compiler.h ?

Otherwise, Reviewed-by: Andrew Cooper 

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

Re: [Xen-devel] [Very RFC PATCH 3/3] livepatch: Initial ARM32/64 support.

[Julien Grall]

Hi Konrad,

On 09/08/2016 06:19, Konrad Rzeszutek Wilk wrote:

The initial support for ARM64 - and livepatching
works:


As it is a very RFC I only gave a quick look. I have few comments on it 
(see below).




(XEN) livepatch: xen_hello_world: Applying 1 functions
(XEN) hi_func: Hi! (called 1 times)
(XEN) Hook executing.
(XEN) livepatch: xen_hello_world finished APPLY with rc=0
(XEN) livepatch.c:1687: livepatch: load_payload_fnc: rc=0 (p->rc=0)
(XEN) livepatch: Hello World
(XEN) 'x' pressed - Dumping all livepatch patches
(XEN) build-id: e144bafc4ee8635eee5bed8e3988b484765c46c8
(XEN)  name=xen_hello_world state=APPLIED(2) 00318000 
(.data=00319000, .rodata=0031a000) using 3 pages.
(XEN) xen_extra_version patch 00233fac(12) with 00318000 
(16)
(XEN) build-id=c4b842c276be43adbe4db788598b1e11bce04dc6
(XEN) depend-on=9affa110481e8e13606c61b21e5f6a357a3c8ef9

ARM32 still has some issues.

The are some TODOs left to be done:

General:
- Bubble ALT_ORIG_PTR macro for both x86/ARM.
- Unify the ELF RELA checks - they are the same on x86/ARM[32,64].
- Makefile generating .livepatch.depends needs to ingest the
 -O argument based on architecture
- Test cases should move to common/ ? [Needs Jan's Ack]


In general, I would be in favor of sharing as much as possible the code.


ARM32 issues:
- vm_init_type: Assertion 'is_xen_heap_mfn(ma >> PAGE_SHIFT)' failed at 
xen/include/asm/mm.h:23


xen/include/asm/mm.h:23 points to the beginning of struct page_info. Did 
you mean to write instead 233?


This would point to maddr_virt. This would mean someone is trying to get 
the virtual address of MFN that is not in the xenheap (only the xenheap 
is mapped on ARM32). Do you have the full call stack?


[...]



Signed-off-by: Konrad Rzeszutek Wilk 


[...]


diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index aba1320..67749ed 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -6,66 +6,100 @@
 #include 
 #include 
 #include 
+#include 
+#include "livepatch.h"
+
+#include 
+
+void *vmap_of_xen_text;

 void arch_livepatch_quiesce(void)
 {
+mfn_t text_mfn;
+unsigned int text_order;
+
+if ( vmap_of_xen_text )
+return;
+
+text_mfn = _mfn(virt_to_mfn(_stext));
+text_order = get_order_from_bytes(_end - _start);
+
+/*
+ * The text section is read-only. So re-map Xen to be able to patch
+ * the code.
+ */
+vmap_of_xen_text = __vmap(_mfn, 1 << text_order, 1, 1, 
PAGE_HYPERVISOR,
+  VMAP_DEFAULT);


Shouldn't we return an error if we fail to re-map the region?

Otherwise the patch may silently be ignored (see arch_livepatch_apply_jmp).


 }

 void arch_livepatch_revive(void)
 {
+/* Nuke the instruction cache */
+invalidate_icache();


I was about to say that this is not enough. But you called 
clean_and_invalidate_* every time you rewrite the jump. It might be 
worth to add a comment here, explain that the cache has been cleaned 
before hand.


However, I can't find any data cache flush for the payload. Did I miss 
anything?


Lastly, before I forgot, you will need to invalidate the branch 
predictor for ARMv7 as it may be architecturally visible to the software 
(see B2.2.4 in ARM DDI 0406C.b).



+
+if ( vmap_of_xen_text )
+vunmap(vmap_of_xen_text);
+
+vmap_of_xen_text = NULL;
 }

 int arch_livepatch_verify_func(const struct livepatch_func *func)
 {
-return -ENOSYS;
-}
+/* No NOP patching yet. */
+if ( !func->new_size )
+return -EOPNOTSUPP;

-void arch_livepatch_apply_jmp(struct livepatch_func *func)
-{
-}
+if ( func->old_size < PATCH_INSN_SIZE )
+return -EINVAL;

-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
-{
+return 0;
 }

 void arch_livepatch_post_action(void)
 {
+/* arch_livepatch_revive has nuked the instruction cache. */
 }

 void arch_livepatch_mask(void)
 {
+/* TODO: No NMI on ARM? */


All interrupts can be masked on ARM so far. Although, local_irq_disable 
will only mask IRQ (i.e interrupt from the interrupt controller).


We may want to mask SError (System Error) via 
local_abort_{disable,enable} to avoid receiving asynchronous abort 
whilst patching Xen. The interrupt will stay pending until it will be 
re-enabled in arch_livepatch_unmask.



 }

 void arch_livepatch_unmask(void)
 {
+/* TODO: No NMI on ARM? */
 }

-int arch_livepatch_verify_elf(const struct livepatch_elf *elf)
+int arch_livepatch_secure(const void *va, unsigned int pages, enum va_type 
type)
 {
-return -ENOSYS;
-}
+unsigned long start = (unsigned long)va;
+unsigned int flags;

-int arch_livepatch_perform_rel(struct livepatch_elf *elf,
-   const struct livepatch_elf_sec *base,
-   const struct livepatch_elf_sec *rela)
-{
-return -ENOSYS;
-}
+ASSERT(va);
+ASSERT(pages);

-int 

[Xen-devel] [PATCH v2 0/2] x86emul: remaining misc small adjustments

[Jan Beulich]

1: fold SrcImmByte fetching
2: introduce SrcImm16

Signed-off-by: Jan Beulich 



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

[Xen-devel] [xen-unstable baseline-only test] 66968: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66968 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66968/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-rumpuserxen6 xen-buildfail   like 66957
 build-amd64-rumpuserxen   6 xen-buildfail   like 66957
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66957
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66957

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-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-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass

version targeted for testing:
 xen  7f5c8075364776eb139bbd421ad443ae9e4465dc
baseline version:
 xen  8e370ef503e8df249c3e3dd2ea17b3f100d4f20a

Last test of basis66957  2016-08-09 20:48:30 Z2 days
Testing same since66968  2016-08-11 03:48:07 Z1 days1 attempts


People who touched revisions under test:
  George Dunlap 
  Wei Liu 

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-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev 

Re: [Xen-devel] Unable to add disk on ARM64

[Roger Pau Monné]

On Fri, Aug 12, 2016 at 03:00:34PM +0200, Julien Grall wrote:
> On 12/08/2016 14:24, Peng Fan wrote:
> > Hi,
> 
> Hello Peng,
> 
> I have CCed Roger who is more familiar than me with the hotplug scripts.
> 
> > I am using xen master branch on i.MX8 ARM64.
> > 
> > My xl configuration:
> > 
> > kernel = "/root/xen/Image"
> > memory = "128"
> > name = "DomU"
> > vcpus = 1
> > serial="pty"
> > disk = [ 'phy:/dev/loop0,xvda,w' ]
> > extra = "console=hvc0 root=/dev/xvda debug=/bin/sh"
> > 
> > 
> > And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux.
> > 
> > But I met the following error:
> > libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to 
> > execute: /etc/xen/scripts/block add ^M^M
> > Device /dev/loop0 is mounted in the privileged domain,^M^M
> > and so cannot be mounted by a guest.^M^M
> > libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
> > /etc/xen/scripts/block add [800] exited with error status 1^M^M
> > libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch 
> > w=0xfee100: deregister unregistered^M^M
> > libxl: error: libxl_devi
> > ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is 
> > mounted in the privileged domain,^M^M
> > and so cannot be mounted by a guest.^M^M
> 
> From my understanding, you have mounted /dev/loop0 in Dom0, is that correct?
> However, we don't support sharing the same mounting point by default (Roger
> can you confirm).

It seems like the hotplug script has detected that you have the device 
already attached to Dom0, can you paste the output of `xenstore-ls -fp` 
when this happens?
 
It could be that there's some garbage in xenstore from a device that hasn't 
been properly detached.

Roger.

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

Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

[Tamas K Lengyel]

On Aug 12, 2016 05:24, "Julien Grall"  wrote:
>
> Hello Tamas,
>
>
> On 10/08/2016 17:00, Tamas K Lengyel wrote:
>>
>> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
>> index ef614be..97948fd 100644
>> --- a/tools/libxl/libxl_types.idl
>> +++ b/tools/libxl/libxl_types.idl
>> @@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [
>>  ("policy",  libxl_rdm_reserve_policy),
>>  ])
>>
>> +# Consistent with the values defined for HVM_PARAM_ALTP2M
>> +libxl_altp2m_mode = Enumeration("altp2m_mode", [
>> +(0, "disabled"),
>> +(1, "mixed"),
>> +(2, "external_only"),
>> +], init_val = "LIBXL_ALTP2M_MODE_DISABLED")
>> +
>>  libxl_domain_build_info = Struct("domain_build_info",[
>>  ("max_vcpus",   integer),
>>  ("avail_vcpus", libxl_bitmap),
>> @@ -512,7 +519,7 @@ libxl_domain_build_info =
Struct("domain_build_info",[
>> ("mmio_hole_memkb",  MemKB),
>> ("timer_mode",
 libxl_timer_mode),
>> ("nested_hvm",
 libxl_defbool),
>> -   ("altp2m",
 libxl_defbool),
>> +   ("altp2m",
 libxl_altp2m_mode),
>
>
> Should we move altp2m directly outside of the structure "hvm" to avoid
yet another change when altp2m will be supported on ARM? (see [1])
>
> Regards,
>
> [1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00147.html
>
> --
> Julien Grall

Hi Julien,
We can do that here if preferred by the tools maintainers though I'm on the
opinion that it should be adjusted in the ARM altp2m series once it
actually becomes available there.

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

[Xen-devel] [PATCH 2/2] x86/EFI: use less crude way of generating the build ID

[Jan Beulich]

Recent enough binutils support --build-id also for COFF/PE output, and
hence we should use that in favor of the original hack when possible.

This gets complicated by the linker requiring at least one COFF object
file to attach the .buildid section to. Hence the patch introduces a
buildid.ihex (in order to avoid introducing binary files into the repo)
which then gets converted to a binary minimal COFF object (no sections,
no symbols).

Also (to avoid both code fragment going out of sync) remove an unneeded
ALIGN() from xen.lds.S: Adding an equivalent of it to the .buildid
section would cause the _erodata symbol to become associated with the
wrong section again (see commit 0970299de5 ["x86/EFI + Live Patch:
avoid symbol address truncation"]). And it's pointless because the
alignment already gets properly set by the input section(s).

Signed-off-by: Jan Beulich 
---
Question of course is whether consumers of the build ID other than Xen
itself need to be taught how to find it in an EFI binary.

--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -158,24 +158,30 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(N
 $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A 
ALT_START$$,,p')
 # Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
 $(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
+
 ifneq ($(build_id_linker),)
-$(TARGET).efi: note.o
+ifeq ($(call ld-ver-build-id,$(LD) $(EFI_LDFLAGS)),y)
+CFLAGS += -DBUILD_ID_EFI
+EFI_LDFLAGS += $(build_id_linker)
+note_file := efi/buildid.o
+else
 note_file := note.o
+endif
 else
 note_file :=
 endif
 
-$(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o 
$(BASEDIR)/common/symbols-dummy.o efi/mkreloc
+$(TARGET).efi: prelink-efi.o $(note_file) efi.lds efi/relocs-dummy.o 
$(BASEDIR)/common/symbols-dummy.o efi/mkreloc
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
  $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< 
efi/relocs-dummy.o \
-   $(BASEDIR)/common/symbols-dummy.o -o 
$(@D)/.$(@F).$(base).0 &&) :
+   $(BASEDIR)/common/symbols-dummy.o $(note_file) -o 
$(@D)/.$(@F).$(base).0 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).0) >$(@D)/.$(@F).0r.S
$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).0 \
| $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv 
--sort >$(@D)/.$(@F).0s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0r.o 
$(@D)/.$(@F).0s.o
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
  $(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< \
-   $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o -o 
$(@D)/.$(@F).$(base).1 &&) :
+   $(@D)/.$(@F).0r.o $(@D)/.$(@F).0s.o $(note_file) -o 
$(@D)/.$(@F).$(base).1 &&) :
$(guard) efi/mkreloc $(foreach base,$(VIRT_BASE) 
$(ALT_BASE),$(@D)/.$(@F).$(base).1) >$(@D)/.$(@F).1r.S
$(guard) $(NM) -pa --format=sysv $(@D)/.$(@F).$(VIRT_BASE).1 \
| $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv 
--sort >$(@D)/.$(@F).1s.S
@@ -185,8 +191,8 @@ $(TARGET).efi: prelink-efi.o efi.lds efi
if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
rm -f $(@D)/.$(@F).[0-9]*
 
-efi/boot.init.o efi/runtime.o efi/compat.o: $(BASEDIR)/arch/x86/efi/built_in.o
-efi/boot.init.o efi/runtime.o efi/compat.o: ;
+efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: 
$(BASEDIR)/arch/x86/efi/built_in.o
+efi/boot.init.o efi/runtime.o efi/compat.o efi/buildid.o: ;
 
 asm-offsets.s: $(TARGET_SUBARCH)/asm-offsets.c
$(CC) $(filter-out -flto,$(CFLAGS)) -S -o $@ $<
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -9,6 +9,9 @@ efi := $(if $(efi),$(shell $(CC) $(filte
 efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 
2>disabled && echo y))
 efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); 
$(call create,runtime.o)))
 
-extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
+extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o buildid.o
+
+%.o: %.ihex
+   $(OBJCOPY) -I ihex -O binary $< $@
 
 stub.o: $(extra-y)
--- /dev/null
+++ b/xen/arch/x86/efi/buildid.ihex
@@ -0,0 +1,3 @@
+:100064864D8DAD57140014
+:04001000EC
+:0001FF
--- a/xen/arch/x86/efi/mkreloc.c
+++ b/xen/arch/x86/efi/mkreloc.c
@@ -342,6 +342,7 @@ int main(int argc, char *argv[])
  */
 if ( memcmp(sec1[i].name, ".initcal", sizeof(sec1[i].name)) == 0 ||
  memcmp(sec1[i].name, ".init.se", sizeof(sec1[i].name)) == 0 ||
+ memcmp(sec1[i].name, ".buildid", sizeof(sec1[i].name)) == 0 ||
  memcmp(sec1[i].name, ".lockpro", sizeof(sec1[i].name)) == 0 )
 continue;
 
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -91,7 +91,7 @@ 

[Xen-devel] [PATCH 2/2] make use of .startof.() and .sizeof.() assembler expressions

[Jan Beulich]

Section start symbols frequently obscure the actual symbol name living
at the start of the section. Eliminate them where they can be replaced
by linker resolved .startof.* symbols. (Section end symbols may have
the same undesirable effect, but they're less easy to eliminate, as
they'd need to be represented by the sum of .startof. and
.sizeof.).

Along those lines use .sizeof.* where section sizes get calculated
from the difference of section and and section start symbols.

Note that this would be nice for the build-id section too, but:
- The generated (by ld) section names differ between ELF and COFF/PE
  (ELF: .note.gnu.build-id; COFF/PE[2.26+]: .buildid), yet we compile
  version.c just once (and hence can use only either of the necessary
  .startof./.sizeof. forms).
- The ELF section name needs to be quoted in the .startof./.sizeof.
  expressions, yet that quoting is supported only by gas 2.26+.

Signed-off-by: Jan Beulich 

--- a/xen/arch/arm/arm32/head.S
+++ b/xen/arch/arm/arm32/head.S
@@ -184,10 +184,10 @@ hyp:PRINT("- Xen starting in Hyp mod
 bne   skip_bss
 
 PRINT("- Zero BSS -\r\n")
-ldr   r0, =__bss_start   /* Load start & end of bss */
-ldr   r1, =__bss_end
+ldr   r0, =.startof.(.bss)   /* Load start & size of bss */
+ldr   r1, =.sizeof.(.bss)
 add   r0, r0, r10/* Apply physical offset */
-add   r1, r1, r10
+add   r1, r1, r0 /* Calculate end of bss */
 
 mov   r2, #0
 1:  str   r2, [r0], #4
--- a/xen/arch/arm/arm64/head.S
+++ b/xen/arch/arm/arm64/head.S
@@ -318,10 +318,10 @@ el2:PRINT("- Xen starting at EL2 -\r
 cbnz  x22, skip_bss
 
 PRINT("- Zero BSS -\r\n")
-ldr   x0, =__bss_start   /* Load start & end of bss */
-ldr   x1, =__bss_end
+ldr   x0, =.startof.(.bss)   /* Load start & size of bss */
+ldr   x1, =.sizeof.(.bss)
 add   x0, x0, x20/* Apply physical offset */
-add   x1, x1, x20
+add   x1, x1, x0 /* Calculate end of .bss */
 
 1:  str   xzr, [x0], #8
 cmp   x0, x1
--- a/xen/arch/arm/device.c
+++ b/xen/arch/arm/device.c
@@ -21,8 +21,8 @@
 #include 
 #include 
 
-extern const struct device_desc _sdevice[], _edevice[];
-extern const struct acpi_device_desc _asdevice[], _aedevice[];
+extern const struct device_desc _sdevice[] asm(".startof.(.dev.info)");
+extern const struct device_desc _edevice[];
 
 int __init device_init(struct dt_device_node *dev, enum device_class class,
const void *data)
@@ -51,6 +51,11 @@ int __init device_init(struct dt_device_
 return -EBADF;
 }
 
+#ifdef CONFIG_ACPI
+
+extern const struct acpi_device_desc _asdevice[] asm(".startof.(.adev.info)");
+extern const struct acpi_device_desc _aedevice[];
+
 int __init acpi_device_init(enum device_class class, const void *data, int 
class_type)
 {
 const struct acpi_device_desc *desc;
@@ -68,6 +73,8 @@ int __init acpi_device_init(enum device_
 return -EBADF;
 }
 
+#endif
+
 enum device_class device_get_class(const struct dt_device_node *dev)
 {
 const struct device_desc *desc;
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -2058,7 +2058,7 @@ static void __init find_gnttab_region(st
  * enough space for a large grant table
  */
 kinfo->gnttab_start = __pa(_stext);
-kinfo->gnttab_size = (_etext - _stext) & PAGE_MASK;
+kinfo->gnttab_size = _sizeof_text & PAGE_MASK;
 
 /* Make sure the grant table will fit in the region */
 if ( (kinfo->gnttab_size >> PAGE_SHIFT) < max_grant_frames )
--- a/xen/arch/arm/platform.c
+++ b/xen/arch/arm/platform.c
@@ -22,7 +22,8 @@
 #include 
 #include 
 
-extern const struct platform_desc _splatform[], _eplatform[];
+extern const struct platform_desc _splatform[] asm(".startof.(.arch.info)");
+extern const struct platform_desc _eplatform[];
 
 /* Pointer to the current platform description */
 static const struct platform_desc *platform;
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -31,7 +31,6 @@ SECTIONS
   . = XEN_VIRT_START;
   _start = .;
   .text : /* XXX should be AT ( XEN_PHYS_START ) */ {
-_stext = .;/* Text section */
*(.text)
*(.text.cold)
*(.text.unlikely)
@@ -42,7 +41,6 @@ SECTIONS
 
   . = ALIGN(PAGE_SIZE);
   .rodata : {
-_srodata = .;  /* Read-only data */
 /* Bug frames table */
__start_bug_frames = .;
*(.bug_frames.0)
@@ -104,21 +102,18 @@ SECTIONS
 
   . = ALIGN(8);
   .arch.info : {
-  _splatform = .;
   *(.arch.info)
   _eplatform = .;
   } :text
 
   . = ALIGN(8);
   .dev.info : {
-  _sdevice = .;
   *(.dev.info)
   _edevice = .;
   } :text
 
   . = ALIGN(8);
   .adev.info : {
-  _asdevice = .;
   *(.adev.info)
   _aedevice = .;
   } :text
@@ -126,7 +121,6 @@ SECTIONS
   . = ALIGN(PAGE_SIZE); 

[Xen-devel] [PATCH 1/2] x86: force suitable alignment in sources rather than in linker script

[Jan Beulich]

Besides being more logical this also allows verifying correct recording
of alignments in .o files.

The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
value (as it now verifies correct tool chain behavior), but I've left
it in nevertheless.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re
  */
 #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
 unsigned long __section(".bss.page_aligned")
+__attribute__((aligned(PAGE_SIZE)))
 hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
 
 /* Xen command-line option to enable HAP */
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -125,7 +125,8 @@
 #include 
 
 /* Mapping of the fixmap space needed early. */
-l1_pgentry_t __section(".bss.page_aligned") l1_fixmap[L1_PAGETABLE_ENTRIES];
+l1_pgentry_t __section(".bss.page_aligned") __attribute__((aligned(PAGE_SIZE)))
+l1_fixmap[L1_PAGETABLE_ENTRIES];
 
 #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING , _f "\n" , ## _a)
 
@@ -588,7 +589,8 @@ static inline void guest_get_eff_kern_l1
 TOGGLE_MODE();
 }
 
-const char __section(".bss.page_aligned.const") zero_page[PAGE_SIZE];
+const char __section(".bss.page_aligned.const")
+__attribute__((aligned(PAGE_SIZE))) zero_page[PAGE_SIZE];
 
 static void invalidate_shadow_ldt(struct vcpu *v, int flush)
 {
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -105,7 +105,8 @@ unsigned long __read_mostly xen_virt_end
 
 DEFINE_PER_CPU(struct tss_struct, init_tss);
 
-char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
+char __section(".bss.stack_aligned") __attribute__((aligned(STACK_SIZE)))
+cpu0_stack[STACK_SIZE];
 
 struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 };
 
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -222,7 +222,6 @@ SECTIONS
   } :text
 
   .data : {/* Data */
-   . = ALIGN(PAGE_SIZE);
*(.data.page_aligned)
*(.data)
*(.data.rel)
@@ -231,10 +230,8 @@ SECTIONS
   } :text
 
   .bss : { /* BSS */
-   . = ALIGN(STACK_SIZE);
__bss_start = .;
*(.bss.stack_aligned)
-   . = ALIGN(PAGE_SIZE);
*(.bss.page_aligned*)
*(.bss)
. = ALIGN(SMP_CACHE_BYTES);



x86: force suitable alignment in sources rather than in linker script

Besides being more logical this also allows verifying correct recording
of alignments in .o files.

The cpu0_stack related ASSERT() in xen.lds.S is now of questionable
value (as it now verifies correct tool chain behavior), but I've left
it in nevertheless.

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -89,6 +89,7 @@ struct hvm_function_table hvm_funcs __re
  */
 #define HVM_IOBITMAP_SIZE (3 * PAGE_SIZE)
 unsigned long __section(".bss.page_aligned")
+__attribute__((aligned(PAGE_SIZE)))
 hvm_io_bitmap[HVM_IOBITMAP_SIZE / BYTES_PER_LONG];
 
 /* Xen command-line option to enable HAP */
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -125,7 +125,8 @@
 #include 
 
 /* Mapping of the fixmap space needed early. */
-l1_pgentry_t __section(".bss.page_aligned") l1_fixmap[L1_PAGETABLE_ENTRIES];
+l1_pgentry_t __section(".bss.page_aligned") __attribute__((aligned(PAGE_SIZE)))
+l1_fixmap[L1_PAGETABLE_ENTRIES];
 
 #define MEM_LOG(_f, _a...) gdprintk(XENLOG_WARNING , _f "\n" , ## _a)
 
@@ -588,7 +589,8 @@ static inline void guest_get_eff_kern_l1
 TOGGLE_MODE();
 }
 
-const char __section(".bss.page_aligned.const") zero_page[PAGE_SIZE];
+const char __section(".bss.page_aligned.const")
+__attribute__((aligned(PAGE_SIZE))) zero_page[PAGE_SIZE];
 
 static void invalidate_shadow_ldt(struct vcpu *v, int flush)
 {
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -105,7 +105,8 @@ unsigned long __read_mostly xen_virt_end
 
 DEFINE_PER_CPU(struct tss_struct, init_tss);
 
-char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
+char __section(".bss.stack_aligned") __attribute__((aligned(STACK_SIZE)))
+cpu0_stack[STACK_SIZE];
 
 struct cpuinfo_x86 __read_mostly boot_cpu_data = { 0, 0, 0, 0, -1 };
 
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -222,7 +222,6 @@ SECTIONS
   } :text
 
   .data : {/* Data */
-   . = ALIGN(PAGE_SIZE);
*(.data.page_aligned)
*(.data)
*(.data.rel)
@@ -231,10 +230,8 @@ SECTIONS
   } :text
 
   .bss : { /* BSS */
-   . = ALIGN(STACK_SIZE);
__bss_start = .;
*(.bss.stack_aligned)
-   . = ALIGN(PAGE_SIZE);
*(.bss.page_aligned*)
*(.bss)
. = ALIGN(SMP_CACHE_BYTES);
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 1/2] build-id: fix minor quirks

[Jan Beulich]

The initial size check in xen_build_id_check() came too late (after the
first access to the structure), but was mostly redundant with checks
done in all callers; convert it to a properly placed ASSERT(). The
"mostly" part being addressed too: xen_build_init() was off by one.

And then there was a stray semicolon.

Signed-off-by: Jan Beulich 

--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -90,12 +91,11 @@ int xen_build_id_check(const Elf_Note *n
const void **p, unsigned int *len)
 {
 /* Check if we really have a build-id. */
+ASSERT(n_sz > sizeof(*n));
+
 if ( NT_GNU_BUILD_ID != n->type )
 return -ENODATA;
 
-if ( n_sz <= sizeof(*n) )
-return -EINVAL;
-
 if ( n->namesz + n->descsz < n->namesz )
 return -EINVAL;
 
@@ -127,8 +127,8 @@ static int __init xen_build_init(void)
 return -ENODATA;
 
 /* Check for full Note header. */
-if ( [1] > __note_gnu_build_id_end )
-return -ENODATA;;
+if ( [1] >= __note_gnu_build_id_end )
+return -ENODATA;
 
 sz = (void *)__note_gnu_build_id_end - (void *)n;
 



build-id: fix minor quirks

The initial size check in xen_build_id_check() came too late (after the
first access to the structure), but was mostly redundant with checks
done in all callers; convert it to a properly placed ASSERT(). The
"mostly" part being addressed too: xen_build_init() was off by one.

And then there was a stray semicolon.

Signed-off-by: Jan Beulich 

--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -1,6 +1,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -90,12 +91,11 @@ int xen_build_id_check(const Elf_Note *n
const void **p, unsigned int *len)
 {
 /* Check if we really have a build-id. */
+ASSERT(n_sz > sizeof(*n));
+
 if ( NT_GNU_BUILD_ID != n->type )
 return -ENODATA;
 
-if ( n_sz <= sizeof(*n) )
-return -EINVAL;
-
 if ( n->namesz + n->descsz < n->namesz )
 return -EINVAL;
 
@@ -127,8 +127,8 @@ static int __init xen_build_init(void)
 return -ENODATA;
 
 /* Check for full Note header. */
-if ( [1] > __note_gnu_build_id_end )
-return -ENODATA;;
+if ( [1] >= __note_gnu_build_id_end )
+return -ENODATA;
 
 sz = (void *)__note_gnu_build_id_end - (void *)n;
 
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[Xen-devel] [PATCH 0/2] eliminate some section start symbols

[Jan Beulich]

Section start symbols frequently obscure the actual symbol name living
at the start of the section. Eliminate them where they can be replaced
by linker resolved .startof.* symbols. (Section end symbols may have
the same undesirable effect, but they're less easy to eliminate, as
they'd need to be represented by the sum of .startof. and
.sizeof.).

1: x86: force suitable alignment in sources rather than in linker script
2: make use of .startof.() and .sizeof.() assembler expressions

Signed-off-by: Jan Beulich 


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

[Xen-devel] [PATCH 0/2] build-id adjustments

[Jan Beulich]

1: build-id: fix minor quirks
2: x86/EFI: use less crude way of generating the build ID

Signed-off-by: Jan Beulich 


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

[Xen-devel] [ovmf test] 100452: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 62b8b5be713dd1f801cd44e4eb28f68585a9bd85
baseline version:
 ovmf 82df618711c596d3b6164e790572c795b7ea4dcc

Last test of basis   100433  2016-08-12 07:46:05 Z0 days
Testing same since   100452  2016-08-12 12:15:55 Z0 days1 attempts


People who touched revisions under test:
  Star Zeng 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=62b8b5be713dd1f801cd44e4eb28f68585a9bd85
+ . ./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 ovmf 
62b8b5be713dd1f801cd44e4eb28f68585a9bd85
+ branch=ovmf
+ revision=62b8b5be713dd1f801cd44e4eb28f68585a9bd85
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x62b8b5be713dd1f801cd44e4eb28f68585a9bd85 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'

Re: [Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON

[Samuel Thibault]

Wei Liu, on Fri 12 Aug 2016 15:01:07 +0100, wrote:
> BUILD_BUG_ON should not appear in a public-facing header, otherwise it
> risks clashing with macro with the same name in other code bases. I
> encountered such issue when trying to add BUILD_BUG_ON to a private
> header in Xen's gnttab library.
> 
> Ideally BUILD_BUG_ON should be moved to a private header, but there is
> actually no user of it in mini-os tree, just remove it.
> 
> Signed-off-by: Wei Liu 

Acked-by: Samuel Thibault 

> ---
>  include/lib.h | 9 -
>  1 file changed, 9 deletions(-)
> 
> diff --git a/include/lib.h b/include/lib.h
> index 39d6a18..e7155e2 100644
> --- a/include/lib.h
> +++ b/include/lib.h
> @@ -54,15 +54,6 @@
>  #include 
>  #include "gntmap.h"
>  
> -#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
> -#define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
> -#define BUILD_BUG_ON_ZERO(cond) \
> -sizeof(struct { _Static_assert(!(cond), "!(" #cond ")"); })
> -#else
> -#define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); })
> -#define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
> -#endif
> -
>  #ifdef HAVE_LIBC
>  #include 
>  #include 
> -- 
> 2.1.4
> 

-- 
Samuel
(03:13:14)  bon
(03:13:19)  il est tard :p
(03:13:25)  c'est l'heure de manger
(03:13:38)  hm j'ai mangé à 1h moi, j'ai des horaires raisonnables

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

[Xen-devel] [MINIOS PATCH] lib.h: remove BUILD_BUG_ON

[Wei Liu]

BUILD_BUG_ON should not appear in a public-facing header, otherwise it
risks clashing with macro with the same name in other code bases. I
encountered such issue when trying to add BUILD_BUG_ON to a private
header in Xen's gnttab library.

Ideally BUILD_BUG_ON should be moved to a private header, but there is
actually no user of it in mini-os tree, just remove it.

Signed-off-by: Wei Liu 
---
 include/lib.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/include/lib.h b/include/lib.h
index 39d6a18..e7155e2 100644
--- a/include/lib.h
+++ b/include/lib.h
@@ -54,15 +54,6 @@
 #include 
 #include "gntmap.h"
 
-#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6)
-#define BUILD_BUG_ON(cond) ({ _Static_assert(!(cond), "!(" #cond ")"); })
-#define BUILD_BUG_ON_ZERO(cond) \
-sizeof(struct { _Static_assert(!(cond), "!(" #cond ")"); })
-#else
-#define BUILD_BUG_ON_ZERO(cond) sizeof(struct { int:-!!(cond); })
-#define BUILD_BUG_ON(cond) ((void)BUILD_BUG_ON_ZERO(cond))
-#endif
-
 #ifdef HAVE_LIBC
 #include 
 #include 
-- 
2.1.4


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

[Xen-devel] [xen-unstable test] 100431: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-libvirt   5 libvirt-buildfail REGR. vs. 100424

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-xsm  7 host-ping-check-xenfail pass in 100424

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

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail in 100424 never pass
 test-amd64-amd64-libvirt12 migrate-support-check fail in 100424 never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail in 100424 never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail in 100424 never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 100424 never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail in 100424 never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-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
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 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-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 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-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  072e6709978143145a1c1b98c7f014dc4d87907f
baseline version:
 xen  072e6709978143145a1c1b98c7f014dc4d87907f

Last test of basis   100431  2016-08-12 07:34:23 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 17025 days0 attempts

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

Re: [Xen-devel] [V4 PATCH 2/2] mips/panic: Replace smp_send_stop() with kdump friendly version in panic path

[Corey Minyard]

I'll try to test this, but I have one comment inline...

On 08/11/2016 10:17 PM, Dave Young wrote:

On 08/10/16 at 05:09pm, Hidehiro Kawai wrote:

Daniel Walker reported problems which happens when
crash_kexec_post_notifiers kernel option is enabled
(https://lkml.org/lkml/2015/6/24/44).

In that case, smp_send_stop() is called before entering kdump routines
which assume other CPUs are still online.  As the result, kdump
routines fail to save other CPUs' registers.  Additionally for MIPS
OCTEON, it misses to stop the watchdog timer.

To fix this problem, call a new kdump friendly function,
crash_smp_send_stop(), instead of the smp_send_stop() when
crash_kexec_post_notifiers is enabled.  crash_smp_send_stop() is a
weak function, and it just call smp_send_stop().  Architecture
codes should override it so that kdump can work appropriately.
This patch provides MIPS version.

Reported-by: Daniel Walker 
Fixes: f06e5153f4ae (kernel/panic.c: add "crash_kexec_post_notifiers" option)
Signed-off-by: Hidehiro Kawai 
Cc: Ralf Baechle 
Cc: David Daney 
Cc: Aaro Koskinen 
Cc: "Steven J. Hill" 
Cc: Corey Minyard 

---
I'm not familiar with MIPS, and I don't have a test environment and
just did build tests only.  Please don't apply this patch until
someone does enough tests, otherwise simply drop this patch.
---
  arch/mips/cavium-octeon/setup.c  |   14 ++
  arch/mips/include/asm/kexec.h|1 +
  arch/mips/kernel/crash.c |   18 +-
  arch/mips/kernel/machine_kexec.c |1 +
  4 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/arch/mips/cavium-octeon/setup.c b/arch/mips/cavium-octeon/setup.c
index cb16fcc..5537f95 100644
--- a/arch/mips/cavium-octeon/setup.c
+++ b/arch/mips/cavium-octeon/setup.c
@@ -267,6 +267,17 @@ static void octeon_crash_shutdown(struct pt_regs *regs)
default_machine_crash_shutdown(regs);
  }
  
+#ifdef CONFIG_SMP

+void octeon_crash_smp_send_stop(void)
+{
+   int cpu;
+
+   /* disable watchdogs */
+   for_each_online_cpu(cpu)
+   cvmx_write_csr(CVMX_CIU_WDOGX(cpu_logical_map(cpu)), 0);
+}
+#endif
+
  #endif /* CONFIG_KEXEC */
  
  #ifdef CONFIG_CAVIUM_RESERVE32

@@ -911,6 +922,9 @@ void __init prom_init(void)
_machine_kexec_shutdown = octeon_shutdown;
_machine_crash_shutdown = octeon_crash_shutdown;
_machine_kexec_prepare = octeon_kexec_prepare;
+#ifdef CONFIG_SMP
+   _crash_smp_send_stop = octeon_crash_smp_send_stop;
+#endif
  #endif
  
  	octeon_user_io_init();

diff --git a/arch/mips/include/asm/kexec.h b/arch/mips/include/asm/kexec.h
index ee25ebb..493a3cc 100644
--- a/arch/mips/include/asm/kexec.h
+++ b/arch/mips/include/asm/kexec.h
@@ -45,6 +45,7 @@ extern const unsigned char kexec_smp_wait[];
  extern unsigned long secondary_kexec_args[4];
  extern void (*relocated_kexec_smp_wait) (void *);
  extern atomic_t kexec_ready_to_reboot;
+extern void (*_crash_smp_send_stop)(void);
  #endif
  #endif
  
diff --git a/arch/mips/kernel/crash.c b/arch/mips/kernel/crash.c

index 610f0f3..1723b17 100644
--- a/arch/mips/kernel/crash.c
+++ b/arch/mips/kernel/crash.c
@@ -47,9 +47,14 @@ static void crash_shutdown_secondary(void *passed_regs)
  
  static void crash_kexec_prepare_cpus(void)

  {
+   static int cpus_stopped;
unsigned int msecs;
+   unsigned int ncpus;
  
-	unsigned int ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */

+   if (cpus_stopped)
+   return;


Wouldn't you want an atomic operation and some special handling here to
ensure that only one CPU does this?  So if a CPU comes in here and
another CPU is already in the process stopping the CPUs it won't result in a
deadlock.

-corey


+
+   ncpus = num_online_cpus() - 1;/* Excluding the panic cpu */
  
  	dump_send_ipi(crash_shutdown_secondary);

smp_wmb();
@@ -64,6 +69,17 @@ static void crash_kexec_prepare_cpus(void)
cpu_relax();
mdelay(1);
}
+
+   cpus_stopped = 1;
+}
+
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+   if (_crash_smp_send_stop)
+   _crash_smp_send_stop();
+
+   crash_kexec_prepare_cpus();
  }
  
  #else /* !defined(CONFIG_SMP)  */

diff --git a/arch/mips/kernel/machine_kexec.c b/arch/mips/kernel/machine_kexec.c
index 50980bf3..5972520 100644
--- a/arch/mips/kernel/machine_kexec.c
+++ b/arch/mips/kernel/machine_kexec.c
@@ -25,6 +25,7 @@ void (*_machine_crash_shutdown)(struct pt_regs *regs) = NULL;
  #ifdef CONFIG_SMP
  void (*relocated_kexec_smp_wait) (void *);
  atomic_t kexec_ready_to_reboot = ATOMIC_INIT(0);
+void (*_crash_smp_send_stop)(void) = NULL;
  #endif
  
  int




Can any mips people review this patch and have a test?

Thanks
Dave




___
Xen-devel 

[Xen-devel] dependences for backporting to 4.6 [was: Re: [PATCH 2/3] xen: Have schedulers revise initial placement]

[Jan Beulich]

>>> On 12.08.16 at 03:59,  wrote:
> On Fri, 2016-08-05 at 07:24 -0600, Jan Beulich wrote:
>> I'd really like to have those backported, but I have to ask one
>> of you to identify which prereq-s are needed on 4.6 and 4.5
>> (I'll revert them from 4.5 right away, but I'll wait for an osstest
>> flight to confirm the same issue exists on 4.6).
>>
> So, for 4.6, I think the only prerequisite would be this:
> 
> 6b53bb4ab3c9bd5eccde88a5175cf72589ba6d52
> "sched: better handle (not) inserting idle vCPUs in runqueues"
> 
> That, however, does not apply cleanly. The important part of it is the
> last hunk:
> 
> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> index 92057eb..c195129 100644
> --- a/xen/common/schedule.c
> +++ b/xen/common/schedule.c
> @@ -240,20 +240,22 @@ int sched_init_vcpu(struct vcpu *v, unsigned int 
> processor)
>  init_timer(>poll_timer, poll_timer_fn,
> v, v->processor);
>  
> -/* Idle VCPUs are scheduled immediately. */
> +v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
> +if ( v->sched_priv == NULL )
> +return 1;
> +
> +TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
> +
> +/* Idle VCPUs are scheduled immediately, so don't put them in runqueue. 
> */
>  if ( is_idle_domain(d) )
>  {
>  per_cpu(schedule_data, v->processor).curr = v;
>  v->is_running = 1;
>  }
> -
> -TRACE_2D(TRC_SCHED_DOM_ADD, v->domain->domain_id, v->vcpu_id);
> -
> -v->sched_priv = SCHED_OP(DOM2OP(d), alloc_vdata, v, d->sched_priv);
> -if ( v->sched_priv == NULL )
> -return 1;
> -
> -SCHED_OP(DOM2OP(d), insert_vcpu, v);
> +else
> +{
> +SCHED_OP(DOM2OP(d), insert_vcpu, v);
> +}
>  
>  return 0;
>  }
> 
> With this only applied, things works for me. The hunk is actually the
> core of the patch, the only real functionality change. The other hunks
> are refactoring and cleanups (made possible by it).
> 
> So, I'm not sure whether the best route here is:
>  - fully backport 6b53bb4ab3c9b;
>  - backport only the last hunk of 6b53bb4ab3c9b as its own patch;
>  - fold the last hunk of 6b53bb4ab3c9b in the backport of George's 
>patch (I mean, what was 83dff3992a89 in staging-4.6);
> 
> Thoughts?

First of all - thanks a lot for helping out here. With above extra
commit things are indeed back to normal again for me. Since the
adjustments to that commit to make it apply were mostly
mechanical, I think I'd prefer taking the entire backport. Same
for 4.5 then, were the backport adjusted for 4.6 then applied
cleanly.

Jan


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

Re: [Xen-devel] Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

[Konrad Rzeszutek Wilk]

On Thu, Aug 11, 2016 at 09:11:10AM +0100, Ross Lagerwall wrote:
> On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote:
> > Hey Ross,
> > 
> > I am running in a symbol dependency issue that I am not exactly
> > sure how to solve.
> > 
> > I have an payload that introduces a new function (xen_foobar) which
> > will patch over xen_extra_version().
> > 
> snip
> > 
> > As livepatch_symbols_lookup_by_name only looks for symbols that
> > have the ->new_symbol set. And xen_foobar does not. So the loading is
> > aborted.
> > 
> > Which makes sense - we don't want to match the symbols as they haven't
> > really been "finally loaded" in.
> > 
> > But what if the xen_foobar is applied. In that case we should
> > change the xen_foobar to be new_symbol=1?
> 
> I think you're confused about the purpose of new_symbol. The purpose is to
> ensure that you link against the correct symbol from the base hypervisor or
> the live patch that first introduced it. So, new_symbol=0 is when a symbol
> overrides an existing symbol. new_symbol=1 is set when a symbol is new

But it does not (overrides the existing symbol).

The patch (xen_foobar) introduces a new function called xen_foobar
which is patching xen_extra_version.

That is:

static char foobar_patch_this_fnc[] = "xen_extra_version";

struct livepatch_func __section(".livepatch.funcs") livepatch_xen_foobar = { 
.version = LIVEPATCH_PAYLOAD_VERSION,
.name = foobar_patch_this_fnc,
.new_addr = xen_foobar,
.old_addr = xen_extra_version,
.new_size = NEW_CODE_SZ,
.old_size = OLD_CODE_SZ,
};

> introduced in a live patch.

And this loop:

for ( j = 0; j < payload->nfuncs; j++ ) 
{   
if ( symtab[i].value == (unsigned long)payload->funcs[j].new_addr ) 
{   
found = 1;  
break;  
}   
}

Will force new_symbol=0 for xen_foobar.

> 
> Since all the linking happens during load and not apply, it is perfectly OK
> to link against a symbol that hasn't been applied -- the dependencies are
> there to ensure that you can't apply a patch which links against unapplied
> symbols.
> 
> The assumption is that when overriding an existing symbol, the symbol in the
> payload has the same name as the one it is overriding. You're having issues
> above because you're breaking this assumption.

Yes :-)

> 
> > 
> > This following patch does that, but I am wondering if there is a better
> > way?
> 
> The patch is misusing new_symbol for something completely different from how
> it was intended so I hope there is a better way :-P

Well for my use-case I think I can just s/xen_foobar/xen_extra_version/ and we
should be OK.

> Let's have a discussion about this and the symbol issues here at the Xen
> Summit in a couple of weeks time.

/me nods.
> 
> -- 
> Ross Lagerwall

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

[Xen-devel] [distros-debian-wheezy test] 66969: all pass

[Platform Team regression test user]

flight 66969 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66969/

Perfect :-)
All tests in this flight passed as required
baseline version:
 flight   66914

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-wheezy-netboot-pvgrub pass
 test-amd64-i386-i386-wheezy-netboot-pvgrub   pass
 test-amd64-i386-amd64-wheezy-netboot-pygrub  pass
 test-amd64-amd64-i386-wheezy-netboot-pygrub  pass



sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images

Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.


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

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

[Wei Liu]

On Fri, Aug 12, 2016 at 10:51:37AM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting 
> output"):
> > On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > > We don't care when xenconsoled closes the logfile.  We care about when
> > > it last calls write() (with a nonempty buffer).
> > 
> > In logfile mode, no console client is spawned, because it is not
> > reliable -- that's why we use logfile mode in the first place.
> > 
> > And I would rather just add a bodge (wait 1 or 2 seconds)
> 
> That would increase the duration of each test by that 1 or 2 seconds.
> I suppose you could conclude the logfile is complete if it contains
> the expected end-of-run message from the vm, and only poll if not.
> 
> But, it's worse:
> 
> I went to read the xenconsoled source code, and it can handle a domain
> death event before finishing reading all of the data out of a domain's
> ring.
> 
> Maybe this will be mitigated by XTF's printf waiting for the
> xenconsoled ring pointer to catch up ?
> 

I think so.

Under normal circumstance (micro VM doesn't crash), we're sure that all
output is consumed by xenconsoled before the VM shuts down itself.

> xenconsoled advances the ring pointer before writing to the logfile,
> but (assuming there's no overflow), the write will happen before it
> goes back into the event loop, so it won't be lost.
> 

Correct.

> > than to rely on sophisticated hack.
> 
> To my mind polling the logfile looking for the final message from the
> vm is something of a hack.
> 
> But indeed I can't see another way to wait for xenconsoled, than
> going behind libxl's back with something like
>  * spawn xl create -p -F
>  * look for the console tty in xenstore
>  * open the console tty
>  * unpause
>  * wait for the console tty to get eof
> 
> This is not a logfile mode at all, of course.  It probably wouldn't be
> easily adaptable to other toolstacks (eg XenServer).
> 

Andrew, what is your opinion?

Wei.

> Ian.

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

[Xen-devel] [PATCH] xl cpupool-numa-split: don't try to bring any dom0 vCPUs online

[Jonathan Davies]

Since commit a9dd01431a799b6743193a75f4f1ce2fdfdb7296, main_cpupoolnumasplit
wants to ensure that dom0 doesn't have more online vCPUs than the number of
pCPUs in a NUMA node.

However, if dom0 already has fewer online vCPUs than the number of pCPUs in a
NUMA node, this will cause some to be made online.

Furthermore, if dom0's maximum number of vCPUs is less than the number of pCPUs,
this will result in an error like the following:

libxl: error: libxl.c:5564:libxl_set_vcpuonline: Requested 24 VCPUs, 
however maxcpus is 12!: Function not implemented
error on removing vcpus for Domain-0

Instead, make main_cpupoolnumasplit only reduce the number of vCPUs dom0 has
online, and don't try to add any more.

This incurs an extra call to libxl_domain_info to find out the current number of
dom0 vCPUs. Conveniently, there is already an initialised libxl_dominfo that we
can use.

Signed-off-by: Jonathan Davies 
---
 tools/libxl/xl_cmdimpl.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 7f961e3..d5df20d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -8614,12 +8614,19 @@ int main_cpupoolnumasplit(int argc, char **argv)
 goto out;
 }
 
+if (libxl_domain_info(ctx, , 0)) {
+fprintf(stderr, "error on getting info for Domain-0\n");
+goto out;
+}
+
 n = 0;
 for (c = 0; c < n_cpus; c++) {
 if (topology[c].node == node) {
 topology[c].node = LIBXL_CPUTOPOLOGY_INVALID_ENTRY;
-libxl_bitmap_set(, n);
-n++;
+if (n < info.vcpu_online) {
+libxl_bitmap_set(, n);
+n++;
+}
 }
 }
 if (libxl_domain_info(ctx, , 0)) {
-- 
1.9.1


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

Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning

[Samuel Thibault]

Wei Liu, on Fri 12 Aug 2016 13:48:09 +0100, wrote:
> ---8<---
> From d72510368cdc3c73af3c8918a404a8137f40bd9c Mon Sep 17 00:00:00 2001
> From: Wei Liu 
> Date: Fri, 12 Aug 2016 11:32:57 +0100
> Subject: [PATCH] x86/arch_mm.h: move p2m_chk_pfn to x86/mm.c
> 
> Making that function inlined won't buy us much and is causing error in
> vtpm manager stubdom build.
> 
> Signed-off-by: Wei Liu 

Acked-by: Samuel Thibault 

> ---
>  arch/x86/mm.c |  9 +
>  include/x86/arch_mm.h | 11 +++
>  2 files changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/x86/mm.c b/arch/x86/mm.c
> index 8fa3b4c..88a928d 100644
> --- a/arch/x86/mm.c
> +++ b/arch/x86/mm.c
> @@ -608,6 +608,15 @@ static void clear_bootstrap(void)
>  printk("Unable to unmap NULL page. rc=%d\n", rc);
>  }
>  
> +void p2m_chk_pfn(unsigned long pfn)
> +{
> +if ( (pfn >> L3_P2M_SHIFT) > 0 )
> +{
> +printk("Error: Too many pfns.\n");
> +do_exit();
> +}
> +}
> +
>  void arch_init_p2m(unsigned long max_pfn)
>  {
>  unsigned long *l2_list = NULL, *l3_list;
> diff --git a/include/x86/arch_mm.h b/include/x86/arch_mm.h
> index e5d9c57..690a919 100644
> --- a/include/x86/arch_mm.h
> +++ b/include/x86/arch_mm.h
> @@ -190,14 +190,9 @@ typedef unsigned long pgentry_t;
>  #define L2_P2M_IDX(pfn) (((pfn) >> L1_P2M_SHIFT) & P2M_MASK)
>  #define L3_P2M_IDX(pfn) (((pfn) >> L2_P2M_SHIFT) & P2M_MASK)
>  #define INVALID_P2M_ENTRY (~0UL)
> -static inline void p2m_chk_pfn(unsigned long pfn)
> -{
> -if ( (pfn >> L3_P2M_SHIFT) > 0 )
> -{
> -printk("Error: Too many pfns.\n");
> -do_exit();
> -}
> -}
> +
> +void p2m_chk_pfn(unsigned long pfn);
> +
>  static inline unsigned long p2m_pages(unsigned long pages)
>  {
>  return (pages + P2M_ENTRIES - 1) >> L1_P2M_SHIFT;
> -- 
> 2.1.4
> 

-- 
Samuel
"How should I know if it works?  That's what beta testers are for.  I only
coded it."
(Attributed to Linus Torvalds, somewhere in a posting)

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

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Jan Beulich]

>>> On 12.08.16 at 14:53,  wrote:
> On 12/08/2016 13:41, "Jan Beulich"  wrote:
> On 12.08.16 at 01:13,  wrote:
>>> +### Lazy Consensus {#lazyconsensus}
>>> +
>>> +Lazy Consensus is a useful technique to make decisions for specific
>>>proposals 
>>> +which are not covered by the Review Then Commit Policy or do not
>>>require a more 
>>> +formal decison (see below). Lazy Consensus is extremely useful, when
>>>you don't 
>>> +anticipate any objections, or to gage whether there are objections to
>>>a 
>>> +proposal. To make use of it, post something like the following on the
>>>project's 
>>> +mailing list (or some other communication channel):
>>>  
>>>  
>>>-
>>>
>>> -ISSUES TO BE ADDRESSED LATER:
>>> -- The "Consensus Decision Making" section is totally wrong. It
>>>does not describe
>>> -  "Lazy Consensus"
>>> +Should we set a fixed time-frame? If so what?
>>>  
>>>-
>>>
>>>  
>>> -Sub-projects or teams hosted on Xenproject.org are normally
>>>auto-governing and
>>> -driven by the people who volunteer for the job. This functions well
>>>for most 
>>> -cases. When more formal decision making and coordination is required,
>>>decisions 
>>> -are taken with a lazy consensus approach: a few positive votes with no
>>>negative 
>>> -vote are enough to get going.
>>> +> I am assuming we are agreed on X and am going to assume lazy
>>>consensus: <
>>> +> if there are no objections within the next seven days.
>>>   <
>>> +
>>> +You should however ensure that all relevant stake-holders which may
>>>object are 
>>> +explicitly CC'ed, such as relevant maintainers or committers, ensure
>>>that 
>>> +**lazy consensus** is in the body of your message (this helps set up
>>>mail 
>>> +filters) and choose a reasonable time-frame. If it is unclear who the
>>>relevant 
>>> +stake-holders are, the project leadership can nominate a group of
>>>stake-holders 
>>> +to decide, or may choose to own the decision collectively and resolve
>>>it.
>>> +
>>> +Objections by stake-holders should be expressed using the [conventions
>>> +above](#expressingopinion) to make disagreements easily identifiable.
>>> +
>>> +__Passed/Failed:__
>>> +
>>> +-   Failed: A single **-2** by a stake-holder whose approval is
>>>necessary
>>> +-   Failed: **-1**'s by all stake-holder whose approval is necessary
>>> +-   Passed: In all other situations
>>
>>Hmm, that means all -1's except a single 0 would already be a pass?
> 
> That is not the intention. If we have only -1's and 0's it should be a
> fail. 
> Let me fix this in the next revisions.
> 
> How about: 
> +-   Failed: Only **-1** or **0** votes by all stake-holder whose approval
> is necessary

That would still leave 10 -1's overruled by a single +1.

> Although maybe someone can come up with a clearer way to express this.

Maybe when there are no +2's, simply take the sum of all votes,
and require it to be non-negative?

Jan


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

Re: [Xen-devel] Unable to add disk on ARM64

[Julien Grall]

On 12/08/2016 14:24, Peng Fan wrote:

Hi,


Hello Peng,

I have CCed Roger who is more familiar than me with the hotplug scripts.


I am using xen master branch on i.MX8 ARM64.

My xl configuration:

kernel = "/root/xen/Image"
memory = "128"
name = "DomU"
vcpus = 1
serial="pty"
disk = [ 'phy:/dev/loop0,xvda,w' ]
extra = "console=hvc0 root=/dev/xvda debug=/bin/sh"


And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux.

But I met the following error:
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: 
/etc/xen/scripts/block add ^M^M
Device /dev/loop0 is mounted in the privileged domain,^M^M
and so cannot be mounted by a guest.^M^M
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
/etc/xen/scripts/block add [800] exited with error status 1^M^M
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: 
deregister unregistered^M^M
libxl: error: libxl_devi
ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is mounted 
in the privileged domain,^M^M
and so cannot be mounted by a guest.^M^M


From my understanding, you have mounted /dev/loop0 in Dom0, is that 
correct? However, we don't support sharing the same mounting point by 
default (Roger can you confirm).



libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: 
deregister unregistered^M^M
libxl: error: libxl_create.c:1244:domcreate_launch_dm: unable to add disk 
devices

Then I change disk to "disk = [ 'format=raw, vdev=xvda, access=rw, 
target=/root/DomU-rootfs' ]"
But met other errors:
"
/etc/xen/scripts/block failed; error detected.
"


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Lars Kurth]

On 12/08/2016 13:41, "Jan Beulich"  wrote:

 On 12.08.16 at 01:13,  wrote:
>> +### Lazy Consensus {#lazyconsensus}
>> +
>> +Lazy Consensus is a useful technique to make decisions for specific
>>proposals 
>> +which are not covered by the Review Then Commit Policy or do not
>>require a more 
>> +formal decison (see below). Lazy Consensus is extremely useful, when
>>you don't 
>> +anticipate any objections, or to gage whether there are objections to
>>a 
>> +proposal. To make use of it, post something like the following on the
>>project's 
>> +mailing list (or some other communication channel):
>>  
>>  
>>-
>>
>> -ISSUES TO BE ADDRESSED LATER:
>> -- The "Consensus Decision Making" section is totally wrong. It
>>does not describe
>> -  "Lazy Consensus"
>> +Should we set a fixed time-frame? If so what?
>>  
>>-
>>
>>  
>> -Sub-projects or teams hosted on Xenproject.org are normally
>>auto-governing and
>> -driven by the people who volunteer for the job. This functions well
>>for most 
>> -cases. When more formal decision making and coordination is required,
>>decisions 
>> -are taken with a lazy consensus approach: a few positive votes with no
>>negative 
>> -vote are enough to get going.
>> +> I am assuming we are agreed on X and am going to assume lazy
>>consensus: <
>> +> if there are no objections within the next seven days.
>>   <
>> +
>> +You should however ensure that all relevant stake-holders which may
>>object are 
>> +explicitly CC'ed, such as relevant maintainers or committers, ensure
>>that 
>> +**lazy consensus** is in the body of your message (this helps set up
>>mail 
>> +filters) and choose a reasonable time-frame. If it is unclear who the
>>relevant 
>> +stake-holders are, the project leadership can nominate a group of
>>stake-holders 
>> +to decide, or may choose to own the decision collectively and resolve
>>it.
>> +
>> +Objections by stake-holders should be expressed using the [conventions
>> +above](#expressingopinion) to make disagreements easily identifiable.
>> +
>> +__Passed/Failed:__
>> +
>> +-   Failed: A single **-2** by a stake-holder whose approval is
>>necessary
>> +-   Failed: **-1**'s by all stake-holder whose approval is necessary
>> +-   Passed: In all other situations
>
>Hmm, that means all -1's except a single 0 would already be a pass?

That is not the intention. If we have only -1's and 0's it should be a
fail. 
Let me fix this in the next revisions.

How about: 
+-   Failed: Only **-1** or **0** votes by all stake-holder whose approval
is necessary


Although maybe someone can come up with a clearer way to express this.


>> +Let me express this as an algorithm.
>> +
>> +  treshhold=2/3;
>> +  active='number of active members'; (7 for the Hypervisor
>>project; IanC is inactive)
>> +  favour='number of +1 and +2 votes'
>> +  against='number of -1 and -2 votes'
>> +  strong-against='number -2 votes'; just added this as a sanity
>>check
>> +
>> +One open question is what to do with 0-votes. We could introduce a
>>rule discounting 
>> +0 votes (let's call it 0-rule). If someone votes 0, we assume they
>>really don't care
>> +about the outcome and are considered inactive for the purpose of
>>the vote. 
>> +
>> +In that case:
>> +
>> +  active -= 0-votes;
>> +
>> +Without the 0-rule:
>> +- to pass: favour/active >= treshhold
>> +  to pass: with active==7, favour >= 5
>> +  in other words, 3 (0,-1,-2)-votes block the proposal as we cant
>>achieve favour>=5
>> +
>> +With the 0-rule, let's consider 1, 2 or 3 0-votes
>> +1=>6: to pass: favour >=4
>> +  in other words, 3 (-1,-2)-votes block the proposal
>> +2=>5: to pass: favour >=4
>> +  in other words, 2 (-1,-2)-vote blocks the proposal
>> +3=>4: to pass: favour >=3
>> +  in other words, 2 (-1,-2)-vote blocks the proposal
>> +
>> +Looking at the arithmetic, it does probably make sense to go for
>>the 0-rule. If we
>> +do, there ought to be more votes in favour of a proposal, than
>>0-votes.
>> +
>> +On the other hand, not having the 0-rule forces everyone to form
>>an opinion, 
>> +otherise we will find it hard to make decisions. But in some
>>cases, forming an
>> +opinion costs significant mental capacity.
>> +
>> +It would also allow us to remove the complexity of differentiating
>>between
>> +active and non-active leadership team members by assuming that no
>>vote, equals
>> +a "0" vote.
>> +
>> +Opinions?
>
>I'm in favor of the "with 0-rule" variant.

That's what I assumed most people would go for and which is (hopefully
correctly)
implemented in the rules above the comment section.

Regards
Lars

Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning

[Wei Liu]

On Fri, Aug 12, 2016 at 12:42:31PM +0100, Wei Liu wrote:
> On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote:
> > Support ballooning Mini-OS automatically up in case of memory shortage.
> > 
> > Do some cleanups, a small correction and add some basic features to
> > lay groundwork for support of ballooning in Mini-OS (patches 1-14).
> > 
> > The main visible change is the virtual memory layout: to be able to
> > add memory to the running Mini-OS we need to have some spare areas
> > especially after the 1:1 mapping of physical memory.
> > 
> > Then add the ballooning functionality: the p2m map must be expanded,
> > the page allocator's bitmap must  be expanded and we must get new
> > memory from the hypervisor.
> > 
> > In case of a detected memory shortage the domain will balloon up until
> > either enough memory is available or the upper limit has been reached.
> > 
> > Ballooning has been tested with a xenstore stubdom.
> > Regression tests have been done with:
> > - pure mini-os
> > - ioemu stubdom
> > - pvgrub 64 bit
> > 
> 
> Unfortunately vtmpmgr stubdom build failed. :-/
> 


And that's probably because vtpmmgr uses printk or whatever...

Here is a patch that seems to fix the build:

---8<---
From d72510368cdc3c73af3c8918a404a8137f40bd9c Mon Sep 17 00:00:00 2001
From: Wei Liu 
Date: Fri, 12 Aug 2016 11:32:57 +0100
Subject: [PATCH] x86/arch_mm.h: move p2m_chk_pfn to x86/mm.c

Making that function inlined won't buy us much and is causing error in
vtpm manager stubdom build.

Signed-off-by: Wei Liu 
---
 arch/x86/mm.c |  9 +
 include/x86/arch_mm.h | 11 +++
 2 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/arch/x86/mm.c b/arch/x86/mm.c
index 8fa3b4c..88a928d 100644
--- a/arch/x86/mm.c
+++ b/arch/x86/mm.c
@@ -608,6 +608,15 @@ static void clear_bootstrap(void)
 printk("Unable to unmap NULL page. rc=%d\n", rc);
 }
 
+void p2m_chk_pfn(unsigned long pfn)
+{
+if ( (pfn >> L3_P2M_SHIFT) > 0 )
+{
+printk("Error: Too many pfns.\n");
+do_exit();
+}
+}
+
 void arch_init_p2m(unsigned long max_pfn)
 {
 unsigned long *l2_list = NULL, *l3_list;
diff --git a/include/x86/arch_mm.h b/include/x86/arch_mm.h
index e5d9c57..690a919 100644
--- a/include/x86/arch_mm.h
+++ b/include/x86/arch_mm.h
@@ -190,14 +190,9 @@ typedef unsigned long pgentry_t;
 #define L2_P2M_IDX(pfn) (((pfn) >> L1_P2M_SHIFT) & P2M_MASK)
 #define L3_P2M_IDX(pfn) (((pfn) >> L2_P2M_SHIFT) & P2M_MASK)
 #define INVALID_P2M_ENTRY (~0UL)
-static inline void p2m_chk_pfn(unsigned long pfn)
-{
-if ( (pfn >> L3_P2M_SHIFT) > 0 )
-{
-printk("Error: Too many pfns.\n");
-do_exit();
-}
-}
+
+void p2m_chk_pfn(unsigned long pfn);
+
 static inline unsigned long p2m_pages(unsigned long pages)
 {
 return (pages + P2M_ENTRIES - 1) >> L1_P2M_SHIFT;
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 3/3] Significant changes to decision making; some new roles and minor changes

[Jan Beulich]

>>> On 12.08.16 at 01:13,  wrote:
> +### Lazy Consensus {#lazyconsensus}
> +
> +Lazy Consensus is a useful technique to make decisions for specific 
> proposals 
> +which are not covered by the Review Then Commit Policy or do not require a 
> more 
> +formal decison (see below). Lazy Consensus is extremely useful, when you 
> don't 
> +anticipate any objections, or to gage whether there are objections to a 
> +proposal. To make use of it, post something like the following on the 
> project's 
> +mailing list (or some other communication channel):
>  
>  
> -
> -ISSUES TO BE ADDRESSED LATER:
> -- The "Consensus Decision Making" section is totally wrong. It does not 
> describe 
> -  "Lazy Consensus"
> +Should we set a fixed time-frame? If so what?
>  
> -
>  
> -Sub-projects or teams hosted on Xenproject.org are normally auto-governing 
> and 
> -driven by the people who volunteer for the job. This functions well for most 
> -cases. When more formal decision making and coordination is required, 
> decisions 
> -are taken with a lazy consensus approach: a few positive votes with no 
> negative 
> -vote are enough to get going.
> +> I am assuming we are agreed on X and am going to assume lazy 
> consensus: <
> +> if there are no objections within the next seven days. 
>  <
> +
> +You should however ensure that all relevant stake-holders which may object 
> are 
> +explicitly CC'ed, such as relevant maintainers or committers, ensure that 
> +**lazy consensus** is in the body of your message (this helps set up mail 
> +filters) and choose a reasonable time-frame. If it is unclear who the 
> relevant 
> +stake-holders are, the project leadership can nominate a group of 
> stake-holders 
> +to decide, or may choose to own the decision collectively and resolve it.
> +
> +Objections by stake-holders should be expressed using the [conventions 
> +above](#expressingopinion) to make disagreements easily identifiable.
> +
> +__Passed/Failed:__
> +
> +-   Failed: A single **-2** by a stake-holder whose approval is necessary
> +-   Failed: **-1**'s by all stake-holder whose approval is necessary
> +-   Passed: In all other situations

Hmm, that means all -1's except a single 0 would already be a pass?

> +Let me express this as an algorithm.
> +
> +  treshhold=2/3;
> +  active='number of active members'; (7 for the Hypervisor project; IanC 
> is inactive)
> +  favour='number of +1 and +2 votes' 
> +  against='number of -1 and -2 votes'
> +  strong-against='number -2 votes'; just added this as a sanity check
> +
> +One open question is what to do with 0-votes. We could introduce a rule 
> discounting 
> +0 votes (let's call it 0-rule). If someone votes 0, we assume they 
> really don't care
> +about the outcome and are considered inactive for the purpose of the 
> vote. 
> +
> +In that case:
> +
> +  active -= 0-votes;
> +
> +Without the 0-rule: 
> +- to pass: favour/active >= treshhold 
> +  to pass: with active==7, favour >= 5
> +  in other words, 3 (0,-1,-2)-votes block the proposal as we cant 
> achieve favour>=5
> +
> +With the 0-rule, let's consider 1, 2 or 3 0-votes
> +1=>6: to pass: favour >=4
> +  in other words, 3 (-1,-2)-votes block the proposal
> +2=>5: to pass: favour >=4
> +  in other words, 2 (-1,-2)-vote blocks the proposal
> +3=>4: to pass: favour >=3
> +  in other words, 2 (-1,-2)-vote blocks the proposal
> +
> +Looking at the arithmetic, it does probably make sense to go for the 
> 0-rule. If we
> +do, there ought to be more votes in favour of a proposal, than 0-votes.
> +
> +On the other hand, not having the 0-rule forces everyone to form an 
> opinion, 
> +otherise we will find it hard to make decisions. But in some cases, 
> forming an
> +opinion costs significant mental capacity.
> +
> +It would also allow us to remove the complexity of differentiating 
> between
> +active and non-active leadership team members by assuming that no vote, 
> equals
> +a "0" vote. 
> +
> +Opinions?

I'm in favor of the "with 0-rule" variant.

Jan

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

[Xen-devel] Unable to add disk on ARM64

[Peng Fan]

Hi,

I am using xen master branch on i.MX8 ARM64.

My xl configuration:

kernel = "/root/xen/Image"
memory = "128"
name = "DomU"
vcpus = 1
serial="pty"
disk = [ 'phy:/dev/loop0,xvda,w' ]
extra = "console=hvc0 root=/dev/xvda debug=/bin/sh"


And I "losetup /dev/loop0 /root/DomU-rootfs" in Dom0 Linux.

But I met the following error:
libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: 
/etc/xen/scripts/block add ^M^M
Device /dev/loop0 is mounted in the privileged domain,^M^M
and so cannot be mounted by a guest.^M^M
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: 
/etc/xen/scripts/block add [800] exited with error status 1^M^M
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: 
deregister unregistered^M^M
libxl: error: libxl_devi
ce.c:1202:device_hotplug_child_death_cb: script: Device /dev/loop0 is mounted 
in the privileged domain,^M^M
and so cannot be mounted by a guest.^M^M
libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0xfee100: 
deregister unregistered^M^M
libxl: error: libxl_create.c:1244:domcreate_launch_dm: unable to add disk 
devices

Then I change disk to "disk = [ 'format=raw, vdev=xvda, access=rw, 
target=/root/DomU-rootfs' ]"
But met other errors:
"
/etc/xen/scripts/block failed; error detected.
"

Any ideas?

Thanks,
Peng.

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

Re: [Xen-devel] [PATCH 2/2] x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL

[Jan Beulich]

>>> On 12.08.16 at 12:35,  wrote:
> The undefined behaviour sanitiser shows that it really is NULL via the
> pre_initcall path.
> 
>   (XEN) 
> 
>   (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66
>   (XEN) member access within null pointer of type 'struct processor_pminfo'
>   (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Not tainted ]
>   
>   (XEN)[] cpufreq_add_cpu+0x161/0xdc0
>   (XEN)[] cpufreq.c#cpu_callback+0x20/0x30
>   (XEN)[] cpufreq.c#cpufreq_presmp_init+0x2d/0x50
>   (XEN)[] do_presmp_initcalls+0x22/0x30
>   (XEN)[] __start_xen+0x378d/0x42f0
>   (XEN)[] __high_start+0x53/0x60
> 
> Fix two other occurances of the same buggy logic.
> 
> The processor_pminfo[] objects are only allocated as a result of
> XENPF_set_processor_pminfo hypercalls, which means that this early cpu
> callback will always hit the early NULL check, and is therefore pointless.
> 
> Signed-off-by: Andrew Cooper 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH 1/2] x86/boot: Align e820 and video data in the boot trampoline

[Jan Beulich]

>>> On 12.08.16 at 12:35,  wrote:
> The undefined behaviour sanitiser in Clang 3.8 identifies that these are all
> misaigned when used in __start_xen().
> 
> Signed-off-by: Andrew Cooper 

Acked-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only

[Jan Beulich]

>>> On 12.08.16 at 12:03,  wrote:
> On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote:
>> >>> On 11.08.16 at 11:17,  wrote:
>> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long 
> mbi_p)
>> >  if ( !opt_smep )
>> >  setup_clear_cpu_cap(X86_FEATURE_SMEP);
>> >  if ( cpu_has_smep )
>> > +{
>> >  set_in_cr4(X86_CR4_SMEP);
>> > +if ( smep_hvm_only )
>> > +write_cr4(read_cr4() & ~X86_CR4_SMEP);
>> > +}
>> 
>> So that'll clear CR4.SMEP right here, but won't help with CR4 loads
>> from mmu_cr4_features (as e.g. happens indirectly during VM exits,
>> since the HOST_CR4 field gets set from this variable).
>> 
>> Did you in fact test your change, including validation of the features
>> correctly remaining off over the lifetime of the system?
>> 
>> Further, considering that you don't clear the two flags from Xen's
>> internal feature bitmap, and taken together with the internal feature
>> bitmap driving alternative instruction patching, I'd assume pointless
>> (and performance wise perhaps harmful) patching to now take place.
>> 
> Let me see whether I understand this correctly...
> 
> Regarding alternative instruction patching, if enabling SMAP for HVM but
> disabling it for Xen, SMAP bit must be set in x86_capability feature
> bitmap and cleared in mmu_cr4_features, which means instruction patching
> would take place and a #UD may occur (since SMAP is disable in Xen, but
> STAC/CLAC are patched and called).

No #UD would occur (hence I only said "performance wise perhaps
harmful"), as per the SDM.

> A little dirty solution I can think of now is to temperarily clear SMAP
> bit in x86_capability before patching instruction and then set it back
> when instruction patching finish, like:
> 
> ```
> if ( opt_smap == SMAP_HVM_ONLY )
> setup_clear_cpu_cap(X86_FEATURE_SMAP);
> 
> alternative_instructions();
> 
> if ( opt_smap == SMAP_HVM_ONLY )
> __set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);
> ```

Except that this would need further adjustment (e.g. using just
__clear_bit() instead of setup_clear_cpu_cap(), or else you'd
break CPU hotplug).

I'm not against "a little dirty" solutions, as long as it doesn't end
in plain hackery, and as long as the end result indeed meets all
requirements.

> Appreciate it if you have a better solution.

Well, if I had a reasonably good solution, I could have gone and
simply implemented it. It is the need to consider all resulting cases
properly which makes this involved, and hence we've turned to
you (Intel) for assistance.

Jan


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

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

[Andrew Cooper]

On 12/08/16 11:58, Jan Beulich wrote:
 On 11.08.16 at 20:10,  wrote:
>> On 09/08/16 11:40, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/mtrr/main.c
>>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
>>> printk(KERN_WARNING
>>>"mtrr: your processor doesn't support 
>>> write-combining\n");
>>> -   return -ENOSYS;
>>> +   return -EOPNOTSUPP;
>> Will this break the classic-xen MTRR code?  ISTR it was very picky, from
>> the cpuid work.
> There are no -ENOSYS checks in there afaics, and I also can't
> otherwise see any way for this change to break it.
>
>>  Also, as some further cleanup, that printk should
>> become a print-once.
> Well, for a message that presumably would never actually get
> issued (as I'm unaware of 64-bit capable CPUs not supporting
> WC) I don't think this sort of cleanup has a really high priority.
> Certainly not in this patch.

Agreed.  This was a TODO note, rather than a request for this patch.  I
have noticed a few other printk()'s which should become print once.

Sorry for the confusion.

~Andrew

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

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[Jan Beulich]

>>> On 12.08.16 at 11:44,  wrote:
> On 09/08/16 12:30, Jan Beulich wrote:
> On 09.08.16 at 12:48,  wrote:
>>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
>>> depriv)"):
 Actually, having thought about this some more, and taking this
 together with the expectations to the privcmd driver previously
 outlined, I think this part is problematic: If all the driver is to know
 is the position (within the interface structure) of the target domain
 ID, then any guest handles embedded in the interface structure
 (XEN_HVMCTL_track_dirty_vram only for now) couldn't get
 validated, and hence user mode code would have a way to access
 or modify kernel memory.
>>>
>>> Could the hypervisor know the difference between user and kernel
>>> memory, in principle ?
>> 
>> Not without further new hypercalls, as the guest kernel would need
>> to tell Xen what address ranges are kernel vs user (and that implies
>> that any OS wishing to be able to act as Dom0 has a uniform
>> separation of address spaces).
> 
> Couldn't Xen tell from the guest pagetables whether the memory being
> accessed was user-mode or kernel mode?

That would be possible, but would feel like adding heuristics instead
of a proper distinction. Clearly we'd already be in some trouble if
there were cases where some structure doesn't get written to (and
hence could live in user-r/o mapped space), but others would need
to be verified to be user-r/w mapped. A lot of special casing, that is,
and hence of lot of things to be got wrong.

And then there is the problem of calling code being in rings 1 or 2:
Page tables don't guard ring 0 against such, and we don't even have
the notion of selectors (and hence address ranges) bounding
accessible regions. We can't even say we assume all of them to be
%ds-relative, as it would certainly be legitimate for such a structure
to e.g. live on the stack. Of course an option would be to require
the kernel driver to not allow requests from other than ring 3.

Plus finally - how would we tell interface structures coming from a
kernel invoked hypercall from those originating from user mode?
There would need to be at least some kind of flag then, which the
privcmd driver set, but normal hypercalls originating in the kernel
don't. Or would you envision to allow this DMOP hypercall to only
be made by user mode tools? If so, does stubdom run its qemu in
ring 3 or rather in ring 0?

[breaking the order of quoting]
> And unless we're positive the guest kernel will never need these
> hypercalls, we probably need a flag that allows kernel-mode pointers.

Ah, you actually mention that already.

>>>  (Would it be sufficient to check the starts, or would
>>> the ends need to be checked too?)
>> 
>> Both would need to be checked, so the size field(s) would need to
>> be locatable too.
>
> We could have the "fixed" part of the structure contain domid and an
> array of  which the privcmd driver could check.  I don't think
> that would be terrible.

Doable, yes, but not really nice, especially for the party invoking
the hypercall as well as the backing implementation in Xen (as
opposed to the privcmd driver, for which such a model would likely
work quite well), as they  then can't use the normal, simple reading
of structure fields, but instead would need to populate array
elements in the right order.

Jan


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

Re: [Xen-devel] [Minios-devel] [PATCH v3 00/19] mini-os: support of auto-ballooning

[Wei Liu]

On Thu, Aug 11, 2016 at 11:18:03AM +0200, Juergen Gross wrote:
> Support ballooning Mini-OS automatically up in case of memory shortage.
> 
> Do some cleanups, a small correction and add some basic features to
> lay groundwork for support of ballooning in Mini-OS (patches 1-14).
> 
> The main visible change is the virtual memory layout: to be able to
> add memory to the running Mini-OS we need to have some spare areas
> especially after the 1:1 mapping of physical memory.
> 
> Then add the ballooning functionality: the p2m map must be expanded,
> the page allocator's bitmap must  be expanded and we must get new
> memory from the hypervisor.
> 
> In case of a detected memory shortage the domain will balloon up until
> either enough memory is available or the upper limit has been reached.
> 
> Ballooning has been tested with a xenstore stubdom.
> Regression tests have been done with:
> - pure mini-os
> - ioemu stubdom
> - pvgrub 64 bit
> 

Unfortunately vtmpmgr stubdom build failed. :-/

Wei.

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

Re: [Xen-devel] [PATCH 5/7] x86emul: don't special case fetching unsigned 8-bit immediates

[Andrew Cooper]

On 12/08/16 11:50, Jan Beulich wrote:
 On 11.08.16 at 19:38,  wrote:
>> On 11/08/16 17:44, Jan Beulich wrote:
>> On 11.08.16 at 18:32,  wrote:
 On 11/08/16 13:06, Jan Beulich wrote:
> @@ -2893,7 +2894,6 @@ x86_emulate(
>  goto swint;
>  
>  case 0xcd: /* int imm8 */
> -src.val = insn_fetch_type(uint8_t);
>  swint_type = x86_swint_int;
>  swint:
>  rc = inject_swint(swint_type, src.val,
 I would be tempted to and an explicit (uint8_t) here, so that injection
 doesn't break if the prototype of inject_swint() changes.
>>> I guess I'll leave it that way, for two reasons:
>>> - One shouldn't change prototypes without checking whether callers
>>>   cope.
>> Indeed, but that doesn't alter the fact that you, I, and others we have
>> reviewed code from have managed to do precisely this, and break things.
> Well, okay, will do that then.
>
>>> - Here you basically suggest the opposite of what you wish done to
>>>   the earlier patch for the jmp_rel() invocations.
>> jmp_rel() is a macro not a function, but in hindsight, I rescind that
>> request.
> As that was the only change request to that other patch, may I
> translate that to an ack / R-b for it then?

Yes.  Sorry for the confusion.

~Andrew

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

[Xen-devel] [ovmf test] 100433: all pass - PUSHED

[osstest service owner]

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf 82df618711c596d3b6164e790572c795b7ea4dcc
baseline version:
 ovmf 753cf34e29c52bb45d25eb0580e04145f19cd83d

Last test of basis   100427  2016-08-12 04:44:41 Z0 days
Testing same since   100433  2016-08-12 07:46:05 Z0 days1 attempts


People who touched revisions under test:
  Ard Biesheuvel 
  Dandan Bi 

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



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

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

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

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


Pushing revision :

+ branch=ovmf
+ revision=82df618711c596d3b6164e790572c795b7ea4dcc
+ . ./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 ovmf 
82df618711c596d3b6164e790572c795b7ea4dcc
+ branch=ovmf
+ revision=82df618711c596d3b6164e790572c795b7ea4dcc
+ . ./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=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.7-testing
+ '[' x82df618711c596d3b6164e790572c795b7ea4dcc = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src 
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
 getconfig GitCacheProxy
 perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 

Re: [Xen-devel] [PATCH v2 2/2] x86/altp2m: allow specifying external-only use-case

[Julien Grall]

Hello Tamas,

On 10/08/2016 17:00, Tamas K Lengyel wrote:

diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index ef614be..97948fd 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -439,6 +439,13 @@ libxl_rdm_reserve = Struct("rdm_reserve", [
 ("policy",  libxl_rdm_reserve_policy),
 ])

+# Consistent with the values defined for HVM_PARAM_ALTP2M
+libxl_altp2m_mode = Enumeration("altp2m_mode", [
+(0, "disabled"),
+(1, "mixed"),
+(2, "external_only"),
+], init_val = "LIBXL_ALTP2M_MODE_DISABLED")
+
 libxl_domain_build_info = Struct("domain_build_info",[
 ("max_vcpus",   integer),
 ("avail_vcpus", libxl_bitmap),
@@ -512,7 +519,7 @@ libxl_domain_build_info = Struct("domain_build_info",[
("mmio_hole_memkb",  MemKB),
("timer_mode",   libxl_timer_mode),
("nested_hvm",   libxl_defbool),
-   ("altp2m",   libxl_defbool),
+   ("altp2m",   libxl_altp2m_mode),


Should we move altp2m directly outside of the structure "hvm" to avoid 
yet another change when altp2m will be supported on ARM? (see [1])


Regards,

[1] https://lists.xen.org/archives/html/xen-devel/2016-08/msg00147.html

--
Julien Grall

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

Re: [Xen-devel] 答复: xen does not support the 8G large bar

[Jan Beulich]

>>> On 12.08.16 at 05:18,  wrote:
> Hi Jan,
> Thanks for your reply.
> Qemu-xen seems that has problem for support 8G large Bar.
> I think this patch is not perfect: 
> https://xenbits.xen.org/gitweb/?p=qemu-xen.git;a=commitdiff;h=aabc8530c7ba2b 
> e89e21463f051056ad7c255e6e
> Because I found upper 32bit bar of 8G large bar was not register.
> xen_pt_config_init.c:456  xen_pt_bar_reg_write
> 
> case XEN_PT_BAR_FLAG_UPPER:
> bar_emu_mask = XEN_PT_BAR_ALLF;
> bar_ro_mask = r_size ? r_size - 1 : 0;
> break;
> r_size is always 0. So, bar_sz_upper is always 0x, regardless of 
> whether 64 bit BAR size is larger than 4G.

Depending on how qemu sets things up, the issue may simply be on
of wrong types being used: r->size is of type pcibus_t (which I
sincerely hope is a 64-bit type), yet r_size is uint32_t. But then
again r->size being pcibus_t suggests that d->io_regions[] fields
for the upper halves of 64-bit BARs may not get populated at all
(in which case a possible fix would likely be more involved). I'm not
a qemu expert, so I can't easily tell.

Jan


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

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

[Jan Beulich]

>>> On 12.08.16 at 12:34,  wrote:
> On 11/08/16 19:10, Andrew Cooper wrote:
>> On 09/08/16 11:40, Jan Beulich wrote:
>>> --- a/xen/arch/x86/cpu/mtrr/main.c
>>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>>> if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
>>> printk(KERN_WARNING
>>>"mtrr: your processor doesn't support 
>>> write-combining\n");
>>> -   return -ENOSYS;
>>> +   return -EOPNOTSUPP;
>> 
>> Will this break the classic-xen MTRR code?  ISTR it was very picky, from
>> the cpuid work.  Also, as some further cleanup, that printk should
>> become a print-once.
>> 
>> The others look ok.
> 
> That does bring up a good general point though -- the return value is
> part of the ABI.  Are you reasonably confident that none of the callers
> will be confused when this return value changes?  If so, a note in the
> commit message justifying this confidence would be helpful I think.

I don't think specific return values can be considered part of the
ABI, or else we couldn't e.g. change the order in which certain
checks get performed.

And then please also consider a hypothetical future hypervisor with
the MTRR operations simply ripped out - that would return -ENOSYS
or -EOPNOTSUPP then too, without a way for the caller to tell that
more generic error condition from the more specific one here.

Jan


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

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

[Jan Beulich]

>>> On 11.08.16 at 20:10,  wrote:
> On 09/08/16 11:40, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>>  if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
>>  printk(KERN_WARNING
>> "mtrr: your processor doesn't support 
>> write-combining\n");
>> -return -ENOSYS;
>> +return -EOPNOTSUPP;
> 
> Will this break the classic-xen MTRR code?  ISTR it was very picky, from
> the cpuid work.

There are no -ENOSYS checks in there afaics, and I also can't
otherwise see any way for this change to break it.

>  Also, as some further cleanup, that printk should
> become a print-once.

Well, for a message that presumably would never actually get
issued (as I'm unaware of 64-bit capable CPUs not supporting
WC) I don't think this sort of cleanup has a really high priority.
Certainly not in this patch.

Jan


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

Re: [Xen-devel] [PATCH 5/7] x86emul: don't special case fetching unsigned 8-bit immediates

[Jan Beulich]

>>> On 11.08.16 at 19:38,  wrote:
> On 11/08/16 17:44, Jan Beulich wrote:
> On 11.08.16 at 18:32,  wrote:
>>> On 11/08/16 13:06, Jan Beulich wrote:
 @@ -2893,7 +2894,6 @@ x86_emulate(
  goto swint;
  
  case 0xcd: /* int imm8 */
 -src.val = insn_fetch_type(uint8_t);
  swint_type = x86_swint_int;
  swint:
  rc = inject_swint(swint_type, src.val,
>>> I would be tempted to and an explicit (uint8_t) here, so that injection
>>> doesn't break if the prototype of inject_swint() changes.
>> I guess I'll leave it that way, for two reasons:
>> - One shouldn't change prototypes without checking whether callers
>>   cope.
> 
> Indeed, but that doesn't alter the fact that you, I, and others we have
> reviewed code from have managed to do precisely this, and break things.

Well, okay, will do that then.

>> - Here you basically suggest the opposite of what you wish done to
>>   the earlier patch for the jmp_rel() invocations.
> 
> jmp_rel() is a macro not a function, but in hindsight, I rescind that
> request.

As that was the only change request to that other patch, may I
translate that to an ack / R-b for it then?

Jan


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

[Xen-devel] [PATCH 2/2] x86/cpufreq: Avoid using processor_pminfo[cpu] when it is NULL

[Andrew Cooper]

The undefined behaviour sanitiser shows that it really is NULL via the
pre_initcall path.

  (XEN) 

  (XEN) UBSAN: Undefined behaviour in cpufreq.c:158:66
  (XEN) member access within null pointer of type 'struct processor_pminfo'
  (XEN) [ Xen-4.8-unstable  x86_64  debug=y  Not tainted ]
  
  (XEN)[] cpufreq_add_cpu+0x161/0xdc0
  (XEN)[] cpufreq.c#cpu_callback+0x20/0x30
  (XEN)[] cpufreq.c#cpufreq_presmp_init+0x2d/0x50
  (XEN)[] do_presmp_initcalls+0x22/0x30
  (XEN)[] __start_xen+0x378d/0x42f0
  (XEN)[] __high_start+0x53/0x60

Fix two other occurances of the same buggy logic.

The processor_pminfo[] objects are only allocated as a result of
XENPF_set_processor_pminfo hypercalls, which means that this early cpu
callback will always hit the early NULL check, and is therefore pointless.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/drivers/cpufreq/cpufreq.c | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
index f19b403..fd82ef5 100644
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -126,7 +126,7 @@ int __init cpufreq_register_governor(struct 
cpufreq_governor *governor)
 
 int cpufreq_limit_change(unsigned int cpu)
 {
-struct processor_performance *perf = _pminfo[cpu]->perf;
+struct processor_performance *perf;
 struct cpufreq_policy *data;
 struct cpufreq_policy policy;
 
@@ -134,6 +134,8 @@ int cpufreq_limit_change(unsigned int cpu)
 !processor_pminfo[cpu])
 return -ENODEV;
 
+perf = _pminfo[cpu]->perf;
+
 if (perf->platform_limit >= perf->state_count)
 return -EINVAL;
 
@@ -155,12 +157,15 @@ int cpufreq_add_cpu(unsigned int cpu)
 struct cpufreq_dom *cpufreq_dom = NULL;
 struct cpufreq_policy new_policy;
 struct cpufreq_policy *policy;
-struct processor_performance *perf = _pminfo[cpu]->perf;
+struct processor_performance *perf;
 
 /* to protect the case when Px was not controlled by xen */
-if (!processor_pminfo[cpu]  ||
-!(perf->init & XEN_PX_INIT) ||
-!cpu_online(cpu))
+if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
+return -EINVAL;
+
+perf = _pminfo[cpu]->perf;
+
+if ( !(perf->init & XEN_PX_INIT) )
 return -EINVAL;
 
 if (!cpufreq_driver)
@@ -310,12 +315,15 @@ int cpufreq_del_cpu(unsigned int cpu)
 struct list_head *pos;
 struct cpufreq_dom *cpufreq_dom = NULL;
 struct cpufreq_policy *policy;
-struct processor_performance *perf = _pminfo[cpu]->perf;
+struct processor_performance *perf;
 
 /* to protect the case when Px was not controlled by xen */
-if (!processor_pminfo[cpu]  ||
-!(perf->init & XEN_PX_INIT) ||
-!cpu_online(cpu))
+if ( !processor_pminfo[cpu] || !cpu_online(cpu) )
+return -EINVAL;
+
+perf = _pminfo[cpu]->perf;
+
+if ( !(perf->init & XEN_PX_INIT) )
 return -EINVAL;
 
 if (!per_cpu(cpufreq_cpu_policy, cpu))
@@ -637,8 +645,6 @@ static struct notifier_block cpu_nfb = {
 
 static int __init cpufreq_presmp_init(void)
 {
-void *cpu = (void *)(long)smp_processor_id();
-cpu_callback(_nfb, CPU_ONLINE, cpu);
 register_cpu_notifier(_nfb);
 return 0;
 }
-- 
2.1.4


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

[Xen-devel] [PATCH 1/2] x86/boot: Align e820 and video data in the boot trampoline

[Andrew Cooper]

The undefined behaviour sanitiser in Clang 3.8 identifies that these are all
misaigned when used in __start_xen().

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
---
 xen/arch/x86/boot/mem.S   | 1 +
 xen/arch/x86/boot/video.S | 1 +
 2 files changed, 2 insertions(+)

diff --git a/xen/arch/x86/boot/mem.S b/xen/arch/x86/boot/mem.S
index 820aea9..602ab2c 100644
--- a/xen/arch/x86/boot/mem.S
+++ b/xen/arch/x86/boot/mem.S
@@ -67,6 +67,7 @@ get_memory_map:
 
 ret
 
+.align  4
 GLOBAL(e820map)
 .fill   E820MAX*20,1,0
 GLOBAL(e820nr)
diff --git a/xen/arch/x86/boot/video.S b/xen/arch/x86/boot/video.S
index b238bf3..2aafbeb 100644
--- a/xen/arch/x86/boot/video.S
+++ b/xen/arch/x86/boot/video.S
@@ -994,6 +994,7 @@ force_size: .word   0   # Use this size instead of 
the one in BIOS vars
 vesa_size:  .word   0,0,0   # width x depth x height
 
 /* If we don't run at all, assume basic video mode 3 at 80x25. */
+.align  2
 GLOBAL(boot_vid_mode)
 .word   VIDEO_80x25
 GLOBAL(boot_vid_info)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] replace bogus -ENOSYS uses

[George Dunlap]

On 11/08/16 19:10, Andrew Cooper wrote:
> On 09/08/16 11:40, Jan Beulich wrote:
>> --- a/xen/arch/x86/cpu/mtrr/main.c
>> +++ b/xen/arch/x86/cpu/mtrr/main.c
>> @@ -332,7 +332,7 @@ int mtrr_add_page(unsigned long base, un
>>  if ((type == MTRR_TYPE_WRCOMB) && !have_wrcomb()) {
>>  printk(KERN_WARNING
>> "mtrr: your processor doesn't support 
>> write-combining\n");
>> -return -ENOSYS;
>> +return -EOPNOTSUPP;
> 
> Will this break the classic-xen MTRR code?  ISTR it was very picky, from
> the cpuid work.  Also, as some further cleanup, that printk should
> become a print-once.
> 
> The others look ok.

That does bring up a good general point though -- the return value is
part of the ABI.  Are you reasonably confident that none of the callers
will be confused when this return value changes?  If so, a note in the
commit message justifying this confidence would be helpful I think.

 -George


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

Re: [Xen-devel] [PATCH V2] xen: support enabling SMEP/SMAP for HVM only

[He Chen]

On Thu, Aug 11, 2016 at 07:14:06AM -0600, Jan Beulich wrote:
> >>> On 11.08.16 at 11:17,  wrote:
> > @@ -1404,12 +1438,20 @@ void __init noreturn __start_xen(unsigned long 
> > mbi_p)
> >  if ( !opt_smep )
> >  setup_clear_cpu_cap(X86_FEATURE_SMEP);
> >  if ( cpu_has_smep )
> > +{
> >  set_in_cr4(X86_CR4_SMEP);
> > +if ( smep_hvm_only )
> > +write_cr4(read_cr4() & ~X86_CR4_SMEP);
> > +}
> 
> So that'll clear CR4.SMEP right here, but won't help with CR4 loads
> from mmu_cr4_features (as e.g. happens indirectly during VM exits,
> since the HOST_CR4 field gets set from this variable).
> 
> Did you in fact test your change, including validation of the features
> correctly remaining off over the lifetime of the system?
> 
> Further, considering that you don't clear the two flags from Xen's
> internal feature bitmap, and taken together with the internal feature
> bitmap driving alternative instruction patching, I'd assume pointless
> (and performance wise perhaps harmful) patching to now take place.
> 
Let me see whether I understand this correctly...

Regarding alternative instruction patching, if enabling SMAP for HVM but
disabling it for Xen, SMAP bit must be set in x86_capability feature
bitmap and cleared in mmu_cr4_features, which means instruction patching
would take place and a #UD may occur (since SMAP is disable in Xen, but
STAC/CLAC are patched and called).

A little dirty solution I can think of now is to temperarily clear SMAP
bit in x86_capability before patching instruction and then set it back
when instruction patching finish, like:

```
if ( opt_smap == SMAP_HVM_ONLY )
setup_clear_cpu_cap(X86_FEATURE_SMAP);

alternative_instructions();

if ( opt_smap == SMAP_HVM_ONLY )
__set_bit(X86_FEATURE_SMAP, boot_cpu_data.x86_capability);
```

Appreciate it if you have a better solution.

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

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

[Ian Jackson]

Wei Liu writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for getting 
output"):
> On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> > We don't care when xenconsoled closes the logfile.  We care about when
> > it last calls write() (with a nonempty buffer).
> 
> In logfile mode, no console client is spawned, because it is not
> reliable -- that's why we use logfile mode in the first place.
> 
> And I would rather just add a bodge (wait 1 or 2 seconds)

That would increase the duration of each test by that 1 or 2 seconds.
I suppose you could conclude the logfile is complete if it contains
the expected end-of-run message from the vm, and only poll if not.

But, it's worse:

I went to read the xenconsoled source code, and it can handle a domain
death event before finishing reading all of the data out of a domain's
ring.

Maybe this will be mitigated by XTF's printf waiting for the
xenconsoled ring pointer to catch up ?

xenconsoled advances the ring pointer before writing to the logfile,
but (assuming there's no overflow), the write will happen before it
goes back into the event loop, so it won't be lost.

> than to rely on sophisticated hack.

To my mind polling the logfile looking for the final message from the
vm is something of a hack.

But indeed I can't see another way to wait for xenconsoled, than
going behind libxl's back with something like
 * spawn xl create -p -F
 * look for the console tty in xenstore
 * open the console tty
 * unpause
 * wait for the console tty to get eof

This is not a logfile mode at all, of course.  It probably wouldn't be
easily adaptable to other toolstacks (eg XenServer).

Ian.

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

Re: [Xen-devel] [PATCH] xen: credit1: fix a race when picking initial pCPU for a vCPU

[Dario Faggioli]

On Fri, 2016-08-12 at 10:14 +0100, George Dunlap wrote:
> On 12/08/16 05:07, Dario Faggioli wrote:
> > 
> > Reported-by: Andrew Cooper 
> > Signed-off-by: Dario Faggioli 
> It might be nice if we could add an ASSERT() that the appropriate
> runqueue was locked, to make sure we don't get caught out again like
> this in the future, but I think that would probably require turning
> it
> into a static inline (which probably wouldn't be so bad anyway).
> 
Mmm... good point.

> But in any case:
> 
> Acked-by: George Dunlap 
> 
> Let me know if you want me to check this in as-is or if you think you
> might send a follow-up patch adding an ASSERT.
> 
Yes, I'll send a new patch.

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
https://lists.xen.org/xen-devel

Re: [Xen-devel] Device model operation hypercall (DMOP, re qemu depriv)

[George Dunlap]

On 09/08/16 12:30, Jan Beulich wrote:
 On 09.08.16 at 12:48,  wrote:
>> Jan Beulich writes ("Re: Device model operation hypercall (DMOP, re qemu 
>> depriv)"):
>>> Actually, having thought about this some more, and taking this
>>> together with the expectations to the privcmd driver previously
>>> outlined, I think this part is problematic: If all the driver is to know
>>> is the position (within the interface structure) of the target domain
>>> ID, then any guest handles embedded in the interface structure
>>> (XEN_HVMCTL_track_dirty_vram only for now) couldn't get
>>> validated, and hence user mode code would have a way to access
>>> or modify kernel memory.
>>
>> Could the hypervisor know the difference between user and kernel
>> memory, in principle ?
> 
> Not without further new hypercalls, as the guest kernel would need
> to tell Xen what address ranges are kernel vs user (and that implies
> that any OS wishing to be able to act as Dom0 has a uniform
> separation of address spaces).

Couldn't Xen tell from the guest pagetables whether the memory being
accessed was user-mode or kernel mode?

>> Alternatively, would it be possible for the ABI to specify somehow
>> what parameters are guest handles, so that the privcmd driver could
>> check them ?
> 
> We could presumably invent something, but I'm afraid it would end
> up quite ugly.
> 
>>  (Would it be sufficient to check the starts, or would
>> the ends need to be checked too?)
> 
> Both would need to be checked, so the size field(s) would need to
> be locatable too.

We could have the "fixed" part of the structure contain domid and an
array of  which the privcmd driver could check.  I don't think
that would be terrible.

Alternately, the "fixed" part of the hypercall could contain a
 range, which if non-zero, Xen should use to check any
pointer contained in the struct -- that would be more flexible probably.

Or we could do as Jan hints at above -- have some way to have dom0
communicate the kernel address range to Xen (either via hypercall, or
maybe via the shared info page) so that Xen just knows the address
layout for any individual domain.

And unless we're positive the guest kernel will never need these
hypercalls, we probably need a flag that allows kernel-mode pointers.

It's worth pointing out that the problem Xen has distinguishing
user/kernel mode pointers is the same even if we use the alternate
suggestion of per-process XSM labels.

 -George

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

[Xen-devel] [PATCH v2] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Lars Kurth]

COPYING file:
The motivation of this change is to make it easier for new
contributors to conduct a license and patent review, WITHOUT
changing any licenses.
- Remove references to BSD-style licenses as we have more
  common license exceptions and replace with "other license
  stanzas"
- List the most common situations under which code is licensed
  under licenses other than GPLv2 (section "Licensing Exceptions")
- List the most common non-GPLv2 licenses that are in use in
  this repository based on a recent FOSSology scan (section
  "Licensing Exceptions")
- List other license related conventions within the project
  to make it easier to conduct a license review.
- Clarify the incoming license as its omission has confused
  past contributors (section "Contributions")

CONTRIBUTION file:
The motivation of this file is to make it easier for contributors
to find contribution related resources. Add information on existing
license related conventions to avoid unintentional future licensing
issues. Provide templates for copyright headers for the most commonly
used licenses in this repository.

Signed-off-by: Lars Kurth 

---
Changed since v1:
  * Fixed typos
  * Used GPL / LGPL license header spelling out version instead of v
  
---
 CONTRIBUTING | 210 +++
 COPYING  |  64 ++
 2 files changed, 260 insertions(+), 14 deletions(-)
 create mode 100644 CONTRIBUTING

diff --git a/CONTRIBUTING b/CONTRIBUTING
new file mode 100644
index 000..67ecdb7
--- /dev/null
+++ b/CONTRIBUTING
@@ -0,0 +1,210 @@
+
+CONTRIBUTING
+
+
+INBOUND LICENSE
+---
+
+Contributions are governed by the license that applies to relevant 
+specific file or by the license specified in the COPYING file, that
+governs the license of its containing directory and its subdirectories.
+
+Most of the Xen Project code is licensed under GPLv2, but a number of 
+directories are primarily licensed under different licenses. 
+
+Most notably:
+ - tools/blktap2  : BSD-Modified
+ - tools/libxc: LGPL v2.1
+ - tools/libxl: LGPL v2.1
+ - xen/include/public : MIT license
+
+When creating new components and directories that contain a 
+significant amount of files that are licensed under licenses other 
+than GPLv2 or the license specified in the COPYING file, please 
+create a new COPYING file in that directory containing a copy of the 
+license text and a rationale for using a different license. This helps 
+ensure that the license of this new component/directory is maintained 
+consistently with the original intention.
+
+When importing code from other upstream projects into this repository, 
+please create a README.source file in the directory the code is imported 
+to, listing the original source of the code. An example can be found at 
+m4/README.source
+
+The COMMON COPYRIGHT NOTICES section of this document contains 
+sample copyright notices for the most common licenses used within 
+this repository.
+
+Developer's Certificate of Origin
+-
+
+All patches to the Xen Project code base must include the line 
+"Signed-off-by: your_name " at the end of the change 
+description. This is required and indicates that you certify the patch 
+under the "Developer's Certificate of Origin" which states:
+
+  Developer's Certificate of Origin 1.1
+
+  By making a contribution to this project, I certify that:
+
+  (a) The contribution was created in whole or in part by me and I
+  have the right to submit it under the open source license
+  indicated in the file; or
+
+  (b) The contribution is based upon previous work that, to the best
+  of my knowledge, is covered under an appropriate open source
+  license and I have the right under that license to submit that
+  work with modifications, whether created in whole or in part
+  by me, under the same open source license (unless I am
+  permitted to submit under a different license), as indicated
+  in the file; or
+
+  (c) The contribution was provided directly to me by some other
+  person who certified (a), (b) or (c) and I have not modified
+  it.
+
+  (d) I understand and agree that this project and the contribution
+  are public and that a record of the contribution (including all
+  personal information I submit with it, including my sign-off) is
+  maintained indefinitely and may be redistributed consistent with
+  this project or the open source license(s) involved.
+
+GOVERNANCE AND WORKFLOW
+---
+
+The following documents provide a general overview of governance and
+contribution guidelines for the Xen Project:
+ - https://xenproject.org/governance.html  
+ - https://xenproject.org/help/contribution-guidelines.html 
+
+For more information on contributing to this repository, see
+ - CODING_STYLE file in this directory
+ - 

Re: [Xen-devel] [XTF PATCH v2] xtf-runner: support two modes for getting output

[Wei Liu]

On Thu, Aug 11, 2016 at 07:29:00PM +0100, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [XTF PATCH v2] xtf-runner: support two modes for 
> getting output"):
> > On 11/08/16 18:51, Wei Liu wrote:
> > > I'm pretty out of idea here.
> > 
> > Because of XTF's behaviour (waiting for xenconsoled to catch up), you
> > know for certain that once `xl create` has finished, nothing more will
> > write into the log.
> 
> You're missing the problem, I think.  It's this possible race:
> 
>VM prints last output to ring
> xenconsoled wakes up from poll
>VM calls shutdown
>  xenstored sends domain death event
>  xl receives domain death event
>  xl tears down guest, destroying
>  all relevant xenstore nodes
>  xl exits
>  xtf-runner opens logfile
>  xtf-runner reads logfile
>  xtf-runner gets eof on logfile
> 
>xenconsoled reads data from
>ring (which page is now only
>owned by xenconsoled)
> 
>xenconsoled writes final data
>to logfile
> 
> Wei: Maybe you could rely on `xl console' not exiting until xenconsole
> has written the last data to the logfile ?  You say:
> 
> > It is sure that xenconsoled will close the tty before closing the file,
> > so stat'ing the actual device node won't work either.
> 
> We don't care when xenconsoled closes the logfile.  We care about when
> it last calls write() (with a nonempty buffer).
> 

In logfile mode, no console client is spawned, because it is not
reliable -- that's why we use logfile mode in the first place.

And I would rather just add a bodge (wait 1 or 2 seconds) than to rely
on sophisticated hack.

Wei.

> Ian.

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

[Xen-devel] [qemu-mainline baseline-only test] 66966: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 66966 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/66966/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 66960
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  like 66960

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

version targeted for testing:
 qemuu2bb15bddf2607110820d5ce5aa43baac27292fb3
baseline version:
 qemuuab861f3915e8667927cf18ad97f71cae7ccf8818

Last test of basis66960  2016-08-10 08:28:59 Z2 days
Testing same since66966  2016-08-11 01:50:59 Z1 days1 attempts


People who touched revisions under test:
  John Snow 
  Paolo Bonzini 
  Peter Maydell 

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   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-xsm 

Re: [Xen-devel] [PATCH] Remove ambiguities in the COPYING file; add CONTRIBUTING file

[Lars Kurth]

On 11/08/2016 19:57, "Stefano Stabellini"  wrote:

>On Thu, 11 Aug 2016, George Dunlap wrote:
>> On 11/08/16 01:51, Stefano Stabellini wrote:
>> > On Wed, 10 Aug 2016, Lars Kurth wrote:
>>
>> >> diff --git a/CONTRIBUTING b/CONTRIBUTING
>> >> new file mode 100644
>> >> index 000..7af13c4
>> >> --- /dev/null
>> >> +++ b/CONTRIBUTING
>> >> @@ -0,0 +1,210 @@
>> >> +
>> >> +CONTRIBUTING
>> >> +
>> >> +
>> >> +INBOUND LICENSE
>> >> +---
>> >> +
>> >> +Contributions are governed by the license that applies to relevant
>> >> +specific file or by the license specified in the COPYING file, that
>> >  ^files
>> 
>> I think "file" is better here, as the license is on a file-by-file
>> basis, not on a whole contribution basis.  That is, if your contribution
>> changes a BSD file and a GPLv2 file in a single series (or a single
>> patch), then the changes to the BSD file are goverened by the BSD
>> licence, and the changes to the GPLv2 file are governed by the GPLv2.
>
>OK, I understand the intention behind that sentence but it sounds odd to
>me (possibly because I am not a native English speaker so if it is
>technically correct, you might want to ignore my comment).
>Shouldn't it be:
>
>to _a_ relevant specific file

I will fix this. I think probably _the_ instead of _a_ is better. Next
revision coming.
Lars

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