[Xen-devel] [qemu-upstream-4.6-testing test] 93371: trouble: blocked/broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

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

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

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

version targeted for testing:
 qemuu62936f64308aae81530b1273ad2c248b6476e62e
baseline version:
 qemuu9869880372c8e786502ce140d50158118e29a165

Last test of basis83624  2016-02-22 06:20:45 Z   70 days
Testing same since93357  2016-05-02 09:44:06 Z0 days2 attempts


People who touched revisions under test:
  "Hao, Xudong" 
  Anthony Perard 
  Stefano Stabellini 
  Stefano Stabellini 
  Wei Liu 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  broken  
 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 

Re: [Xen-devel] osstest standalong complaining about 'logs/standalone'

[Konrad Rzeszutek Wilk]

On Mon, May 02, 2016 at 09:21:18PM -0400, Konrad Rzeszutek Wilk wrote:
> This is brand new Jessie install (8.04) and this is what I've for my
> .xen-osstest/config:
> 
> The network is very simple - this 'osstest' is the only host for
> the whole 192.168.110.0 subnet. It has PXE, DHCP, DNS and ntpd running
> and configured.
> 
> Here is what I've for my .xen-osstest/config:
> 
> konrad@g-osstest:~/osstest$ more ~/.xen-osstest/config 
> DnsDomain   dumpdata.com
> NetNameservers  192.168.110.2
> HostProp_DhcpWatchMethod leases dhcp3 /var/lib/dhcp/dhcpd.leases
> AuthorizedKeysFiles
> /home/konrad/.ssh/id_rsa.pub:/home/konrad/.ssh/authorized_keys2
> 
> DebianNonfreeFirmware=''
> 
> TftpPath /srv/tftp/
> TftpPlayDir osstest/
> TftpDiVersion 2015-09-07
> DebianSuite jessie
> 
> WebspaceFile/srv/tftp/public_html/
> WebspaceUrl http://192.168.110.0/public_html/
 ^
This is actually 192.168.110.2.

> WebspaceLog /var/log/apache3/access.log
> DebianMirrorHosthttp://192.168.110.2/debian/
> 
> TestHostg-vmtest
> TestHost_g-vmtest_Ether  00:0F:4B:00:00:86
> TestHost_g-vmtest_NtpServer 192.168.110.2
> TestHost_g-vmtest_Power_Method manual
> 
> I ran the ./standalone-reset and it did its thing.

> 
> After that I tried to run the first job and go:

If I also create an directory 'logs' in the osstest.git directory
this finishes, albeit it actually doesn't do anything.

Should WebspaceFile actually point to /home/konrad/osstest.git/logs ?
(And naturally I also need to modify apache2 alias for 'logs' to point
to this directory?)

The logs don't actually have anything:

konrad@g-osstest:~/osstest$ find logs
logs
logs/standalone
logs/standalone/build-amd64

Ah. Found out partially what was the problem. My /etc/resolv.conf
was pointing to 8.8.8.8 instead of 192.168.110.2 so it did not resolve
g-vmtest.dumpdata.com

Now of to find out where (or who?) creates the pxelinux.cfg/default
file.. 

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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Shannon Zhao]

On 2016/5/2 18:45, Matt Fleming wrote:
> On Sun, 01 May, at 10:36:51PM, Shannon Zhao wrote:
>> So is there any other way you suggest?
> 
> Would this work (compile tested but not runtime tested)?
> 
> ---
> 
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 3a69ed5ecfcb..13d8be16447a 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -469,12 +469,14 @@ device_initcall(efi_load_efivars);
>   FIELD_SIZEOF(struct efi_fdt_params, field) \
>   }
>  
> -static __initdata struct {
> +struct params {
>   const char name[32];
>   const char propname[32];
>   int offset;
>   int size;
> -} dt_params[] = {
> +};
> +
> +static __initdata struct params fdt_params[] = {
>   UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
>   UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
>   UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
> @@ -482,44 +484,83 @@ static __initdata struct {
>   UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
>  };
>  
> +static __initdata struct params xen_fdt_params[] = {
> + UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
> + UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
> + UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
> + UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
> + UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
> +};
> +
> +#define EFI_FDT_PARAMS_SIZE  ARRAY_SIZE(fdt_params)
> +
> +static __initdata struct {
> + const char *uname;
> + struct params *params;
> +} dt_params[] = {
> + { "hypervisor", xen_fdt_params },
While the uefi params are located under /hypervisor/uefi node not
/hypervisor node.

> + { "chosen", fdt_params },
> +};
> +
>  struct param_info {
>   int found;
>   void *params;
> + const char *missing;
>  };
>  
> -static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
> -int depth, void *data)
> +static int __init __find_uefi_params(unsigned long node,
> +  struct param_info *info,
> +  struct params *params)
>  {
> - struct param_info *info = data;
>   const void *prop;
>   void *dest;
>   u64 val;
>   int i, len;
>  
> - if (depth != 1 || strcmp(uname, "chosen") != 0)
> - return 0;
> -
> - for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
> - prop = of_get_flat_dt_prop(node, dt_params[i].propname, );
> - if (!prop)
> + for (i = 0; i < EFI_FDT_PARAMS_SIZE; i++) {
> + prop = of_get_flat_dt_prop(node, params[i].propname, );
> + if (!prop) {
> + info->missing = params[i].name;
>   return 0;
> - dest = info->params + dt_params[i].offset;
> + }
> +
> + dest = info->params + params[i].offset;
>   info->found++;
>  
>   val = of_read_number(prop, len / sizeof(u32));
>  
> - if (dt_params[i].size == sizeof(u32))
> + if (params[i].size == sizeof(u32))
>   *(u32 *)dest = val;
>   else
>   *(u64 *)dest = val;
>  
>   if (efi_enabled(EFI_DBG))
> - pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
> - dt_params[i].size * 2, val);
> + pr_info("  %s: 0x%0*llx\n", params[i].name,
> + params[i].size * 2, val);
>   }
> +
>   return 1;
>  }
>  
> +static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
> +int depth, void *data)
> +{
> + struct param_info *info = data;
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
> +
> + if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
> + info->missing = dt_params[i].params[0].name;
> + continue;
> + }
> +
So here it needs to check whether the node is /hypervisor. If so, get
the subnode "uefi". Like below:
if (strcmp(uname, "hypervisor") == 0) {
offset = of_get_flat_dt_subnode_by_name(node, "uefi");
if (offset < 0)
return 0;
node = offset;
}

> + return __find_uefi_params(node, info, dt_params[i].params);
> + }
> +
> + return 0;
> +}
> +
>  int __init efi_get_fdt_params(struct efi_fdt_params *params)
>  {
>   struct param_info info;
> @@ -535,7 +576,7 @@ int __init efi_get_fdt_params(struct efi_fdt_params 
> *params)
>   pr_info("UEFI not found.\n");
>   else if (!ret)
>   pr_err("Can't find '%s' in device tree!\n",
> -dt_params[info.found].name);
> +

[Xen-devel] osstest standalong complaining about 'logs/standalone'

[Konrad Rzeszutek Wilk]

This is brand new Jessie install (8.04) and this is what I've for my
.xen-osstest/config:

The network is very simple - this 'osstest' is the only host for
the whole 192.168.110.0 subnet. It has PXE, DHCP, DNS and ntpd running
and configured.

Here is what I've for my .xen-osstest/config:

konrad@g-osstest:~/osstest$ more ~/.xen-osstest/config 
DnsDomain   dumpdata.com
NetNameservers  192.168.110.2
HostProp_DhcpWatchMethod leases dhcp3 /var/lib/dhcp/dhcpd.leases
AuthorizedKeysFiles
/home/konrad/.ssh/id_rsa.pub:/home/konrad/.ssh/authorized_keys2

DebianNonfreeFirmware=''

TftpPath /srv/tftp/
TftpPlayDir osstest/
TftpDiVersion 2015-09-07
DebianSuite jessie

WebspaceFile/srv/tftp/public_html/
WebspaceUrl http://192.168.110.0/public_html/
WebspaceLog /var/log/apache2/access.log
DebianMirrorHosthttp://192.168.110.2/debian/

TestHostg-vmtest
TestHost_g-vmtest_Ether  00:0F:4B:00:00:86
TestHost_g-vmtest_NtpServer 192.168.110.2
TestHost_g-vmtest_Power_Method manual

I ran the ./standalone-reset and it did its thing.

After that I tried to run the first job and go:

2016-05-03 01:07:06 Z starting standalone.build-amd64 ts-build-check
build-check(1)
2016-05-03 01:07:06 Z standalone.build-amd64 == 1 testid build-check(1) 
==
2016-05-03 01:07:06 Z awaiting standalone.build-amd64 ts-build-check 
2016-05-03 01:07:06 Z standalone.build-amd64 1 status status blocked
2016-05-03 01:07:06 Z finished standalone.build-amd64 ts-build-check blocked 
child process exited abnormally
+ OSSTEST_JOB=build-amd64
+ export OSSTEST_JOB
+ ./ts-build-check
2016-05-03 01:07:06 Z starting standalone.build-amd64
2016-05-03 01:07:06 Z setting arch=amd64
2016-05-03 01:07:06 Z setting build_lvextend_max=50
2016-05-03 01:07:06 Z setting enable_ovmf=true
2016-05-03 01:07:06 Z setting enable_xend=false
2016-05-03 01:07:06 Z setting enable_xsm=false
2016-05-03 01:07:06 Z setting host=g-vmtest
2016-05-03 01:07:06 Z setting 
host_hostflags=share-build-jessie-amd64,arch-amd64,suite-jessie,purpose-build
2016-05-03 01:07:06 Z setting revision_ovmf=
2016-05-03 01:07:06 Z setting revision_qemu=
2016-05-03 01:07:06 Z setting revision_qemuu=
2016-05-03 01:07:06 Z setting revision_seabios=
2016-05-03 01:07:06 Z setting revision_xen=
2016-05-03 01:07:06 Z setting tree_ovmf=
2016-05-03 01:07:06 Z setting 
tree_qemu=git://xenbits.xen.org/qemu-xen-traditional.git
2016-05-03 01:07:06 Z setting tree_qemuu=git://xenbits.xen.org/qemu-xen.git
2016-05-03 01:07:06 Z setting tree_seabios=
2016-05-03 01:07:06 Z setting tree_xen=git://xenbits.xen.org/xen.git
logs/standalone No such file or directory at Osstest.pm line 380.
+ rc=2
+ date -u +%Y-%m-%d %H:%M:%S Z exit status 2
2016-05-03 01:07:06 Z exit status 2
+ exit 2
2016-05-03 01:07:06 Z standalone.build-amd64 check-not-blocked failed:
test script failed

I am not an expert on Perl so I figured I missed some configuration
entry. Or perhaps is osstest.git suppose to be in ${WebspaceUrl} ?

Thanks!

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

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

[Jim Fehlig]

In LIBXL_API_VERSION 0x040400, the libxl_domain_create_restore API
gained a parameter for specifying restore parameters. Switch to
using version 0x040400, which will be useful in a subsequent commit
to specify the Xen migration stream version when restoring.

Signed-off-by: Jim Fehlig 
---
 configure.ac | 9 +
 src/libxl/libxl_domain.c | 6 +-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/configure.ac b/configure.ac
index 88e2e20..0da0f75 100644
--- a/configure.ac
+++ b/configure.ac
@@ -875,10 +875,11 @@ if test "$with_libxl" != "no" ; then
 fi
 fi
 
-# Until there is a need to use enhancements of libxl APIs such as
-# libxl_domain_create_restore and libxl_set_vcpuaffinity, stick with
-# the APIs as defined in libxl API version 4.2.0.
-LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040200"
+# LIBXL_API_VERSION 4.4.0 introduced a new parameter to
+# libxl_domain_create_restore for specifying restore parameters.
+# The libxl driver will make use of this new parameter for specifying
+# the Xen migration stream version.
+LIBXL_CFLAGS="$LIBXL_CFLAGS -DLIBXL_API_VERSION=0x040400"
 LIBS="$old_LIBS"
 CFLAGS="$old_CFLAGS"
 
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 14a900c..32ad946 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1028,6 +1028,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
 libxlDriverConfigPtr cfg;
 virHostdevManagerPtr hostdev_mgr = driver->hostdevMgr;
 libxl_asyncprogress_how aop_console_how;
+libxl_domain_restore_params params;
 
 libxl_domain_config_init(_config);
 
@@ -1115,8 +1116,11 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
 ret = libxl_domain_create_new(cfg->ctx, _config,
   , NULL, _console_how);
 } else {
+libxl_domain_restore_params_init();
 ret = libxl_domain_create_restore(cfg->ctx, _config, ,
-  restore_fd, NULL, _console_how);
+  restore_fd, , NULL,
+  _console_how);
+libxl_domain_restore_params_dispose();
 }
 virObjectLock(vm);
 
-- 
2.1.4


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

[Xen-devel] [PATCH 3/3] libxl: support migration stream V2 in migration

[Jim Fehlig]

Similar to "support Xen migration stream V2 in save/restore",
add support for indicating the migration stream version in
the migration code. To accomplish this, add a minimal migration
cookie in the libxl driver that is passed between source and
destination hosts. Initially, the cookie is only used in
the Begin and Prepare phases of migration to communicate the
version of the migration stream produced by the source.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_driver.c|  14 +--
 src/libxl/libxl_migration.c | 204 +++-
 src/libxl/libxl_migration.h |   6 +-
 3 files changed, 213 insertions(+), 11 deletions(-)

diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 8977ae2..062d6f8 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -5151,8 +5151,8 @@ static char *
 libxlDomainMigrateBegin3Params(virDomainPtr domain,
virTypedParameterPtr params,
int nparams,
-   char **cookieout ATTRIBUTE_UNUSED,
-   int *cookieoutlen ATTRIBUTE_UNUSED,
+   char **cookieout,
+   int *cookieoutlen,
unsigned int flags)
 {
 const char *xmlin = NULL;
@@ -5193,15 +5193,16 @@ libxlDomainMigrateBegin3Params(virDomainPtr domain,
 return NULL;
 }
 
-return libxlDomainMigrationBegin(domain->conn, vm, xmlin);
+return libxlDomainMigrationBegin(domain->conn, vm, xmlin,
+ cookieout, cookieoutlen);
 }
 
 static int
 libxlDomainMigratePrepare3Params(virConnectPtr dconn,
  virTypedParameterPtr params,
  int nparams,
- const char *cookiein ATTRIBUTE_UNUSED,
- int cookieinlen ATTRIBUTE_UNUSED,
+ const char *cookiein,
+ int cookieinlen,
  char **cookieout ATTRIBUTE_UNUSED,
  int *cookieoutlen ATTRIBUTE_UNUSED,
  char **uri_out,
@@ -5240,7 +5241,8 @@ libxlDomainMigratePrepare3Params(virConnectPtr dconn,
 if (virDomainMigratePrepare3ParamsEnsureACL(dconn, def) < 0)
 goto error;
 
-if (libxlDomainMigrationPrepare(dconn, , uri_in, uri_out, flags) < 0)
+if (libxlDomainMigrationPrepare(dconn, , uri_in, uri_out,
+cookiein, cookieinlen, flags) < 0)
 goto error;
 
 return 0;
diff --git a/src/libxl/libxl_migration.c b/src/libxl/libxl_migration.c
index 1d4ec5e..ad54960 100644
--- a/src/libxl/libxl_migration.c
+++ b/src/libxl/libxl_migration.c
@@ -48,6 +48,18 @@
 
 VIR_LOG_INIT("libxl.libxl_migration");
 
+typedef struct _libxlMigrationCookie libxlMigrationCookie;
+typedef libxlMigrationCookie *libxlMigrationCookiePtr;
+struct _libxlMigrationCookie {
+/* Host properties */
+char *srcHostname;
+uint32_t xenMigStreamVer;
+
+/* Guest properties */
+unsigned char uuid[VIR_UUID_BUFLEN];
+char *name;
+};
+
 typedef struct _libxlMigrationDstArgs {
 virObject parent;
 
@@ -55,6 +67,7 @@ typedef struct _libxlMigrationDstArgs {
 virConnectPtr conn;
 virDomainObjPtr vm;
 unsigned int flags;
+libxlMigrationCookiePtr migcookie;
 
 /* for freeing listen sockets */
 virNetSocketPtr *socks;
@@ -63,11 +76,166 @@ typedef struct _libxlMigrationDstArgs {
 
 static virClassPtr libxlMigrationDstArgsClass;
 
+
+static void
+libxlMigrationCookieFree(libxlMigrationCookiePtr mig)
+{
+if (!mig)
+return;
+
+VIR_FREE(mig->srcHostname);
+VIR_FREE(mig->name);
+VIR_FREE(mig);
+}
+
+static libxlMigrationCookiePtr
+libxlMigrationCookieNew(virDomainObjPtr dom)
+{
+libxlMigrationCookiePtr mig = NULL;
+
+if (VIR_ALLOC(mig) < 0)
+goto error;
+
+if (VIR_STRDUP(mig->name, dom->def->name) < 0)
+goto error;
+
+memcpy(mig->uuid, dom->def->uuid, VIR_UUID_BUFLEN);
+
+if (!(mig->srcHostname = virGetHostname()))
+goto error;
+
+mig->xenMigStreamVer = LIBXL_SAVE_VERSION;
+
+return mig;
+
+ error:
+libxlMigrationCookieFree(mig);
+return NULL;
+}
+
+
+static int
+libxlMigrationBakeCookie(libxlMigrationCookiePtr mig,
+ char **cookieout,
+ int *cookieoutlen)
+{
+virBuffer buf = VIR_BUFFER_INITIALIZER;
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+
+if (!cookieout || !cookieoutlen)
+return 0;
+
+*cookieoutlen = 0;
+virUUIDFormat(mig->uuid, uuidstr);
+
+virBufferAddLit(, "\n");
+virBufferAdjustIndent(, 2);
+virBufferEscapeString(, "%s\n", mig->name);
+virBufferAsprintf(, "%s\n", uuidstr);
+virBufferEscapeString(, "%s\n", mig->srcHostname);
+virBufferAsprintf(, 
"%u\n", 

[Xen-devel] [PATCH 2/3] libxl: support Xen migration stream V2 in save/restore

[Jim Fehlig]

Xen 4.6 introduced a new migration stream commonly referred to as
"migration V2". Xen 4.6 and newer always produce this new stream,
whereas Xen 4.5 and older always produce the legacy stream.
Support for migration stream V2 can be detected at build time with
LIBXL_HAVE_SRM_V2 from libxl.h. The legacy and V2 streams are not
compatible, but a V2 host can accept and convert a legacy stream.

Commit e7440656 changed the libxl driver to use the lowest libxl
API version possible (version 0x040200) to ensure the driver
builds against older Xen releases. The old 4.2 restore API does
not support specifying a stream version and assumes a legacy
stream, even if the incoming stream is migration V2. Thinking it
has been given a legacy stream, libxl will fail to convert an
incoming stream that is already V2, which causes the entire
restore operation to fail. Xen's libvirt-related OSSTest has been
failing since commit e7440656 landed in libvirt.git master. One
of the more recent failures can be seen here

http://lists.xenproject.org/archives/html/xen-devel/2016-05/msg00071.html

This patch changes the call to libxl_domain_create_restore() to
include the stream version if LIBXL_HAVE_SRM_V2 is defined. The
version field of the libxlSavefileHeader struct is also updated
to '2' when LIBXL_HAVE_SRM_V2 is defined, ensuring the stream
version in the header matches the actual stream version produced
by Xen. Along with bumping the libxl API requirement to 0x040400,
this patch fixes save/restore on a migration V2 Xen host.

Oddly, migration has never used the libxlSavefileHeader. It
handles passing configuration in the Begin and Prepare phases,
and then calls libxl directly to transfer domain state/memory
in the Perform phase. A subsequent patch will add stream
version handling in the Begin and Prepare phase handshaking,
which will fix the migration related OSSTest failures.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_conf.h  |  6 +-
 src/libxl/libxl_domain.c| 40 
 src/libxl/libxl_domain.h| 14 ++
 src/libxl/libxl_driver.c| 13 -
 src/libxl/libxl_migration.c |  2 +-
 5 files changed, 60 insertions(+), 15 deletions(-)

diff --git a/src/libxl/libxl_conf.h b/src/libxl/libxl_conf.h
index 24e2911..c5b9429 100644
--- a/src/libxl/libxl_conf.h
+++ b/src/libxl/libxl_conf.h
@@ -148,7 +148,11 @@ struct _libxlDriverPrivate {
 };
 
 # define LIBXL_SAVE_MAGIC "libvirt-xml\n \0 \r"
-# define LIBXL_SAVE_VERSION 1
+# ifdef LIBXL_HAVE_SRM_V2
+#  define LIBXL_SAVE_VERSION 2
+# else
+#  define LIBXL_SAVE_VERSION 1
+# endif
 
 typedef struct _libxlSavefileHeader libxlSavefileHeader;
 typedef libxlSavefileHeader *libxlSavefileHeaderPtr;
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 32ad946..5fa1bd9 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -514,7 +514,7 @@ libxlDomainShutdownThread(void *opaque)
 }
 libxlDomainDestroyInternal(driver, vm);
 libxlDomainCleanup(driver, vm);
-if (libxlDomainStart(driver, vm, false, -1) < 0) {
+if (libxlDomainStartNew(driver, vm, false) < 0) {
 virErrorPtr err = virGetLastError();
 VIR_ERROR(_("Failed to restart VM '%s': %s"),
   vm->def->name, err ? err->message : _("unknown error"));
@@ -1006,14 +1006,23 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def, 
libxl_domain_config *d_config)
 }
 
 
+#ifdef LIBXL_HAVE_SRM_V2
+# define LIBXL_DOMSTART_RESTORE_VER_ATTR /* empty */
+#else
+# define LIBXL_DOMSTART_RESTORE_VER_ATTR ATTRIBUTE_UNUSED
+#endif
+
 /*
  * Start a domain through libxenlight.
  *
  * virDomainObjPtr must be locked and a job acquired on invocation
  */
-int
-libxlDomainStart(libxlDriverPrivatePtr driver, virDomainObjPtr vm,
- bool start_paused, int restore_fd)
+static int
+libxlDomainStart(libxlDriverPrivatePtr driver,
+ virDomainObjPtr vm,
+ bool start_paused,
+ int restore_fd,
+ uint32_t restore_ver LIBXL_DOMSTART_RESTORE_VER_ATTR)
 {
 libxl_domain_config d_config;
 virDomainDefPtr def = NULL;
@@ -1049,6 +1058,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
 goto cleanup;
 
 restore_fd = managed_save_fd;
+restore_ver = hdr.version;
 
 if (STRNEQ(vm->def->name, def->name) ||
 memcmp(vm->def->uuid, def->uuid, VIR_UUID_BUFLEN)) {
@@ -1117,6 +1127,9 @@ libxlDomainStart(libxlDriverPrivatePtr driver, 
virDomainObjPtr vm,
   , NULL, _console_how);
 } else {
 libxl_domain_restore_params_init();
+#ifdef LIBXL_HAVE_SRM_V2
+params.stream_version = restore_ver;
+#endif
 ret = libxl_domain_create_restore(cfg->ctx, _config, ,
   restore_fd, , NULL,
   _console_how);
@@ -1203,6 +1216,25 @@ 

[Xen-devel] [PATCH 0/3] libxl: support Xen migration stream V2

[Jim Fehlig]

Hi all,

This patch adds support for Xen migration stream V2 to the libvirt
libxl driver. In the process it fixes save/restore and migration
tests in OSSTest, which have been failing since libvirt commit
e7440656.

Patch1 changes the libxl API requirement from version 4.2 to 4.4,
enabling use of an extended libxl_domain_create_restore() function
that allows passing restore parameters such as stream version.

Patch2 adds support for migration stream V2 in the basic save/restore
logic, taking advantage of a save image header that includes a version
field. The version is set to '2' if the host produces a V2 migration
stream. This patch fixes the failing save/restore tests in OSSTest.

Patch3 adds support for migration stream V2 in the migration logic.
The migration code does not use the save image header and instead
uses libvirt's migration protocol to transfer domain configuration
and other such goodies from source to destination. The patch
enables sending version information in the Begin and Prepare
migration phases so the correct stream version information can be
passed to libxl_domain_create_restore(). An upshot of this approach
is safely detecting and aborting a migration from a V2 host to a
V1-only host. This patch fixes the failing migration tests in
OSSTest.

Jim Fehlig (3):
  libxl: switch to using libxl_domain_create_restore from v4.4 API
  libxl: support Xen migration stream V2 in save/restore
  libxl: support migration stream V2 in migration

 configure.ac|   9 +-
 src/libxl/libxl_conf.h  |   6 +-
 src/libxl/libxl_domain.c|  46 --
 src/libxl/libxl_domain.h|  14 ++-
 src/libxl/libxl_driver.c|  27 +++---
 src/libxl/libxl_migration.c | 204 +++-
 src/libxl/libxl_migration.h |   6 +-
 7 files changed, 282 insertions(+), 30 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 4.5 035/200] x86/mm/xen: Suppress hugetlbfs in PV guests

[Greg Kroah-Hartman]

4.5-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/hugetlb.h |1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,



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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  15 guest-start/debian.repeat fail REGR. vs. 93337

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

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-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-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  7f62212d992fb8ae600faf6009475692a025bf99
baseline version:
 xen  c2994f8632d56e5379e612daa216401477dccbdb

Last test of basis93337  2016-05-02 01:57:38 Z0 days
Testing same since93364  2016-05-02 13:47:09 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Tim Deegan 
  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
 

[Xen-devel] [PATCH 4.4 027/163] x86/mm/xen: Suppress hugetlbfs in PV guests

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Beulich 

commit 103f6112f253017d7062cd74d17f4a514ed4485c upstream.

Huge pages are not normally available to PV guests. Not suppressing
hugetlbfs use results in an endless loop of page faults when user mode
code tries to access a hugetlbfs mapped area (since the hypervisor
denies such PTEs to be created, but error indications can't be
propagated out of xen_set_pte_at(), just like for various of its
siblings), and - once killed in an oops like this:

  kernel BUG at .../fs/hugetlbfs/inode.c:428!
  invalid opcode:  [#1] SMP
  ...
  RIP: e030:[]  [] 
remove_inode_hugepages+0x25b/0x320
  ...
  Call Trace:
   [] hugetlbfs_evict_inode+0x15/0x40
   [] evict+0xbd/0x1b0
   [] __dentry_kill+0x19a/0x1f0
   [] dput+0x1fe/0x220
   [] __fput+0x155/0x200
   [] task_work_run+0x60/0xa0
   [] do_exit+0x160/0x400
   [] do_group_exit+0x3b/0xa0
   [] get_signal+0x1ed/0x470
   [] do_signal+0x14/0x110
   [] prepare_exit_to_usermode+0xe9/0xf0
   [] retint_user+0x8/0x13

This is CVE-2016-3961 / XSA-174.

Reported-by: Vitaly Kuznetsov 
Signed-off-by: Jan Beulich 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: David Vrabel 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Luis R. Rodriguez 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Toshi Kani 
Cc: xen-devel 
Link: http://lkml.kernel.org/r/57188ed80278000e4...@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/include/asm/hugetlb.h |1 +
 1 file changed, 1 insertion(+)

--- a/arch/x86/include/asm/hugetlb.h
+++ b/arch/x86/include/asm/hugetlb.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 
+#define hugepages_supported() cpu_has_pse
 
 static inline int is_hugepage_only_range(struct mm_struct *mm,
 unsigned long addr,



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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  146 days
Failing since 65593  2015-12-08 23:44:51 Z  145 days  202 attempts
Testing same since93232  2016-04-29 20:13:53 Z3 days   11 attempts


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

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

[gre...@linuxfoundation.org]

On Wed, Mar 30, 2016 at 05:04:28AM +1100, Steven Haigh wrote:
> Greg, please see below - this is probably more for you...
> 
> On 03/29/2016 04:56 AM, Steven Haigh wrote:
> >
> > Interestingly enough, this just happened again - but on a different
> > virtual machine. I'm starting to wonder if this may have something to do
> > with the uptime of the machine - as the system that this seems to happen
> > to is always different.
> >
> > Destroying it and monitoring it again has so far come up blank.
> >
> > I've thrown the latest lot of kernel messages here:
> >  http://paste.fedoraproject.org/346802/59241532
> 
> So I just did a bit of digging via the almighty Google.
> 
> I started hunting for these lines, as they happen just before the stall:
> BUG: Bad rss-counter state mm:88007b7db480 idx:2 val:-1
> BUG: Bad rss-counter state mm:880079c638c0 idx:0 val:-1
> BUG: Bad rss-counter state mm:880079c638c0 idx:2 val:-1
> 
> I stumbled across this post on the lkml:
> http://marc.info/?l=linux-kernel=145141546409607
> 
> The patch attached seems to reference the following change in
> unmap_mapping_range in mm/memory.c:
> > -   struct zap_details details;
> > +   struct zap_details details = { };
> 
> When I browse the GIT tree for 4.4.6:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/mm/memory.c?id=refs/tags/v4.4.6
> 
> I see at line 2411:
> struct zap_details details;
> 
> Is this something that has been missed being merged into the 4.4 tree?
> I'll admit my kernel knowledge is not enough to understand what the code
> actually does - but the similarities here seem uncanny.

I'm sorry, I have no idea what you are asking me about here.  Did I miss
a patch that should be backported?  Did I backport something
incorrectly?

confused,

greg k-h

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

[Xen-devel] [qemu-mainline test] 93362: trouble: broken/fail/pass

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-libvirt  3 host-install(3) broken REGR. vs. 93237

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail REGR. vs. 93237
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93237
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93237

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

version targeted for testing:
 qemuu20b0f5fef66012e12bde32b14eaa64de2b1b9dbe
baseline version:
 qemuu47dac82d8b013a5c7dd044a797ae6727b553959a

Last test of basis93237  2016-04-30 02:12:43 Z2 days
Testing same since93362  2016-05-02 11:13:06 Z0 days1 attempts


People who touched revisions under test:
  Igor Mammedov 
  Laurent Vivier 
  Michael S. Tsirkin 
  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
 

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Greg KH]

On Mon, May 02, 2016 at 11:34:33AM -0700, Kees Cook wrote:
> On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez  wrote:
> > On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote:
> >> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
> >> > This ports built-in firmware to use linker tables,
> >> > this replaces the custom section solution with a
> >> > generic solution.
> >> >
> >> > This also demos the use of the .rodata (SECTION_RO)
> >> > linker tables.
> >> >
> >> > Tested with 0 built-in firmware, 1 and 2 built-in
> >> > firmwares successfully.
> >>
> >> I think we'd do better to rip this support out entirely. It just isn't
> >> needed; firmware can live in an initramfs and don't even need *any*
> >> actual running userspace support to load it from there these days, do
> >> we?
> >
> > I think this is reasonable if and only if we really don't know of anyone
> > out there not able to use initramfs. I'm happy to rip it out.
> 
> The changelog for this doesn't say anything about _why_ the change is
> being made? (and what about other architectures.) Also, Chrome OS
> doesn't use an initramfs (and plenty of other things don't too). Being
> able to build monolithic kernels (e.g. Android and Brillo) with
> builtin firmware is very handy. Please don't remove built-in firmware
> support.

I second this, we can't break existing systems at all.  I thought we
were going to keep built-in firmware, right Luis?

thanks,

greg k-h

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

Re: [Xen-devel] [RFC v2 3/7] firmware: port built-in section to linker table

[Kees Cook]

On Mon, Feb 29, 2016 at 10:56 AM, Luis R. Rodriguez  wrote:
> On Mon, Feb 29, 2016 at 10:12:50AM +, David Woodhouse wrote:
>> On Fri, 2016-02-19 at 05:45 -0800, Luis R. Rodriguez wrote:
>> > This ports built-in firmware to use linker tables,
>> > this replaces the custom section solution with a
>> > generic solution.
>> >
>> > This also demos the use of the .rodata (SECTION_RO)
>> > linker tables.
>> >
>> > Tested with 0 built-in firmware, 1 and 2 built-in
>> > firmwares successfully.
>>
>> I think we'd do better to rip this support out entirely. It just isn't
>> needed; firmware can live in an initramfs and don't even need *any*
>> actual running userspace support to load it from there these days, do
>> we?
>
> I think this is reasonable if and only if we really don't know of anyone
> out there not able to use initramfs. I'm happy to rip it out.

The changelog for this doesn't say anything about _why_ the change is
being made? (and what about other architectures.) Also, Chrome OS
doesn't use an initramfs (and plenty of other things don't too). Being
able to build monolithic kernels (e.g. Android and Brillo) with
builtin firmware is very handy. Please don't remove built-in firmware
support.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

Re: [Xen-devel] [PATCH] xen/x86: don't lose event interrupts

[Roger Pau Monné]

On Thu, Apr 21, 2016 at 02:34:25PM +0100, Stefano Stabellini wrote:
> xen/x86: don't lose event interrupts
> 
> On slow platforms with unreliable TSC, such as QEMU emulated machines,
> it is possible for the FreeBSD kernel to request the next event in the
> past. In that case, in the current implementation of
> xentimer_vcpu_start_timer, we simply return -ETIME. To be precise Xen
> returns -ETIME and we pass it on. As a consequence we need to loop
> around to function to make sure that the timer is properly set.
> 
> Instead it is better to always ask the hypervisor for a timer event,
> even if the timeout is past. To do that, remove the VCPU_SSHOTTMR_future
> flag.
> 
> Signed-off-by: Stefano Stabellini 

Thanks, it's now committed:

https://svnweb.freebsd.org/base?view=revision=298926

Roger.

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

[Xen-devel] [qemu-upstream-4.6-testing test] 93357: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail REGR. vs. 83624
 test-armhf-armhf-xl-arndale   6 xen-boot  fail REGR. vs. 83624

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 83624
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 83624

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

version targeted for testing:
 qemuu62936f64308aae81530b1273ad2c248b6476e62e
baseline version:
 qemuu9869880372c8e786502ce140d50158118e29a165

Last test of basis83624  2016-02-22 06:20:45 Z   70 days
Testing same since93357  2016-05-02 09:44:06 Z0 days1 attempts


People who touched revisions under test:
  "Hao, Xudong" 
  Anthony Perard 
  Stefano Stabellini 
  Stefano Stabellini 
  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-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-xsmpass
 

[Xen-devel] [PATCH v2] build: change MINI-OS_ROOT to MINIOS_ROOT

[Wei Liu]

In the GNU make manual "How to Use Variables" section there is such
word:

"However, variable names containing characters other than letters,
numbers, and underscores should be considered carefully, as in some
shells they cannot be passed through the environment to a sub-make (see
Communicating Variables to a Sub-make)."

I discover xen stubdom fails to build on Ubuntu 16.04 and Debian
unstable due to MINI-OS_ROOT is not preserved in the invocation of
sub-make, while stubdom builds fine on older versions of Ubuntu and
Debian. It's hard to track down what exactly is changed in those
systems, but changing MINI-OS_ROOT to MINIOS_ROOT fixes the problem.

Signed-off-by: Wei Liu 
Acked-by: Samuel Thibault 
---
Cc: Samuel Thibault 
Cc: xen-de...@lists.xenproject.org

v2: use MINIOS_ROOT instead
---
 Config.mk| 14 +++---
 Makefile |  2 +-
 config/MiniOS.mk |  4 ++--
 minios.mk|  8 
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/Config.mk b/Config.mk
index e5d8ade..9d19cd7 100644
--- a/Config.mk
+++ b/Config.mk
@@ -27,11 +27,11 @@ cc-option = $(shell if test -z "`echo 'void*p=1;' | \
 # stubdom, some XEN_ variables are set, set MINIOS_ variables accordingly.
 #
 ifneq ($(XEN_ROOT),)
-MINI-OS_ROOT=$(XEN_ROOT)/extras/mini-os
+MINIOS_ROOT=$(XEN_ROOT)/extras/mini-os
 else
-MINI-OS_ROOT=$(TOPLEVEL_DIR)
+MINIOS_ROOT=$(TOPLEVEL_DIR)
 endif
-export MINI-OS_ROOT
+export MINIOS_ROOT
 
 ifneq ($(XEN_TARGET_ARCH),)
 MINIOS_TARGET_ARCH = $(XEN_TARGET_ARCH)
@@ -78,16 +78,16 @@ EXTRA_INC = $(ARCH_INC)
 
 # Include the architecture family's special makerules.
 # This must be before include minios.mk!
-include $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+include $(MINIOS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
-extra_incl := $(foreach dir,$(EXTRA_INC),-isystem 
$(MINI-OS_ROOT)/include/$(dir))
+extra_incl := $(foreach dir,$(EXTRA_INC),-isystem 
$(MINIOS_ROOT)/include/$(dir))
 
-DEF_CPPFLAGS += -isystem $(MINI-OS_ROOT)/include
+DEF_CPPFLAGS += -isystem $(MINIOS_ROOT)/include
 DEF_CPPFLAGS += -D__MINIOS__
 
 ifeq ($(libc),y)
 DEF_CPPFLAGS += -DHAVE_LIBC
-DEF_CPPFLAGS += -isystem $(MINI-OS_ROOT)/include/posix
+DEF_CPPFLAGS += -isystem $(MINIOS_ROOT)/include/posix
 DEF_CPPFLAGS += -isystem $(XEN_ROOT)/tools/xenstore/include
 endif
 
diff --git a/Makefile b/Makefile
index cfe015a..10c05a5 100644
--- a/Makefile
+++ b/Makefile
@@ -14,7 +14,7 @@ EXTRA_DEPS += $(MINIOS_CONFIG)
 include $(MINIOS_CONFIG)
 endif
 
-include $(MINI-OS_ROOT)/config/MiniOS.mk
+include $(MINIOS_ROOT)/config/MiniOS.mk
 
 # Configuration defaults
 CONFIG_START_NETWORK ?= y
diff --git a/config/MiniOS.mk b/config/MiniOS.mk
index e4febe4..be542dc 100644
--- a/config/MiniOS.mk
+++ b/config/MiniOS.mk
@@ -1,5 +1,5 @@
-include $(MINI-OS_ROOT)/config/StdGNU.mk
-include $(MINI-OS_ROOT)/Config.mk
+include $(MINIOS_ROOT)/config/StdGNU.mk
+include $(MINIOS_ROOT)/Config.mk
 CFLAGS += $(DEF_CFLAGS) $(ARCH_CFLAGS)
 CPPFLAGS += $(DEF_CPPFLAGS) $(ARCH_CPPFLAGS) $(extra_incl)
 ASFLAGS += $(DEF_ASFLAGS) $(ARCH_ASFLAGS)
diff --git a/minios.mk b/minios.mk
index e042027..89534f7 100644
--- a/minios.mk
+++ b/minios.mk
@@ -39,12 +39,12 @@ LDFLAGS := $(DEF_LDFLAGS) $(ARCH_LDFLAGS)
 
 # Special build dependencies.
 # Rebuild all after touching this/these file(s)
-EXTRA_DEPS += $(MINI-OS_ROOT)/minios.mk
-EXTRA_DEPS += $(MINI-OS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
+EXTRA_DEPS += $(MINIOS_ROOT)/minios.mk
+EXTRA_DEPS += $(MINIOS_ROOT)/$(TARGET_ARCH_DIR)/arch.mk
 
 # Find all header files for checking dependencies.
-HDRS := $(wildcard $(MINI-OS_ROOT)/include/*.h)
-HDRS += $(wildcard $(MINI-OS_ROOT)/include/xen/*.h)
+HDRS := $(wildcard $(MINIOS_ROOT)/include/*.h)
+HDRS += $(wildcard $(MINIOS_ROOT)/include/xen/*.h)
 HDRS += $(wildcard $(ARCH_INC)/*.h)
 # For special wanted header directories.
 extra_heads := $(foreach dir,$(EXTRA_INC),$(wildcard $(dir)/*.h))
-- 
2.1.4


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

[Xen-devel] Patch to honor --enable-githttp

[Paul Lai]

commit 747f48e6dd7bcc2fbe14d37c62018c5c9e0e44c8
Author: Paul Lai 
Date:   Mon Apr 11 10:43:57 2016 -0700

Honor '--enable-githttp' in toplevel Makefile generation

During the make world, git mini-os.git didn't honor the 'configure
--enable-githttp' option.  The 'enable-githttp' was only honored in
the tools subdirectory.

Signed-off-by: Paul Lai 

diff --git a/config/Toplevel.mk.in b/config/Toplevel.mk.in
index 4db7eaf..1d99189 100644
--- a/config/Toplevel.mk.in
+++ b/config/Toplevel.mk.in
@@ -1 +1,2 @@
 SUBSYSTEMS   := @SUBSYSTEMS@
+GIT_HTTP := @githttp@
diff --git a/configure b/configure
index 3c269fa..78e8025 100755
--- a/configure
+++ b/configure
@@ -594,6 +594,7 @@ stubdom
 tools
 xen
 subdirs
+githttp
 XEN_DUMP_DIR
 XEN_PAGING_DIR
 XEN_LOCK_DIR
@@ -660,6 +661,7 @@ enable_option_checking
 with_initddir
 with_sysconfig_leaf_dir
 with_xen_dumpdir
+enable_githttp
 enable_xen
 enable_tools
 enable_stubdom
@@ -1284,6 +1286,8 @@ Optional Features:
   --disable-option-checking  ignore unrecognized --enable/--with options
   --disable-FEATURE   do not include FEATURE (same as --enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
+  --enable-githttpDownload GIT repositories via HTTP (default is
+  DISABLED)
   --disable-xen   Disable build and install of xen
   --disable-tools Disable build and install of tools
   --enable-stubdomEnable build and install of stubdom
@@ -1985,6 +1989,29 @@ XEN_DUMP_DIR=$xen_dumpdir_path
 
 
 
+# Check whether --enable-githttp was given.
+if test "${enable_githttp+set}" = set; then :
+  enableval=$enable_githttp;
+fi
+
+
+if test "x$enable_githttp" = "xno"; then :
+
+ax_cv_githttp="n"
+
+elif test "x$enable_githttp" = "xyes"; then :
+
+ax_cv_githttp="y"
+
+elif test -z $ax_cv_githttp; then :
+
+ax_cv_githttp="n"
+
+fi
+githttp=$ax_cv_githttp
+
+
+
 case "$host_cpu" in
 i[3456]86|x86_64)
 arch_enable_stubdom=y
diff --git a/configure.ac b/configure.ac
index 1843b52..7388b28 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ m4_include([m4/subsystem.m4])
 m4_include([m4/paths.m4])
 
 AX_XEN_EXPAND_CONFIG()
+AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
 
 dnl mini-os is only ported to certain platforms
 case "$host_cpu" in

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

[Xen-devel] Patch to honor --enable-githttp

[Lai, Paul C]

The following patch fixes the toplevel Xen makefile gereration to honor 
-enable-githttp if the option is used during configuration.


commit 040510913564ec7e9f46ce833f8bdf1a40950ff7
Author: Paul Lai 
Date:   Mon Apr 11 10:43:57 2016 -0700

Honor '--enable-githttp' in toplevel Makefile generation

During the make world, git mini-os.git didn't honor the 'configure
--enable-githttp' option.  The 'enable-githttp' was only honored in
the tools subdirectory.

diff --git a/config/Toplevel.mk.in b/config/Toplevel.mk.in
index 4db7eaf..1d99189 100644
--- a/config/Toplevel.mk.in
+++ b/config/Toplevel.mk.in
@@ -1 +1,2 @@
SUBSYSTEMS   := @SUBSYSTEMS@
+GIT_HTTP := @githttp@
diff --git a/configure b/configure
index 3c269fa..78e8025 100755
--- a/configure
+++ b/configure
@@ -594,6 +594,7 @@ stubdom
tools
xen
subdirs
+githttp
XEN_DUMP_DIR
XEN_PAGING_DIR
XEN_LOCK_DIR
@@ -660,6 +661,7 @@ enable_option_checking
with_initddir
with_sysconfig_leaf_dir
with_xen_dumpdir
+enable_githttp
enable_xen
enable_tools
enable_stubdom
@@ -1284,6 +1286,8 @@ Optional Features:
   --disable-option-checking  ignore unrecognized --enable/--with options
   --disable-FEATURE   do not include FEATURE (same as --enable-FEATURE=no)
   --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
+  --enable-githttpDownload GIT repositories via HTTP (default is
+  DISABLED)
   --disable-xen   Disable build and install of xen
   --disable-tools Disable build and install of tools
   --enable-stubdomEnable build and install of stubdom
@@ -1985,6 +1989,29 @@ XEN_DUMP_DIR=$xen_dumpdir_path


+# Check whether --enable-githttp was given.
+if test "${enable_githttp+set}" = set; then :
+  enableval=$enable_githttp;
+fi
+
+
+if test "x$enable_githttp" = "xno"; then :
+
+ax_cv_githttp="n"
+
+elif test "x$enable_githttp" = "xyes"; then :
+
+ax_cv_githttp="y"
+
+elif test -z $ax_cv_githttp; then :
+
+ax_cv_githttp="n"
+
+fi
+githttp=$ax_cv_githttp
+
+
+
case "$host_cpu" in
 i[3456]86|x86_64)
 arch_enable_stubdom=y
diff --git a/configure.ac b/configure.ac
index 1843b52..7388b28 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,7 @@ m4_include([m4/subsystem.m4])
m4_include([m4/paths.m4])
 AX_XEN_EXPAND_CONFIG()
+AX_ARG_DEFAULT_DISABLE([githttp], [Download GIT repositories via HTTP])
 dnl mini-os is only ported to certain platforms
case "$host_cpu" in




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

[Xen-devel] Altp2m misbehavior

[Lai, Paul C]

Hello list:

Been playing with the altp2m code and noticed that it's not behaving in Xen 4.7 
tree.
Two changesets have been identified as where the be behavior changes.

The change is commit bd2239d9fa975a1ee5bcd27c218ae042cd0a57bc,
  x86/HVM: always intercept #AC and #DB
where an executable goes from working to crashing after a 10+ hypercalls.

The second change is in commit 484c14b7254e8d8936c05e3c28e332ea825c0155:
   x86/vmx: enable PML by default
This hangs the VM guest on the first few hypercalls.

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

Re: [Xen-devel] [RFC PATCH 7/7] build: convert lock_profile to Kconfig

[Konrad Rzeszutek Wilk]

On Sun, May 01, 2016 at 11:10:46PM -0500, Doug Goldstein wrote:
> Convert the 'lock_profile' option to Kconfig as CONFIG_LOCK_PROFILE.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> ---
>  INSTALL|  1 -
>  xen/Kconfig.debug  |  6 ++
>  xen/Rules.mk   |  2 --
>  xen/arch/arm/xen.lds.S |  2 +-
>  xen/arch/x86/domain.c  |  2 +-
>  xen/arch/x86/xen.lds.S |  2 +-
>  xen/common/keyhandler.c|  2 +-
>  xen/common/spinlock.c  | 10 +-
>  xen/common/sysctl.c|  2 +-
>  xen/include/xen/spinlock.h |  4 ++--
>  10 files changed, 18 insertions(+), 15 deletions(-)
> 
> diff --git a/INSTALL b/INSTALL
> index 623887d..616a67a 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
>  
>  The following variables can be used to tweak some aspects of the
>  hypervisor build.
> -lock_profile=y
>  lto=y
>  
>  During tools build external repos will be cloned into the source tree.
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 4727273..5b370e8 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -28,6 +28,12 @@ config FRAME_POINTER
> maybe slower, but it gives very useful debugging information
> in case of any Xen bugs.
>  
> +config LOCK_PROFILE
> + bool "Lock Profiiling"
> + default n
> + ---help---
> +   Lock Profiling

Would it make sense to also mention what tool one can use this with?

Perhaps:

"Lock profiling allows you to see how often locks are taken and blocked.
You can use serial console to print (and reset) using 'l' and 'L'
respectively, or the 'xenlockprof' tool.

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

Re: [Xen-devel] [RFC PATCH 5/7] build: wire up pre-existing debug build flag

[Konrad Rzeszutek Wilk]

On Sun, May 01, 2016 at 11:10:44PM -0500, Doug Goldstein wrote:
> This allows 'make debug=n' and 'make debug=y' work as it did previously
> but only in the case of the user not having an existing .config file
> from a 'make menuconfig'. This is because the command line 'debug' flag
> can only be used to set the default value and if the user has already
> built up a config their have their real preference set.

s/their have their/with their/ ?

Thank you for making this work.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> ---
>  xen/Kconfig.debug | 5 +
>  xen/Makefile  | 1 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 0b2ec50..ec27b09 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -1,6 +1,11 @@
> +config DEBUG_ENV
> + bool
> + option env="debug"
>  
>  menuconfig DEBUG
>   bool "Debugging Options"
> + default y if DEBUG_ENV = "y"
> + default n
>   ---help---
> If you want to debug Xen say Y and select any additional debugging
> support options. This enables additional debugging through Xen
> diff --git a/xen/Makefile b/xen/Makefile
> index f49014b..e2da895 100644
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -27,6 +27,7 @@ SRCARCH=$(shell echo $(ARCH) | sed -e 's/x86.*/x86/' -e 
> s'/arm\(32\|64\)/arm/g')
>  # Don't break if the build process wasn't called from the top level
>  # we need XEN_TARGET_ARCH to generate the proper config
>  include $(XEN_ROOT)/Config.mk
> +export debug
>  
>  # Allow someone to change their config file
>  export KCONFIG_CONFIG ?= .config
> -- 
> 2.7.3
> 

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

Re: [Xen-devel] [RFC PATCH 4/7] build: convert frame_pointer to Kconfig

[Jan Beulich]

>>> On 02.05.16 at 17:25,  wrote:
> On Sun, May 01, 2016 at 11:10:43PM -0500, Doug Goldstein wrote:
>> --- a/xen/Kconfig.debug
>> +++ b/xen/Kconfig.debug
>> @@ -15,6 +15,14 @@ config CRASH_DEBUG
>>If you want to be able to attach gdb to Xen to be able to debug
>>Xen if it crashes then say Y.
>>  
>> +config FRAME_POINTER
>> +bool "Compile Xen with frame pointers"
>> +default y
>> +---help---
>> +  If you say Y here the resulting Xen will be slightly larger and
>> +  maybe slower, but it gives very useful debugging information
> 
> The extra cost is:
> 
>  leaq  offs(%rsp),%rbp;
>  notq  %rbp   
> 
> On entry in hypervisor.

An higher register pressure.

> Perhaps just say two extra operations are added on every vmexit ?
> 
> Is there an use-case for _not_ having frame pointers?

Yes - having one more register available for the compiler to put
data in. That's why we build with frame pointers in debug mode
only by default.

Jan


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

Re: [Xen-devel] [PATCH v2 4/5] x86/hvm: Add debug exception vm_events

[Tamas K Lengyel]

On May 2, 2016 09:40, "Jan Beulich"  wrote:
>
> >>> On 02.05.16 at 17:35,  wrote:
> > On May 2, 2016 07:12, "Jan Beulich"  wrote:
> >>
> >> >>> On 29.04.16 at 20:07,  wrote:
> >> > @@ -229,8 +231,15 @@ struct vm_event_write_ctrlreg {
> >> >  uint64_t old_value;
> >> >  };
> >> >
> >> > +struct vm_event_singlestep {
> >> > +uint64_t gfn;
> >> > +};
> >> > +
> >> >  struct vm_event_debug {
> >> >  uint64_t gfn;
> >> > +uint8_t type;/* HVMOP_TRAP_* */
> >> > +uint8_t insn_length;
> >> > +uint8_t _pad[6];
> >> >  };
> >>
> >> This being an incompatible change - didn't you mean to increment some
> >> version number?
> >
> > I'm not sure. It would still work with clients compiled with the older
> > version of the header as the layout of the debug struct didnt change,
was
> > just appended. The size of the request/response struct didn't change
either
> > so technically this would still be backwards compatible.
>
> But you also need to consider the other direction: Code compiled
> against the new variant, but running on an older hypervisor would
> expect the new fields to be valid, yet they can't be, and the caller
> has no way to know.

Fair point, will incrementnthe version.

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

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

[osstest service owner]

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

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  356b5512b0dc9ce81a8007983a110de9798206dc
baseline version:
 xen  7f62212d992fb8ae600faf6009475692a025bf99

Last test of basis93361  2016-05-02 11:02:23 Z0 days
Testing same since93366  2016-05-02 14:02:33 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Konrad Rzeszutek Wilk 

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



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

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

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

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


Pushing revision :

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

Re: [Xen-devel] [PATCH v2 4/5] x86/hvm: Add debug exception vm_events

[Jan Beulich]

>>> On 02.05.16 at 17:35,  wrote:
> On May 2, 2016 07:12, "Jan Beulich"  wrote:
>>
>> >>> On 29.04.16 at 20:07,  wrote:
>> > @@ -229,8 +231,15 @@ struct vm_event_write_ctrlreg {
>> >  uint64_t old_value;
>> >  };
>> >
>> > +struct vm_event_singlestep {
>> > +uint64_t gfn;
>> > +};
>> > +
>> >  struct vm_event_debug {
>> >  uint64_t gfn;
>> > +uint8_t type;/* HVMOP_TRAP_* */
>> > +uint8_t insn_length;
>> > +uint8_t _pad[6];
>> >  };
>>
>> This being an incompatible change - didn't you mean to increment some
>> version number?
> 
> I'm not sure. It would still work with clients compiled with the older
> version of the header as the layout of the debug struct didnt change, was
> just appended. The size of the request/response struct didn't change either
> so technically this would still be backwards compatible.

But you also need to consider the other direction: Code compiled
against the new variant, but running on an older hypervisor would
expect the new fields to be valid, yet they can't be, and the caller
has no way to know.

Jan


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

Re: [Xen-devel] [PATCH v2 4/5] x86/hvm: Add debug exception vm_events

[Tamas K Lengyel]

On May 2, 2016 07:12, "Jan Beulich"  wrote:
>
> >>> On 29.04.16 at 20:07,  wrote:
> > @@ -229,8 +231,15 @@ struct vm_event_write_ctrlreg {
> >  uint64_t old_value;
> >  };
> >
> > +struct vm_event_singlestep {
> > +uint64_t gfn;
> > +};
> > +
> >  struct vm_event_debug {
> >  uint64_t gfn;
> > +uint8_t type;/* HVMOP_TRAP_* */
> > +uint8_t insn_length;
> > +uint8_t _pad[6];
> >  };
>
> This being an incompatible change - didn't you mean to increment some
> version number?
>
> Jan

I'm not sure. It would still work with clients compiled with the older
version of the header as the layout of the debug struct didnt change, was
just appended. The size of the request/response struct didn't change either
so technically this would still be backwards compatible.

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

Re: [Xen-devel] [RFC PATCH 4/7] build: convert frame_pointer to Kconfig

[Konrad Rzeszutek Wilk]

On Sun, May 01, 2016 at 11:10:43PM -0500, Doug Goldstein wrote:
> Converts the frame_pointer option to a Kconfig option.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> ---
>  INSTALL   | 1 -
>  xen/Kconfig.debug | 8 
>  xen/Rules.mk  | 6 +-
>  3 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/INSTALL b/INSTALL
> index 35668bd..f55d42c 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -230,7 +230,6 @@ hypervisor build.
>  perfc=y
>  perfc_arrays=y
>  lock_profile=y
> -frame_pointer=y
>  lto=y
>  
>  During tools build external repos will be cloned into the source tree.
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index 94a6381..0b2ec50 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,6 +15,14 @@ config CRASH_DEBUG
> If you want to be able to attach gdb to Xen to be able to debug
> Xen if it crashes then say Y.
>  
> +config FRAME_POINTER
> + bool "Compile Xen with frame pointers"
> + default y
> + ---help---
> +   If you say Y here the resulting Xen will be slightly larger and
> +   maybe slower, but it gives very useful debugging information

The extra cost is:

 leaq  offs(%rsp),%rbp;
 notq  %rbp   

On entry in hypervisor.

Perhaps just say two extra operations are added on every vmexit ?

Is there an use-case for _not_ having frame pointers?


> +   in case of any Xen bugs.
> +
>  config VERBOSE_DEBUG
>   bool "Verbose debug messages"
>   default y
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index b159451..84b9d81 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -6,7 +6,6 @@
>  perfc ?= n
>  perfc_arrays  ?= n
>  lock_profile  ?= n
> -frame_pointer ?= n
>  lto   ?= n
>  
>  -include $(BASEDIR)/include/config/auto.conf
> @@ -15,9 +14,6 @@ include $(XEN_ROOT)/Config.mk
>  
>  # Hardcoded configuration implications and dependencies.
>  # Do this is a neater way if it becomes unwieldy.
> -ifeq ($(debug),y)
> -frame_pointer := y
> -endif
>  ifeq ($(perfc_arrays),y)
>  perfc := y
>  endif
> @@ -58,7 +54,7 @@ endif
>  CFLAGS-$(perfc) += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> -CFLAGS-$(frame_pointer) += -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER
> +CFLAGS-$(CONFIG_FRAME_POINTER) += -fno-omit-frame-pointer
>  
>  ifneq ($(max_phys_irqs),)
>  CFLAGS-y+= -DMAX_PHYS_IRQS=$(max_phys_irqs)
> -- 
> 2.7.3
> 

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

Re: [Xen-devel] [RFC PATCH 3/7] build: convert verbose to Kconfig

[Konrad Rzeszutek Wilk]

On Sun, May 01, 2016 at 11:10:42PM -0500, Doug Goldstein wrote:
> Convert 'verbose', which was enabled by 'debug=y' to Kconfig as
> CONFIG_VERBOSE_DEBUG which is enabled by default when CONFIG_DEBUG is
> enabled.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Stefano Stabellini 
> CC: Julien Grall 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Daniel De Graaf 
> ---
>  INSTALL | 1 -
>  xen/Kconfig.debug   | 6 ++
>  xen/Rules.mk| 5 -
>  xen/arch/arm/kernel.c   | 2 +-
>  xen/arch/x86/domain_build.c | 2 +-
>  xen/include/xsm/dummy.h | 2 +-
>  6 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/INSTALL b/INSTALL
> index 2974b9b..35668bd 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -227,7 +227,6 @@ VGABIOS_REL_DATE="dd Mon "
>  
>  The following variables can be used to tweak some aspects of the
>  hypervisor build.
> -verbose=y
>  perfc=y
>  perfc_arrays=y
>  lock_profile=y
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> index ee68f0d..94a6381 100644
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -15,4 +15,10 @@ config CRASH_DEBUG
> If you want to be able to attach gdb to Xen to be able to debug
> Xen if it crashes then say Y.
>  
> +config VERBOSE_DEBUG
> + bool "Verbose debug messages"
> + default y
> + ---help---
> +   Enables the verbose flag when loading ELF images.

..and when guests use HYPERVISOR_console_io

Perhaps:

Guest output from HYPERVISOR_console_io and hypervisor parsing ELF images
(dom0) is logged in the Xen ring buffer?

> +
>  endif # DEBUG
> diff --git a/xen/Rules.mk b/xen/Rules.mk
> index c044fd1..b159451 100644
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -3,7 +3,6 @@
>  # If you change any of these configuration options then you must
>  # 'make clean' before rebuilding.
>  #
> -verbose   ?= n
>  perfc ?= n
>  perfc_arrays  ?= n
>  lock_profile  ?= n
> @@ -17,10 +16,7 @@ include $(XEN_ROOT)/Config.mk
>  # Hardcoded configuration implications and dependencies.
>  # Do this is a neater way if it becomes unwieldy.
>  ifeq ($(debug),y)
> -verbose   := y
>  frame_pointer := y
> -else
> -CFLAGS += -DNDEBUG
>  endif
>  ifeq ($(perfc_arrays),y)
>  perfc := y
> @@ -59,7 +55,6 @@ ifneq ($(clang),y)
>  CFLAGS += -Wa,--strip-local-absolute
>  endif
>  
> -CFLAGS-$(verbose)   += -DVERBOSE
>  CFLAGS-$(perfc) += -DPERF_COUNTERS
>  CFLAGS-$(perfc_arrays)  += -DPERF_ARRAYS
>  CFLAGS-$(lock_profile)  += -DLOCK_PROFILE
> diff --git a/xen/arch/arm/kernel.c b/xen/arch/arm/kernel.c
> index 9871bd9..3f6cce3 100644
> --- a/xen/arch/arm/kernel.c
> +++ b/xen/arch/arm/kernel.c
> @@ -472,7 +472,7 @@ static int kernel_elf_probe(struct kernel_info *info,
>  
>  if ( (rc = elf_init(>elf.elf, info->elf.kernel_img, size )) != 0 )
>  goto err;
> -#ifdef VERBOSE
> +#ifdef CONFIG_VERBOSE_DEBUG
>  elf_set_verbose(>elf.elf);
>  #endif
>  elf_parse_binary(>elf.elf);
> diff --git a/xen/arch/x86/domain_build.c b/xen/arch/x86/domain_build.c
> index f9a3eca..b29c377 100644
> --- a/xen/arch/x86/domain_build.c
> +++ b/xen/arch/x86/domain_build.c
> @@ -942,7 +942,7 @@ int __init construct_dom0(
>  
>  if ( (rc = elf_init(, image_start, image_len)) != 0 )
>  return rc;
> -#ifdef VERBOSE
> +#ifdef CONFIG_VERBOSE_DEBUG
>  elf_set_verbose();
>  #endif
>  elf_parse_binary();
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index abbe282..406cd18 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -215,7 +215,7 @@ static XSM_INLINE int 
> xsm_memory_stat_reservation(XSM_DEFAULT_ARG struct domain
>  static XSM_INLINE int xsm_console_io(XSM_DEFAULT_ARG struct domain *d, int 
> cmd)
>  {
>  XSM_ASSERT_ACTION(XSM_OTHER);
> -#ifdef VERBOSE
> +#ifdef CONFIG_VERBOSE_DEBUG
>  if ( cmd == CONSOLEIO_write )
>  return xsm_default_action(XSM_HOOK, d, NULL);
>  #endif
> -- 
> 2.7.3
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH] x86: cap address bits CPUID output

[Jan Beulich]

Don't use more or report more to guests than we are capable of
handling.

At once simplify the code in hvm_cpuid() and mtrr_top_of_ram().

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -46,6 +46,7 @@ const struct cpu_dev *__read_mostly cpu_
 
 unsigned int paddr_bits __read_mostly = 36;
 unsigned int hap_paddr_bits __read_mostly = 36;
+unsigned int vaddr_bits __read_mostly = VADDR_BITS;
 
 /*
  * Default host IA32_CR_PAT value to cover all memory types.
@@ -240,7 +241,14 @@ static void __init early_cpu_detect(void
if ( cpuid_eax(0x8000) >= 0x8008 ) {
eax = cpuid_eax(0x8008);
paddr_bits = eax & 0xff;
+   if (paddr_bits > PADDR_BITS)
+   paddr_bits = PADDR_BITS;
+   vaddr_bits = (eax >> 8) & 0xff;
+   if (vaddr_bits > VADDR_BITS)
+   vaddr_bits = VADDR_BITS;
hap_paddr_bits = ((eax >> 16) & 0xff) ?: paddr_bits;
+   if (hap_paddr_bits > PADDR_BITS)
+   hap_paddr_bits = PADDR_BITS;
}
 }
 
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ -451,11 +451,11 @@ static uint64_t __init mtrr_top_of_ram(v
  return 0;
 
 /* Find the physical address size for this CPU. */
-cpuid(0x8000, , , , );
-if ( eax >= 0x8008 )
+if ( cpuid_eax(0x8000) >= 0x8008 )
 {
-cpuid(0x8008, , , , );
-phys_bits = (uint8_t)eax;
+phys_bits = (uint8_t)cpuid_eax(0x8008);
+if ( phys_bits > PADDR_BITS )
+phys_bits = PADDR_BITS;
 }
 addr_mask = ((1ull << phys_bits) - 1) & ~((1ull << 12) - 1);
 
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -3504,19 +3504,19 @@ void hvm_cpuid(unsigned int input, unsig
 break;
 
 case 0x8008:
+*eax &= 0xff;
 count = d->arch.paging.gfn_bits + PAGE_SHIFT;
-if ( (*eax & 0xff) > count )
-*eax = (*eax & ~0xff) | count;
+if ( *eax > count )
+*eax = count;
 
 hvm_cpuid(1, NULL, NULL, NULL, &_edx);
 count = _edx & (cpufeat_mask(X86_FEATURE_PAE) |
 cpufeat_mask(X86_FEATURE_PSE36)) ? 36 : 32;
-if ( (*eax & 0xff) < count )
-*eax = (*eax & ~0xff) | count;
+if ( *eax < count )
+*eax = count;
 
 hvm_cpuid(0x8001, NULL, NULL, NULL, &_edx);
-*eax = (*eax & ~0x00) | (_edx & cpufeat_mask(X86_FEATURE_LM)
- ? 0x3000 : 0x2000);
+*eax |= _edx & cpufeat_mask(X86_FEATURE_LM) ? vaddr_bits << 8 : 0x2000;
 
 *ebx &= hvm_featureset[FEATURESET_e8b];
 break;
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1146,6 +1146,7 @@ void pv_cpuid(struct cpu_user_regs *regs
 break;
 
 case 0x8008:
+a = paddr_bits | (vaddr_bits << 8);
 b &= pv_featureset[FEATURESET_e8b];
 break;
 
--- a/xen/include/asm-x86/processor.h
+++ b/xen/include/asm-x86/processor.h
@@ -216,10 +216,12 @@ extern bool_t opt_cpu_info;
 extern u32 cpuid_ext_features;
 extern u64 trampoline_misc_enable_off;
 
-/* Maximum width of physical addresses supported by the hardware */
+/* Maximum width of physical addresses supported by the hardware. */
 extern unsigned int paddr_bits;
-/* Max physical address width supported within HAP guests */
+/* Max physical address width supported within HAP guests. */
 extern unsigned int hap_paddr_bits;
+/* Maximum width of virtual addresses supported by the hardware. */
+extern unsigned int vaddr_bits;
 
 extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id table[]);
 



x86: cap address bits CPUID output

Don't use more or report more to guests than we are capable of
handling.

At once simplify the code in hvm_cpuid() and mtrr_top_of_ram().

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -46,6 +46,7 @@ const struct cpu_dev *__read_mostly cpu_
 
 unsigned int paddr_bits __read_mostly = 36;
 unsigned int hap_paddr_bits __read_mostly = 36;
+unsigned int vaddr_bits __read_mostly = VADDR_BITS;
 
 /*
  * Default host IA32_CR_PAT value to cover all memory types.
@@ -240,7 +241,14 @@ static void __init early_cpu_detect(void
if ( cpuid_eax(0x8000) >= 0x8008 ) {
eax = cpuid_eax(0x8008);
paddr_bits = eax & 0xff;
+   if (paddr_bits > PADDR_BITS)
+   paddr_bits = PADDR_BITS;
+   vaddr_bits = (eax >> 8) & 0xff;
+   if (vaddr_bits > VADDR_BITS)
+   vaddr_bits = VADDR_BITS;
hap_paddr_bits = ((eax >> 16) & 0xff) ?: paddr_bits;
+   if (hap_paddr_bits > PADDR_BITS)
+   hap_paddr_bits = PADDR_BITS;
}
 }
 
--- a/xen/arch/x86/e820.c
+++ b/xen/arch/x86/e820.c
@@ 

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  146 days
Failing since 65593  2015-12-08 23:44:51 Z  145 days  201 attempts
Testing same since93232  2016-04-29 20:13:53 Z2 days   10 attempts


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

Re: [Xen-devel] [RFC PATCH 1/7] build: add debug menu to Kconfig

[Doug Goldstein]

On 5/2/16 6:02 AM, Andrew Cooper wrote:
> On 02/05/2016 11:42, Wei Liu wrote:
>> On Sun, May 01, 2016 at 11:10:40PM -0500, Doug Goldstein wrote:
>>> There are a number of debugging options for Xen so the idea is to have a
>>> menu to group them all together. Enabling this menu item will also
>>> disable NDEBUG which will result in more debug prints. This was
>>> previously wired into the 'debug=y' command line option.
>>>
>>> Signed-off-by: Doug Goldstein 
>>> ---
>>> CC: Andrew Cooper 
>>> CC: George Dunlap 
>>> CC: Ian Jackson 
>>> CC: Jan Beulich 
>>> CC: Konrad Rzeszutek Wilk 
>>> CC: Stefano Stabellini 
>>> CC: Tim Deegan 
>>> CC: Wei Liu 
>>> ---
>>>  xen/Kconfig  | 2 ++
>>>  xen/Kconfig.debug| 7 +++
>>>  xen/include/xen/config.h | 4 
>>>  3 files changed, 13 insertions(+)
>>>  create mode 100644 xen/Kconfig.debug
>>>
>>> diff --git a/xen/Kconfig b/xen/Kconfig
>>> index fa8b27c..0fe7a1a 100644
>>> --- a/xen/Kconfig
>>> +++ b/xen/Kconfig
>>> @@ -26,3 +26,5 @@ config DEFCONFIG_LIST
>>>  config EXPERT
>>> string
>>> option env="XEN_CONFIG_EXPERT"
>>> +
>>> +source "Kconfig.debug"
>>> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
>>> new file mode 100644
>>> index 000..d14d758
>>> --- /dev/null
>>> +++ b/xen/Kconfig.debug
>>> @@ -0,0 +1,7 @@
>>> +
>>> +menuconfig DEBUG
>>> +   bool "Debugging Options"
>>> +   ---help---
>>> + If you want to debug Xen say Y and select any additional debugging
>>> + support options. This enables additional debugging through Xen
>>> + and as a result enabling this option results in no security 
>>> guarantees.
>> Maybe that's because I'm not a native speaker, this doesn't sound right
>> to me -- it implies debugging option makes xen insecure.
>>
>> I think you mean "results in no security support"?
> 
> Instead of mentioning security, I would simply say "Enabling this option
> is intended for development purposes only, and not for production use".
> 
> There is already a statement saying that issues which only affect a
> debug hypervisor are not considered security relevant.
> 
> ~Andrew
> 

Yeah that's better wording than what I've got. I'll update it. Thanks!

-- 
Doug Goldstein



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

[Xen-devel] [xen-unstable test] 93337: tolerable FAIL

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt-raw  9 debian-di-install  fail in 93296 pass in 93337
 test-amd64-i386-qemut-rhel6hvm-intel 11 guest-start/redhat.repeat fail pass in 
93296
 test-amd64-amd64-xl-qemut-debianhvm-amd64 15 guest-localmigrate/x10 fail pass 
in 93296
 test-armhf-armhf-xl-vhd   6 xen-bootfail pass in 93296

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 93296 like 93256
 build-i386-rumpuserxen6 xen-buildfail   like 93296
 build-amd64-rumpuserxen   6 xen-buildfail   like 93296
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 93296
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 93296
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 93296
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 93296
 test-amd64-amd64-xl-rtds  9 debian-install   fail   like 93296

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-armhf-armhf-xl-vhd  11 migrate-support-check fail in 93296 never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-check fail in 93296 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-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-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  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-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  c2994f8632d56e5379e612daa216401477dccbdb
baseline version:
 xen  c2994f8632d56e5379e612daa216401477dccbdb

Last test of basis93337  2016-05-02 01:57:38 Z0 days
Testing same since0  1970-01-01 00:00:00 Z 16923 days0 attempts

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
 

Re: [Xen-devel] [PATCH] xsplice: Missing if ( sec )

[Wei Liu]

On Mon, May 02, 2016 at 02:09:16PM +0100, Wei Liu wrote:
> On Mon, May 02, 2016 at 09:05:34AM -0400, Konrad Rzeszutek Wilk wrote:
> > Add the missing conditional.
> > 
> > Reported-by: Jan Beulich 
> > Signed-off-by: Konrad Rzeszutek Wilk 
> > 
> 
> FWIW:
> 
> Reviewed-by: Wei Liu 
> 
> And subject to ack from HV maintainer:
> 
> Release-acked-by: Wei Liu 
> 

I would like to have Ack from Jan, Andrew or Ross if possible. But this
bug is so trivial so whether they ack it or not my release ack stands.

Wei.

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

Re: [Xen-devel] [PATCH] xsplice: Missing if ( sec )

[Jan Beulich]

>>> On 02.05.16 at 15:09,  wrote:
> On Mon, May 02, 2016 at 09:05:34AM -0400, Konrad Rzeszutek Wilk wrote:
>> Add the missing conditional.
>> 
>> Reported-by: Jan Beulich 
>> Signed-off-by: Konrad Rzeszutek Wilk 
>> 
> 
> FWIW:
> 
> Reviewed-by: Wei Liu 
> 
> And subject to ack from HV maintainer:
> 
> Release-acked-by: Wei Liu 

A think the ack can basically be implied from the Reported-by above;
Konrad - feel free.

Jan


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

Re: [Xen-devel] [PATCH v2 4/5] x86/hvm: Add debug exception vm_events

[Jan Beulich]

>>> On 29.04.16 at 20:07,  wrote:
> @@ -229,8 +231,15 @@ struct vm_event_write_ctrlreg {
>  uint64_t old_value;
>  };
>  
> +struct vm_event_singlestep {
> +uint64_t gfn;
> +};
> +
>  struct vm_event_debug {
>  uint64_t gfn;
> +uint8_t type;/* HVMOP_TRAP_* */
> +uint8_t insn_length;
> +uint8_t _pad[6];
>  };

This being an incompatible change - didn't you mean to increment some
version number?

Jan



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

Re: [Xen-devel] [PATCH] xsplice: Missing if ( sec )

[Wei Liu]

On Mon, May 02, 2016 at 09:05:34AM -0400, Konrad Rzeszutek Wilk wrote:
> Add the missing conditional.
> 
> Reported-by: Jan Beulich 
> Signed-off-by: Konrad Rzeszutek Wilk 
> 

FWIW:

Reviewed-by: Wei Liu 

And subject to ack from HV maintainer:

Release-acked-by: Wei Liu 

> ---
> This has been in there since v3 posting! And I really need to finish
> with the OSSTest regression tests to catch this.
> 
> Cc: Andrew Cooper 
> Cc: Jan Beulich 
> Cc: Wei Liu 
> ---
>  xen/common/xsplice.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
> index 777faa7..c9fc53a 100644
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -548,6 +548,7 @@ static int prepare_payload(struct payload *payload,
>  }
>  
>  sec = xsplice_elf_sec_by_name(elf, ELF_XSPLICE_DEPENDS);
> +if ( sec )
>  {
>  n = sec->load_addr;
>  
> -- 
> 2.5.0
> 

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

Re: [Xen-devel] [PATCH v10 21/24] xsplice: Stacking build-id dependency checking.

[Konrad Rzeszutek Wilk]

On Mon, May 02, 2016 at 12:37:09AM -0600, Jan Beulich wrote:
> >>> On 27.04.16 at 21:27,  wrote:
> > @@ -506,6 +518,37 @@ static int prepare_payload(struct payload *payload,
> >  }
> >  }
> >  
> > +sec = xsplice_elf_sec_by_name(elf, ELF_BUILD_ID_NOTE);
> > +if ( sec )
> > +{
> > +n = sec->load_addr;
> > +
> > +if ( sec->sec->sh_size <= sizeof(*n) )
> > +return -EINVAL;
> > +
> > +if ( xen_build_id_check(n, sec->sec->sh_size,
> > +>id.p, >id.len) )
> > +return -EINVAL;
> > +
> > +if ( !payload->id.len || !payload->id.p )
> > +return -EINVAL;
> > +}
> > +
> > +sec = xsplice_elf_sec_by_name(elf, ELF_XSPLICE_DEPENDS);
> > +{
> 
> Looks like an "if ( sec )" got lost here.



Patch sent. Thank you for spotting that!
> 
> Jan
> 

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

[Xen-devel] [PATCH] xsplice: Missing if ( sec )

[Konrad Rzeszutek Wilk]

Add the missing conditional.

Reported-by: Jan Beulich 
Signed-off-by: Konrad Rzeszutek Wilk 

---
This has been in there since v3 posting! And I really need to finish
with the OSSTest regression tests to catch this.

Cc: Andrew Cooper 
Cc: Jan Beulich 
Cc: Wei Liu 
---
 xen/common/xsplice.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 777faa7..c9fc53a 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -548,6 +548,7 @@ static int prepare_payload(struct payload *payload,
 }
 
 sec = xsplice_elf_sec_by_name(elf, ELF_XSPLICE_DEPENDS);
+if ( sec )
 {
 n = sec->load_addr;
 
-- 
2.5.0


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

Re: [Xen-devel] [PATCH v2 5/5] MAINTAINERS: Update monitor/vm_event covered code

[Jan Beulich]

>>> On 29.04.16 at 20:07,  wrote:
> Add headers to the covered list.
> 
> Signed-off-by: Tamas K Lengyel 

Acked-by: Jan Beulich 


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

[Xen-devel] [PATCH] IOMMU/x86: per-domain control structure is not HVM-specific

[Jan Beulich]

... and hence should not live in the HVM part of the PV/HVM union. In
fact it's not even architecture specific (there already is a per-arch
extension type to it), so it gets moved out right to common struct
domain.

Signed-off-by: Jan Beulich 
---
Of course this is quite large a patch for 4.7, but I don't think we
should try to make this brokenness slightly more safe by e.g. adding a
suitable BUILD_BUG_ON() guaranteeing that the shared structure sits
above the end of the PV part of the union. That's at best something to
be considered for the stable trees, imo.

--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -647,7 +647,7 @@ long arch_do_domctl(
 
 case XEN_DOMCTL_ioport_mapping:
 {
-struct hvm_iommu *hd;
+struct domain_iommu *hd;
 unsigned int fgp = domctl->u.ioport_mapping.first_gport;
 unsigned int fmp = domctl->u.ioport_mapping.first_mport;
 unsigned int np = domctl->u.ioport_mapping.nr_ports;
@@ -673,7 +673,7 @@ long arch_do_domctl(
 if ( ret )
 break;
 
-hd = domain_hvm_iommu(d);
+hd = dom_iommu(d);
 if ( add )
 {
 printk(XENLOG_G_INFO
--- a/xen/arch/x86/hvm/io.c
+++ b/xen/arch/x86/hvm/io.c
@@ -174,12 +174,12 @@ static bool_t dpci_portio_accept(const s
  const ioreq_t *p)
 {
 struct vcpu *curr = current;
-struct hvm_iommu *hd = domain_hvm_iommu(curr->domain);
+const struct domain_iommu *dio = dom_iommu(curr->domain);
 struct hvm_vcpu_io *vio = >arch.hvm_vcpu.hvm_io;
 struct g2m_ioport *g2m_ioport;
 unsigned int start, end;
 
-list_for_each_entry( g2m_ioport, >arch.g2m_ioport_list, list )
+list_for_each_entry( g2m_ioport, >arch.g2m_ioport_list, list )
 {
 start = g2m_ioport->gport;
 end = start + g2m_ioport->np;
--- a/xen/arch/x86/tboot.c
+++ b/xen/arch/x86/tboot.c
@@ -229,9 +229,10 @@ static void tboot_gen_domain_integrity(c
 
 if ( !is_idle_domain(d) )
 {
-struct hvm_iommu *hd = domain_hvm_iommu(d);
-update_iommu_mac(, hd->arch.pgd_maddr,
- agaw_to_level(hd->arch.agaw));
+const struct domain_iommu *dio = dom_iommu(d);
+
+update_iommu_mac(, dio->arch.pgd_maddr,
+ agaw_to_level(dio->arch.agaw));
 }
 }
 
--- a/xen/drivers/passthrough/amd/iommu_cmd.c
+++ b/xen/drivers/passthrough/amd/iommu_cmd.c
@@ -18,7 +18,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include "../ats.h"
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -18,7 +18,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -59,12 +58,12 @@ static uint16_t guest_bdf(struct domain
 
 static inline struct guest_iommu *domain_iommu(struct domain *d)
 {
-return domain_hvm_iommu(d)->arch.g_iommu;
+return dom_iommu(d)->arch.g_iommu;
 }
 
 static inline struct guest_iommu *vcpu_iommu(struct vcpu *v)
 {
-return domain_hvm_iommu(v->domain)->arch.g_iommu;
+return dom_iommu(v->domain)->arch.g_iommu;
 }
 
 static void guest_iommu_enable(struct guest_iommu *iommu)
@@ -885,7 +884,7 @@ static const struct hvm_mmio_ops iommu_m
 int guest_iommu_init(struct domain* d)
 {
 struct guest_iommu *iommu;
-struct hvm_iommu *hd  = domain_hvm_iommu(d);
+struct domain_iommu *hd = dom_iommu(d);
 
 if ( !is_hvm_domain(d) || !iommu_enabled || !iommuv2_enabled ||
  !has_viommu(d) )
@@ -924,5 +923,5 @@ void guest_iommu_destroy(struct domain *
 tasklet_kill(>cmd_buffer_tasklet);
 xfree(iommu);
 
-domain_hvm_iommu(d)->arch.g_iommu = NULL;
+dom_iommu(d)->arch.g_iommu = NULL;
 }
--- a/xen/drivers/passthrough/amd/iommu_intr.c
+++ b/xen/drivers/passthrough/amd/iommu_intr.c
@@ -18,7 +18,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include "../ats.h"
@@ -340,7 +339,7 @@ static int iommu_update_pde_count(struct
 unsigned long first_mfn;
 u64 *table, *pde, *ntable;
 u64 ntable_maddr, mask;
-struct hvm_iommu *hd = domain_hvm_iommu(d);
+struct domain_iommu *hd = dom_iommu(d);
 bool_t ok = 0;
 
 ASSERT( spin_is_locked(>arch.mapping_lock) && pt_mfn );
@@ -395,7 +394,7 @@ static int iommu_merge_pages(struct doma
 u64 *table, *pde, *ntable;
 u64 ntable_mfn;
 unsigned long first_mfn;
-struct hvm_iommu *hd = domain_hvm_iommu(d);
+struct domain_iommu *hd = dom_iommu(d);
 
 ASSERT( spin_is_locked(>arch.mapping_lock) && pt_mfn );
 
@@ -445,7 +444,7 @@ static int iommu_pde_from_gfn(struct dom
 unsigned long  next_table_mfn;
 unsigned int level;
 struct page_info *table;
-struct hvm_iommu *hd = domain_hvm_iommu(d);
+const struct domain_iommu *hd 

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

[osstest service owner]

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

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  7f62212d992fb8ae600faf6009475692a025bf99
baseline version:
 xen  77eb5dbeff78bbe549793325520f59ab46a187f8

Last test of basis93352  2016-05-02 08:03:18 Z0 days
Testing same since93361  2016-05-02 11:02:23 Z0 days1 attempts


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

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

>
> Check the errno please, thats' where the information is stored.


I looked up in the source code of xen 4.6, and find that errno 4 indicates
"Interrupted system call
",
I'm not sure if it is the cause.

Another information about VMFUNC error is from the Intel Manual:

25.5.5.2 General Operation of the VMFUNC Instruction
> The VMFUNC instruction causes an invalid-opcode exception (#UD) if the
> “enable VM functions” VM-execution
> controls is 0 or the value of EAX is greater than 63 (only VM functions
> 0–63 can be enable). Otherwise, the
> instruction causes a VM exit if the bit at position EAX is 0 in the
> VM-function controls (the selected VM function is
> not enabled). If such a VM exit occurs, the basic exit reason used is 59
> (3BH), indicating “VMFUNC”, and the length
> of the VMFUNC instruction is saved into the VM-exit instruction-length
> field. If the instruction causes neither an
> invalid-opcode exception nor a VM exit due to a disabled VM function, it
> performs the functionality of the
> VM function specified by the value in EAX.


 i.e. In conditions when guest software invoked a VM function with the
VMFUNC instruction and the VM function either was not
enabled or generated a function-specific condition causing a VM exit.

But I've already enabled VM function and the conditions described in the
manual are not true (EAX is 0), so I'm still not clear the real reason
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] bad page flags booting 32bit dom0 on 64bit hypervisor using dom0_mem (kernel >=4.2)

[Juergen Gross]

On 02/05/16 12:47, Stefan Bader wrote:
> I recently tried to boot 32bit dom0 on 64bit Xen host which I configured to 
> run
> with a limited, fix amount of memory for dom0. It seems that somewhere between
> kernel versions 3.19 and 4.2 (sorry that is still a wide range) the Linux 
> kernel
> would report bad page flags for a range of pages (which seem to be around the
> end of the guest pfn range). For a 4.2 kernel that was easily missed as the 
> boot
> finished ok and dom0 was accessible. However starting with 4.4 (tested 4.5 
> and a
> 4.6-rc) the serial console output freezes after some of those bad page flag
> messages and then (unfortunately without any further helpful output) the host
> reboots (I assume there is a panic that triggers a reset).
> 
> I suspect the problem is more a kernel side one. It is just possible to
> influence things by variation of dom0_mem=#,max:#. 512M seems ok, 1024M, 
> 2048M,
> and 3072M cause bad page flags starting around kernel 4.2 and reboots around
> 4.4. Then 4096M and not clamping dom0 memory seem to be ok again (though not
> limiting dom0 memory seems to cause trouble on 32bit dom0 later when a domU
> tries to balloon memory, but I think that is a different problem).
> 
> I have not seen this on a 64bit dom0. Below is an example of those bad page
> errors. Somehow it looks to be a page marked as reserved. Initially I wondered
> whether this could be a problem of not clearing page flags when moving 
> mappings
> to match the e820. But I never looked into i386 memory setup in that detail. 
> So
> I am posting this, hoping that someone may have an idea from the detail about
> where to look next. PAE is enabled there. Usually its bpf init that gets hit 
> but
> that likely is just because that is doing the first vmallocs.

Could you please post the kernel config, Xen and dom0 boot parameters?
I'm quite sure this is no common problem as there are standard tests
running for each kernel version including 32 bit dom0 with limited
memory size.


Juergen

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-xsm  9 debian-installfail REGR. vs. 91479
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt-vhd 13 guest-saverestore fail REGR. vs. 91479
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. 
vs. 91479
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
91479
 test-amd64-i386-libvirt-xsm  14 guest-saverestore fail REGR. vs. 91479
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 12 guest-saverestore fail 
REGR. vs. 91479
 test-amd64-amd64-libvirt 14 guest-saverestore fail REGR. vs. 91479

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

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

Last test of basis91479  2016-04-15 05:33:51 Z   17 days
Failing since 91597  2016-04-16 04:20:46 Z   16 days   16 attempts
Testing same since93343  2016-05-02 04:22:50 Z0 days1 attempts


People who touched revisions under test:
  Andrea Bolognani 
  Ben Gray 
  Cole Robinson 
  Daniel Veillard 
  Dmitry Andreev 
  Erik Skultety 
  Jason J. Herne 
  Jim Fehlig 
  Jiri Denemark 
  John Ferlan 
  Ján Tomko 
  Laine Stump 
  Martin Kletzander 
  Maxim Nestratov 
  Michal Privoznik 
  Mikhail Feoktistov 
  Nikolay Shirokovskiy 
  Nitesh Konkar 
  Nitesh Konkar 
  Olga Krishtal 
  Peter Krempa 
  Richard Laager 
  Richard W.M. Jones 
  Roman Bogorodskiy 
  Simon Arlott 
  Yuri Chornoivan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 test-amd64-amd64-libvirt-xsm fail
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  fail
 test-amd64-amd64-libvirt fail
 

Re: [Xen-devel] 2016 Xen hackathon notes - xenstored

[Wei Liu]

Luis, thanks for starting this thread.

On Fri, Apr 29, 2016 at 08:55:04PM +0200, Luis R. Rodriguez wrote:
> On Fri, Apr 29, 2016 at 04:33:31PM +0200, Filipe Manco wrote:
> > Hi
> > 
> > Regarding LiXS, our goal is to make it one of the upstream xenstore
> > alternatives. For that I already started getting internal approvals
> > to release the code open source, which should happen somewhere
> > around next month. I also need to fix some bugs and would like to do
> > some performance testing before the release.
> > 
> > Once it is released, it would be nice to get some comments from the
> > community on the implementation, specifically about how to make it
> > upstreamable; I’ll let you know when the code is available.
> > 
> > Does this plan sound reasonable?
> 
> I have no say in the Xen community, but to me this sounds reasonable,
> you should have competing solutions and let people win, its the
> same principle that was applied to Linux Security Modules, for
> instance, and that philosophy tends to enable all viable options
> to compete while upstream. For Xen, there are already 2 xenstores,
> having another IMHO should just require commitment for a maintainer
> to upkeep it. Without that it should make no sense.
> 

I think the best way forward is to post design doc and / or code to
xen-devel to decide what next step is.  We shall discuss things based on
their merits.

> You also require C++ though ? That's a new requirement AFAICT, so
> that would need to be addressed.
> 

IIRC we already need g++ to build QEMU (it doesn't get along with gcc
last time I checked), so that wouldn't be a big issue IMHO.

Wei.

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

Re: [Xen-devel] [PATCH v10 17/24] build_id: Provide ld-embedded build-ids

[Jan Beulich]

>>> On 02.05.16 at 13:19,  wrote:
> On Mon, May 02, 2016 at 05:13:24AM -0600, Jan Beulich wrote:
>> >>> On 02.05.16 at 13:05,  wrote:
>> > On Mon, May 02, 2016 at 12:02:43AM -0600, Jan Beulich wrote:
>> >> >>> On 29.04.16 at 19:23,  wrote:
>> >> > On Fri, Apr 29, 2016 at 10:38:07AM -0600, Jan Beulich wrote:
>> >> >> >>> On 27.04.16 at 21:27,  wrote:
>> >> >> > @@ -304,6 +338,32 @@ int main(int argc, char **argv)
>> >> >> >  /*mem_siz = (u32)in64_phdr.p_memsz;*/
>> >> >> >  mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
>> >> >> >  
>> >> >> > +note_sz = note_base = offset = 0;
>> >> >> > +if ( num_phdrs > 1 )
>> >> >> > +{
>> >> >> > +offset = in64_phdr.p_offset;
>> >> >> > +note_base = in64_phdr.p_vaddr;
>> >> >> > +
>> >> >> > +(void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), 
>> >> >> > SEEK_SET);
>> >> >> > +do_read(infd, _phdr, sizeof(in64_phdr));
>> >> >> > +endianadjust_phdr64(_phdr);
>> >> >> > +
>> >> >> > +(void)lseek(infd, offset, SEEK_SET);
>> >> >> > +
>> >> >> > +note_sz = in64_phdr.p_memsz;
>> >> >> > +note_base = in64_phdr.p_vaddr - note_base;
>> >> >> > +
>> >> >> > +if ( in64_phdr.p_offset > dat_siz || offset > 
>> >> >> > in64_phdr.p_offset )
>> >> >> > +{
>> >> >> > +fprintf(stderr, "Expected .note section within .text 
>> >> > section!\n" \
>> >> >> > +"Offset %ld not within %d!\n",
>> >> >> > +in64_phdr.p_offset, dat_siz);
>> >> >> 
>> >> >> This fails to build on a 32-bit build host (which is one of the two
>> >> >> post-commit, pre-push checks I normally do).
>> >> > 
>> >> > I hadn't realized that it was possible to build an 64-bit hypervisor on 
>> >> > 32-bit
>> >> > GCC toolchain. I've never done that - always built the hypervisor in 
>> >> > 64-bit 
>> >> > env and the 32-bit toolstack in 32-bit environment. Then booted it.
>> >> 
>> >> 32-bit toolchain? No. A 64-bit cross tool chain (similar to what I use
>> >> for ARM build testing, except that here I also actively run the
>> >> resulting hypervisor).
>> > 
>> > Then I'm a bit confused what you meant by "32-bit build host" in your
>> > previous email.
>> 
>> What's confusing you here? Running a 64-bit hypervisor and/or a
>> 64-bit kernel underneath a 32-bit distro is working quite fine.
>> 
> 
> Hmm... How did you discover that problem if you did not cross-compile
> with 32-bit toolchain? That's how I discovered the breakage.

Hmm, so maybe we're just meaning "32-bit" for different things: I
imply it to stand for the target architecture, but maybe you mean
the (build) host architecture instead. Konrad's original reply meant
to me that he somehow expected the _native_ tool chain on a
32-bit host to be capable of that (where host arch == target arch),
which in theory was possible too, but I don't think is in actual use
anywhere.

Jan


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

Re: [Xen-devel] [PATCH v10 17/24] build_id: Provide ld-embedded build-ids

[Wei Liu]

On Mon, May 02, 2016 at 05:13:24AM -0600, Jan Beulich wrote:
> >>> On 02.05.16 at 13:05,  wrote:
> > On Mon, May 02, 2016 at 12:02:43AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 19:23,  wrote:
> >> > On Fri, Apr 29, 2016 at 10:38:07AM -0600, Jan Beulich wrote:
> >> >> >>> On 27.04.16 at 21:27,  wrote:
> >> >> > @@ -304,6 +338,32 @@ int main(int argc, char **argv)
> >> >> >  /*mem_siz = (u32)in64_phdr.p_memsz;*/
> >> >> >  mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
> >> >> >  
> >> >> > +note_sz = note_base = offset = 0;
> >> >> > +if ( num_phdrs > 1 )
> >> >> > +{
> >> >> > +offset = in64_phdr.p_offset;
> >> >> > +note_base = in64_phdr.p_vaddr;
> >> >> > +
> >> >> > +(void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), 
> >> >> > SEEK_SET);
> >> >> > +do_read(infd, _phdr, sizeof(in64_phdr));
> >> >> > +endianadjust_phdr64(_phdr);
> >> >> > +
> >> >> > +(void)lseek(infd, offset, SEEK_SET);
> >> >> > +
> >> >> > +note_sz = in64_phdr.p_memsz;
> >> >> > +note_base = in64_phdr.p_vaddr - note_base;
> >> >> > +
> >> >> > +if ( in64_phdr.p_offset > dat_siz || offset > 
> >> >> > in64_phdr.p_offset )
> >> >> > +{
> >> >> > +fprintf(stderr, "Expected .note section within .text 
> >> > section!\n" \
> >> >> > +"Offset %ld not within %d!\n",
> >> >> > +in64_phdr.p_offset, dat_siz);
> >> >> 
> >> >> This fails to build on a 32-bit build host (which is one of the two
> >> >> post-commit, pre-push checks I normally do).
> >> > 
> >> > I hadn't realized that it was possible to build an 64-bit hypervisor on 
> >> > 32-bit
> >> > GCC toolchain. I've never done that - always built the hypervisor in 
> >> > 64-bit 
> >> > env and the 32-bit toolstack in 32-bit environment. Then booted it.
> >> 
> >> 32-bit toolchain? No. A 64-bit cross tool chain (similar to what I use
> >> for ARM build testing, except that here I also actively run the
> >> resulting hypervisor).
> > 
> > Then I'm a bit confused what you meant by "32-bit build host" in your
> > previous email.
> 
> What's confusing you here? Running a 64-bit hypervisor and/or a
> 64-bit kernel underneath a 32-bit distro is working quite fine.
> 

Hmm... How did you discover that problem if you did not cross-compile
with 32-bit toolchain? That's how I discovered the breakage.

Actually never mind. It's probably counter-productive to quibble over
words we use to describe build setups, especially ...

> > Anyway,  does my patch ("mkelf32: fix compilation on 32 bit build host")
> > fix the problem you saw?
> 
> Yes. That was also what I had used as a temporary workaround. I
> just didn't have the time right away to put this into proper patch
> shape.
> 

... now that you confirm the build is fixed.

Thanks for confirming BTW.

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v2 3/3] xl: new "loglvl" command

[Wei Liu]

On Fri, Apr 29, 2016 at 01:20:57AM -0600, Jan Beulich wrote:
> >>> On 28.04.16 at 17:33,  wrote:
> > On Wed, Mar 16, 2016 at 05:22:27AM -0600, Jan Beulich wrote:
> >> >>> On 15.03.16 at 16:38,  wrote:
> >> > Jan Beulich writes ("Re: [PATCH v2 3/3] xl: new "loglvl" command"):
> >> >> Yes and no. If all of the sudden the hypervisor didn't have an "error"
> >> >> log level anymore, what would you do? Mapping "error" to "warning"
> >> >> wouldn't be right. Nor would mapping it to anything else. Correct
> >> >> behavior in that case would simply be failure, and it wouldn't seem
> >> >> too relevant to me at what layer that failure would get signaled.
> >> > 
> >> > I think you are looking at this the wrong way.
> >> 
> >> Quite possible, and all of what you write makes sense. Yet that
> >> wasn't my intention here. I specifically put the string <-> number
> >> mapping in xl, so it could be that (and only that, outside the
> >> hypervisor itself) which gets changed if the hypervisor log levels
> >> ever change. The tool could use version information or some
> >> other detection mechanism to provide backwards compatibility
> >> (and be independent of the precise hypervisor version it got
> >> built in parallel with, if that's desired). And hence I specifically
> >> made the interfaces dumb - raw numbers, with no meaning
> >> assigned to their values.
> >> 
> >> And then, with what you describe I assume the current hypervisor
> >> side implementation wouldn't be suitable anymore anyway, as the
> >> translation between the interface exposed log levels and the
> >> internally used ones would need to happen in the sysctl handler.
> >> 
> >> To me, all of this looks increasingly like over-engineering for a
> >> very simple debugging aid (which is all the new command was
> >> meant for). If you and Wei can settle on some alternative
> >> implementation, I'm fine to accept that, but I don't think I'm
> >> going to spend much more time on fiddling with any of the 3
> >> patches. It's going to be sad though if even the serial console
> >> based log level adjustment won't make it into 4.7, despite it
> >> having got posted months ago (with this v2 just extending on
> >> it).
> > 
> > If this is just a debugging aid and not intending to be consumed by high
> > level toolstack, maybe we can make a dedicated helper program? We
> > already have a bunch of those. Should the need really arises we can
> > then consider making it proper stable API / ABI.
> 
> That's an option, albeit a slightly awkward one. This new thing
> really fits well with the debug-key and dmesg sub-commands,
> which both are there just for debugging, too.
> 

This is a good argument. I'm fine with treating it like debug-key and
dmesg.

Ian?

Wei.

> Jan
> 

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

Re: [Xen-devel] [PATCH v10 17/24] build_id: Provide ld-embedded build-ids

[Jan Beulich]

>>> On 02.05.16 at 13:05,  wrote:
> On Mon, May 02, 2016 at 12:02:43AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 19:23,  wrote:
>> > On Fri, Apr 29, 2016 at 10:38:07AM -0600, Jan Beulich wrote:
>> >> >>> On 27.04.16 at 21:27,  wrote:
>> >> > @@ -304,6 +338,32 @@ int main(int argc, char **argv)
>> >> >  /*mem_siz = (u32)in64_phdr.p_memsz;*/
>> >> >  mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
>> >> >  
>> >> > +note_sz = note_base = offset = 0;
>> >> > +if ( num_phdrs > 1 )
>> >> > +{
>> >> > +offset = in64_phdr.p_offset;
>> >> > +note_base = in64_phdr.p_vaddr;
>> >> > +
>> >> > +(void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), 
>> >> > SEEK_SET);
>> >> > +do_read(infd, _phdr, sizeof(in64_phdr));
>> >> > +endianadjust_phdr64(_phdr);
>> >> > +
>> >> > +(void)lseek(infd, offset, SEEK_SET);
>> >> > +
>> >> > +note_sz = in64_phdr.p_memsz;
>> >> > +note_base = in64_phdr.p_vaddr - note_base;
>> >> > +
>> >> > +if ( in64_phdr.p_offset > dat_siz || offset > 
>> >> > in64_phdr.p_offset )
>> >> > +{
>> >> > +fprintf(stderr, "Expected .note section within .text 
>> > section!\n" \
>> >> > +"Offset %ld not within %d!\n",
>> >> > +in64_phdr.p_offset, dat_siz);
>> >> 
>> >> This fails to build on a 32-bit build host (which is one of the two
>> >> post-commit, pre-push checks I normally do).
>> > 
>> > I hadn't realized that it was possible to build an 64-bit hypervisor on 
>> > 32-bit
>> > GCC toolchain. I've never done that - always built the hypervisor in 
>> > 64-bit 
>> > env and the 32-bit toolstack in 32-bit environment. Then booted it.
>> 
>> 32-bit toolchain? No. A 64-bit cross tool chain (similar to what I use
>> for ARM build testing, except that here I also actively run the
>> resulting hypervisor).
> 
> Then I'm a bit confused what you meant by "32-bit build host" in your
> previous email.

What's confusing you here? Running a 64-bit hypervisor and/or a
64-bit kernel underneath a 32-bit distro is working quite fine.

> Anyway,  does my patch ("mkelf32: fix compilation on 32 bit build host")
> fix the problem you saw?

Yes. That was also what I had used as a temporary workaround. I
just didn't have the time right away to put this into proper patch
shape.

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Mon, May 02, 2016 at 03:06:21AM -0600, Jan Beulich wrote:
> >>> On 02.05.16 at 10:55,  wrote:
> > On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
> >> But how would that help you? Would you mean to monitor future
> >> patches for not again introducing some use of ENODATA that the
> >> tool stack wants to explicitly check for? That would be quite tedious
> >> a task...
> > 
> > Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
> > FreeBSD list of error codes seems quite pointless when there's no in-tree 
> > user of it.
> 
> That's a slightly strange way of looking at it: Shouldn't a component
> sitting on top of another component be capable of dealing with all
> output of that lower component, i.e. also any of the error codes that
> one may produce? In which case "no in-tree user" simply becomes a
> non-argument imo... (For comparison, consider a user mode library
> not itself using EINVAL: Would you say it's okay for the library to not
> care about EINVAL coming back from system calls?)

If it wasn't marked as optional and obsolescent I would have added it to 
FreeBSD without questioning, but the fact that the POSIX standard says that 
strictly conforming POSIX applications should not use it makes me wonder 
whether that is the right to do. ENODATA is the only error code that Xen 
uses that's not part of the core POSIX error codes.

IMHO Xen should be a strictly conforming POSIX application, it being a 
kernel that shares a common interface between a wide variety of different 
OSes.

I don't really want to make this any longer than necessary, so I think I'm 
going to try to get ENODATA added to the FreeBSD errno.h header, but I 
wouldn't be surprised if I found some resistance there, and TBH, I don't 
think I will be able to make a good point.

Roger.

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

Re: [Xen-devel] [PATCH v10 17/24] build_id: Provide ld-embedded build-ids

[Wei Liu]

On Mon, May 02, 2016 at 12:02:43AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 19:23,  wrote:
> > On Fri, Apr 29, 2016 at 10:38:07AM -0600, Jan Beulich wrote:
> >> >>> On 27.04.16 at 21:27,  wrote:
> >> > @@ -304,6 +338,32 @@ int main(int argc, char **argv)
> >> >  /*mem_siz = (u32)in64_phdr.p_memsz;*/
> >> >  mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
> >> >  
> >> > +note_sz = note_base = offset = 0;
> >> > +if ( num_phdrs > 1 )
> >> > +{
> >> > +offset = in64_phdr.p_offset;
> >> > +note_base = in64_phdr.p_vaddr;
> >> > +
> >> > +(void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), 
> >> > SEEK_SET);
> >> > +do_read(infd, _phdr, sizeof(in64_phdr));
> >> > +endianadjust_phdr64(_phdr);
> >> > +
> >> > +(void)lseek(infd, offset, SEEK_SET);
> >> > +
> >> > +note_sz = in64_phdr.p_memsz;
> >> > +note_base = in64_phdr.p_vaddr - note_base;
> >> > +
> >> > +if ( in64_phdr.p_offset > dat_siz || offset > 
> >> > in64_phdr.p_offset )
> >> > +{
> >> > +fprintf(stderr, "Expected .note section within .text 
> > section!\n" \
> >> > +"Offset %ld not within %d!\n",
> >> > +in64_phdr.p_offset, dat_siz);
> >> 
> >> This fails to build on a 32-bit build host (which is one of the two
> >> post-commit, pre-push checks I normally do).
> > 
> > I hadn't realized that it was possible to build an 64-bit hypervisor on 
> > 32-bit
> > GCC toolchain. I've never done that - always built the hypervisor in 64-bit 
> > env and the 32-bit toolstack in 32-bit environment. Then booted it.
> 
> 32-bit toolchain? No. A 64-bit cross tool chain (similar to what I use
> for ARM build testing, except that here I also actively run the
> resulting hypervisor).
> 

Then I'm a bit confused what you meant by "32-bit build host" in your
previous email.

Anyway,  does my patch ("mkelf32: fix compilation on 32 bit build host")
fix the problem you saw?

Wei.

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

Re: [Xen-devel] [RFC PATCH 1/7] build: add debug menu to Kconfig

[Andrew Cooper]

On 02/05/2016 11:42, Wei Liu wrote:
> On Sun, May 01, 2016 at 11:10:40PM -0500, Doug Goldstein wrote:
>> There are a number of debugging options for Xen so the idea is to have a
>> menu to group them all together. Enabling this menu item will also
>> disable NDEBUG which will result in more debug prints. This was
>> previously wired into the 'debug=y' command line option.
>>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Andrew Cooper 
>> CC: George Dunlap 
>> CC: Ian Jackson 
>> CC: Jan Beulich 
>> CC: Konrad Rzeszutek Wilk 
>> CC: Stefano Stabellini 
>> CC: Tim Deegan 
>> CC: Wei Liu 
>> ---
>>  xen/Kconfig  | 2 ++
>>  xen/Kconfig.debug| 7 +++
>>  xen/include/xen/config.h | 4 
>>  3 files changed, 13 insertions(+)
>>  create mode 100644 xen/Kconfig.debug
>>
>> diff --git a/xen/Kconfig b/xen/Kconfig
>> index fa8b27c..0fe7a1a 100644
>> --- a/xen/Kconfig
>> +++ b/xen/Kconfig
>> @@ -26,3 +26,5 @@ config DEFCONFIG_LIST
>>  config EXPERT
>>  string
>>  option env="XEN_CONFIG_EXPERT"
>> +
>> +source "Kconfig.debug"
>> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
>> new file mode 100644
>> index 000..d14d758
>> --- /dev/null
>> +++ b/xen/Kconfig.debug
>> @@ -0,0 +1,7 @@
>> +
>> +menuconfig DEBUG
>> +bool "Debugging Options"
>> +---help---
>> +  If you want to debug Xen say Y and select any additional debugging
>> +  support options. This enables additional debugging through Xen
>> +  and as a result enabling this option results in no security 
>> guarantees.
> Maybe that's because I'm not a native speaker, this doesn't sound right
> to me -- it implies debugging option makes xen insecure.
>
> I think you mean "results in no security support"?

Instead of mentioning security, I would simply say "Enabling this option
is intended for development purposes only, and not for production use".

There is already a statement saying that issues which only affect a
debug hypervisor are not considered security relevant.

~Andrew

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

Re: [Xen-devel] [PATCH for-4.7 3/4] tools/xsplice: fix mixing system errno values with Xen ones.

[Wei Liu]

On Fri, Apr 29, 2016 at 04:21:19PM +0200, Roger Pau Monne wrote:
> Avoid using system errno values when comparing with Xen errno values.
> 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: Konrad Rzeszutek Wilk 
> Cc: Ross Lagerwall 
> Cc: Ian Jackson 
> Cc: Wei Liu 
> ---
> Using errno values inside of hypercall structs is not right IMHO, but there
> are already several occurrences of this. Although I'm adding the correct XEN_
> prefixes here, it's very likely that new additions/modifications to this
> file will not take this into account, breaking it for OSes != Linux.

While the discussion of errno is on-going, I think we should accept this
patch for the time being.

Wei.

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

Re: [Xen-devel] [Xen-users] How can I change "dom0" settings?

[Alex Watila]

How to Configure dom0 Memory in XenServer 6.1 and Later
http://support.citrix.com/article/CTX134951


On Sun, May 1, 2016 at 10:06 AM, Jason Long  wrote:

> Hello.
> How can I change "Dom0" settings on my Xen. I guess, I just can change
> memory setting. Am I right?
>
> Tnx.
>
> ___
> Xen-users mailing list
> xen-us...@lists.xen.org
> http://lists.xen.org/xen-users
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] bad page flags booting 32bit dom0 on 64bit hypervisor using dom0_mem (kernel >=4.2)

[Stefan Bader]

I recently tried to boot 32bit dom0 on 64bit Xen host which I configured to run
with a limited, fix amount of memory for dom0. It seems that somewhere between
kernel versions 3.19 and 4.2 (sorry that is still a wide range) the Linux kernel
would report bad page flags for a range of pages (which seem to be around the
end of the guest pfn range). For a 4.2 kernel that was easily missed as the boot
finished ok and dom0 was accessible. However starting with 4.4 (tested 4.5 and a
4.6-rc) the serial console output freezes after some of those bad page flag
messages and then (unfortunately without any further helpful output) the host
reboots (I assume there is a panic that triggers a reset).

I suspect the problem is more a kernel side one. It is just possible to
influence things by variation of dom0_mem=#,max:#. 512M seems ok, 1024M, 2048M,
and 3072M cause bad page flags starting around kernel 4.2 and reboots around
4.4. Then 4096M and not clamping dom0 memory seem to be ok again (though not
limiting dom0 memory seems to cause trouble on 32bit dom0 later when a domU
tries to balloon memory, but I think that is a different problem).

I have not seen this on a 64bit dom0. Below is an example of those bad page
errors. Somehow it looks to be a page marked as reserved. Initially I wondered
whether this could be a problem of not clearing page flags when moving mappings
to match the e820. But I never looked into i386 memory setup in that detail. So
I am posting this, hoping that someone may have an idea from the detail about
where to look next. PAE is enabled there. Usually its bpf init that gets hit but
that likely is just because that is doing the first vmallocs.

-Stefan


[4.748815] BUG: Bad page state in process swapper/0  pfn:3fc1e
[4.748861] page:f675a4b0 count:0 mapcount:0 mapping:  (null) index:0x0
[4.748908] flags: 0x3000400(reserved)
[4.748984] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set
[4.749030] bad because of flags:
[4.749069] flags: 0x400(reserved)
[4.749143] Modules linked in:
[4.749201] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB
4.2.0-10-generic #12-Ubuntu
[4.749303] Hardware name: Intel Corporation ...
[4.749379]    f0cffcfc c1730710 f675a4b0 f0cffd20 c115be27
c194692c
[4.749584]  f0d503ec 0003fc1e 007f c1946eb8 c194a70e 0001 f0cffd8c
c115f4c3
[4.749790]  0002 0141 9069 c1ac5384  f11d7ce4 f11d7ce4
c1ac4dc0
[4.749993] Call Trace:
[4.750034]  [] dump_stack+0x41/0x52
[4.750078]  [] bad_page+0xb7/0x110
[4.750121]  [] get_page_from_freelist+0x2d3/0x610
[4.750168]  [] __alloc_pages_nodemask+0x146/0x8f0
[4.750215]  [] ? find_entry.isra.13+0x52/0x90
[4.750260]  [] ? kmem_cache_alloc_trace+0x175/0x1e0
[4.750308]  [] ? 
__raw_callee_save___pv_queued_spin_unlock+0x6/0x10
[4.750373]  [] ? __kmalloc+0x21d/0x240
[4.750417]  [] __vmalloc_node_range+0x10e/0x210
[4.750464]  [] ? bpf_prog_alloc+0x37/0xa0
[4.750509]  [] __vmalloc_node+0x66/0x70
[4.750553]  [] ? bpf_prog_alloc+0x37/0xa0
[4.750598]  [] __vmalloc+0x34/0x40
[4.750642]  [] ? bpf_prog_alloc+0x37/0xa0
[4.750687]  [] bpf_prog_alloc+0x37/0xa0
[4.750732]  [] bpf_prog_create+0x2c/0x90
[4.750776]  [] ? bsp_pm_check_init+0x11/0x11
[4.750821]  [] ptp_classifier_init+0x20/0x28
[4.750866]  [] ?
[4.750933]  [] sock_init+0x7c/0x83
[4.750977]  [] do_one_initcall+0xaa/0x200
[4.751021]  [] ? bsp_pm_check_init+0x11/0x11
[4.751067]  [] ? parse_args+0x2ad/0x540
[4.751112]  [] kernel_init_freeable+0x13a/0x1bc
[4.751158]  [] kernel_init+0x10/0xe0
[4.751203]  [] ? schedule_tail+0x11/0x50
[4.751251]  [] ret_from_kernel_thread+0x21/0x30
[4.751297]  [] ? rest_init+0x70/0x70

For reference some memory info from an Intel box with 8G physical memory, booted
with 1024M dom0 memory on a 4.2 kernel. The range of bad page pfn from syslog
was 3fc1e to 3fc3b. The reported pages (f675a4b0 to f675a938) all with the same
line about no mappings or references.

(XEN) Xen-e820 RAM map:
(XEN)  - 0009a400 (usable)
(XEN) 0009a400 - 000a (reserved)
(XEN) 000e - 0010 (reserved)
(XEN) 0010 - 30a48000 (usable)
(XEN) 30a48000 - 30a49000 (reserved)
(XEN) 30a49000 - a27f4000 (usable)
(XEN) a27f4000 - a2ab4000 (reserved)
(XEN) a2ab4000 - a2fb4000 (ACPI NVS)
(XEN) a2fb4000 - a2feb000 (ACPI data)
(XEN) a2feb000 - a300 (usable)
(XEN) a300 - afa0 (reserved)
(XEN) e000 - f000 (reserved)
(XEN) fec0 - fec01000 (reserved)
(XEN) fed0 - fed04000 (reserved)
(XEN) fed1 - fed1a000 (reserved)
(XEN) fed1c000 - fed2 (reserved)
(XEN) fed84000 - fed85000 (reserved)
(XEN) 

Re: [Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Wei Liu]

On Mon, May 02, 2016 at 04:36:11PM +0800, Big Strong wrote:
> I've successfully add a new physical page to guest and trying to use it as
> the virtualization exception (#VE) infomation page. However, the function:
> xc_altp2m_set_vcpu_enable_notify(xci, domid, vcpuid, gfn)
> failed for unknown reason (return -1). The only related info I can get is

Check the errno please, thats' where the information is stored.

Wei.

> by `dmesg`:
> 
> [605716.546390] vmfunc[16835]: segfault at 0 ip 004009fb sp
> > 7fff3a7b87a0 error 4 in vmfunc[40+1000]
> > [605781.162125] vmfunc[16840]: segfault at 0 ip 004009fb sp
> > 7fffd84c86d0 error 4 in vmfunc[40+1000]
> > [606113.290934] vmfunc[16860]: segfault at 0 ip 004009fb sp
> > 7fffaa076fb0 error 4 in vmfunc[40+1000]

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


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

Re: [Xen-devel] efi_enabled(EFI_PARAVIRT) use

[Matt Fleming]

On Sun, 01 May, at 10:36:51PM, Shannon Zhao wrote:
> So is there any other way you suggest?

Would this work (compile tested but not runtime tested)?

---

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3a69ed5ecfcb..13d8be16447a 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -469,12 +469,14 @@ device_initcall(efi_load_efivars);
FIELD_SIZEOF(struct efi_fdt_params, field) \
}
 
-static __initdata struct {
+struct params {
const char name[32];
const char propname[32];
int offset;
int size;
-} dt_params[] = {
+};
+
+static __initdata struct params fdt_params[] = {
UEFI_PARAM("System Table", "linux,uefi-system-table", system_table),
UEFI_PARAM("MemMap Address", "linux,uefi-mmap-start", mmap),
UEFI_PARAM("MemMap Size", "linux,uefi-mmap-size", mmap_size),
@@ -482,44 +484,83 @@ static __initdata struct {
UEFI_PARAM("MemMap Desc. Version", "linux,uefi-mmap-desc-ver", desc_ver)
 };
 
+static __initdata struct params xen_fdt_params[] = {
+   UEFI_PARAM("System Table", "xen,uefi-system-table", system_table),
+   UEFI_PARAM("MemMap Address", "xen,uefi-mmap-start", mmap),
+   UEFI_PARAM("MemMap Size", "xen,uefi-mmap-size", mmap_size),
+   UEFI_PARAM("MemMap Desc. Size", "xen,uefi-mmap-desc-size", desc_size),
+   UEFI_PARAM("MemMap Desc. Version", "xen,uefi-mmap-desc-ver", desc_ver)
+};
+
+#define EFI_FDT_PARAMS_SIZEARRAY_SIZE(fdt_params)
+
+static __initdata struct {
+   const char *uname;
+   struct params *params;
+} dt_params[] = {
+   { "hypervisor", xen_fdt_params },
+   { "chosen", fdt_params },
+};
+
 struct param_info {
int found;
void *params;
+   const char *missing;
 };
 
-static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
-  int depth, void *data)
+static int __init __find_uefi_params(unsigned long node,
+struct param_info *info,
+struct params *params)
 {
-   struct param_info *info = data;
const void *prop;
void *dest;
u64 val;
int i, len;
 
-   if (depth != 1 || strcmp(uname, "chosen") != 0)
-   return 0;
-
-   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
-   prop = of_get_flat_dt_prop(node, dt_params[i].propname, );
-   if (!prop)
+   for (i = 0; i < EFI_FDT_PARAMS_SIZE; i++) {
+   prop = of_get_flat_dt_prop(node, params[i].propname, );
+   if (!prop) {
+   info->missing = params[i].name;
return 0;
-   dest = info->params + dt_params[i].offset;
+   }
+
+   dest = info->params + params[i].offset;
info->found++;
 
val = of_read_number(prop, len / sizeof(u32));
 
-   if (dt_params[i].size == sizeof(u32))
+   if (params[i].size == sizeof(u32))
*(u32 *)dest = val;
else
*(u64 *)dest = val;
 
if (efi_enabled(EFI_DBG))
-   pr_info("  %s: 0x%0*llx\n", dt_params[i].name,
-   dt_params[i].size * 2, val);
+   pr_info("  %s: 0x%0*llx\n", params[i].name,
+   params[i].size * 2, val);
}
+
return 1;
 }
 
+static int __init fdt_find_uefi_params(unsigned long node, const char *uname,
+  int depth, void *data)
+{
+   struct param_info *info = data;
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(dt_params); i++) {
+
+   if (depth != 1 || strcmp(uname, dt_params[i].uname) != 0) {
+   info->missing = dt_params[i].params[0].name;
+   continue;
+   }
+
+   return __find_uefi_params(node, info, dt_params[i].params);
+   }
+
+   return 0;
+}
+
 int __init efi_get_fdt_params(struct efi_fdt_params *params)
 {
struct param_info info;
@@ -535,7 +576,7 @@ int __init efi_get_fdt_params(struct efi_fdt_params *params)
pr_info("UEFI not found.\n");
else if (!ret)
pr_err("Can't find '%s' in device tree!\n",
-  dt_params[info.found].name);
+  info.missing);
 
return ret;
 }

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

Re: [Xen-devel] [RFC PATCH 1/7] build: add debug menu to Kconfig

[Wei Liu]

On Sun, May 01, 2016 at 11:10:40PM -0500, Doug Goldstein wrote:
> There are a number of debugging options for Xen so the idea is to have a
> menu to group them all together. Enabling this menu item will also
> disable NDEBUG which will result in more debug prints. This was
> previously wired into the 'debug=y' command line option.
> 
> Signed-off-by: Doug Goldstein 
> ---
> CC: Andrew Cooper 
> CC: George Dunlap 
> CC: Ian Jackson 
> CC: Jan Beulich 
> CC: Konrad Rzeszutek Wilk 
> CC: Stefano Stabellini 
> CC: Tim Deegan 
> CC: Wei Liu 
> ---
>  xen/Kconfig  | 2 ++
>  xen/Kconfig.debug| 7 +++
>  xen/include/xen/config.h | 4 
>  3 files changed, 13 insertions(+)
>  create mode 100644 xen/Kconfig.debug
> 
> diff --git a/xen/Kconfig b/xen/Kconfig
> index fa8b27c..0fe7a1a 100644
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -26,3 +26,5 @@ config DEFCONFIG_LIST
>  config EXPERT
>   string
>   option env="XEN_CONFIG_EXPERT"
> +
> +source "Kconfig.debug"
> diff --git a/xen/Kconfig.debug b/xen/Kconfig.debug
> new file mode 100644
> index 000..d14d758
> --- /dev/null
> +++ b/xen/Kconfig.debug
> @@ -0,0 +1,7 @@
> +
> +menuconfig DEBUG
> + bool "Debugging Options"
> + ---help---
> +   If you want to debug Xen say Y and select any additional debugging
> +   support options. This enables additional debugging through Xen
> +   and as a result enabling this option results in no security 
> guarantees.

Maybe that's because I'm not a native speaker, this doesn't sound right
to me -- it implies debugging option makes xen insecure.

I think you mean "results in no security support"?

Wei.

> diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
> index ef6e5ee..473c5e8 100644
> --- a/xen/include/xen/config.h
> +++ b/xen/include/xen/config.h
> @@ -81,4 +81,8 @@
>  /* allow existing code to work with Kconfig variable */
>  #define NR_CPUS CONFIG_NR_CPUS
>  
> +#ifndef CONFIG_DEBUG
> +#define NDEBUG
> +#endif
> +
>  #endif /* __XEN_CONFIG_H__ */
> -- 
> 2.7.3
> 

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

Re: [Xen-devel] [PATCH v2 2/5] vm_event: Implement ARM SMC events

[Wei Liu]

On Fri, Apr 29, 2016 at 12:07:30PM -0600, Tamas K Lengyel wrote:
>  tools/libxc/include/xenctrl.h   |   2 +
>  tools/libxc/xc_monitor.c|  26 +++-

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH V3] x86/monitor: Disallow setting mem_access_emulate_each_rep when vm_event is NULL

[Wei Liu]

On Fri, Apr 29, 2016 at 07:12:47PM +0300, Razvan Cojocaru wrote:
> On 04/09/16 08:54, Razvan Cojocaru wrote:
> > It is meaningless (and potentially dangerous - see 
> > hvmemul_virtual_to_linear())
> > to set mem_access_emulate_each_rep before xc_monitor_enable() (which 
> > allocates
> > vcpu->arch.vm_event) has been called, so return an error from the
> > XEN_DOMCTL_MONITOR_OP_EMULATE_EACH_REP hypercall when that is the case.
> > 
> > Signed-off-by: Razvan Cojocaru 
> > Reviewed-by: Andrew Cooper 

Release-acked-by: Wei Liu 

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

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

[Wei Liu]

On Fri, Apr 22, 2016 at 02:44:25AM -0600, Jan Beulich wrote:
> Short of getting any feedback on the previous discussion item
> http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg00571.html
> here's a formal revert request: Please revert commit 19f6c522a6
> from the staging tree (afaict it didn't get mirrored to any of the
> stable trees yet), as the changes it does are not necessary and
> possibly misleading.
> 

FWIW your analysis in the other thread makes sense to me. There doesn't
seem to be interaction between untrusted frontend and backend.

Wei.

> Thanks, Jan
> 

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

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

[osstest service owner]

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

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  77eb5dbeff78bbe549793325520f59ab46a187f8
baseline version:
 xen  c2994f8632d56e5379e612daa216401477dccbdb

Last test of basis93229  2016-04-29 19:02:30 Z2 days
Testing same since93352  2016-05-02 08:03:18 Z0 days1 attempts


People who touched revisions under test:
  Jan Beulich 
  Tim Deegan 

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=77eb5dbeff78bbe549793325520f59ab46a187f8
+ . ./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 
77eb5dbeff78bbe549793325520f59ab46a187f8
+ branch=xen-unstable-smoke
+ revision=77eb5dbeff78bbe549793325520f59ab46a187f8
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.6-testing
+ '[' x77eb5dbeff78bbe549793325520f59ab46a187f8 = 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 

Re: [Xen-devel] [PATCH for-4.6] Config.mk: update mini-os commit

[Wei Liu]

On Mon, May 02, 2016 at 11:51:45AM +0200, Samuel Thibault wrote:
> Wei Liu, on Mon 02 May 2016 10:48:11 +0100, wrote:
> > On Mon, Apr 25, 2016 at 12:21:51PM +0100, Wei Liu wrote:
> > > On Mon, Apr 25, 2016 at 05:15:57AM -0600, Jan Beulich wrote:
> > > > >>> On 25.04.16 at 13:12,  wrote:
> > > > > Backport several fixes to mini-os in order to fix stubdom in 4.6.
> > > > > 
> > > > > Patches pulled in:
> > > > > 
> > > > > xenbus: notify the other end when necessary
> > > > > Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483
> > > > > Clean arch/x86/time.c
> > > > > Fix time update
> > > > > 
> > > > > Signed-off-by: Wei Liu 
> > > > 
> > > > Fine by me, provided the mini-os maintainer agrees these are
> > > > important enough to go into a stable update.
> > > > 
> > > 
> > > Oops, I forgot to CC Samuel. Thanks Jan for doing that.
> > > 
> > > Samuel, the branch is xen-stable-4.6 in mini-os.git.
> > 
> > Ping?
> 
> I'm not sure who is the destination of the ping, but just in case: yes I
> agree these should go to a stable update.
> 

It was directed to you because you're listed as mini-os maintainer in
xen.git MAINTAINERS file.

Sorry if that's not clear.

Wei.

> Samuel

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

Re: [Xen-devel] [PATCH for-4.6] Config.mk: update mini-os commit

[Samuel Thibault]

Wei Liu, on Mon 02 May 2016 10:48:11 +0100, wrote:
> On Mon, Apr 25, 2016 at 12:21:51PM +0100, Wei Liu wrote:
> > On Mon, Apr 25, 2016 at 05:15:57AM -0600, Jan Beulich wrote:
> > > >>> On 25.04.16 at 13:12,  wrote:
> > > > Backport several fixes to mini-os in order to fix stubdom in 4.6.
> > > > 
> > > > Patches pulled in:
> > > > 
> > > > xenbus: notify the other end when necessary
> > > > Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483
> > > > Clean arch/x86/time.c
> > > > Fix time update
> > > > 
> > > > Signed-off-by: Wei Liu 
> > > 
> > > Fine by me, provided the mini-os maintainer agrees these are
> > > important enough to go into a stable update.
> > > 
> > 
> > Oops, I forgot to CC Samuel. Thanks Jan for doing that.
> > 
> > Samuel, the branch is xen-stable-4.6 in mini-os.git.
> 
> Ping?

I'm not sure who is the destination of the ping, but just in case: yes I
agree these should go to a stable update.

Samuel

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

Re: [Xen-devel] failed to get gcov result for libelf_* files

[Zhangbo (Oscar)]

>Hi all:
>I'm backporting gcov-related patches(68ca0bc4ba -> 922153cd37) to xen
>4.1.2, but encountered with several problems, one problem is as follows:
>1) although all the files are gathered into gcov_info_list correctly by
>__gcov_init(), but when we call write_gcov(), 3 gcov_info seem had been broken.
>   xen/common/libelf/libelf-tools.c
>   xen/common/libelf/libelf-loader.c
>   xen/common/libelf/libelf-dominfo.c
>
>info->filename of theis are NULL, thus when we call write_gcov() ->
>write_string() -> strlen(), segment fault and kernel panic occurs.
>
>2)  even if we fixed the above problem by:
>If ( !info->filename )
>continue;
>   inside write_gcov(),  I found that the info next to the problem one is
>null, thus, files after the problem one all get skipped. ( we only get 200 
>gcda files
>although we have 262 source files in total)
>
>3) I 'fixed' this by modify __gcov_init():
>   void __gcov_init(struct gcov_info *info)
>   {
>   /* add new profiling data structure to list */
>  +n_info_list ++;
>  +if (n_info_list >= 61 && n_info_list <=63) {
>  +   printk("skip:%d\n", n_info_list);
>  +   return;
>  +}
>   info->next = info_list;
>   info_list = info;
>   }
>   Then the files after these 3 files are not affected. We got 259 gcda 
> files
>then.
>

I found that OBJCOPY is related to the problem! If I remove the OBJCOPY process 
in the Makefile of libelf, the problem got 'fixed':

diff --git a/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile 
b/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile
index 854e738..f522ae0 100755
--- a/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile
+++ b/open-source/xen/xen-4.1.2/xen/common/libelf/Makefile
@@ -1,9 +1,9 @@
 obj-y := libelf.o

-SECTIONS := text data rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) $(foreach 
r,rel rel.ro,data.$(r) data.$(r).local)
+#SECTIONS := text data rodata $(foreach n,1 2 4 8,rodata.str1.$(n)) $(foreach 
r,rel rel.ro,data.$(r) data.$(r).local)

-libelf.o: libelf-temp.o Makefile
-   $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) 
$< $@
+#libelf.o: libelf-temp.o Makefile
+#  $(OBJCOPY) $(foreach s,$(SECTIONS),--rename-section .$(s)=.init.$(s)) 
$< $@

-libelf-temp.o: libelf-tools.o libelf-loader.o libelf-dominfo.o 
#libelf-relocate.o
+libelf.o: libelf-tools.o libelf-loader.o libelf-dominfo.o #libelf-relocate.o
$(LD) $(LDFLAGS) -r -o $@ $^

It's still not the final solution. What's objcopy here used for? What bad 
result will happen if I remove it here? Thanks.


>But, my solution obviously is the not the right solution, what's special 
> about
>the 3 files? Why are their gcov_info get modified(filename changed to NULL)
>between __gcov_init() and write_gcov()? What's your suggestion to debug the
>problem?
>
>Thanks in advance.
>
>   Oscar.

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

Re: [Xen-devel] [PATCH for-4.6] Config.mk: update mini-os commit

[Wei Liu]

On Mon, Apr 25, 2016 at 12:21:51PM +0100, Wei Liu wrote:
> On Mon, Apr 25, 2016 at 05:15:57AM -0600, Jan Beulich wrote:
> > >>> On 25.04.16 at 13:12,  wrote:
> > > Backport several fixes to mini-os in order to fix stubdom in 4.6.
> > > 
> > > Patches pulled in:
> > > 
> > > xenbus: notify the other end when necessary
> > > Mini-OS: netfront: fix off-by-one error introduced in 7c8f3483
> > > Clean arch/x86/time.c
> > > Fix time update
> > > 
> > > Signed-off-by: Wei Liu 
> > 
> > Fine by me, provided the mini-os maintainer agrees these are
> > important enough to go into a stable update.
> > 
> 
> Oops, I forgot to CC Samuel. Thanks Jan for doing that.
> 
> Samuel, the branch is xen-stable-4.6 in mini-os.git.
> 

Ping?

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

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

[osstest service owner]

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

Regressions :-(

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

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

Last test of basis65543  2015-12-08 08:45:15 Z  146 days
Failing since 65593  2015-12-08 23:44:51 Z  145 days  200 attempts
Testing same since93232  2016-04-29 20:13:53 Z2 days9 attempts


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

Re: [Xen-devel] [PATCH for-4.7] tools: xen-xsplice.c: fix length parameter of memset in list_func

[Wei Liu]

On Sun, May 01, 2016 at 08:42:56PM -0400, Konrad Rzeszutek Wilk wrote:
> On Sun, May 01, 2016 at 07:21:45PM +0100, Wei Liu wrote:
> > The length expression should be the same one used in malloc.
> > 
> > CID: 1358947
> > 
> > Signed-off-by: Wei Liu 
> > ---
> > Cc: Ian Jackson 
> > Cc: Konrad Rzeszutek Wilk 
> 
> Reviewed-by: Konrad Rzeszutek Wilk 
> 

Thanks for the quick response.

Queued.

> > Cc: Ross Lagerwall 
> > ---
> >  tools/misc/xen-xsplice.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
> > index 0f1ab5a..b3bf048 100644
> > --- a/tools/misc/xen-xsplice.c
> > +++ b/tools/misc/xen-xsplice.c
> > @@ -95,7 +95,7 @@ static int list_func(int argc, char *argv[])
> >  done = 0;
> >  /* The memset is done to catch errors. */
> >  memset(info, 'A', sizeof(*info) * MAX_LEN);
> > -memset(name, 'B', sizeof(*name * MAX_LEN * XEN_XSPLICE_NAME_SIZE));
> > +memset(name, 'B', sizeof(*name) * MAX_LEN * XEN_XSPLICE_NAME_SIZE);
> >  memset(len, 'C', sizeof(*len) * MAX_LEN);
> >  rc = xc_xsplice_list(xch, MAX_LEN, idx, info, name, len, , 
> > );
> >  if ( rc )
> > -- 
> > 2.1.4
> > 

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

Re: [Xen-devel] [PATCH] ocaml/xc_get_cpu_featureset/arm: Return not implemented on ARM

[Wei Liu]

On Fri, Apr 29, 2016 at 04:30:45PM +0100, Andrew Cooper wrote:
> On 29/04/16 15:54, Wei Liu wrote:
> > On Fri, Apr 29, 2016 at 02:38:33AM -0400, Konrad Rzeszutek Wilk wrote:
> >> . as it is not implemented on it.
> >>
> >> Signed-off-by: Konrad Rzeszutek Wilk 
> >>
> >> ---
> >> v1: Initial botched patch that didn't compile.
> >> v2: Andrew mentioned to "need to set ENOSYS in the xch last
> >> error." - but we do not use 'failwith_xc', and:
> >>a). The error codes you set are no EXX type.
> >>b). The best I can do is set errno=ENOSYS; Is that what you would 
> >> like?
> >>
> > As far as I can tell this change follows existing pattern so it's
> > probably fine. But I will wait until some ocaml experts chime in.
> 
> This appears to be the prevailing pattern.
> 
> Reviewed-by: Andrew Cooper 

Thanks.

Acked and queued.

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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 02.05.16 at 10:55,  wrote:
> On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
>> But how would that help you? Would you mean to monitor future
>> patches for not again introducing some use of ENODATA that the
>> tool stack wants to explicitly check for? That would be quite tedious
>> a task...
> 
> Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
> FreeBSD list of error codes seems quite pointless when there's no in-tree 
> user of it.

That's a slightly strange way of looking at it: Shouldn't a component
sitting on top of another component be capable of dealing with all
output of that lower component, i.e. also any of the error codes that
one may produce? In which case "no in-tree user" simply becomes a
non-argument imo... (For comparison, consider a user mode library
not itself using EINVAL: Would you say it's okay for the library to not
care about EINVAL coming back from system calls?)

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Roger Pau Monne]

On Mon, May 02, 2016 at 12:22:35AM -0600, Jan Beulich wrote:
> >>> On 29.04.16 at 18:52,  wrote:
> > On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
> >> >>> On 29.04.16 at 18:34,  wrote:
> >> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
> >> >> >>> On 29.04.16 at 17:06,  wrote:
> >> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 29.04.16 at 16:21,  wrote:
> >> >> >> > According to the POSIX standard for error codes [0], ENODATA is 
> >> >> >> > both
> >> >> >> > obsolescent (so it may be removed in the future) and optional.
> >> >> >> 
> >> >> >> It being optional still doesn't preclude us using it.
> >> >> >> 
> >> >> >> > Replace it's
> >> >> >> > usage with ENOENT, which seems like the closest match. Both 
> >> >> >> > FreeBSD and
> >> >> >> > OpenBSD don't have this error code in the native errno.h headers.
> >> >> >> 
> >> >> >> There's no rule saying that Xen's errno set must match any other 
> >> >> >> OS'es.
> >> >> >> That's one of the reasons why we (finally) separated ours.
> >> >> > 
> >> >> > I understand that, but doing this means that then on the toolstack 
> >> >> > side we 
> > 
> >> >> > need to start doing ifdefery in order to match values that are not 
> >> >> > present 
> > 
> >> >> > in the native OS. For example a check was added to libxl against 
> >> >> > XENVER_build_id returning ENODATA, this means that then on libxl I 
> >> >> > would 
> >> >> > have to add a:
> >> >> > 
> >> >> > #ifdef __FreeBSD__
> >> >> > #define ENODATA ENOENT
> >> >> > #endif
> >> >> 
> >> >> You ought to be using XEN_NODATA there anyway.
> >> > 
> >> > No, the privcmd driver is the one that performs the translation from Xen 
> >> > error codes into the OS error code space, so the tools just see error 
> >> > codes 
> > 
> >> > in the OS space. No tools at all use XEN_* error codes directly.
> >> 
> >> That's the supposed behavior for return values, but not for
> >> structure contents. The structures are Xen-specific, so them
> >> holding Xen-specific values is known to the callers, and they
> >> should (be made) cope.
> > 
> > And the usage of ENODATA I'm trying to fix here is from the direct return 
> > of 
> > 
> > an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I 
> > just think it would be better to simply replace the usage of ENODATA with 
> > something else, so I could avoid adding more ifdefery to the tools.
> > 
> > Would you be fine with me just adjusting xen_build_id (in 
> > xen/common/version.c) to return ENOENT instead of ENODATA?
> 
> Well, I wouldn't be particularly happy, but I'd also not be as heavily
> opposed as to removing that error code altogether. In general (and
> I probably should have said this in the first reply, despite there
> having been the other more important reason to object) I don't view
> ENOENT as a good replacement for ENODATA. The two really mean
> different things, but in this particular case it would seem a reasonable
> replacement.

Right. But since the privcmd driver does the error code translation I think 
ENOENT is the closest match to ENODATA when doing automatic error 
translation (I'm open to suggestions if someone knows a better replacement 
for it).

> But how would that help you? Would you mean to monitor future
> patches for not again introducing some use of ENODATA that the
> tool stack wants to explicitly check for? That would be quite tedious
> a task...

Yes it is, but TBH I cannot find any other solution. Adding ENODATA to the 
FreeBSD list of error codes seems quite pointless when there's no in-tree 
user of it.

Roger.

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

[Xen-devel] xc_altp2m_set_vcpu_enable_notify fail

[Big Strong]

I've successfully add a new physical page to guest and trying to use it as
the virtualization exception (#VE) infomation page. However, the function:
xc_altp2m_set_vcpu_enable_notify(xci, domid, vcpuid, gfn)
failed for unknown reason (return -1). The only related info I can get is
by `dmesg`:

[605716.546390] vmfunc[16835]: segfault at 0 ip 004009fb sp
> 7fff3a7b87a0 error 4 in vmfunc[40+1000]
> [605781.162125] vmfunc[16840]: segfault at 0 ip 004009fb sp
> 7fffd84c86d0 error 4 in vmfunc[40+1000]
> [606113.290934] vmfunc[16860]: segfault at 0 ip 004009fb sp
> 7fffaa076fb0 error 4 in vmfunc[40+1000]
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] failed to get gcov result for libelf_* files

[Zhangbo (Oscar)]

Hi all:
I'm backporting gcov-related patches(68ca0bc4ba -> 922153cd37) to xen 
4.1.2, but encountered with several problems, one problem is as follows:
1) although all the files are gathered into gcov_info_list correctly by 
__gcov_init(), but when we call write_gcov(), 3 gcov_info seem had been broken.
   xen/common/libelf/libelf-tools.c
   xen/common/libelf/libelf-loader.c
   xen/common/libelf/libelf-dominfo.c

info->filename of theis are NULL, thus when we call write_gcov() -> 
write_string() -> strlen(), segment fault and kernel panic occurs.

2)  even if we fixed the above problem by:
If ( !info->filename )
continue;
   inside write_gcov(),  I found that the info next to the problem one is 
null, thus, files after the problem one all get skipped. ( we only get 200 gcda 
files although we have 262 source files in total)

3) I 'fixed' this by modify __gcov_init():
   void __gcov_init(struct gcov_info *info)
   {
   /* add new profiling data structure to list */
  +n_info_list ++;
  +if (n_info_list >= 61 && n_info_list <=63) {
  +   printk("skip:%d\n", n_info_list);
  +   return;
  +}
   info->next = info_list;
   info_list = info;
   }
   Then the files after these 3 files are not affected. We got 259 gcda 
files then.

But, my solution obviously is the not the right solution, what's special 
about the 3 files? Why are their gcov_info get modified(filename changed to 
NULL) between __gcov_init() and write_gcov()? What's your suggestion to debug 
the problem?

Thanks in advance.

   Oscar.

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

[Xen-devel] [distros-debian-sid test] 44379: tolerable trouble: blocked/broken

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-armhf-pvops 3 host-install(3)  broken like 44363
 build-armhf   3 host-install(3)  broken like 44363
 build-amd64   3 host-install(3)  broken like 44363
 build-amd64-pvops 3 host-install(3)  broken like 44363
 build-i3863 host-install(3)  broken like 44363
 build-i386-pvops  3 host-install(3)  broken like 44363

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-sid-netboot-pygrub  1 build-check(1)blocked n/a
 test-amd64-amd64-i386-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-i386-i386-sid-netboot-pvgrub  1 build-check(1)  blocked n/a
 test-amd64-i386-amd64-sid-netboot-pygrub  1 build-check(1) blocked n/a
 test-amd64-amd64-amd64-sid-netboot-pvgrub  1 build-check(1)blocked n/a

baseline version:
 flight   44363

jobs:
 build-amd64  broken  
 build-armhf  broken  
 build-i386   broken  
 build-amd64-pvopsbroken  
 build-armhf-pvopsbroken  
 build-i386-pvops broken  
 test-amd64-amd64-amd64-sid-netboot-pvgrubblocked 
 test-amd64-i386-i386-sid-netboot-pvgrub  blocked 
 test-amd64-i386-amd64-sid-netboot-pygrub blocked 
 test-armhf-armhf-armhf-sid-netboot-pygrubblocked 
 test-amd64-amd64-i386-sid-netboot-pygrub blocked 



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

Re: [Xen-devel] [PATCH v10 21/24] xsplice: Stacking build-id dependency checking.

[Jan Beulich]

>>> On 27.04.16 at 21:27,  wrote:
> @@ -506,6 +518,37 @@ static int prepare_payload(struct payload *payload,
>  }
>  }
>  
> +sec = xsplice_elf_sec_by_name(elf, ELF_BUILD_ID_NOTE);
> +if ( sec )
> +{
> +n = sec->load_addr;
> +
> +if ( sec->sec->sh_size <= sizeof(*n) )
> +return -EINVAL;
> +
> +if ( xen_build_id_check(n, sec->sec->sh_size,
> +>id.p, >id.len) )
> +return -EINVAL;
> +
> +if ( !payload->id.len || !payload->id.p )
> +return -EINVAL;
> +}
> +
> +sec = xsplice_elf_sec_by_name(elf, ELF_XSPLICE_DEPENDS);
> +{

Looks like an "if ( sec )" got lost here.

Jan


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

Re: [Xen-devel] [PATCH for-4.7 1/4] xen: remove usage of ENODATA error code

[Jan Beulich]

>>> On 29.04.16 at 18:52,  wrote:
> On Fri, Apr 29, 2016 at 10:42:06AM -0600, Jan Beulich wrote:
>> >>> On 29.04.16 at 18:34,  wrote:
>> > On Fri, Apr 29, 2016 at 10:19:41AM -0600, Jan Beulich wrote:
>> >> >>> On 29.04.16 at 17:06,  wrote:
>> >> > On Fri, Apr 29, 2016 at 08:44:48AM -0600, Jan Beulich wrote:
>> >> >> >>> On 29.04.16 at 16:21,  wrote:
>> >> >> > According to the POSIX standard for error codes [0], ENODATA is both
>> >> >> > obsolescent (so it may be removed in the future) and optional.
>> >> >> 
>> >> >> It being optional still doesn't preclude us using it.
>> >> >> 
>> >> >> > Replace it's
>> >> >> > usage with ENOENT, which seems like the closest match. Both FreeBSD 
>> >> >> > and
>> >> >> > OpenBSD don't have this error code in the native errno.h headers.
>> >> >> 
>> >> >> There's no rule saying that Xen's errno set must match any other OS'es.
>> >> >> That's one of the reasons why we (finally) separated ours.
>> >> > 
>> >> > I understand that, but doing this means that then on the toolstack side 
>> >> > we 
> 
>> >> > need to start doing ifdefery in order to match values that are not 
>> >> > present 
> 
>> >> > in the native OS. For example a check was added to libxl against 
>> >> > XENVER_build_id returning ENODATA, this means that then on libxl I 
>> >> > would 
>> >> > have to add a:
>> >> > 
>> >> > #ifdef __FreeBSD__
>> >> > #define ENODATA ENOENT
>> >> > #endif
>> >> 
>> >> You ought to be using XEN_NODATA there anyway.
>> > 
>> > No, the privcmd driver is the one that performs the translation from Xen 
>> > error codes into the OS error code space, so the tools just see error 
>> > codes 
> 
>> > in the OS space. No tools at all use XEN_* error codes directly.
>> 
>> That's the supposed behavior for return values, but not for
>> structure contents. The structures are Xen-specific, so them
>> holding Xen-specific values is known to the callers, and they
>> should (be made) cope.
> 
> And the usage of ENODATA I'm trying to fix here is from the direct return of 
> 
> an hypercall (__HYPERVISOR_xen_version). I don't mind adding this define, I 
> just think it would be better to simply replace the usage of ENODATA with 
> something else, so I could avoid adding more ifdefery to the tools.
> 
> Would you be fine with me just adjusting xen_build_id (in 
> xen/common/version.c) to return ENOENT instead of ENODATA?

Well, I wouldn't be particularly happy, but I'd also not be as heavily
opposed as to removing that error code altogether. In general (and
I probably should have said this in the first reply, despite there
having been the other more important reason to object) I don't view
ENOENT as a good replacement for ENODATA. The two really mean
different things, but in this particular case it would seem a reasonable
replacement.

But how would that help you? Would you mean to monitor future
patches for not again introducing some use of ENODATA that the
tool stack wants to explicitly check for? That would be quite tedious
a task...

Jan


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