date:20151023

[Xen-devel] [xen-unstable baseline-only test] 38203: regressions - trouble: broken/fail/pass

2015-10-23 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-pygrub  19 guest-start.2 fail REGR. vs. 38179
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 4 host-ping-check-native fail 
REGR. vs. 38179
 test-amd64-amd64-xl-qemuu-winxpsp3 4 host-ping-check-native fail REGR. vs. 
38179

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-multivcpu 19 capture-logs(19)  broken blocked in 38179
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail 
like 38179
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 38179
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 38179

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-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-amd64-xl-pvh-intel 11 guest-start  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-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 xen  e08f3834c2f375153f104c827dd7c2fea93b288e
baseline version:
 xen  3a95c3f9c26a4b877598d45886eae95963c5d793

Last test of basis38179  2015-10-19 03:49:03 Z5 days
Testing same since38203  2015-10-23 10:52:03 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Kai Huang 
  Kevin Tian 
  Tim Deegan 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-oldkern  pass
 build-i386-oldkern   pass
 build-amd64-prev pass
 build-i386-prev  pass
 buil

[Xen-devel] [PATCH v2 1/5] xl: convert exit codes to EXIT_[SUCCESS|FAILURE]

2015-10-23 Thread Harmandeep Kaur

turning main function xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

also includes a document comment in xl.h stating xl process should
always return EXIT_FOO and main_* can be treated as main() as if
they are returning a process exit status and not a function return
value)

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl.c | 12 ++--
 tools/libxl/xl.h |  6 ++
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/tools/libxl/xl.c b/tools/libxl/xl.c
index 5316ad9..dfae84a 100644
--- a/tools/libxl/xl.c
+++ b/tools/libxl/xl.c
@@ -318,7 +318,7 @@ int main(int argc, char **argv)
 break;
 default:
 fprintf(stderr, "unknown global option\n");
-exit(2);
+exit(EXIT_FAILURE);
 }
 }
 
@@ -326,13 +326,13 @@ int main(int argc, char **argv)
 
 if (!cmd) {
 help(NULL);
-exit(1);
+exit(EXIT_FAILURE);
 }
 opterr = 0;
 
 logger = xtl_createlogger_stdiostream(stderr, minmsglevel,
 (progress_use_cr ? XTL_STDIOSTREAM_PROGRESS_USE_CR : 0));
-if (!logger) exit(1);
+if (!logger) exit(EXIT_FAILURE);
 
 atexit(xl_ctx_free);
 
@@ -355,16 +355,16 @@ int main(int argc, char **argv)
 if (cspec) {
 if (dryrun_only && !cspec->can_dryrun) {
 fprintf(stderr, "command does not implement -N (dryrun) option\n");
-ret = 1;
+ret = EXIT_FAILURE;
 goto xit;
 }
 ret = cspec->cmd_impl(argc, argv);
 } else if (!strcmp(cmd, "help")) {
 help(argv[1]);
-ret = 0;
+ret = EXIT_SUCCESS;
 } else {
 fprintf(stderr, "command not implemented\n");
-ret = 1;
+ret = EXIT_FAILURE;
 }
 
  xit:
diff --git a/tools/libxl/xl.h b/tools/libxl/xl.h
index 0021112..0533398 100644
--- a/tools/libxl/xl.h
+++ b/tools/libxl/xl.h
@@ -30,6 +30,12 @@ struct cmd_spec {
 char *cmd_option;
 };
 
+/*
+*xl process should always return EXIT_FOO and main_* can be treated
+*as main() as if they are returning a process exit status and not a
+*function return value.
+*/
+
 int main_vcpulist(int argc, char **argv);
 int main_info(int argc, char **argv);
 int main_sharing(int argc, char **argv);
-- 
1.9.1


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

[Xen-devel] [PATCH v2 0/5] xl: convert exit codes to EXIT_[SUCCESS|FAILURE]

2015-10-23 Thread Harmandeep Kaur

*Its my "bite size contribution" that is required for applying to the
Outreachy program.

*main_foo() is treated somewhat as a regular main(), it is changed to
return EXIT_SUCCESS or EXIT_FAILURE.

*functions that are not main_foo(), are changed to do 'return 0' or
'return 1', and then 0/1 is taken care in the main_foo() functions
that calls them.

*fuctions in xl.c and xl_cmdimpl.c are changed.

*functions related to scheduling, vcpu, cpupool and parsing are
currently changed excluding parse_config_data() which is big enough
to deserve its own patch.

*Some discussions about this patch:
https://www.mail-archive.com/xen-devel@lists.xen.org/msg42850.html

*v1 of this patch
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02497.html

Signed-off-by: Harmandeep Kaur 
---

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

[Xen-devel] [PATCH v2 2/5] xl: improve return and exit codes of scheduling related functions

2015-10-23 Thread Harmandeep Kaur

turning scheduling related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 147 ++-
 1 file changed, 70 insertions(+), 77 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 646b281..718be54 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5793,18 +5793,15 @@ int main_sharing(int argc, char **argv)
 static int sched_domain_get(libxl_scheduler sched, int domid,
 libxl_domain_sched_params *scinfo)
 {
-int rc;
-
-rc = libxl_domain_sched_params_get(ctx, domid, scinfo);
-if (rc) {
+if (libxl_domain_sched_params_get(ctx, domid, scinfo)){
 fprintf(stderr, "libxl_domain_sched_params_get failed.\n");
-return rc;
+return 1;
 }
 if (scinfo->sched != sched) {
 fprintf(stderr, "libxl_domain_sched_params_get returned %s not %s.\n",
 libxl_scheduler_to_string(scinfo->sched),
 libxl_scheduler_to_string(sched));
-return ERROR_INVAL;
+return 1;
 }
 
 return 0;
@@ -5812,42 +5809,38 @@ static int sched_domain_get(libxl_scheduler sched, int 
domid,
 
 static int sched_domain_set(int domid, const libxl_domain_sched_params *scinfo)
 {
-int rc;
-
-rc = libxl_domain_sched_params_set(ctx, domid, scinfo);
-if (rc)
+if (libxl_domain_sched_params_set(ctx, domid, scinfo)){
 fprintf(stderr, "libxl_domain_sched_params_set failed.\n");
+return 1;
+}
 
-return rc;
+return 0;
 }
 
 static int sched_credit_params_set(int poolid, libxl_sched_credit_params 
*scinfo)
 {
-int rc;
-
-rc = libxl_sched_credit_params_set(ctx, poolid, scinfo);
-if (rc)
+if (libxl_sched_credit_params_set(ctx, poolid, scinfo)){
 fprintf(stderr, "libxl_sched_credit_params_set failed.\n");
-
-return rc;
+return 1;
+}
+
+return 0;
 }
 
 static int sched_credit_params_get(int poolid, libxl_sched_credit_params 
*scinfo)
 {
-int rc;
-
-rc = libxl_sched_credit_params_get(ctx, poolid, scinfo);
-if (rc)
+if (libxl_sched_credit_params_get(ctx, poolid, scinfo)){
 fprintf(stderr, "libxl_sched_credit_params_get failed.\n");
+return 1;
+}
 
-return rc;
+return 0;
 }
 
 static int sched_credit_domain_output(int domid)
 {
 char *domname;
 libxl_domain_sched_params scinfo;
-int rc;
 
 if (domid < 0) {
 printf("%-33s %4s %6s %4s\n", "Name", "ID", "Weight", "Cap");
@@ -5855,9 +5848,10 @@ static int sched_credit_domain_output(int domid)
 }
 
 libxl_domain_sched_params_init(&scinfo);
-rc = sched_domain_get(LIBXL_SCHEDULER_CREDIT, domid, &scinfo);
-if (rc)
-return rc;
+if (sched_domain_get(LIBXL_SCHEDULER_CREDIT, domid, &scinfo)){
+libxl_domain_sched_params_dispose(&scinfo);
+return 1;
+}
 domname = libxl_domid_to_name(ctx, domid);
 printf("%-33s %4d %6d %4d\n",
 domname,
@@ -5873,11 +5867,9 @@ static int sched_credit_pool_output(uint32_t poolid)
 {
 libxl_sched_credit_params scparam;
 char *poolname;
-int rc;
 
 poolname = libxl_cpupoolid_to_name(ctx, poolid);
-rc = sched_credit_params_get(poolid, &scparam);
-if (rc) {
+if (sched_credit_params_get(poolid, &scparam)){
 printf("Cpupool %s: [sched params unavailable]\n",
poolname);
 } else {
@@ -5895,7 +5887,6 @@ static int sched_credit2_domain_output(
 {
 char *domname;
 libxl_domain_sched_params scinfo;
-int rc;
 
 if (domid < 0) {
 printf("%-33s %4s %6s\n", "Name", "ID", "Weight");
@@ -5903,9 +5894,10 @@ static int sched_credit2_domain_output(
 }
 
 libxl_domain_sched_params_init(&scinfo);
-rc = sched_domain_get(LIBXL_SCHEDULER_CREDIT2, domid, &scinfo);
-if (rc)
-return rc;
+if (sched_domain_get(LIBXL_SCHEDULER_CREDIT2, domid, &scinfo)){
+libxl_domain_sched_params_dispose(&scinfo);
+return 1;
+}
 domname = libxl_domid_to_name(ctx, domid);
 printf("%-33s %4d %6d\n",
 domname,
@@ -5921,7 +5913,6 @@ static int sched_rtds_domain_output(
 {
 char *domname;
 libxl_domain_sched_params scinfo;
-int rc = 0;
 
 if (domid < 0) {
 printf("%-33s %4s %9s %9s\n", "Name", "ID", "Period", "Budget");
@@ -5929,9 +5920,10 @@ static int sched_rtds_domain_output(
 }
 
 libxl_domain_sched_params_init(&scinfo);
-rc = sched_domain_get(LIBXL_SCHEDULER_RTDS, domid, &scinfo);
-if (rc)
-goto out;
+if (sched_domain_get(LIBXL_SCHEDULER_RTDS, domid, &scinfo)){
+libxl_domain_sched_params_dispose(&scinfo);
+return 1;
+}
 
 domname = libxl_domid_to_name(ctx, domid);
 printf("%-33s %4d %9d %9d\n",
@@ -5940,10 +5932,8 @@ static int sched_rtds_domain_o

[Xen-devel] [PATCH v2 4/5] xl: improve return and exit codes of cpupool related functions

2015-10-23 Thread Harmandeep Kaur

turning  cpupools related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 52 
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index f71a7f0..07b2bcd 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -7311,7 +7311,7 @@ int main_cpupoolcreate(int argc, char **argv)
 libxl_bitmap cpumap;
 libxl_uuid uuid;
 libxl_cputopology *topology;
-int rc = 1;
+int rc = EXIT_FAILURE;
 
 SWITCH_FOREACH_OPT(opt, "nf:", opts, "cpupool-create", 0) {
 case 'f':
@@ -7481,7 +7481,7 @@ int main_cpupoolcreate(int argc, char **argv)
 }
 }
 /* We made it! */
-rc = 0;
+rc = EXIT_SUCCESS;

 out_cfg:
 xlu_cfg_destroy(config);
@@ -7518,14 +7518,14 @@ int main_cpupoollist(int argc, char **argv)
 pool = argv[optind];
 if (libxl_name_to_cpupoolid(ctx, pool, &poolid)) {
 fprintf(stderr, "Pool \'%s\' does not exist\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 }
 
 poolinfo = libxl_list_cpupool(ctx, &n_pools);
 if (!poolinfo) {
 fprintf(stderr, "error getting cpupool info\n");
-return 1;
+return EXIT_FAILURE;
 }
 
 printf("%-19s", "Name");
@@ -7556,7 +7556,7 @@ int main_cpupoollist(int argc, char **argv)
 
 libxl_cpupoolinfo_list_free(poolinfo, n_pools);
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupooldestroy(int argc, char **argv)
@@ -7574,13 +7574,13 @@ int main_cpupooldestroy(int argc, char **argv)
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid, NULL) ||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
 if (libxl_cpupool_destroy(ctx, poolid))
-return 1;
+return EXIT_FAILURE;
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupoolrename(int argc, char **argv)
@@ -7599,17 +7599,17 @@ int main_cpupoolrename(int argc, char **argv)
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid, NULL) ||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
 new_name = argv[optind];
 
 if (libxl_cpupool_rename(ctx, new_name, poolid)) {
 fprintf(stderr, "Can't rename cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_cpupoolcpuadd(int argc, char **argv)
@@ -7618,7 +7618,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
 const char *pool;
 uint32_t poolid;
 libxl_bitmap cpumap;
-int rc = 1;
+int rc = EXIT_FAILURE;
 
 SWITCH_FOREACH_OPT(opt, "", NULL, "cpupool-cpu-add", 2) {
 /* No options */
@@ -7627,7 +7627,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
 libxl_bitmap_init(&cpumap);
 if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
 fprintf(stderr, "Unable to allocate cpumap");
-return 1;
+return EXIT_FAILURE;
 }
 
 pool = argv[optind++];
@@ -7643,7 +7643,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
 if (libxl_cpupool_cpuadd_cpumap(ctx, poolid, &cpumap))
 fprintf(stderr, "some cpus may not have been added to %s\n", pool);
 
-rc = 0;
+rc = EXIT_SUCCESS;
 
 out:
 libxl_bitmap_dispose(&cpumap);
@@ -7656,12 +7656,12 @@ int main_cpupoolcpuremove(int argc, char **argv)
 const char *pool;
 uint32_t poolid;
 libxl_bitmap cpumap;
-int rc = 1;
+int rc = EXIT_FAILURE;
 
 libxl_bitmap_init(&cpumap);
 if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
 fprintf(stderr, "Unable to allocate cpumap");
-return 1;
+return EXIT_FAILURE;
 }
 
 SWITCH_FOREACH_OPT(opt, "", NULL, "cpupool-cpu-remove", 2) {
@@ -7681,7 +7681,7 @@ int main_cpupoolcpuremove(int argc, char **argv)
 if (libxl_cpupool_cpuremove_cpumap(ctx, poolid, &cpumap))
 fprintf(stderr, "some cpus may not have been removed from %s\n", pool);
 
-rc = 0;
+rc = EXIT_SUCCESS;
 
 out:
 libxl_bitmap_dispose(&cpumap);
@@ -7706,19 +7706,19 @@ int main_cpupoolmigrate(int argc, char **argv)
 if (libxl_domain_qualifier_to_domid(ctx, dom, &domid) ||
 !libxl_domid_to_name(ctx, domid)) {
 fprintf(stderr, "unknown domain '%s'\n", dom);
-return 1;
+return EXIT_FAILURE;
 }
 
 if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid, NULL) ||
 !libxl_cpupoolid_is_valid(ctx, poolid)) {
 fprintf(stderr, "unknown cpupool '%s'\n", pool);
-return 1;
+return EXIT_FAILURE;
 }
 
 if (libxl_cpupool_movedomain(ctx, pooli

[Xen-devel] [PATCH v2 5/5] xl: improve return and exit codes of parse related functions

2015-10-23 Thread Harmandeep Kaur

turning  parsing related functions xl exit codes towards using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

it doesn't include parse_config_data() which is big enough to deserve its
own patch

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 71 ++--
 1 file changed, 32 insertions(+), 39 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 07b2bcd..f176689 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -578,10 +578,10 @@ static void parse_disk_config_multistring(XLU_Config 
**config,
 }
 
 e = xlu_disk_parse(*config, nspecs, specs, disk);
-if (e == EINVAL) exit(-1);
+if (e == EINVAL) exit(EXIT_FAILURE);
 if (e) {
 fprintf(stderr,"xlu_disk_parse failed: %s\n",strerror(errno));
-exit(-1);
+exit(EXIT_FAILURE);
 }
 }
 
@@ -600,7 +600,7 @@ static void parse_vif_rate(XLU_Config **config, const char 
*rate,
 if (e == EINVAL || e == EOVERFLOW) exit(-1);
 if (e) {
 fprintf(stderr,"xlu_vif_parse_rate failed: %s\n",strerror(errno));
-exit(-1);
+exit(EXIT_FAILURE);
 }
 }
 
@@ -741,19 +741,19 @@ static int parse_range(const char *str, unsigned long *a, 
unsigned long *b)
 
 *a = *b = strtoul(str, &endptr, 10);
 if (endptr == str || *a == ULONG_MAX)
-return ERROR_INVAL;
+return 1;
 
 if (*endptr == '-') {
 nstr = endptr + 1;
 
 *b = strtoul(nstr, &endptr, 10);
 if (endptr == nstr || *b == ULONG_MAX || *b < *a)
-return ERROR_INVAL;
+return 1;
 }
 
 /* Valid value or range so far, but we also don't want junk after that */
 if (*endptr != '\0')
-return ERROR_INVAL;
+return 1;
 
 return 0;
 }
@@ -841,17 +841,15 @@ static int update_cpumap_range(const char *str, 
libxl_bitmap *cpumap)
 static int cpurange_parse(const char *cpu, libxl_bitmap *cpumap)
 {
 char *ptr, *saveptr = NULL, *buf = strdup(cpu);
-int rc = 0;
 
 for (ptr = strtok_r(buf, ",", &saveptr); ptr;
  ptr = strtok_r(NULL, ",", &saveptr)) {
-rc = update_cpumap_range(ptr, cpumap);
-if (rc)
+if (update_cpumap_range(ptr, cpumap))
 break;
 }
 free(buf);
 
-return rc;
+return 0;
 }
 
 static void parse_top_level_vnc_options(XLU_Config *config,
@@ -902,7 +900,7 @@ static char *parse_cmdline(XLU_Config *config)
 
 if ((buf || root || extra) && !cmdline) {
 fprintf(stderr, "Failed to allocate memory for cmdline\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 return cmdline;
@@ -946,11 +944,11 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 libxl_bitmap_init(&vcpu_affinity_array[j]);
 if (libxl_cpu_bitmap_alloc(ctx, &vcpu_affinity_array[j], 0)) {
 fprintf(stderr, "Unable to allocate cpumap for vcpu %d\n", j);
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 if (cpurange_parse(buf, &vcpu_affinity_array[j]))
-exit(1);
+exit(EXIT_FAILURE);
 
 j++;
 }
@@ -963,17 +961,17 @@ static void parse_vcpu_affinity(libxl_domain_build_info 
*b_info,
 libxl_bitmap_init(&vcpu_affinity_array[0]);
 if (libxl_cpu_bitmap_alloc(ctx, &vcpu_affinity_array[0], 0)) {
 fprintf(stderr, "Unable to allocate cpumap for vcpu 0\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 if (cpurange_parse(buf, &vcpu_affinity_array[0]))
-exit(1);
+exit(EXIT_FAILURE);
 
 for (i = 1; i < b_info->max_vcpus; i++) {
 libxl_bitmap_init(&vcpu_affinity_array[i]);
 if (libxl_cpu_bitmap_alloc(ctx, &vcpu_affinity_array[i], 0)) {
 fprintf(stderr, "Unable to allocate cpumap for vcpu %d\n", i);
-exit(1);
+exit(EXIT_FAILURE);
 }
 libxl_bitmap_copy(ctx, &vcpu_affinity_array[i],
   &vcpu_affinity_array[0]);
@@ -1064,7 +1062,7 @@ static unsigned long parse_ulong(const char *str)
 val = strtoul(str, &endptr, 10);
 if (endptr == str || val == ULONG_MAX) {
 fprintf(stderr, "xl: failed to convert \"%s\" to number\n", str);
-exit(1);
+exit(EXIT_FAILURE);
 }
 return val;
 }
@@ -1086,7 +1084,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 if (libxl_get_physinfo(ctx, &physinfo) != 0) {
 libxl_physinfo_dispose(&physinfo);
 fprintf(stderr, "libxl_get_physinfo failed\n");
-exit(1);
+exit(EXIT_FAILURE);
 }
 
 nr_nodes = physinfo.nr_nodes;
@@ -1105,7 +1103,7 @@ static void parse_vnuma_config(const XLU_Config *config,
 libxl_bitmap_init(&vcpu_parsed[i]);
 if (libxl_cpu_bitmap_alloc(ctx, &vcpu_parsed[i], b_info->max

[Xen-devel] [PATCH v2 3/5] xl: improve return and exit codes of vcpu related functions

2015-10-23 Thread Harmandeep Kaur

turning vcpu manipulation functions xl exit codes toward using the
EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary numbers
or libxl return codes.

Signed-off-by: Harmandeep Kaur 
---
 tools/libxl/xl_cmdimpl.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 718be54..f71a7f0 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5316,7 +5316,7 @@ int main_vcpulist(int argc, char **argv)
 }
 
 vcpulist(argc - optind, argv + optind);
-return 0;
+return EXIT_SUCCESS;
 }
 
 int main_vcpupin(int argc, char **argv)
@@ -5332,7 +5332,7 @@ int main_vcpupin(int argc, char **argv)
 long vcpuid;
 const char *vcpu, *hard_str, *soft_str;
 char *endptr;
-int opt, nb_cpu, nb_vcpu, rc = -1;
+int opt, nb_cpu, nb_vcpu, rc = EXIT_FAILURE;
 
 libxl_bitmap_init(&cpumap_hard);
 libxl_bitmap_init(&cpumap_soft);
@@ -5407,10 +5407,10 @@ int main_vcpupin(int argc, char **argv)
 
 if (ferror(stdout) || fflush(stdout)) {
 perror("stdout");
-exit(-1);
+exit(EXIT_FAILURE);
 }
 
-rc = 0;
+rc = EXIT_SUCCESS;
 goto out;
 }
 
@@ -5430,7 +5430,7 @@ int main_vcpupin(int argc, char **argv)
 libxl_vcpuinfo_list_free(vcpuinfo, nb_vcpu);
 }
 
-rc = 0;
+rc = EXIT_SUCCESS;
  out:
 libxl_bitmap_dispose(&cpumap_soft);
 libxl_bitmap_dispose(&cpumap_hard);
@@ -5459,8 +5459,7 @@ static int vcpuset(uint32_t domid, const char* nr_vcpus, 
int check_host)
 unsigned int host_cpu = libxl_get_max_cpus(ctx);
 libxl_dominfo dominfo;
 
-rc = libxl_domain_info(ctx, &dominfo, domid);
-if (rc)
+if (libxl_domain_info(ctx, &dominfo, domid))
 return 1;
 
 if (max_vcpus > dominfo.vcpu_online && max_vcpus > host_cpu) {
@@ -5473,8 +5472,7 @@ static int vcpuset(uint32_t domid, const char* nr_vcpus, 
int check_host)
 if (rc)
 return 1;
 }
-rc = libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus);
-if (rc) {
+if (libxl_cpu_bitmap_alloc(ctx, &cpumap, max_vcpus)){
 fprintf(stderr, "libxl_cpu_bitmap_alloc failed, rc: %d\n", rc);
 return 1;
 }
@@ -5508,7 +5506,9 @@ int main_vcpuset(int argc, char **argv)
 break;
 }
 
-return vcpuset(find_domain(argv[optind]), argv[optind + 1], check_host);
+if (vcpuset(find_domain(argv[optind]), argv[optind + 1], check_host))
+return EXIT_FAILURE;
+else return EXIT_SUCCESS;
 }
 
 static void output_xeninfo(void)
-- 
1.9.1


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

[Xen-devel] [linux-3.10 test] 63224: regressions - FAIL

2015-10-23 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-pvops 5 kernel-build  fail REGR. vs. 62642

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 62642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 62642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 62642

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass

version targeted for testing:
 linux61ce1520149bb1cfdc9a2946a1b6a33119742881
baseline version:
 linuxf5552cd830e58c46dffae3617b3ce0c839771981

Last test of basis62642  2015-10-03 17:59:45 Z   20 days
Testing same since63224  2015-10-22 22:20:05 Z1 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Adam Radford 
  Al Viro 
  Alexey Klimov 
  Andi Kleen 
  Andreas Schwab 
  Andrew Morton 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Ben Hutchings 
  Christoph Biedl 
  Christoph Hellwig 
  cov...@ccs.covici.com 
  Daniel Vetter 
  Daniel Vetter 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  Ding Tianhong 
  dingtianhong 
  Dirk Mueller 
  Dirk MÃ¼ller 
  Doug Ledford 
  Eric W. Biederman 
  Geert Uytterhoeven 
  Greg Kroah-Hartman 
  Guenter Roeck 
  H. Peter Anvin 
  Ian Abbott 
  Ingo Molnar 
  James Bottomley 
  James Hogan 
  Jan Kara 
  Jann Horn 
  Jarkko Nikula 
  Jeff Mahoney 
  Jiri Slaby 
  Joe Stringer 
  Joe Thornber 
  Johan Hovold 
  John Covici 
  Julian Anastasov 
  Kees Cook 
  Linus Torvalds 
  Liu.Zhao 
  Mark Brown 
  Mark Salyzyn 
  Mathias Nyman 
  Mel Gorman 
  Michael Ellerman 
  Michal Hocko 
  Mike Marciniszyn 
  Mike Snitzer 
  Mikulas Patocka 
  Namhyung Kim 
  NeilBrown 
  Nicolas Pitre 
  Nikolay Aleksandrov 
  Pablo Neira Ayuso 
  Paolo Bonzini 
  Paul Bolle 
  Paul Mackerras 
  Paul Mackerras 
  Ralf Baechle 
  Reyad Attiyat 
  Richard Weinberger 
  Riley Andrews 
  Robert Jarzmik 
  Roger Quadros 
  Roland Dreier 
  Russell King 
  Samuel Thibault 
  Shaohua Li 
  Sheng Yong 
  shengyong 
  Simon Horman 
  Stephen Smalley 
  Steve French 
  Steve French 
  Takashi Iwai 
  Tan, Jui Nee 
  Thomas Gleixner 
  TÃ³th Attila 
  Vincent Palatin 
  Vitaly Kuznetsov 
  Will Deacon 
  Yao-Wen Mao 
  Yitian Bu 
  Yitian Bu 
  Zhang Zhen 

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-pvopsfail
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-a

[Xen-devel] [linux-4.1 test] 63223: tolerable FAIL - PUSHED

2015-10-23 Thread osstest service owner

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt-pair  9 xen-boot/src_hostfail REGR. vs. 63087
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 62976
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 63067
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 63067
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 63087
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 63087
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 63087

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

version targeted for testing:
 linux205a8514e63a221c3a5071f27521013444e43e5f
baseline version:
 linux27f1b7fed9c305ef46f8708f1bdde9cdb5f166bd

Last test of basis63087  2015-10-20 11:31:28 Z3 days
Testing same since63223  2015-10-22 22:19:07 Z1 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  Aaron Brown 
  Adam Radford 
  Adrian Hunter 
  AKASHI Takahiro 
  Al Viro 
  Alex Deucher 
  Alex Gartrell 
  Alex Gorbachev 
  Alex Williamson 
  Alexander Inyukhin 
  Alexey Brodkin 
  Alexey Brodkin 
  Alexey Klimov 
  Andreas Schwab 
  Andrew Morton 
  Andrey Jr. Melnikov 
  Andy Grover 
  Andy Lutomirski 
  Andy Shevchenko 
  Antoine Tenart 
  Antoine TÃ©nart 
  Antonio Quartulli 
  Ard Biesheuvel 
  Arnaldo Carvalho de Melo 
  Azael Avalos 
  Ben Dooks 
  Ben Hutchings 
  Ben Segall 
  Bin Liu 
  Bjorn Helgaas 
  Bjorn Helgaas 
  Boris Brezillon 
  Borislav Petkov 
  Brian King 
  Brian Norris 
  Carl Frederik Werner 
  Catalin Marinas 
  Chanho Park 
  Chas Williams <3ch...@gmail.com>
  Christian Borntraeger 
  Christian Engelmayer 
  Christoph Biedl 
  Christoph Hellwig 
  Christoph Lameter 
  Chuck Lever 
  cov...@ccs.covici.com 
  Dan Williams 
  Daniel Vetter 
  Daniel Vetter 
  Darren Hart 
  Dave Airlie 
  Dave Martin 
  David Howells 
  David S. Miller 
  David Vrabel 
  David Woodhouse 
  David Woodhouse 
  dedek

[Xen-devel] [qemu-mainline baseline-only test] 38204: regressions - trouble: broken/fail/pass

2015-10-23 Thread Platform Team regression test user

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl  19 capture-logs(19)broken REGR. vs. 38185
 test-amd64-i386-xl-xsm6 xen-boot  fail REGR. vs. 38185
 test-amd64-i386-freebsd10-amd64  6 xen-boot   fail REGR. vs. 38185

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-libvirt  6 xen-boot  fail REGR. vs. 38185
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 38185
 test-amd64-amd64-xl-xsm  21 guest-start/debian.repeatfail   like 38185
 test-amd64-amd64-xl  21 guest-start/debian.repeatfail   like 38185
 test-amd64-amd64-xl-credit2  21 guest-start/debian.repeatfail   like 38185
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail like 38185

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

version targeted for testing:
 qemuu426c0df9e3e6e64c7ea489092c57088ca4d227d0
baseline version:
 qemuu26c7be842637ee65a79cd77f96a99c23ddcd90ad

Last test of basis38185  2015-10-21 06:47:20 Z2 days
Testing same since38204  2015-10-23 10:50:51 Z0 days1 attempts


People who touched revisions under test:
  Benjamin Herrenschmidt 
  Daniel P. Berrange 
  Denis V. Lunev 
  Gabriel L. Somlo 
  Gabriel Somlo 
  Gerd Hoffmann 
  Kevin O'Connor 
  Marc MarÃ 
  Marc-AndrÃ© Lureau 
  Markus Armbruster 
  Michael Roth 
  Peter Maydell 
  Yuri Pudgorodskiy 

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  fail
 test-armhf-armhf-xl

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

2015-10-23 Thread osstest service owner

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

Failures and problems with tests :-(

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

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 63117

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

version targeted for testing:
 qemuu6a6739de510706e1d337180d12be74ebbd0c7666
baseline version:
 qemuu426c0df9e3e6e64c7ea489092c57088ca4d227d0

Last test of basis63117  2015-10-21 13:12:41 Z2 days
Failing since 63202  2015-10-22 01:09:34 Z1 days2 attempts
Testing same since63222  2015-10-22 19:15:12 Z1 days1 attempts


People who touched revisions under test:
  Andreas FÃ¤rber 
  Aurelien Jarno 
  Christian Borntraeger 
  Cornelia Huck 
  David Hildenbrand 
  Eduardo Otubo 
  Igor Mammedov 
  James Hogan 
  Knut Omang 
  Laszlo Ersek 
  Leon Alrae 
  Marc-AndrÃ© Lureau 
  Max Filippov 
  Michael S. Tsirkin 
  Michael Walle 
  Paolo Bonzini 
  Peter Crosthwaite 
  Peter Crosthwaite 
  Peter Maydell 
  Richard Henderson 
  Thibaut Collet 
  Tony Krowiak 
  zhanghailiang 
  Zhu Guihua 

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  broken
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-libvirt-xsm

Re: [Xen-devel] xSplice prototype

2015-10-23 Thread Konrad Rzeszutek Wilk

On Fri, Oct 23, 2015 at 04:28:25PM +0100, Ross Lagerwall wrote:
> Hi all,
> 
> I've gone ahead and implemented a bunch of xSplice stuff based on Konrad's
> xsplice branch. It is sitting in my github repository:
> https://github.com/rosslagerwall/xen tagged prototype-v1
> This is obviously prototype code, but please try it out. You'll also need
> this tool to build patches: https://github.com/rosslagerwall/xsplice-build
> tagged prototype-v1
> 

Fantastic!!!

I should take vacation more often :-)

> 
> Much of the work is implementing a basic version of the Linux kernel module
> loader. So the code does:
> * Loading of xsplice modules.
> * Copying allocated sections into a new executable region of memory.
> * Resolving symbols.
> * Applying relocations.
> * Patching of altinstructions.
> * Special handling of bug frames and exception tables.
> * Unloading of xsplice modules.
> 
> The other main bit of this work is applying and reverting the patches
> safely. As implemented, the code is patched with each CPU waiting in the
> return-to-guest path (i.e. with no stack) which appears to be the safest way
> of patching. It should mean that stack checking is not required.
> 
> All of the following should work:
> * Applying patches safely.
> * Reverting patches safely.
> * Replacing patches safely (e.g. reverting any applied patches and applying
> a new patch).
> * Bug frames as part of modules. This means adding or changing WARN, ASSERT,
> BUG, and run_in_exception_handler works correctly. Line number only changes
> _are ignored_.
> * Exception tables as part of modules. E.g. wrmsr_safe and copy_to_user work
> correctly when used in a patch module.
> * Hook load and unload functions which run at patch apply and revert time
> respectively.

OK, we (me) should then also update the design document to mention that.

> * Shadow variables. A minimal bit of infrastructure to attach a new variable
> to an existing data structure.
> 
> 
> Limitations
> ===
> The above is enough to fully implement an update system where multiple
> source patches are combined (using combinediff) and built into a single
> binary which then atomically replaces any existing loaded patches (this is
> why I added a REPLACE operation). This is the approach used by kPatch and
> kGraft. Multiple completely independent patches can also be loaded but
> unexpected interactions may occur.
> 
> As it stands, the patches are statically linked which means that independent
> patches cannot be linked against one another (e.g. if one introduces a new
> symbol). Using the combinediff approach above fixes this.
> 
> Backtraces containing functions from a patch module do not show the symbol
> name.
> 
> There is no checking that a patch which is loaded is built for the correct
> hypervisor.

Hehe.. bugs? What bugs!?
> 
> Binary patching works at the function level.
> 
> 
> Design thoughts
> ===
> Combining patches at the source level is relatively easy. Multiple binary
> patches applied at runtime is tricky. I'm not convinced that it is
> necessarily a good idea. Based on the discussion so far, the sanest way of
> doing this that I can think of is:
> * Each hypervisor has an embedded build id.
> * Each binary patch has an embedded build id.
> * The hypervisor should expose its build id and the build id of every loaded
> binary patch.
> * Each binary patch specifies one or more build ids on which it depends.
> These build ids can be either a hypervisor build id or another patch build
> id. The dependencies could either identified automatically or by a
> developer.
> * The userspace tool enforces dependency management (user can optionally
> force patch apply). I don't see any reason to involve the
> hypervisor for dependency management.
> Implementing this scheme will require dynamically linking the binary
> patches.
> 
> The CHECK phase seems unnecessary to me. I would think that any safety
> checking that needs to be done would be done atomically at the point of
> patch apply (or revert). Given the implemented system of applying patches,
> I'm not sure if any safety checking need be done at all.

It was added as a way to do signature checking and any other type
of checking that needed to be done. And which may take quite a while
to get done - hence doing it asynchronously.


We have a meeting this Monday (Oct 26th) @ 10AM on the #xsplice channel.

And in which we can disucss the 'combining patches' part, the build-id, the
logging mechanism, and other things you had encountered and have thoughts on.

Again, thank you for doing this!
> 
> 
> Testing
> ===
> In case it's not clear what the workflow is, here is a sample transcript:
> 
> $ mkdir ~/work
> $ cd ~/work
> $ git clone git://github.com/rosslagerwall/xen.git
> $ cd xen
> $ git checkout prototype-v1
> $ # Build a debug Xen and tools (including misc/xen-xsplice), install on a
> host and reboot
> 
> $ # Write a patch
> $ git diff > ~/work/test1.patch
> $ git reset --hard
> $ # Write ano

Re: [Xen-devel] Adding Xen development headers to XenServer

2015-10-23 Thread Razvan Cojocaru

On 10/23/2015 09:07 PM, D'Mita Levy wrote:
> Is it possible to add Xen development headers to XenServer? I would like
> to do a little bit of VM introspection with LibVMI on XenServer. I have
> all the other dependencies installed (glib, flex, etc.) just missing the
> ones for Xen...Any help is greatly appreciated.

The XenServer source code is freely available, that includes the
hypervisor / tools:

https://www.citrix.com/go/products/xenserver/xenserver-source-free.html

http://xenserver.org/overview-xenserver-open-source-virtualization/source-code.html


Cheers,
Razvan

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

Re: [Xen-devel] Adding Xen development headers to XenServer

2015-10-23 Thread Andrew Cooper

On 23/10/15 19:07, D'Mita Levy wrote:
> Is it possible to add Xen development headers to XenServer? I would
> like to do a little bit of VM introspection with LibVMI on XenServer.
> I have all the other dependencies installed (glib, flex, etc.) just
> missing the ones for Xen...Any help is greatly appreciated.

Wrong list.  Dropping xen-devel to BCC, adding xs-devel to CC.

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

[Xen-devel] Adding Xen development headers to XenServer

2015-10-23 Thread D'Mita Levy

Is it possible to add Xen development headers to XenServer? I would like to
do a little bit of VM introspection with LibVMI on XenServer. I have all
the other dependencies installed (glib, flex, etc.) just missing the ones
for Xen...Any help is greatly appreciated.

Thanks,
D'Mita

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

[Xen-devel] [PATCH] x86/vmx: Improvements to vmentry failure handling

2015-10-23 Thread Andrew Cooper

Combine the almost identical vm_launch_fail() and vm_resume_fail() into
a single vmx_vmentry_failure().

Re-save all GPRs so that domain_crash() prints the real register values,
rather than the active stack of the vmx_vmentry_failure() callpath.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Jun Nakajima 
CC: Kevin Tian 
---
 xen/arch/x86/hvm/vmx/entry.S |  9 +
 xen/arch/x86/hvm/vmx/vmcs.c  | 15 ---
 2 files changed, 9 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 2a4ed57..a5438a4 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -101,14 +101,15 @@ UNLIKELY_END(realmode)
 
 /*.Lvmx_resume:*/
 VMRESUME
-sti
-call vm_resume_fail
-ud2
+jmp  .Lvmx_vmentry_fail
 
 .Lvmx_launch:
 VMLAUNCH
+
+.Lvmx_vmentry_fail:
 sti
-call vm_launch_fail
+SAVE_ALL
+call vmx_vmentry_failure
 ud2
 
 ENTRY(vmx_asm_do_vmentry)
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 62e405f..7beac12 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -1588,21 +1588,14 @@ void vmx_destroy_vmcs(struct vcpu *v)
 free_xenheap_page(v->arch.hvm_vmx.msr_bitmap);
 }
 
-void vm_launch_fail(void)
-{
-unsigned long error;
-
-__vmread(VM_INSTRUCTION_ERROR, &error);
-printk(" error code %lx\n", error);
-domain_crash_synchronous();
-}
-
-void vm_resume_fail(void)
+void vmx_vmentry_failure(void)
 {
+struct vcpu *curr = current;
 unsigned long error;
 
 __vmread(VM_INSTRUCTION_ERROR, &error);
-printk(" error code %lx\n", error);
+printk(XENLOG_ERR "VM%s error: %#lx\n",
+   curr->arch.hvm_vmx.launched ? "RESUME" : "LAUNCH", error);
 domain_crash_synchronous();
 }
 
-- 
2.1.4


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

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

2015-10-23 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail REGR. vs. 62677
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
62677

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumpuserxen-amd64 15 
rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 62677
 test-armhf-armhf-xl-rtds 15 guest-start.2fail   like 62677
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 62677

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

version targeted for testing:
 xen  e4a1dcbfaeb4aa30101b2c9befaca9d460713396
baseline version:
 xen  b24ad7ba911a9f0688ab179736476e44c52144f1

Last test of basis62677  2015-10-05 14:44:46 Z   18 days
Failing since 63162  2015-10-21 16:08:32 Z2 days2 attempts
Testing same since63216  2015-10-22 15:09:04 Z1 days1 attempts


People who touched revisions under test:
  Daniel De Graaf 
  David Vrabel 
  Fabio Fantoni 
  George Dunlap 
  Ian Campbell 
  Jan Beulich 
  Konrad Rzeszutek Wilk 
  Stefano Stabellini 
  Wei Liu 
  Yang Zhang 

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

Re: [Xen-devel] Questions regarding XEN subsystems..

2015-10-23 Thread Andrew Cooper

On 23/10/15 18:16, Mike wrote:
> Hello,
>
> I'm doing some reviewing of XEN source code.  Does x86_emulate() (from
> x86_emulate.c) execute on every guest, or is this whenever a machine
> doesn't have hardware assisted virtualization?

By default, guests do not have instructions emulated.  They run on the
real hardware.

There are situations which occur, (as a side effect of virtualisation),
when it traps into Xen.  e.g. updating pagetables while shadow paging is
in use, a write hitting an MMIO page emulated by Qemu, etc.

In such circumstances, the instruction which faulted must be emulated so
Xen can work out what the guest did, and apply the appropriate action. 
e.g. update the pagetable as requested or forward an io request to qemu.

Especially for the SIMD instructions, x86_emulate() is not capable of
providing a software alternative to an instruction not supported by the
hardware.

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

[Xen-devel] Questions regarding XEN subsystems..

2015-10-23 Thread Mike

Hello,

I'm doing some reviewing of XEN source code.  Does x86_emulate() (from
x86_emulate.c) execute on every guest, or is this whenever a machine
doesn't have hardware assisted virtualization?

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

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

2015-10-23 Thread Ian Jackson

Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: 
Linky linky revision graph"):
> On 23/10/15 17:46, Ian Jackson wrote:
> > Yes, indeed.  It appears that your browser is rather poor :-).  (Most
> > are...)
> 
> How is yours configured then, to do something sensible with a git:// uri ?

I did say most browsers were poor :-).

ISTM that this information is better than nothing.

Ian.

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

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

2015-10-23 Thread Andrew Cooper

On 23/10/15 17:46, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: 
> Linky linky revision graph"):
>> On 23/10/15 17:35, Ian Jackson wrote:
>>> Example of the output:
>>>
>>> http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.html
>>> http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.svg
>> I get "The address wasn't understood" from my browser.
>>
>> It appears that it is using the git:// URLs
>> e.g. git://xenbits.xen.org/linux-pvops.git#1230ae0e99e0
> Yes, indeed.  It appears that your browser is rather poor :-).  (Most
> are...)

How is yours configured then, to do something sensible with a git:// uri ?

~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

2015-10-23 Thread Ian Jackson

Andrew Cooper writes ("Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: 
Linky linky revision graph"):
> On 23/10/15 17:35, Ian Jackson wrote:
> > Example of the output:
> >
> > http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.html
> > http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.svg
> 
> I get "The address wasn't understood" from my browser.
> 
> It appears that it is using the git:// URLs
> e.g. git://xenbits.xen.org/linux-pvops.git#1230ae0e99e0

Yes, indeed.  It appears that your browser is rather poor :-).  (Most
are...)

> Shouldn't the HTTP links be used?

They aren't available.

The information here comes from the flights database, which contains
the URLs used to clone the code, but not any corresponding links
suitable for use in a browser.[1]

In fact, osstest doesn't handle or know of such browseable links for
any of the trees it deals with.  In the general case such browseable
links may not even exist.

[1] It is true that in some cases, for some trees, there are links
that can be used for both; but we prefer to have osstest use git://
urls because they cache well, with our git caching proxy.

Ian.

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

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

2015-10-23 Thread osstest service owner

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

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  cd84a2baadd4a5767d2568b1c01b055328cc84db
baseline version:
 xen  01a8a8126d02b81bac4fe81541be0cccefc8a4c8

Last test of basis63218  2015-10-22 16:00:55 Z1 days
Testing same since63260  2015-10-23 14:00:55 Z0 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Ian Jackson 
  Julien Grall 
  Wei Liu 
  Zhigang Wang 

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

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

2015-10-23 Thread Andrew Cooper

On 23/10/15 17:35, Ian Jackson wrote:
> Ian Jackson writes ("[OSSTEST PATCH 0/3] cs-bisection-step: Linky linky 
> revision graph"):
>> These three patches contrive to produce (in a rather ugly way) an SVG
>> version of the revision graph in which the revisions and (most
>> usefully) the flights are hyperlinks.
> Example of the output:
>
> http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.html
> http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.svg

I get "The address wasn't understood" from my browser.

It appears that it is using the git:// URLs

e.g. git://xenbits.xen.org/linux-pvops.git#1230ae0e99e0

Shouldn't the HTTP links be used?

~Andrew

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

Re: [Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

2015-10-23 Thread Ian Jackson

Ian Jackson writes ("[OSSTEST PATCH 0/3] cs-bisection-step: Linky linky 
revision graph"):
> These three patches contrive to produce (in a rather ugly way) an SVG
> version of the revision graph in which the revisions and (most
> usefully) the flights are hyperlinks.

Example of the output:

http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.html
http://xenbits.xen.org/people/iwj/2015/bisection-svg/t.svg

Ian.

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

[Xen-devel] [OSSTEST PATCH 0/3] cs-bisection-step: Linky linky revision graph

2015-10-23 Thread Ian Jackson

These three patches contrive to produce (in a rather ugly way) an SVG
version of the revision graph in which the revisions and (most
usefully) the flights are hyperlinks.


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

[Xen-devel] [OSSTEST PATCH 3/3] cs-bisection-step: Mark which revision(s) changed in each node

2015-10-23 Thread Ian Jackson

We compare the revision rtuple elements with each of the parents, and
mark changes by surrounding the revision id with *asterisks*.

In the SVG output, we have to strip these when generating the URL, and
we can show this by emboldening the relevant revision instead.  This
involves changing the ther output to be of normal weight by deleting
the emboldening output by dot.

Signed-off-by: Ian Jackson 
---
 README.bisection  |3 +++
 cs-bisection-step |   27 +--
 2 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/README.bisection b/README.bisection
index 8ea3d3e..ae8a1aa 100644
--- a/README.bisection
+++ b/README.bisection
@@ -159,6 +159,9 @@ revision) or blue (if the attempt with that particular 
revision tuple
 was inconclusive because the test step being bisected was blocked by
 an earlier failure).
 
+The revision(s) which changed compared to the parent(s) are marked
+with asterisks, or in bold.
+
 The revision being fingered (or, when the bisector is running, the
 next revision to test) is highlighed with a double boundary.
 
diff --git a/cs-bisection-step b/cs-bisection-step
index 841a46a..e51babd 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -928,9 +928,18 @@ END
 sub gnodename ($) {
 my ($n) = @_;
 
-my $lab= $n->{Rtuple};
-$lab =~ s/(\S{12})\S+/$1/g;
-$lab =~ s/ /,/g;
+my @lab = split / /, $n->{Rtuple};
+foreach (my $i=0; $i<@lab; $i++) {
+   my $lab = $lab[$i];
+   $lab = substr $lab, 0, 12;
+   $lab = "*$lab*"
+   if grep {
+   my @ptuple = split / /, $_->{Rtuple};
+   $ptuple[$i] ne $lab[$i];
+   } @{ $n->{Parents} };
+   $lab[$i] = $lab;
+}
+my $lab = join ",", @lab;
 
 my $fs= $n->{Flights};
 if ($fs) {
@@ -1034,18 +1043,24 @@ END
open SVGO, ">", "$graphfile.svg.new" or die "$graphfile.svg.new $!";
while () {
if (m/^\)[0-9a-f]{12}(?:,[0-9a-f]{12})*(?=\<)/) {
+   if (m/(?<=\>)\*?[0-9a-f]{12}\*?(?:,\*?[0-9a-f]{12}\*?)*(?=\<)/) 
{
my ($l,$r) = ($`,$'); #');
my @commits = split /\,/, $&;
my @ocommits;
for (my $i=0; $i<@commits; $i++) {
-   my $url = "$treeinfos[$i]{Url}#$commits[$i]";
+   my $commit = $commits[$i];
+   $commit =~ s#\*##g;
+   my $url = "$treeinfos[$i]{Url}#$commit";
+   my $show = $commits[$i];
+   $show =~ s#^\*##;
+   $show =~ s#\*$##;
push @ocommits, "".
-   $commits[$i].
+   $show.
"";
}
+   $l =~ s# font-weight="bold" # #;
$_ = $l.(join ",", @ocommits).$r;
} elsif (m/(?<=\>)\d+:[-a-z]+(?: \d+:[-a-z]+)*(?=\<)/) {
my ($l,$r) = ($`,$'); #');
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 2/3] cs-bisection-step: Make hyperlinks in SVG revision graph

2015-10-23 Thread Ian Jackson

Make various elements in the output into hyperlinks and hence document
that the SVG version of the graph is best to use.

AFAICT dot does not provide a way to put literal SVG elements into its
output.  So we postprocess it.  Luckily we produced the input to dot
so we know a lot about what the output will look like.

In theory it would be better to feed the SVG into an XML parser and do
this editing at the ESIS level, via XSLT.  However, I don't understand
XSLT, and this regexp-based version will work until the authors of dot
decide to change the output syntax.  If they do, the hyperlinking will
go away, but everything else will still work.  I think this approach
will be less effort overall.  This is particularly true as even using
XSLT would involve us knowing how dot's output is structured, and
changes to the syntax of the dot output are not very likely unless the
dot authors also change the semantics.

Signed-off-by: Ian Jackson 
---
 README.bisection  |5 +
 cs-bisection-step |   36 
 2 files changed, 41 insertions(+)

diff --git a/README.bisection b/README.bisection
index ca3405c..8ea3d3e 100644
--- a/README.bisection
+++ b/README.bisection
@@ -137,6 +137,11 @@ Revision Graph
 The revision graph page shows the osstest bisector's view of the
 situation.
 
+The SVG version of the graph is best if your browser supports it.  In
+that graph the individual revisions and flight result notations are
+hyperlinks (even though they may not be marked as such in your
+browser).
+
 Each node in the graph corresponds to a tuple of revisions: one
 revision for each of the relevant trees.  Each edge changes the
 revision of one of the trees.  (osstest has constructed this graph by
diff --git a/cs-bisection-step b/cs-bisection-step
index bd5a27e..841a46a 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -1030,6 +1030,42 @@ END
 system_checked("dot", "-T$fmt", "-o$graphfile.$fmt",
   "$graphfile.dot");
 }
+   open SVGI, "$graphfile.svg" or die "$graphfile.svg $!";
+   open SVGO, ">", "$graphfile.svg.new" or die "$graphfile.svg.new $!";
+   while () {
+   if (m/^\)[0-9a-f]{12}(?:,[0-9a-f]{12})*(?=\<)/) {
+   my ($l,$r) = ($`,$'); #');
+   my @commits = split /\,/, $&;
+   my @ocommits;
+   for (my $i=0; $i<@commits; $i++) {
+   my $url = "$treeinfos[$i]{Url}#$commits[$i]";
+   push @ocommits, "".
+   $commits[$i].
+   "";
+   }
+   $_ = $l.(join ",", @ocommits).$r;
+   } elsif (m/(?<=\>)\d+:[-a-z]+(?: \d+:[-a-z]+)*(?=\<)/) {
+   my ($l,$r) = ($`,$'); #');
+   my @flights = split / /, $&;
+   foreach my $f (@flights) {
+   $f =~ m/^\d+(?=:)/;
+   $f = "".
+   $f."";
+   }
+   $_ = $l.(join " ", @flights).$r;
+   }
+   }
+   print SVGO or die $!;
+   }
+   close SVGO or die $!;
+   rename "$graphfile.svg.new", "$graphfile.svg"
+   or die "$graphfile.svg $!";
+
 1;
 }) {
my $gsize = $c{BisectionRevisonGraphSize};
-- 
1.7.10.4


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

[Xen-devel] [OSSTEST PATCH 1/3] cs-bisection-step: Generate an SVG graph too

2015-10-23 Thread Ian Jackson

This is going to let us provide a version with hyperlinks.

Signed-off-by: Ian Jackson 
---
 cs-bisection-step |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/cs-bisection-step b/cs-bisection-step
index 7a97b10..bd5a27e 100755
--- a/cs-bisection-step
+++ b/cs-bisection-step
@@ -1026,7 +1026,7 @@ END
 or die "$!";
 
 if (eval {
-foreach my $fmt (qw(ps png)) {
+foreach my $fmt (qw(ps png svg)) {
 system_checked("dot", "-T$fmt", "-o$graphfile.$fmt",
   "$graphfile.dot");
 }
@@ -1045,11 +1045,12 @@ END
 Revision graph overview
 
 Revision graph
+SVG
 PostScript
 
 
 END
-print STDERR "Revision graph left in $graphfile.{dot,ps,png,html}.\n";
+print STDERR "Revision graph left in 
$graphfile.{dot,ps,png,html,svg}.\n";
 } else {
 my $emsg= encode_entities($@);
 print HTML

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

2015-10-23 Thread Dario Faggioli

On Fri, 2015-10-23 at 16:40 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 17:12 +0200, Dario Faggioli wrote:
> > On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:

> > > I think what I would have been expecting is for the xl internal
> > > error
> > > code
> > Well, same here. Except, given xl architecture, I was considering
> > main_foo() functions in xl_cmdimpl.c as some king of extensions of
> > the
> > actual main function.
> 
> I had somehow convinced myself that these weren't being added in a
> main_foo, I agree that main_foo should be treated somewhat like a
> regular
> main().
> 
Ok, glad to see we're on the same page.

> Sorry for the noise.
> 
NP. :-)

> > I'm fine with either, so, if you prefer the latter, I certainly can
> > arrange for doing things that way.
> 
> It would be helpful to a) not combine this change with the logging 
> change
>
Sure, I'll resend the patch without changing that.

> b) include as part of the patch some sort of document comment in
> some relevant xl-ish place explaining some of this stuff (i.e. that
> an xl
> process should always return EXIT_FOO and that main_* can be treated
> like
> main() as if they are returning a process exit status and not a
> function
> return value).
> 
About this...

> I think it would also be useful to have xl's main() DTRT before
> starting to convert main_*. Currently it returns explicit 0 or 1 or
> the result of the main_*.
> 
... and this, I'll see if I can convince Harman to pick these up, as
part of her work on the subject. :-P :-P

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



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

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

2015-10-23 Thread osstest service owner

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf   4 host-build-prep   fail REGR. vs. 63099
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
63099

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt  14 guest-saverestore fail REGR. vs. 63099
 test-amd64-amd64-xl-rtds  6 xen-boot  fail REGR. vs. 63099
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail blocked in 63099
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail like 63099
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 63099

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

version targeted for testing:
 xen  a5d0480d9c5b36b5f47459ce92ed3c67b7bed51d
baseline version:
 xen  80e9f5624f9d1ef2e7bbd9b9b185e96b45e1bb17

Last test of basis63099  2015-10-20 17:40:41 Z2 days
Failing since 63155  2015-10-21 15:43:44 Z2 days2 attempts
Testing same since63214  2015-10-22 13:24:43 Z1 days1 attempts


People who touched revisions under test:
  Ian Campbell 
  Jan Beulich 
  Julien Grall 
  Wei Liu 
  Yang Zhang 

jobs:
 build-amd64  pass
 build-armhf  broken  
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  blocked 
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  pass
 build-i386-rumpuserxen   pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  blocked 
 test-amd64-i386-xl   pass
 test-amd64-amd64-xl-pvh-amd  fail
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  pass
 test-amd64-amd64-rumpuserxen-amd64   pass
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-armhf-armhf-xl-arndale

Re: [Xen-devel] arm64: iomem_resource doesn't contain all the region used

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 15:58 +0100, Julien Grall wrote:
> Is there any way we could register the IO region used on ARM without
> having to enforce it in all the drivers?

This seems like an uphill battle to me.

Why not do as I suggested IRL yesterday and expose the map of "potential
RAM" addresses to the guest as well as the "actual RAM" addresses in the
regular memory properties.

i.e. explicitly expose the holes where RAM can be hotplugged later.

This is even analogous to a native memory hotplug case, which AIUI
similarly involves the provisioning of specific address space where RAM
might plausibly appear in the future (I don't think physical memory hotplug
involves searching for free PA space and hoping for the best, although
strange things have happened I guess).

With any luck you would be able to steal or define the bindings in terms of
the native hotplug case rather than inventing some Xen specific thing.

In terms of dom0 the "potential" RAM is the host's actual RAM banks.

In terms of domU the "potential" RAM is defined by the domain builder
layout (currently the two banks mentioned in Xen's arch-arm.h).

Ian.

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

[Xen-devel] [PATCH] xl: Die on unknown options

2015-10-23 Thread Ian Jackson

def_getopt would print a message to stderr, but blunder on anyway.

Sadly this is probably not a backport candidate.

Signed-off-by: Ian Jackson 
---
 tools/libxl/xl_cmdimpl.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index ea43761..de28593 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -2759,6 +2759,7 @@ static int def_getopt(int argc, char * const argv[],
 exit(0);
 }
 fprintf(stderr, "option `%c' not supported.\n", optopt);
+exit(2);
 }
 if (opt == 'h') {
 help(helpstr);
-- 
1.7.10.4


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

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 17:12 +0200, Dario Faggioli wrote:
> On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
> 
> > Looking at those links, I'm not sure that either you or myself was
> > thinking
> > of using EXIT_* as function return values, just that the eventual
> > process
> > exit would become one of those values instead of some negative
> > number.
> > 
> Exactly.
> 
> > Although the thread doesn't look like it is too clear if it is
> > talking
> > about return values from functions vs. process exit codes.
> > 
> Well, independently from the thread, I certainly meant that I think
> EXIT_* should be used as process exit status, not as internal
> functions' return value.
> 
> > I think what I would have been expecting is for the xl internal error
> > code
> > Well, same here. Except, given xl architecture, I was considering
> main_foo() functions in xl_cmdimpl.c as some king of extensions of the
> actual main function.

I had somehow convinced myself that these weren't being added in a
main_foo, I agree that main_foo should be treated somewhat like a regular
main().

Sorry for the noise.

> I'm fine with either, so, if you prefer the latter, I certainly can
> arrange for doing things that way.

It would be helpful to a) not combine this change with the logging change
and to b) include as part of the patch some sort of document comment in
some relevant xl-ish place explaining some of this stuff (i.e. that an xl
process should always return EXIT_FOO and that main_* can be treated like
main() as if they are returning a process exit status and not a function
return value).

I think it would also be useful to have xl's main() DTRT before starting to 
convert main_*. Currently it returns explicit 0 or 1 or the result of the 
main_*.

Ian.

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

[Xen-devel] xSplice prototype

2015-10-23 Thread Ross Lagerwall


Hi all,

I've gone ahead and implemented a bunch of xSplice stuff based on 
Konrad's xsplice branch. It is sitting in my github repository:

https://github.com/rosslagerwall/xen tagged prototype-v1
This is obviously prototype code, but please try it out. You'll also 
need this tool to build patches: 
https://github.com/rosslagerwall/xsplice-build tagged prototype-v1



Much of the work is implementing a basic version of the Linux kernel 
module loader. So the code does:

* Loading of xsplice modules.
* Copying allocated sections into a new executable region of memory.
* Resolving symbols.
* Applying relocations.
* Patching of altinstructions.
* Special handling of bug frames and exception tables.
* Unloading of xsplice modules.

The other main bit of this work is applying and reverting the patches 
safely. As implemented, the code is patched with each CPU waiting in the 
return-to-guest path (i.e. with no stack) which appears to be the safest 
way of patching. It should mean that stack checking is not required.


All of the following should work:
* Applying patches safely.
* Reverting patches safely.
* Replacing patches safely (e.g. reverting any applied patches and 
applying a new patch).
* Bug frames as part of modules. This means adding or changing WARN, 
ASSERT, BUG, and run_in_exception_handler works correctly. Line number 
only changes _are ignored_.
* Exception tables as part of modules. E.g. wrmsr_safe and copy_to_user 
work correctly when used in a patch module.
* Hook load and unload functions which run at patch apply and revert 
time respectively.
* Shadow variables. A minimal bit of infrastructure to attach a new 
variable to an existing data structure.



Limitations
===
The above is enough to fully implement an update system where multiple 
source patches are combined (using combinediff) and built into a single 
binary which then atomically replaces any existing loaded patches (this 
is why I added a REPLACE operation). This is the approach used by kPatch 
and kGraft. Multiple completely independent patches can also be loaded 
but unexpected interactions may occur.


As it stands, the patches are statically linked which means that 
independent patches cannot be linked against one another (e.g. if one 
introduces a new symbol). Using the combinediff approach above fixes this.


Backtraces containing functions from a patch module do not show the 
symbol name.


There is no checking that a patch which is loaded is built for the 
correct hypervisor.


Binary patching works at the function level.


Design thoughts
===
Combining patches at the source level is relatively easy. Multiple 
binary patches applied at runtime is tricky. I'm not convinced that it 
is necessarily a good idea. Based on the discussion so far, the sanest 
way of doing this that I can think of is:

* Each hypervisor has an embedded build id.
* Each binary patch has an embedded build id.
* The hypervisor should expose its build id and the build id of every 
loaded binary patch.
* Each binary patch specifies one or more build ids on which it depends. 
These build ids can be either a hypervisor build id or another patch 
build id. The dependencies could either identified automatically or by a 
developer.
* The userspace tool enforces dependency management (user can optionally 
force patch apply). I don't see any reason to involve the

hypervisor for dependency management.
Implementing this scheme will require dynamically linking the binary 
patches.


The CHECK phase seems unnecessary to me. I would think that any safety 
checking that needs to be done would be done atomically at the point of 
patch apply (or revert). Given the implemented system of applying 
patches, I'm not sure if any safety checking need be done at all.



Testing
===
In case it's not clear what the workflow is, here is a sample transcript:

$ mkdir ~/work
$ cd ~/work
$ git clone git://github.com/rosslagerwall/xen.git
$ cd xen
$ git checkout prototype-v1
$ # Build a debug Xen and tools (including misc/xen-xsplice), install on 
a host and reboot


$ # Write a patch
$ git diff > ~/work/test1.patch
$ git reset --hard
$ # Write another patch
$ git diff > ~/work/test2.patch
$ git reset --hard
$ # Write another patch
$ git diff > ~/work/test3.patch
$ git reset --hard

$ cd ~/work
$ git clone git://github.com/rosslagerwall/xsplice-build.git
$ cd xsplice-build
$ git checkout prototype-v1
$ make
$ ./xsplice-build -s ~/work/xen -p ~/work/test1.patch -o out1 
--xen-debug --debug
$ ./xsplice-build -s ~/work/xen -p ~/work/test2.patch -o out2 
--xen-debug --debug
$ ./xsplice-build -s ~/work/xen -p ~/work/test3.patch -o out3 
--xen-debug --debug

$ # copy out*/test*.xsplice onto the host


On the host:
# xen-xsplice upload test1 test1.xsplice
# xen-xsplice upload test2 test2.xsplice
# xen-xsplice upload test3 test3.xsplice
# xen-xsplice check test1
# xen-xsplice check test2
# xen-xsplice check test3

# xen-xsplice apply test1
# # Verify test1 is appl

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

2015-10-23 Thread Dario Faggioli

On Fri, 2015-10-23 at 15:09 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:

> Looking at those links, I'm not sure that either you or myself was
> thinking
> of using EXIT_* as function return values, just that the eventual
> process
> exit would become one of those values instead of some negative
> number.
>
Exactly.

> Although the thread doesn't look like it is too clear if it is
> talking
> about return values from functions vs. process exit codes.
> 
Well, independently from the thread, I certainly meant that I think
EXIT_* should be used as process exit status, not as internal
functions' return value.

> I think what I would have been expecting is for the xl internal error
> code
> would become EXIT_* either in the call to exit() or the return from
> main
> instead of being the process exit code directly.
> 
But, in this specific case, and in cases of main_foo() functions in
xl_cmdimpl.c, it's exactly like that, isn't it?

...
if (cspec) {
if (dryrun_only && !cspec->can_dryrun) {
fprintf(stderr, "command does not implement -N (dryrun) option\n");
ret = 1;
goto xit;
}
ret = cspec->cmd_impl(argc, argv);
} else if (!strcmp(cmd, "help")) {
help(argv[1]);
ret = 0;
} else {
fprintf(stderr, "command not implemented\n");
ret = 1;
}

 xit:
return ret;
}

(from main() in xl.c)

> Seeing "return EXIT_FOO" outside of a main function seems rather
> strange to
> me.
> 
Well, same here. Except, given xl architecture, I was considering
main_foo() functions in xl_cmdimpl.c as some king of extensions of the
actual main function.

The alternative would be to always use, say, 0 and 1 in xl_cmdimpl.c,
and then convert them to EXIT_SUCCESS or EXIT_FAILURE in xl.c (for
return-s, of course, exit()-s need to use them no matter where they
are).

I'm fine with either, so, if you prefer the latter, I certainly can
arrange for doing things that way.

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



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

[Xen-devel] arm64: iomem_resource doesn't contain all the region used

2015-10-23 Thread Julien Grall

Hi all,

I've been working on trying to get balloon memory hotplug working for
ARM64 guest on Xen.

In order to find a suitable region to hotplug the fake memory, we are
trying to find a free region within iomem_resource.

But on ARM64, only an handful number of regions are listed in it. For
instance on X-Gene we have only:

42sh> cat /proc/iomem

1051-105103ff : /soc/rtc@1051
1a40-1a400fff : /soc/sata@1a40
1a80-1a800fff : /soc/sata@1a80
1f22-1f220fff : /soc/sata@1a40
1f227000-1f227fff : /soc/sata@1a40
1f22a000-1f22a0ff : /soc/phy@1f22a000
1f22d000-1f22dfff : /soc/sata@1a40
1f22e000-1f22efff : /soc/sata@1a40
1f23-1f230fff : /soc/sata@1a80
1f23a000-1f23a0ff : /soc/phy@1f23a000
1f23d000-1f23dfff : /soc/sata@1a80
1f23e000-1f23efff : /soc/sata@1a80
1f2b-1f2b : csr
7900-798f : /soc/msi@7900
41-41 : System RAM
  410008-41008b58a3 : Kernel code
  410093c000-41009e9fff : Kernel data
e0d000-e0d003 : cfg

This is because most of the ARM drivers are using of_iomap which doesn't
register the region.

Looking to the code, I found a function of_io_request_and_map which
register the resource and does the mapping. I'm wondering if there is
any reason to have introduce a new function rather than doing the job in
of_iomap?

Although, that wouldn't fix all the drivers because some of them are
directly using ioremap. I've got in mind the initialization of GICv2 for
ACPI platform.

Is there any way we could register the IO region used on ARM without
having to enforce it in all the drivers?

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Jan Beulich

>>> On 23.10.15 at 16:55,  wrote:
> On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote:
>> #define set_xen_guest_handle_raw(hnd, val)  \
>> do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0;   \
>>  (hnd).p = val; \
>> } while ( 0 )
> 
> This evaluates hnd twice, which I assumed we wanted to avoid.

Hmm, that's true. We've got a couple of __GNUC__ dependencies
in the headers already - perhaps this is a reason to add one more
(and then also mirror the gcc alternative to x86), keeping the use
of __typeof__() in that case, thus ...

> But if that is OK for x86 in this situation then there is no harm doing it
> on ARM too[0].

... eliminating the need for [0] perhaps entirely. (I also note val
isn't properly parenthesized.)

> But in that case I think we would just do
>   (hnd).q = val ; (hnd).p = val
> rather than messing with &, casts and *.

If you're sure that val always has the upper 32 bits clear...

> I think x86 does it that way because .q doesn't exist in the
>  __guest_handle_foo, only the __guest_handle_64_foo, but it exists in both
> on ARM.

Right.

Jan

> We also know that sizeof(hnd) == 8 always on both arm subarches. Maybe it
> would be worth checking sizeof(hnd.p) == 8 (i.e. whether the real type
> completely fills the padding container), I don't know.
> 
> Ian.
> 
> [0] But maybe do check for arm specific set_guest_handle(foo++, bar) type
> constructs which slipped in...



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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 15:44 +0100, Julien Grall wrote:
> On 23/10/15 15:37, Jan Beulich wrote:
> > > > > On 23.10.15 at 16:31,  wrote:
> > > On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > No, the validating script is a nice-to-have, but nothing more. What
> > > > I was referring to was a patch to drop the use of this gcc
> > > > extension.
> > > 
> > > Then I'm confused. This patch turns a typeof into a __typeof__. In <
> > > 56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof()
> > > is a
> > > gcc extension".
> > > 
> > > Are you now saying that __typeof__ also a gcc extension too?
> > > 
> > > I was under the impression that __typeof__ was standard (by some cxx
> > > at
> > > least) and your mail reinforced that (possibly wrong) impression.
> > 
> > There's no typeof or __typeof__ in C11 or any earlier standard.
> > I'm sorry if earlier replies of mine gave a different impression.
> > 
> > > https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you
> > > are
> > > writing a header file that must work when included in ISO C programs,
> > > write
> > > __typeof__ instead of typeof", which also lead me to believe
> > > __typeof__ was
> > > OK from this PoV.
> > 
> > That's solely to prevent name space issues - __typeof__ is a
> > reserved name, while typeof isn't.
> 
> Thank you for the explanation. I think we can do the same as x86 does
> i.e:
> 
> #define set_xen_guest_handle_raw(hnd, val)  \
> do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0;   \
>  (hnd).p = val; \
> } while ( 0 )

This evaluates hnd twice, which I assumed we wanted to avoid.

But if that is OK for x86 in this situation then there is no harm doing it
on ARM too[0].

But in that case I think we would just do
(hnd).q = val ; (hnd).p = val
rather than messing with &, casts and *.

I think x86 does it that way because .q doesn't exist in the
 __guest_handle_foo, only the __guest_handle_64_foo, but it exists in both
on ARM.

We also know that sizeof(hnd) == 8 always on both arm subarches. Maybe it
would be worth checking sizeof(hnd.p) == 8 (i.e. whether the real type
completely fills the padding container), I don't know.

Ian.

[0] But maybe do check for arm specific set_guest_handle(foo++, bar) type
constructs which slipped in...

> 
> I will send a new version of this patch.
> 
> Regards,
> 
> 

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Jan Beulich

>>> On 23.10.15 at 16:48,  wrote:
> Perhaps this needs to be explicitly asked then, So, given:
> #define set_xen_guest_handle_raw(hnd, val)  \
> do {\
> typeof(&(hnd)) _sxghr_tmp = &(hnd); \
> _sxghr_tmp->q = 0;  \
> _sxghr_tmp->p = val;\
> } while ( 0 )
> 
> where typeof is used to avoid the multiple evaluations of hnd which
> assigning to hnd.q and hnd.p would involve, is there some way to do the
> same in pure ANSI C?

As per Julien's earlier reply, perhaps the x86 way is usable for arm
after all.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 08:24 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 16:03,  wrote:
> > On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
> > > > > > On 23.10.15 at 15:30,  wrote:
> > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 04/10/15 20:24, Julien Grall wrote:
> > > > > > The keyword typeof is not portable:
> > > > > > 
> > > > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > > > declaration
> > > > > > of function 'typeof' is invalid in C99
> > > > > > [-Werror,-Wimplicit-function-declaration]
> > > > > 
> > > > > Ping? Aside the fact that other bits of the header may not be iso
> > > > > compliant, I still think this patch is valid.
> > > > 
> > > > Yes, I agree.
> > > > Acked-by: Ian Campbell 
> > > > 
> > > > Jan, after your earlier comments are you happy to go ahead with
> > > > this
> > > > for
> > > > now and sort the other possible issues separately?
> > > 
> > > Well - it's an improvement, sure, so I'm not intending to block it
> > > going in if no better way can be determined in its place right away.
> > > What makes me hesitant is that I'm not sure there indeed will be a
> > > follow up to this any time soon.
> > 
> > Are you saying with "better way" that Julien's fix is incorrect and
> > that
> > there is potentially a "proper" fix for this specific case? i.e. a
> > followup
> > to fix the use of __typeof__ in set_xen_guest_handle_raw which this
> > patch
> > introduces is expected?
> > 
> > I don't think you are, in which case are you suggesting that having
> > fixed
> > this one issue that Julien should then be on the hook for fixing all
> > similar/related issues in these header?
> > 
> > I don't think it is right to mandate that Julien put this followup work
> > onto his TODO list as a condition of accepting this patch, if this is
> > not a
> > case of Julien's change being incorrect and requiring a "proper" fix,
> > but
> > that there are other similar things wrong elsewhere.
> 
> I'm not meaning to mandate Julien to do all other follow up work. If
> anyone was to be mandated, then whoever introduced use of gcc
> extensions into public headers. But as we know, that doesn't
> normally work (on ARM perhaps everyone who helped with the
> bringup may still be around, but outside of ARM that's less likely, so
> arguably not a workable model).
> 
> The patch is an improvement, yes. So it may go in if right now
> no-one can't think of a proper fix for the problem at hand.

If no-one can think of a proper fix now I'm not sure why we would then
expect they would be able to in a follow up, after all if they could they
would have suggested it here and not in a follow up.

Perhaps this needs to be explicitly asked then, So, given:
#define set_xen_guest_handle_raw(hnd, val)  \
do {\
typeof(&(hnd)) _sxghr_tmp = &(hnd); \
_sxghr_tmp->q = 0;  \
_sxghr_tmp->p = val;\
} while ( 0 )

where typeof is used to avoid the multiple evaluations of hnd which
assigning to hnd.q and hnd.p would involve, is there some way to do the
same in pure ANSI C?

Changing the arguments to set_xen_guest_handle_raw (e.g. to include a type)
would be a prohibitively large change to all of the callers I think, we
should probably just rule that out now.

>  But
> in the end all the patch does is papering over an issue, instead
> of eliminating it. And that's the grounds on which I wasn't (and
> still am not really) happy to see it go in.

If it is to go in then I think under the circumstances the limitations of
the change merely from typeof to __typeof__ ought to be spelled out. i.e.
that the latter is no more standard, just perhaps somewhat more portable.

Ian.

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Julien Grall

On 23/10/15 15:37, Jan Beulich wrote:
 On 23.10.15 at 16:31,  wrote:
>> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
>>> No, the validating script is a nice-to-have, but nothing more. What
>>> I was referring to was a patch to drop the use of this gcc extension.
>>
>> Then I'm confused. This patch turns a typeof into a __typeof__. In <
>> 56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof() is a
>> gcc extension".
>>
>> Are you now saying that __typeof__ also a gcc extension too?
>>
>> I was under the impression that __typeof__ was standard (by some cxx at
>> least) and your mail reinforced that (possibly wrong) impression.
> 
> There's no typeof or __typeof__ in C11 or any earlier standard.
> I'm sorry if earlier replies of mine gave a different impression.
> 
>> https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you are
>> writing a header file that must work when included in ISO C programs, write
>> __typeof__ instead of typeof", which also lead me to believe __typeof__ was
>> OK from this PoV.
> 
> That's solely to prevent name space issues - __typeof__ is a
> reserved name, while typeof isn't.

Thank you for the explanation. I think we can do the same as x86 does i.e:

#define set_xen_guest_handle_raw(hnd, val)  \
do { if ( sizeof(hnd) == 8 ) *(uint64_t *)&(hnd) = 0;   \
 (hnd).p = val; \
} while ( 0 )

I will send a new version of this patch.

Regards,


-- 
Julien Grall

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Jan Beulich

>>> On 23.10.15 at 16:31,  wrote:
> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
>> > > > On 23.10.15 at 15:58,  wrote:
>> > On 23/10/15 14:52, Jan Beulich wrote:
>> > > > > > On 23.10.15 at 15:30,  wrote:
>> > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> > > > > Hi,
>> > > > > 
>> > > > > On 04/10/15 20:24, Julien Grall wrote:
>> > > > > > The keyword typeof is not portable:
>> > > > > > 
>> > > > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
>> > > > > > declaration
>> > > > > > of function 'typeof' is invalid in C99
>> > > > > > [-Werror,-Wimplicit-function-declaration]
>> > > > > 
>> > > > > Ping? Aside the fact that other bits of the header may not be iso
>> > > > > compliant, I still think this patch is valid.
>> > > > 
>> > > > Yes, I agree.
>> > > > Acked-by: Ian Campbell 
>> > > > 
>> > > > Jan, after your earlier comments are you happy to go ahead with
>> > > > this for
>> > > > now and sort the other possible issues separately?
>> > > 
>> > > Well - it's an improvement, sure, so I'm not intending to block it
>> > > going in if no better way can be determined in its place right away.
>> > > What makes me hesitant is that I'm not sure there indeed will be a
>> > > follow up to this any time soon.
>> > 
>> > TBH, having a script which check the validity of the headers is not in
>> > the top my todo list. Though it would be nice to have it.
>> 
>> No, the validating script is a nice-to-have, but nothing more. What
>> I was referring to was a patch to drop the use of this gcc extension.
> 
> Then I'm confused. This patch turns a typeof into a __typeof__. In <
> 56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof() is a
> gcc extension".
> 
> Are you now saying that __typeof__ also a gcc extension too?
> 
> I was under the impression that __typeof__ was standard (by some cxx at
> least) and your mail reinforced that (possibly wrong) impression.

There's no typeof or __typeof__ in C11 or any earlier standard.
I'm sorry if earlier replies of mine gave a different impression.

> https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you are
> writing a header file that must work when included in ISO C programs, write
> __typeof__ instead of typeof", which also lead me to believe __typeof__ was
> OK from this PoV.

That's solely to prevent name space issues - __typeof__ is a
reserved name, while typeof isn't.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 15:31 +0100, Ian Campbell wrote:
> On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > > On 23.10.15 at 15:58,  wrote:
> > > On 23/10/15 14:52, Jan Beulich wrote:
> > > > > > > On 23.10.15 at 15:30,  wrote:
> > > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 04/10/15 20:24, Julien Grall wrote:
> > > > > > > The keyword typeof is not portable:
> > > > > > > 
> > > > > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > > > > declaration
> > > > > > > of function 'typeof' is invalid in C99
> > > > > > > [-Werror,-Wimplicit-function-declaration]
> > > > > > 
> > > > > > Ping? Aside the fact that other bits of the header may not be
> > > > > > iso
> > > > > > compliant, I still think this patch is valid.
> > > > > 
> > > > > Yes, I agree.
> > > > > Acked-by: Ian Campbell 
> > > > > 
> > > > > Jan, after your earlier comments are you happy to go ahead with
> > > > > this for
> > > > > now and sort the other possible issues separately?
> > > > 
> > > > Well - it's an improvement, sure, so I'm not intending to block it
> > > > going in if no better way can be determined in its place right
> > > > away.
> > > > What makes me hesitant is that I'm not sure there indeed will be a
> > > > follow up to this any time soon.
> > > 
> > > TBH, having a script which check the validity of the headers is not
> > > in
> > > the top my todo list. Though it would be nice to have it.
> > 
> > No, the validating script is a nice-to-have, but nothing more. What
> > I was referring to was a patch to drop the use of this gcc extension.
> 
> Then I'm confused. This patch turns a typeof into a __typeof__. In <
> 56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof() is a
> gcc extension".
> 
> Are you now saying that __typeof__ also a gcc extension too?
> 
> I was under the impression that __typeof__ was standard (by some cxx at
> least) and your mail reinforced that (possibly wrong) impression.

Hrm, it seems I was indeed wrong here and __typeof__ is just an alternative
name for the gcc extension keyword which is not subject to -ansi.

Ian.

> 
> https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you are
> writing a header file that must work when included in ISO C programs,
> write
> __typeof__ instead of typeof", which also lead me to believe __typeof__
> was
> OK from this PoV.
> 
> Ian.

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 08:16 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 15:58,  wrote:
> > On 23/10/15 14:52, Jan Beulich wrote:
> > > > > > On 23.10.15 at 15:30,  wrote:
> > > > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > > > Hi,
> > > > > 
> > > > > On 04/10/15 20:24, Julien Grall wrote:
> > > > > > The keyword typeof is not portable:
> > > > > > 
> > > > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > > > declaration
> > > > > > of function 'typeof' is invalid in C99
> > > > > > [-Werror,-Wimplicit-function-declaration]
> > > > > 
> > > > > Ping? Aside the fact that other bits of the header may not be iso
> > > > > compliant, I still think this patch is valid.
> > > > 
> > > > Yes, I agree.
> > > > Acked-by: Ian Campbell 
> > > > 
> > > > Jan, after your earlier comments are you happy to go ahead with
> > > > this for
> > > > now and sort the other possible issues separately?
> > > 
> > > Well - it's an improvement, sure, so I'm not intending to block it
> > > going in if no better way can be determined in its place right away.
> > > What makes me hesitant is that I'm not sure there indeed will be a
> > > follow up to this any time soon.
> > 
> > TBH, having a script which check the validity of the headers is not in
> > the top my todo list. Though it would be nice to have it.
> 
> No, the validating script is a nice-to-have, but nothing more. What
> I was referring to was a patch to drop the use of this gcc extension.

Then I'm confused. This patch turns a typeof into a __typeof__. In <
56126d870278000a8...@prv-mh.provo.novell.com> you said "typeof() is a
gcc extension".

Are you now saying that __typeof__ also a gcc extension too?

I was under the impression that __typeof__ was standard (by some cxx at
least) and your mail reinforced that (possibly wrong) impression.

https://gcc.gnu.org/onlinedocs/gcc/Typeof.html also says that "If you are
writing a header file that must work when included in ISO C programs, write
__typeof__ instead of typeof", which also lead me to believe __typeof__ was
OK from this PoV.

Ian.

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Jan Beulich

>>> On 23.10.15 at 15:58,  wrote:
> On 23/10/15 14:52, Jan Beulich wrote:
> On 23.10.15 at 15:30,  wrote:
>>> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
 Hi,

 On 04/10/15 20:24, Julien Grall wrote:
> The keyword typeof is not portable:
>
> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> of function 'typeof' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]

 Ping? Aside the fact that other bits of the header may not be iso
 compliant, I still think this patch is valid.
>>>
>>> Yes, I agree.
>>> Acked-by: Ian Campbell 
>>>
>>> Jan, after your earlier comments are you happy to go ahead with this for
>>> now and sort the other possible issues separately?
>> 
>> Well - it's an improvement, sure, so I'm not intending to block it
>> going in if no better way can be determined in its place right away.
>> What makes me hesitant is that I'm not sure there indeed will be a
>> follow up to this any time soon.
> 
> TBH, having a script which check the validity of the headers is not in
> the top my todo list. Though it would be nice to have it.

No, the validating script is a nice-to-have, but nothing more. What
I was referring to was a patch to drop the use of this gcc extension.

> But I don't think we should delay this valid patch just because we don't
> have time to write a such script.

As said - I don't intend to block the patch going in; I'm just not
convinced that allowing it to go in won't result in not follow up at all.

Jan


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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Jan Beulich

>>> On 23.10.15 at 16:03,  wrote:
> On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
>> > > > On 23.10.15 at 15:30,  wrote:
>> > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> > > Hi,
>> > > 
>> > > On 04/10/15 20:24, Julien Grall wrote:
>> > > > The keyword typeof is not portable:
>> > > > 
>> > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
>> > > > declaration
>> > > > of function 'typeof' is invalid in C99
>> > > > [-Werror,-Wimplicit-function-declaration]
>> > > 
>> > > Ping? Aside the fact that other bits of the header may not be iso
>> > > compliant, I still think this patch is valid.
>> > 
>> > Yes, I agree.
>> > Acked-by: Ian Campbell 
>> > 
>> > Jan, after your earlier comments are you happy to go ahead with this
>> > for
>> > now and sort the other possible issues separately?
>> 
>> Well - it's an improvement, sure, so I'm not intending to block it
>> going in if no better way can be determined in its place right away.
>> What makes me hesitant is that I'm not sure there indeed will be a
>> follow up to this any time soon.
> 
> Are you saying with "better way" that Julien's fix is incorrect and that
> there is potentially a "proper" fix for this specific case? i.e. a followup
> to fix the use of __typeof__ in set_xen_guest_handle_raw which this patch
> introduces is expected?
> 
> I don't think you are, in which case are you suggesting that having fixed
> this one issue that Julien should then be on the hook for fixing all
> similar/related issues in these header?
> 
> I don't think it is right to mandate that Julien put this followup work
> onto his TODO list as a condition of accepting this patch, if this is not a
> case of Julien's change being incorrect and requiring a "proper" fix, but
> that there are other similar things wrong elsewhere.

I'm not meaning to mandate Julien to do all other follow up work. If
anyone was to be mandated, then whoever introduced use of gcc
extensions into public headers. But as we know, that doesn't
normally work (on ARM perhaps everyone who helped with the
bringup may still be around, but outside of ARM that's less likely, so
arguably not a workable model).

The patch is an improvement, yes. So it may go in if right now
no-one can't think of a proper fix for the problem at hand. But
in the end all the patch does is papering over an issue, instead
of eliminating it. And that's the grounds on which I wasn't (and
still am not really) happy to see it go in.

Jan


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

Re: [Xen-devel] [PATCH] xl: log an error if libxl_cpupool_destroy() fails

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 09:43 +0100, Wei Liu wrote:
> On Thu, Oct 22, 2015 at 07:14:20PM +0200, Dario Faggioli wrote:
> > In fact, right now, failing at destroying a cpupool is just
> > not reported to the user in any explicit way. Log an error,
> > as it is customary for xl in these cases.
> > 
> > While there, take the chance to turn a couple of xl exit
> > codes into EXIT_[SUCCESS|FAILURE], as discussed and agreed
> > here:
> > 
> >  http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01336.h
> > tml
> >  http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01341.h
> > tml
> > 
> > Signed-off-by: Dario Faggioli 
> 
> Acked-by: Wei Liu 

Looking at those links, I'm not sure that either you or myself was thinking
of using EXIT_* as function return values, just that the eventual process
exit would become one of those values instead of some negative number.
Although the thread doesn't look like it is too clear if it is talking
about return values from functions vs. process exit codes.

I think what I would have been expecting is for the xl internal error code
would become EXIT_* either in the call to exit() or the return from main
instead of being the process exit code directly.

Seeing "return EXIT_FOO" outside of a main function seems rather strange to
me.

Wei, you acked so maybe you disagree?

Ian.

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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 07:52 -0600, Jan Beulich wrote:
> > > > On 23.10.15 at 15:30,  wrote:
> > On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 04/10/15 20:24, Julien Grall wrote:
> > > > The keyword typeof is not portable:
> > > > 
> > > > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit
> > > > declaration
> > > > of function 'typeof' is invalid in C99
> > > > [-Werror,-Wimplicit-function-declaration]
> > > 
> > > Ping? Aside the fact that other bits of the header may not be iso
> > > compliant, I still think this patch is valid.
> > 
> > Yes, I agree.
> > Acked-by: Ian Campbell 
> > 
> > Jan, after your earlier comments are you happy to go ahead with this
> > for
> > now and sort the other possible issues separately?
> 
> Well - it's an improvement, sure, so I'm not intending to block it
> going in if no better way can be determined in its place right away.
> What makes me hesitant is that I'm not sure there indeed will be a
> follow up to this any time soon.

Are you saying with "better way" that Julien's fix is incorrect and that
there is potentially a "proper" fix for this specific case? i.e. a followup
to fix the use of __typeof__ in set_xen_guest_handle_raw which this patch
introduces is expected?

I don't think you are, in which case are you suggesting that having fixed
this one issue that Julien should then be on the hook for fixing all
similar/related issues in these header?

I don't think it is right to mandate that Julien put this followup work
onto his TODO list as a condition of accepting this patch, if this is not a
case of Julien's change being incorrect and requiring a "proper" fix, but
that there are other similar things wrong elsewhere.

Of course if he or anyone else wants to do so voluntarily then that's
great.

Ian.

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

Re: [Xen-devel] [PATCH v2] x86/mm: pod: Use the correct memory flags for alloc_domheap_page{, s}

2015-10-23 Thread Dario Faggioli

On Fri, 2015-10-23 at 11:33 +0100, Julien Grall wrote:
> The last parameter of alloc_domheap_page{s,} contain the memory flags
> and
> not the order of the allocation.
> 
> Use 0 for the call in p2m_pod_set_cache_target as it was before
> 1069d63c5ef2510d08b83b2171af660e5bb18c63 "x86/mm/p2m: use defines for
> page sizes". Note that PAGE_ORDER_4K is also equal to 0 so the
> behavior
> stays the same.
> 
> For the call in p2m_pod_offline_or_broken_replace we want to allocate
> the new page on the same numa node as the previous page. So retrieve
> the
> numa node and pass it in the memory flags.
> 
> Signed-off-by: Julien Grall 
> 
> ---
> 
> Note that the patch has only been build tested.
> 
I've done some basic testing. That means I:
 - created an HVM guest with memory < maxmem
 - played with `xl mem-set' and `xl mem-max' on it
 - local migrated it
 - played with `xl mem-set' and `xl mem-max' on it again
 - shutdown it

All done on a NUMA host, with memory dancing (during the 'play' phases)
up and down the amount of RAM present in each NUMA node.

I'm not sure how I should trigger and test memory hotunplug, neither
whether or not my testbox supports it.

Since it seems that memory hotumplug is what was really necessary, I'm
not sure it's appropriate to add the following tag:

Tested-by: Dario Faggioli 

but I'll let you guys (Jan, mainly, I guess) decide. If the above is
deemed enough, feel free to stick it there, if not, fine anyway. :-)

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



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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Julien Grall

On 23/10/15 14:52, Jan Beulich wrote:
 On 23.10.15 at 15:30,  wrote:
>> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>>> Hi,
>>>
>>> On 04/10/15 20:24, Julien Grall wrote:
 The keyword typeof is not portable:

 /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
 of function 'typeof' is invalid in C99
 [-Werror,-Wimplicit-function-declaration]
>>>
>>> Ping? Aside the fact that other bits of the header may not be iso
>>> compliant, I still think this patch is valid.
>>
>> Yes, I agree.
>> Acked-by: Ian Campbell 
>>
>> Jan, after your earlier comments are you happy to go ahead with this for
>> now and sort the other possible issues separately?
> 
> Well - it's an improvement, sure, so I'm not intending to block it
> going in if no better way can be determined in its place right away.
> What makes me hesitant is that I'm not sure there indeed will be a
> follow up to this any time soon.

TBH, having a script which check the validity of the headers is not in
the top my todo list. Though it would be nice to have it.

But I don't think we should delay this valid patch just because we don't
have time to write a such script.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH] tools/python: remove broken xl binding

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-08 at 12:10 -0400, Zhigang Wang wrote:
> On 10/08/2015 11:28 AM, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 10:58 -0400, Zhigang Wang wrote:
> > > On 10/08/2015 10:40 AM, Ian Campbell wrote:
> > > > On Tue, 2015-10-06 at 15:09 -0400, Konrad Rzeszutek Wilk wrote:
> > > > > On Tue, Oct 06, 2015 at 06:13:04PM +0100, Andrew Cooper wrote:
> > > > > > On 06/10/15 17:57, Wei Liu wrote:
> > > > > > > Various people say this binding doesn't compile or doesn't
> > > > > > > work.
> > > > > > > Remove
> > > > > > > it for the benefit of xl feature development -- so that new
> > > > > > > features
> > > > > > > won't need to worry about making this broken binding happy.
> > > > > > > 
> > > > > > > This isn't going to expose any user visible changes because
> > > > > > > that
> > > > > > > module
> > > > > > > is not built by default.
> > > > > > > 
> > > > > > > Signed-off-by: Wei Liu 
> > > > > > 
> > > > > > Reviewed-by: Andrew Cooper 
> > > > > 
> > > > > And Zhigang mentioned to me offline that he is OK with these
> > > > > being
> > > > > gone too.
> > > > 
> > > > Could we get a formal ack from one of you then please?
> > > 
> > > I'm OK with removing libxl python bindings.
> > 
> > Thanks, are you okay with me translating this into
> > 
> > Acked-by: Zhigang Wang 
> > 
> > in the final commit?
> 
> Yes.
> 
> Acked-by: Zhigang Wang 

Thanks, acked it myself and applied.


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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
> Hi,
> 
> On 04/10/15 20:24, Julien Grall wrote:
> > The keyword typeof is not portable:
> > 
> > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> > of function 'typeof' is invalid in C99
> > [-Werror,-Wimplicit-function-declaration]
> 
> Ping? Aside the fact that other bits of the header may not be iso
> compliant, I still think this patch is valid.

Yes, I agree.
Acked-by: Ian Campbell 

Jan, after your earlier comments are you happy to go ahead with this for
now and sort the other possible issues separately?

> 
> FWIW, it fixed build of the FreeBSD kernel for ARM64 with Xen enabled.
> 
> Regards,
> 

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

Re: [Xen-devel] Work on a project: Refactor Linux hotplug scripts

2015-10-23 Thread Roger Pau Monné

El 23/10/15 a les 13.33, Roger Pau Monné ha escrit:
> El 23/10/15 a les 7.53, Надежда Ампилогова ha escrit:
>> Hi all,
>>
>> I am interested in the project Refactor Linux hotplug scripts for 
>> Outreachy(Round 11). I am more of an intermediate-beginner in c. Please can 
>> anyone provide some pointers and helper about the things I need to do to 
>> join this project.
> 
> Hello,
> 
> You have to start by setting up your development system, there's a lot
> of information about how to do this on the Xen wiki:
> 
> http://wiki.xenproject.org/wiki/Getting_Started
> http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source
> http://wiki.xenproject.org/wiki/Xen_Serial_Console
> 
> Since you have to submit a patch before formally applying for OPW, you
> will have to get used to git (if you are not yet familiar with it), we
> also have a couple of wiki pages about this:
> 
> http://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches
> 
> I personally use stgit in order to manage my patches:
> 
> http://wiki.xenproject.org/wiki/Submitting_Xen_Patches_with_StGit
> 
> Maybe during this process you will find issues or things that you think
> can be improved, if that's the case those patch(es) could be used in
> order to fulfil your application. If not, reply back and we will try to
> find a suitable small task.

Here are some simple tasks that are suitable in order to complete your
application (if you pick one of them please say so in order to avoid
collisions with other applicants):

http://www.gossamer-threads.com/lists/xen/devel/34#34

Roger.


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

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> The GICv2 DT node is usually used by the guest to know the address/size
> of the regions (GICD, GICC...) to map into their virtual memory.
> 
> While the GICv2 spec requires the size of the GICC to be 8KB, we
> correctly do an 8KB stage-2 mapping but errornously report 256 in the
> device tree (based on GUEST_GICC_SIZE).

"erroneously"

> 
> I bet we didn't see any issue so far because all the registers except
> GICC_DIR lives in the first 256 bytes of the GICC region and all the guest

"guests"

> I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
> 0.
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 

(typo's fixable on commit).

> ---
> This patch is a good candidate to backport for Xen 4.6 - 4.4.
> Without it a guest relying on the DT can't use GICC_DIR.

Noted, but just to check: This patch (and none of the other fixes in this
series) are all which are required for a guest to be able to use GICC_DIR,
right?


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

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 14:34 +0100, Julien Grall wrote:
> Hi Ian,
> 
> On 23/10/15 14:28, Ian Campbell wrote:
> > On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> > > The GICv2 DT node is usually used by the guest to know the
> > > address/size
> > > of the regions (GICD, GICC...) to map into their virtual memory.
> > > 
> > > While the GICv2 spec requires the size of the GICC to be 8KB, we
> > > correctly do an 8KB stage-2 mapping but errornously report 256 in the
> > > device tree (based on GUEST_GICC_SIZE).
> > 
> > "erroneously"
> > 
> > > 
> > > I bet we didn't see any issue so far because all the registers except
> > > GICC_DIR lives in the first 256 bytes of the GICC region and all the
> > > guest
> > 
> > "guests"
> > 
> > > I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
> > > 0.
> > > 
> > > Signed-off-by: Julien Grall 
> > 
> > Acked-by: Ian Campbell 
> > 
> > (typo's fixable on commit).
> 
> Thank you!
> 
> > > ---
> > > This patch is a good candidate to backport for Xen 4.6 - 4.4.
> > > Without it a guest relying on the DT can't use GICC_DIR.
> > 
> > Noted, but just to check: This patch (and none of the other fixes in
> > this
> > series) are all which are required for a guest to be able to use
> > GICC_DIR,
> > right?
> 
> Correct. BTW, I forgot to mention that this patch may not apply cleanly
> on Xen 4.4 as rearranged the guest memory address space in Xen 4.5.

I'd be inclined not to bother with it for 4.4 at this juncture then.

Ian.

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

Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

2015-10-23 Thread Juergen Gross


On 10/21/2015 07:10 PM, Dario Faggioli wrote:

On Thu, 2015-10-15 at 10:25 +0200, Juergen Gross wrote:

Maybe it would be a good idea to move setting of per_cpu(cpupool,
cpu)
into schedule_cpu_switch(). Originally I didn't do that to avoid
spreading too much cpupool related actions outside of cpupool.c. But
with those ASSERT()s added hiding that action will cause more
confusion
than having the modification of per_cpu(cpupool, cpu) here.


Coming back to this.

When reworking the series, I tried to move 'per_cpu(cpupool, cpu)=c' in
schedule_cpu_switch() and, about this part:


When doing the code movement the current behaviour regarding sequence
of changes must be kept, of course. So when adding the cpu to a pool
the cpupool information must be set _before_ taking the scheduler
lock,
while when removing this must happen after release of the lock.


I don't think I see why I can't do as in the attached patch (i.e., just
update the cpupool per-cpu variable at the bottom of
schedule_cpu_switch() ).

I don't see anything in the various schedulers' code that relies on
that variable, except one thing in sched_credit.c, which looks safe to
me. And indeed I think that even any future potential code being added
there, should either not depend on it, or do it "safely".

Also, all the operations done in schedule_cpu_switch() itself, depend
either on per_cpu(scheduler) or on per_cpu(schedule_data) being updated
properly, rather than on per_cpu(cpupool) (including the locking that
you are mentioning above).

What am I missing?


Hmm, good question. I'm rather sure I had a problem related to exactly
this topic in the early days of cpupools. Maybe the critical code has
been modified since then. Or my memory is wrong. Or we both don't see
it now. ;-)

In case there is a problem it should show up doing a test which
concurrently does all of the following:

- move a domain between two cpupools
- move a cpu between the two cpupools
- create and destroy a domain in one of the two cpupools

If the system is surviving this test for a couple of hours you are fine
and then for the attached patch:

Acked-by: Juergen Gross 


Juergen



Regards,
Dario
---
diff --git a/xen/common/cpupool.c b/xen/common/cpupool.c
index e79850b..8e7b723 100644
--- a/xen/common/cpupool.c
+++ b/xen/common/cpupool.c
@@ -261,19 +261,13 @@ int cpupool_move_domain(struct domain *d, struct cpupool 
*c)
  static int cpupool_assign_cpu_locked(struct cpupool *c, unsigned int cpu)
  {
  int ret;
-struct cpupool *old;
  struct domain *d;

  if ( (cpupool_moving_cpu == cpu) && (c != cpupool_cpu_moving) )
  return -EBUSY;
-old = per_cpu(cpupool, cpu);
-per_cpu(cpupool, cpu) = c;
  ret = schedule_cpu_switch(cpu, c);
  if ( ret )
-{
-per_cpu(cpupool, cpu) = old;
  return ret;
-}

  cpumask_clear_cpu(cpu, &cpupool_free_cpus);
  if (cpupool_moving_cpu == cpu)
@@ -326,7 +320,6 @@ static long cpupool_unassign_cpu_helper(void *info)
  cpumask_clear_cpu(cpu, &cpupool_free_cpus);
  goto out;
  }
-per_cpu(cpupool, cpu) = NULL;
  cpupool_moving_cpu = -1;
  cpupool_put(cpupool_cpu_moving);
  cpupool_cpu_moving = NULL;
diff --git a/xen/common/schedule.c b/xen/common/schedule.c
index d7e2d98..9072540 100644
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1486,6 +1486,17 @@ void __init scheduler_init(void)
  BUG();
  }

+/*
+ * Move a pCPU outside of the influence of the scheduler of its current
+ * cpupool, or subject it to the scheduler of a new cpupool.
+ *
+ * For the pCPUs that are removed from their cpupool, their scheduler becomes
+ * &ops (the default scheduler, selected at boot, which also services the
+ * default cpupool). However, as these pCPUs are not really part of any pool,
+ * there won't be any scheduling event on them, not even from the default
+ * scheduler. Basically, they will just sit idle until they are explicitly
+ * added back to a cpupool.
+ */
  int schedule_cpu_switch(unsigned int cpu, struct cpupool *c)
  {
  unsigned long flags;
@@ -1494,9 +1505,24 @@ int schedule_cpu_switch(unsigned int cpu, struct cpupool 
*c)
  void *ppriv, *ppriv_old, *vpriv, *vpriv_old;
  struct scheduler *old_ops = per_cpu(scheduler, cpu);
  struct scheduler *new_ops = (c == NULL) ? &ops : c->sched;
+struct cpupool *old_pool = per_cpu(cpupool, cpu);
+
+/*
+ * pCPUs only move from a valid cpupool to free (i.e., out of any pool),
+ * or from free to a valid cpupool. In the former case (which happens when
+ * c is NULL), we want the CPU to have been marked as free already, as
+ * well as to not be valid for the source pool any longer, when we get to
+ * here. In the latter case (which happens when c is a valid cpupool), we
+ * want the CPU to still be marked as free, as well as to not yet be valid
+ * for the destination pool.
+ */
+ASSERT(c != old_pool && (c != NULL ||

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 13:25 +, Hu, Robert wrote:
> > -Original Message-
> > From: Ian Campbell [mailto:ian.campb...@citrix.com]
> > Sent: Friday, October 23, 2015 4:15 PM
> > To: Hu, Robert ; 'Ian Jackson'
> > ; 'xen-de...@lists.xenproject.org'
> > 
> > Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> > `nodhcp' to `ensurebridge'
> > 
> > On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> > 
> > > [Hu, Robert]
> > > Seems the failure log shall be this, any idea? I've spent days on
> > > debugging this:(
> > > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > > (XEN) PCI add device :00:00.0
> > > (XEN) PCI add device :00:01.0
> > > (XEN) PCI add device :00:01.1
> > > (XEN) PCI add device :00:01.2
> > > (XEN) PCI add device :00:01.3
> > > (XEN) PCI add device :00:02.0
> > > (XEN) PCI add device :00:03.0
> > > (XEN) d0: Forcing read-only access to MFN fed00
> > > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > > Issued domain 3 reboot
> > > qemu: terminating on signal 1 from pid 4322
> > 
> > Please can you report this as a regular bug in a fresh thread, that way
> > the relevant Xen maintainers are likely to see and react to it, rather
> > than just us osstest folks.
> [Hu, Robert] 
> 
> It shall be in that way after I confirm it is a bug.
> Currently I'm just still not certain it is a nested bug or because of the
> latest
> osstest code change.
> I was just asking for if you can recall some hint on what changes (of
> osstest)
> might causing this.
> I'm to restore to my v12 code, with current Xen and qemu selection to try
> again. I think by this way, I can confirm it is an actual nested bug or
> not.
> Then I would report this in a fresh thread.

A dom0 crash of this sort is pretty certainly a bug somewhere in Xen,
whether it is exposed by a new osstest case or not. The people who are best
placed to figure out where the bug is are certainly not reading this
osstest thread.

So please just report it as a bug as it stands, with the relevant
information.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 15:16 +0200, Fabio Fantoni wrote:
> A recent ovmf patch (already tested) I think is good to backport is:

Pointing out backport candidates in the depths of a thread such as this is
a sure fire way to ensure they get missed I'm afraid.

Please make such requests explicitly in a new thread, or at least in a
reply to the patch in question.

Ian.

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

Re: [Xen-devel] [PATCH] mm: hotplug: Don't release twice the resource on error

2015-10-23 Thread David Vrabel

On 23/10/15 13:57, Julien Grall wrote:
> The function add_memory_resource take in parameter a resource allocated
> by the caller. On error, both add_memory_resource and the caller will
> release the resource via release_memory_source.
[...]
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1298,7 +1298,6 @@ error:
>   /* rollback pgdat allocation and others */
>   if (new_pgdat)
>   rollback_node_hotadd(nid, pgdat);
> - release_memory_resource(res);
>   memblock_remove(start, size);

I've folded this in, thanks.

David

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

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

2015-10-23 Thread Julien Grall

On 23/10/15 14:39, Ian Campbell wrote:
> On Fri, 2015-10-23 at 14:34 +0100, Julien Grall wrote:
>> Hi Ian,
>>
>> On 23/10/15 14:28, Ian Campbell wrote:
>>> On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
 The GICv2 DT node is usually used by the guest to know the
 address/size
 of the regions (GICD, GICC...) to map into their virtual memory.

 While the GICv2 spec requires the size of the GICC to be 8KB, we
 correctly do an 8KB stage-2 mapping but errornously report 256 in the
 device tree (based on GUEST_GICC_SIZE).
>>>
>>> "erroneously"
>>>

 I bet we didn't see any issue so far because all the registers except
 GICC_DIR lives in the first 256 bytes of the GICC region and all the
 guest
>>>
>>> "guests"
>>>
 I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
 0.

 Signed-off-by: Julien Grall 
>>>
>>> Acked-by: Ian Campbell 
>>>
>>> (typo's fixable on commit).
>>
>> Thank you!
>>
 ---
 This patch is a good candidate to backport for Xen 4.6 - 4.4.
 Without it a guest relying on the DT can't use GICC_DIR.
>>>
>>> Noted, but just to check: This patch (and none of the other fixes in
>>> this
>>> series) are all which are required for a guest to be able to use
>>> GICC_DIR,
>>> right?
>>
>> Correct. BTW, I forgot to mention that this patch may not apply cleanly
>> on Xen 4.4 as rearranged the guest memory address space in Xen 4.5.
> 
> I'd be inclined not to bother with it for 4.4 at this juncture then.

I'm fine with that.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [PATCH v2 3/6] xen: sched: clarify use cases of schedule_cpu_switch()

2015-10-23 Thread Dario Faggioli

On Fri, 2015-10-23 at 15:42 +0200, Juergen Gross wrote:
> On 10/21/2015 07:10 PM, Dario Faggioli wrote:

> > Also, all the operations done in schedule_cpu_switch() itself,
> > depend
> > either on per_cpu(scheduler) or on per_cpu(schedule_data) being
> > updated
> > properly, rather than on per_cpu(cpupool) (including the locking
> > that
> > you are mentioning above).
> > 
> > What am I missing?
> 
> Hmm, good question. I'm rather sure I had a problem related to
> exactly
> this topic in the early days of cpupools. Maybe the critical code has
> been modified since then. Or my memory is wrong. 
>
From a quick archeological investigation, some things certainly have
changed. Still, I can't spot anything directly related to this, but
it's quite possible that it's there and I'm missing it.

> Or we both don't see
> it now. ;-)
> 
Yep! :-)

> In case there is a problem it should show up doing a test which
> concurrently does all of the following:
> 
> - move a domain between two cpupools
> - move a cpu between the two cpupools
> - create and destroy a domain in one of the two cpupools
> 
Ok, I'll arrange for this and report.

> If the system is surviving this test for a couple of hours you are
> fine
> and then for the attached patch:
> 
> Acked-by: Juergen Gross 
> 
Thanks :-)
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

Re: [Xen-devel] [PATCH] libxl: Do not call assert() in signal handlers

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-22 at 17:22 +0100, Ian Campbell wrote:
> On Thu, 2015-10-22 at 16:39 +0100, Ian Jackson wrote:
> > assert is not async-signal-safe.
> 
> I don't doubt you, but I'm curious regarding a reference.
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/assert.html doe
> sn
> 't appear to be it, unless it is too subtle for me.
> 
> > In practice the effect of calling assert there is that if the
> > assertion fails we might get a secondary crash, or other undesirable
> > behaviour from stdio (which is how assert usually reports failures).
> 
> Or maybe it's just transitive through the (usual) use of stdio as part of
> assert()?
> 
> > Mention in a comment in libxl__self_pipe_wakeup that it has to be
> > async-signal-safe.
> > 
> > Signed-off-by: Ian Jackson 
> 
> Acked-by: Ian Campbell 

Applied.



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

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Jan Beulich

>>> On 23.10.15 at 15:30,  wrote:
> On Fri, 2015-10-23 at 14:13 +0100, Julien Grall wrote:
>> Hi,
>> 
>> On 04/10/15 20:24, Julien Grall wrote:
>> > The keyword typeof is not portable:
>> > 
>> > /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
>> > of function 'typeof' is invalid in C99
>> > [-Werror,-Wimplicit-function-declaration]
>> 
>> Ping? Aside the fact that other bits of the header may not be iso
>> compliant, I still think this patch is valid.
> 
> Yes, I agree.
> Acked-by: Ian Campbell 
> 
> Jan, after your earlier comments are you happy to go ahead with this for
> now and sort the other possible issues separately?

Well - it's an improvement, sure, so I'm not intending to block it
going in if no better way can be determined in its place right away.
What makes me hesitant is that I'm not sure there indeed will be a
follow up to this any time soon.

Jan


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

Re: [Xen-devel] [PATCH v4 0/4] xen/arm: gic-v2: Detect automatically aliased GIC 400

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> Hi all,
> 
> Only patch #3 is related to the subject of the cover letter. The rest is
> clean
> up of code I looked while I was working on this series. Though, patch #1
> is a
> new bug fix I noticed between v3 and v4.

I fixed the typos I mentioned in my review and have now committed all four.


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

Re: [Xen-devel] [PATCH v2 1/2] xen/arm: Add support of PSCI v1.0 for the host

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 11:39 +0100, Julien Grall wrote:
> On 23/10/15 11:39, Ian Campbell wrote:
> > On Thu, 2015-10-22 at 18:17 +0100, Julien Grall wrote:
> > > Hi,
> > > 
> > > On 22/10/15 16:42, Ian Campbell wrote:
> > > > On Mon, 2015-10-12 at 16:39 +0100, Julien Grall wrote:
> > > > 
> > > > Subject: support PSCI v1.0 for the host.
> > > > 
> > > > > From Xen point of view, PSCI v0.2 and PSCI v1.0 are very similar.
> > > > > All
> > > >Xen's
> > > > 
> > > > > the PSCI calls used within Xen (PSCI_VERSION, CPU_ON, SYSTEM_OFF
> > > > > and
> > > > > SYSTEM_RESET) behaves exactly the same.
> > > > 
> > > > behave
> > > > 
> > > > > Furthermore, based on the spec (5.3.1 DEN0022C), any 1.y version
> > > > > must
> > > > > be
> > > > > compatible with 1.x when y > x for any functions existing in 1.x.
> > > > > 
> > > > > So check the presence of the new compatible string [1] and allow
> > > > > Xen
> > > > > to
> > > > > boot on any platform using PSCI 1.x.
> > > > > 
> > > > > [1] 
> > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-Octobe
> > > > > r/37
> > > > > 4547.html
> > > > > 
> > > > > Signed-off-by: Julien Grall 
> > > > 
> > > > Acked-by: Ian Campbell 
> > > 
> > > Shall I resend a new version with those typos fixed? Or do you plan
> > > to
> > > do it when you'll commit the patch?
> > 
> > Looks like those are the only changes required, so assuming you are are
> > happy with them I'll just do them on commit.
> 
> I'm fine with that.

Applied, thanks.


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

Re: [Xen-devel] [PATCH v4 1/4] xen/arm: vgic-v2: Report the correct GICC size to the guest

2015-10-23 Thread Julien Grall

Hi Ian,

On 23/10/15 14:28, Ian Campbell wrote:
> On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
>> The GICv2 DT node is usually used by the guest to know the address/size
>> of the regions (GICD, GICC...) to map into their virtual memory.
>>
>> While the GICv2 spec requires the size of the GICC to be 8KB, we
>> correctly do an 8KB stage-2 mapping but errornously report 256 in the
>> device tree (based on GUEST_GICC_SIZE).
> 
> "erroneously"
> 
>>
>> I bet we didn't see any issue so far because all the registers except
>> GICC_DIR lives in the first 256 bytes of the GICC region and all the guest
> 
> "guests"
> 
>> I have seen so far are driving the GIC with GICC_CTLR.EIOmode =
>> 0.
>>
>> Signed-off-by: Julien Grall 
> 
> Acked-by: Ian Campbell 
> 
> (typo's fixable on commit).

Thank you!

>> ---
>> This patch is a good candidate to backport for Xen 4.6 - 4.4.
>> Without it a guest relying on the DT can't use GICC_DIR.
> 
> Noted, but just to check: This patch (and none of the other fixes in this
> series) are all which are required for a guest to be able to use GICC_DIR,
> right?

Correct. BTW, I forgot to mention that this patch may not apply cleanly
on Xen 4.4 as rearranged the guest memory address space in Xen 4.5.

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename `nodhcp' to `ensurebridge'

2015-10-23 Thread Hu, Robert

> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: Friday, October 23, 2015 4:15 PM
> To: Hu, Robert ; 'Ian Jackson'
> ; 'xen-de...@lists.xenproject.org'
> 
> Subject: Re: [OSSTEST PATCH 26/26] ts-xen-install: networking: Rename
> `nodhcp' to `ensurebridge'
> 
> On Fri, 2015-10-23 at 06:16 +, Hu, Robert wrote:
> 
> > [Hu, Robert]
> > Seems the failure log shall be this, any idea? I've spent days on
> > debugging this:(
> > (XEN) traps.c:3290: GPF (): 82d080195082 -> 82d080243d9d
> > (XEN) PCI add device :00:00.0
> > (XEN) PCI add device :00:01.0
> > (XEN) PCI add device :00:01.1
> > (XEN) PCI add device :00:01.2
> > (XEN) PCI add device :00:01.3
> > (XEN) PCI add device :00:02.0
> > (XEN) PCI add device :00:03.0
> > (XEN) d0: Forcing read-only access to MFN fed00
> > (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.
> > Issued domain 3 reboot
> > qemu: terminating on signal 1 from pid 4322
> 
> Please can you report this as a regular bug in a fresh thread, that way
> the relevant Xen maintainers are likely to see and react to it, rather
> than just us osstest folks.
[Hu, Robert] 

It shall be in that way after I confirm it is a bug.
Currently I'm just still not certain it is a nested bug or because of the latest
osstest code change.
I was just asking for if you can recall some hint on what changes (of osstest)
might causing this.
I'm to restore to my v12 code, with current Xen and qemu selection to try
again. I think by this way, I can confirm it is an actual nested bug or not.
Then I would report this in a fresh thread.

> 
> Please include whatever information you can, e.g. the guest config file
> used, details about the type of guest, which level of nesting this is
> happening at, the contents of any logs under /var/log/xen in L0 and L1
> host etc.
[Hu, Robert] 

Yes, sure. I will include these in bug reporting.

> 
> If this crash is in an L1 host then you might also want to CC the
> nested hvm maintainers at Intel.
[Hu, Robert] 
Yes, thanks for remind.

> 
> See http://wiki.xenproject.org/wiki/Reporting_Bugs_against_Xen_Project
> for general advice on reporting a bug and other things to consider
> including.
> 
> Thanks,
> Ian.

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

Re: [Xen-devel] [PATCH v4 4/4] xen/arm: platform: Drop the quirks callback

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> All the quirks has been replaced by proper detection. Lets drop the

 have

> callback and hope that no one will need new quirks.
> 
> At the same time, remove the definition platform_dom0_evtchn_ppi with is

 ^of   which

> not used any more.
> 
> Signed-off-by: Julien Grall 
> Acked-by: Ian Campbell 
> 
> ---
> Changes in v2:
> - Add Ian's acked-by
> ---
>  xen/arch/arm/platform.c| 10 --
>  xen/include/asm-arm/platform.h |  8 
>  2 files changed, 18 deletions(-)
> 
> diff --git a/xen/arch/arm/platform.c b/xen/arch/arm/platform.c
> index 0af6d57..b0bfaa9 100644
> --- a/xen/arch/arm/platform.c
> +++ b/xen/arch/arm/platform.c
> @@ -127,16 +127,6 @@ void platform_poweroff(void)
>  platform->poweroff();
>  }
>  
> -bool_t platform_has_quirk(uint32_t quirk)
> -{
> -uint32_t quirks = 0;
> -
> -if ( platform && platform->quirks )
> -quirks = platform->quirks();
> -
> -return !!(quirks & quirk);
> -}
> -
>  bool_t platform_device_is_blacklisted(const struct dt_device_node *node)
>  {
>  const struct dt_device_match *blacklist = NULL;
> diff --git a/xen/include/asm-arm/platform.h b/xen/include/asm
> -arm/platform.h
> index 5e462ac..f97315d 100644
> --- a/xen/include/asm-arm/platform.h
> +++ b/xen/include/asm-arm/platform.h
> @@ -27,12 +27,6 @@ struct platform_desc {
>  /* Platform power-off */
>  void (*poweroff)(void);
>  /*
> - * Platform quirks
> - * Defined has a function because a platform can support multiple
> - * board with different quirk on each
> - */
> -uint32_t (*quirks)(void);
> -/*
>   * Platform blacklist devices
>   * List of devices which must not pass-through to a guest
>   */
> @@ -48,9 +42,7 @@ int platform_cpu_up(int cpu);
>  #endif
>  void platform_reset(void);
>  void platform_poweroff(void);
> -bool_t platform_has_quirk(uint32_t quirk);
>  bool_t platform_device_is_blacklisted(const struct dt_device_node
> *node);
> -unsigned int platform_dom0_evtchn_ppi(void);
>  
>  #define PLATFORM_START(_name, _namestr) \
>  static const struct platform_desc  __plat_desc_##_name __used   \

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

Re: [Xen-devel] [PATCH v4 3/4] xen/arm: gic-v2: Automatically detect aliased GIC400

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> We are currently using a per-platform quirk to know if the 2 4KB region
> of
> the GIC CPU interface are each aligned to 64KB. Although, it may be
> possible to have different layout on a same platform (depending on the
> firmware version).
> 
> Rather than having a quirk it's possible to detect by reading the GIC
> memory. This patch is based from the Linux commit "irqchip/GIC: Add
> workaround
> for aliased GIC400" [1].
> 
> Take the opportunity to clean up the GICv2 of code which was only
> required because of the quirk.
> 
> Note that none of the platform using the gic-hip04 were actually using
> the quirk, so the code has been dropped. I will let the maintainers
> decide whether it's relevant or not to add proper detection for aliased
> GIC for this hardware.
> 
> [1] commit 12e14066f4835f5ee1ca795f0309415b54c067a9
> Author: Marc Zyngier 
> Date:   Sun Sep 13 12:14:31 2015 +0100
> 
> irqchip/GIC: Add workaround for aliased GIC400
> 
> The GICv2 architecture mandates that the two 4kB GIC regions are
> contiguous, and on two separate physical pages (so that access to
> the second page can be trapped by a hypervisor). This doesn't work
> very well when PAGE_SIZE is 64kB.
> 
> A relatively common hack^Wway to work around this is to alias each
> 4kB region over its own 64kB page. Of course in this case, the base
> address you want to use is not really the begining of the region,
> but base + 60kB (so that you get a contiguous 8kB region over two
> distinct pages).
> 
> Normally, this would be described in DT with a new property, but
> some HW is already out there, and the firmware makes sure that
> it will override whatever you put in the GIC node. Duh. And of
> course,
> said firmware source code is not available, despite being based
> on u-boot.
> 
> The workaround is to detect the case where the CPU interface size
> is set to 128kB, and verify the aliasing by checking that the ID
> register for GIC400 (which is the only GIC wired this way so far)
> is the same at base and base + 0xF000. In this case, we update
> the GIC base address and let it roll.
> 
> And if you feel slightly sick by looking at this, rest assured that
> I do too...
> 
> Reported-by: Julien Grall 
> Signed-off-by: Marc Zyngier 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Stuart Yoder 
> Cc: Pavel Fedin 
> Cc: Jason Cooper 
> Link: http://lkml.kernel.org/r/1442142873-20213-2-git-send-email-marc
> .zyng...@arm.com
> Signed-off-by: Thomas Gleixner 
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 

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

Re: [Xen-devel] [PATCH v4 2/4] xen/arm: gic: Check the size of the CPU and vCPU interface retrieved from DT

2015-10-23 Thread Ian Campbell

On Thu, 2015-10-08 at 19:23 +0100, Julien Grall wrote:
> The size of the CPU interface will used in a follow-up patch to map the

^be

> region in Xen memory.
> 
> Based on GICv2 spec, the CPU interface should at least be 8KB, although
> most of the platform we are supporting use incorrectly the GICv1 size
> (i.e 4KB) in their DT. Only warn and update the size to avoid any
> breakage on these platforms.
> 
> Furthermore, Xen is relying on the fact that the Virtual CPU interface
> been at least 8KB. As in reality the Virtual CPU interface matches the


  s/been/is/

> +/* TODO: Add check on distributor */
> +
> +/*
> + * The GICv2 CPU interface should at least be 8KB. Although, most of the 
> DT
> + * doesn't correctly set it and use the GICv1 CPU interface size (i.e 
> 4KB).

   don't

> +&vbase, &vsize);
>  if ( res )
>  return;
>  
> +/*
> + * We emulate a vGICv2 using a GIC CPU interface of GUEST_GICC_SIZE.
> + * So only support GICv2 on GICv3 when the virtuaL CPU interface is

s/L/l/

Apart from the typos:
Acked-by: Ian Campbell 



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

[Xen-devel] [xen-4.3-testing test] 63212: tolerable FAIL - PUSHED

2015-10-23 Thread osstest service owner

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail in 63151 pass 
in 63212
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
63151

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

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-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 63151 never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-amd64-i386-migrupgrade 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 xen  85ca813ec23c5a60680e4a13777dad530065902b
baseline version:
 xen  998424e33db121270690586320e899a03c88b4aa

Last test of basis62742  2015-10-09 07:58:29 Z   14 days
Failing since 63098  2015-10-20 17:42:44 Z2 days3 attempts
Testing same since63151  2015-10-21 15:41:31 Z1 days2 attempts


People who touched revisions under test:
  Anthony PERARD 
  George Dunlap 
  Ian Campbell 
  Ian Jackson 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev pass
 build-i386-prev  pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  fail
 test-amd64-i386-xl   pass
 test-amd64-i386-qemut-rhel6hvm-amd   pass
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64pass
 test-amd64-i386-xl-qemut-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-i386-freebsd10-amd64  pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64 fail
 test-amd64-i386-xl-qemuu-ovmf-amd64  fail
 test-amd64-amd64-rumpuserxen-amd64   blocked 
 test-amd64-amd64-xl-qemut-win7-amd64 fail
 test-amd64-i386-xl-qemut-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-win7-amd64

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

2015-10-23 Thread Fabio Fantoni


Il 23/10/2015 14:56, Ian Campbell ha scritto:

On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:

We have no existing stable baseline for that arch, and no testing or
reason to believe that cb9a7eb (the Config.mk version currently
referenced by 4.6) as being any good at all on that platform,
whether we backport a couple of fixes to it or not.

It is true that ovmf arm64 is not in osstest, but I ran the test
manually and I know that cb9a7eb plus the one backport works, which is
just a build fix. In addition the original work for arm64 support was
done far earlier than cb9a7eb.

20% of the patches since then are ARM related and I'm not sure that a quick
smoke test is a high enough bar to add something in a stable point release
(it might suffice for adding to the development branch and subsequently
releasing, after plenty of time and -rc's, test days etc)


I'm not convinced that taking some arbitrary old (although not as old
as I
thought) OVMF tree which we have tested to our satisfaction and
released on
x86, slapping a couple of arm64 backports on it and saying "this is now
a
good and stable thing to use on arm64" makes it good enough to release
as
ovmf arm64 in 4.6.1, encouraging our users to go about using etc.

Far better to be honest about it for now and point arm64 users at a
more
bleeding edge ovmf release outside of our own stable releases and
prepare
to do something better in 4.7.
  
Are you suggesting we don't create an OVMF branch for 4.6 until the

first backport request comes along which we think is appropriate, then
we decide what to do?  I would rather have an OVMF branch for 4.6 now,
even if it is just cb9a7eb with no backports.

I'm not against having an OVMF branch ready for any potential bug fixes
which might crop up in the feature set we released and in future we should
probably create one as a matter of course as part of branching.

What I don't like is adding OVMF/arm64 as a new feature in a point release
with very little of the usual confidence we would have in something we
would add in a 4.6.0, let alone a 4.6.1.

Ian.

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


A recent ovmf patch (already tested) I think is good to backport is:
0f34a051104e2b1b9123d56d48673de4b21bc533 - OvmfPkg: XenPvBlkDxe: handle 
empty cdrom drives
Can be considered please? Without any domU using ovmf and having empty 
cdrom (required for cd hotplug) freeze on boot start.


There is also another important occasional bug (reported and linked also 
by Stefano Stabellini) but without solution for now where is good 
backport any fixes related when will be done.


Thanks for any reply and sorry for my bad english.

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

Re: [Xen-devel] [PATCH 3/3] xl: convert cpupool related return codes to EXIT_[SUCCESS|FAILURE]

2015-10-23 Thread Harmandeep Kaur

On Fri, Oct 23, 2015 at 5:40 PM, Dario Faggioli 
wrote:

> >  int main_cpupooldestroy(int argc, char **argv)
> > @@ -7580,13 +7580,13 @@ int main_cpupooldestroy(int argc, char
> > **argv)
> >  if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid,
> > NULL) ||
> >  !libxl_cpupoolid_is_valid(ctx, poolid)) {
> >  fprintf(stderr, "unknown cpupool '%s'\n", pool);
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >
> >  if (libxl_cpupool_destroy(ctx, poolid))
> > -return 1;
> > +return EXIT_FAILURE;
> >
> > -return 0;
> > +return EXIT_SUCCESS;
> >  }
> >
> For this one: I've sent a patch for another reason yesterday, and while
> there I did the exit code adjustment myself. So, update your tree and,
> if my patch has been committed already, just skip this function.
>
>  https://www.mail-archive.com/xen-devel@lists.xen.org/msg42850.html
>
> Which brings up a question: what git tree are you using for
> development? You should stay either on master or staging branches (and
> I recommend staging) of the official repository:
>
>  http://wiki.xenproject.org/wiki/Xen_Project_Repositories


I was on master branch, now switching to staging.

Thank you so much for reviewing my patch and helping on this tight
timeline. And regarding your other questions (patch 1 and 2) I will be
answering as I digest all the information you just passed :)

Again, thank you Dario. I really appreciate your help.

Warmest Regards :)
Harman


> > @@ -7653,7 +7653,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
> >
> >  out:
> >  libxl_bitmap_dispose(&cpumap);
> > -return rc;
> > +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
> >
> Same as already said for main_cpupoolcreate, just us rc.
>
> > @@ -7691,7 +7691,7 @@ int main_cpupoolcpuremove(int argc, char
> > **argv)
> >
> >  out:
> >  libxl_bitmap_dispose(&cpumap);
> > -return rc;
> > +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
> >
> And here.
>
> >  int main_cpupoolnumasplit(int argc, char **argv)
> > @@ -7758,7 +7758,7 @@ int main_cpupoolnumasplit(int argc, char
> > **argv)
> >  poolinfo = libxl_list_cpupool(ctx, &n_pools);
> >  if (!poolinfo) {
> >  fprintf(stderr, "error getting cpupool info\n");
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >  poolid = poolinfo[0].poolid;
> >  sched = poolinfo[0].sched;
> > @@ -7766,13 +7766,13 @@ int main_cpupoolnumasplit(int argc, char
> > **argv)
> >
> >  if (n_pools > 1) {
> >  fprintf(stderr, "splitting not possible, already cpupools in
> > use\n");
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >
> >  topology = libxl_get_cpu_topology(ctx, &n_cpus);
> >  if (topology == NULL) {
> >  fprintf(stderr, "libxl_get_topologyinfo failed\n");
> > -return 1;
> > +return EXIT_FAILURE;
> >  }
> >
> >  if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
> > @@ -7869,7 +7869,7 @@ out:
> >  libxl_dominfo_dispose(&info);
> >  free(name);
> >
> > -return rc;
> > +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
> >  }
> >
> And here too.
>
> Thanks and regards,
> Dario
> --
> <> (Raistlin Majere)
> -
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH for-4.6] xen/public: arm: Use typeof rather than typeof

2015-10-23 Thread Julien Grall

Hi,

On 04/10/15 20:24, Julien Grall wrote:
> The keyword typeof is not portable:
> 
> /usr/src/freebsd/sys/xen/hypervisor.h:93:2: error: implicit declaration
> of function 'typeof' is invalid in C99
> [-Werror,-Wimplicit-function-declaration]

Ping? Aside the fact that other bits of the header may not be iso
compliant, I still think this patch is valid.

FWIW, it fixed build of the FreeBSD kernel for ARM64 with Xen enabled.

Regards,

-- 
Julien Grall

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

[Xen-devel] [PATCH 01/13] libxc: remove most of tools/libxc/xc_dom_compat_linux.c

2015-10-23 Thread Juergen Gross

In tools/libxc/xc_dom_compat_linux.c xc_linux_build() is the only
domain building function used by an in-tree component (qemu-xen) which
is really necessary.

Remove the other domain building functions and the unused python
wrapper xc.linux_build() referencing one of the to be removed
functions.

Suggested-by: Ian Campbell 
Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xc_dom.h  |   5 ++
 tools/libxc/include/xenguest.h|  48 -
 tools/libxc/xc_dom_compat_linux.c | 141 --
 tools/libxl/libxl_internal.h  |   1 +
 tools/python/xen/lowlevel/xc/xc.c |  98 --
 5 files changed, 36 insertions(+), 257 deletions(-)

diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
index ccc5926..6c15589 100644
--- a/tools/libxc/include/xc_dom.h
+++ b/tools/libxc/include/xc_dom.h
@@ -13,6 +13,9 @@
  * License along with this library; If not, see .
  */
 
+#ifndef _XC_DOM_H
+#define _XC_DOM_H
+
 #include 
 #include 
 
@@ -406,6 +409,8 @@ static inline xen_pfn_t xc_dom_p2m(struct xc_dom_image 
*dom, xen_pfn_t pfn)
 return dom->p2m_host[pfn - dom->rambase_pfn];
 }
 
+#endif /* _XC_DOM_H */
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index ec67fbd..a9fa32c 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -151,54 +151,6 @@ int xc_linux_build(xc_interface *xch,
unsigned int console_evtchn,
unsigned long *console_mfn);
 
-/** The same interface, but the dom structure is managed by the caller */
-struct xc_dom_image;
-int xc_dom_linux_build(xc_interface *xch,
-  struct xc_dom_image *dom,
-  uint32_t domid,
-  unsigned int mem_mb,
-  const char *image_name,
-  const char *ramdisk_name,
-  unsigned long flags,
-  unsigned int store_evtchn,
-  unsigned long *store_mfn,
-  unsigned int console_evtchn,
-  unsigned long *console_mfn);
-
-/**
- * This function will create a domain for a paravirtualized Linux
- * using buffers for kernel and initrd
- *
- * @parm xch a handle to an open hypervisor interface
- * @parm domid the id of the domain
- * @parm mem_mb memory size in megabytes
- * @parm image_buffer buffer containing kernel image
- * @parm image_size size of the kernel image buffer
- * @parm initrd_buffer name of the ramdisk image file
- * @parm initrd_size size of the ramdisk buffer
- * @parm cmdline command line string
- * @parm flags domain creation flags
- * @parm store_evtchn the store event channel for this domain to use
- * @parm store_mfn returned with the mfn of the store page
- * @parm console_evtchn the console event channel for this domain to use
- * @parm conole_mfn returned with the mfn of the console page
- * @return 0 on success, -1 on failure
- */
-int xc_linux_build_mem(xc_interface *xch,
-   uint32_t domid,
-   unsigned int mem_mb,
-   const char *image_buffer,
-   unsigned long image_size,
-   const char *initrd_buffer,
-   unsigned long initrd_size,
-   const char *cmdline,
-   const char *features,
-   unsigned long flags,
-   unsigned int store_evtchn,
-   unsigned long *store_mfn,
-   unsigned int console_evtchn,
-   unsigned long *console_mfn);
-
 struct xc_hvm_firmware_module {
 uint8_t  *data;
 uint32_t  length;
diff --git a/tools/libxc/xc_dom_compat_linux.c 
b/tools/libxc/xc_dom_compat_linux.c
index 5c1f043..20521cf 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -34,74 +34,26 @@
 
 /*  */
 
-static int xc_linux_build_internal(struct xc_dom_image *dom,
-   xc_interface *xch, uint32_t domid,
-   unsigned int mem_mb,
-   unsigned long flags,
-   unsigned int store_evtchn,
-   unsigned long *store_mfn,
-   unsigned int console_evtchn,
-   unsigned long *console_mfn)
-{
-int rc;
-
-dom->flags = flags;
-dom->console_evtchn = console_evtchn;
-dom->xenstore_evtchn = store_evtchn;
-
-if ( (rc = xc_dom_boot_xen_init(dom, xch, domid)) != 0 )
-goto out;
-if ( (rc = xc_dom_parse_image(dom)) != 0 )
-goto out;
-if ( (rc = xc_dom_mem_init(dom, mem_mb)) != 0 )
-goto out;
-if ( (rc = xc_dom_boot_m

[Xen-devel] [PATCH 09/13] python: remove domain handling related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of domain handling related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 358 --
 1 file changed, 358 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 02f1694..5146a2d 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -36,9 +36,6 @@ typedef struct {
 } XcObject;
 
 
-static PyObject *dom_op(XcObject *self, PyObject *args,
-int (*fn)(xc_interface *, uint32_t));
-
 static PyObject *pyxc_error_to_exception(xc_interface *xch)
 {
 PyObject *pyerr;
@@ -78,136 +75,6 @@ static PyObject *pyxc_error_to_exception(xc_interface *xch)
 return NULL;
 }
 
-static PyObject *pyxc_domain_dumpcore(XcObject *self, PyObject *args)
-{
-uint32_t dom;
-char *corefile;
-
-if ( !PyArg_ParseTuple(args, "is", &dom, &corefile) )
-return NULL;
-
-if ( (corefile == NULL) || (corefile[0] == '\0') )
-return NULL;
-
-if ( xc_domain_dumpcore(self->xc_handle, dom, corefile) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_create(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom = 0, ssidref = 0, flags = 0, target = 0;
-int  ret, i;
-PyObject *pyhandle = NULL;
-xen_domain_handle_t handle = { 
-0xde, 0xad, 0xbe, 0xef, 0xde, 0xad, 0xbe, 0xef,
-0xde, 0xad, 0xbe, 0xef, 0xde, 0xad, 0xbe, 0xef };
-
-static char *kwd_list[] = { "domid", "ssidref", "handle", "flags", 
"target", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iiOii", kwd_list,
-  &dom, &ssidref, &pyhandle, &flags, 
&target))
-return NULL;
-if ( pyhandle != NULL )
-{
-if ( !PyList_Check(pyhandle) || 
- (PyList_Size(pyhandle) != sizeof(xen_domain_handle_t)) )
-goto out_exception;
-
-for ( i = 0; i < sizeof(xen_domain_handle_t); i++ )
-{
-PyObject *p = PyList_GetItem(pyhandle, i);
-if ( !PyInt_Check(p) )
-goto out_exception;
-handle[i] = (uint8_t)PyInt_AsLong(p);
-}
-}
-
-if ( (ret = xc_domain_create(self->xc_handle, ssidref,
- handle, flags, &dom)) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-if ( target )
-if ( (ret = xc_domain_set_target(self->xc_handle, dom, target)) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-
-return PyInt_FromLong(dom);
-
-out_exception:
-errno = EINVAL;
-PyErr_SetFromErrno(xc_error_obj);
-return NULL;
-}
-
-static PyObject *pyxc_domain_max_vcpus(XcObject *self, PyObject *args)
-{
-uint32_t dom, max;
-
-if (!PyArg_ParseTuple(args, "ii", &dom, &max))
-  return NULL;
-
-if (xc_domain_max_vcpus(self->xc_handle, dom, max) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_pause(XcObject *self, PyObject *args)
-{
-return dom_op(self, args, xc_domain_pause);
-}
-
-static PyObject *pyxc_domain_unpause(XcObject *self, PyObject *args)
-{
-return dom_op(self, args, xc_domain_unpause);
-}
-
-static PyObject *pyxc_domain_destroy_hook(XcObject *self, PyObject *args)
-{
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_destroy(XcObject *self, PyObject *args)
-{
-return dom_op(self, args, xc_domain_destroy);
-}
-
-static PyObject *pyxc_domain_shutdown(XcObject *self, PyObject *args)
-{
-uint32_t dom, reason;
-
-if ( !PyArg_ParseTuple(args, "ii", &dom, &reason) )
-  return NULL;
-
-if ( xc_domain_shutdown(self->xc_handle, dom, reason) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_resume(XcObject *self, PyObject *args)
-{
-uint32_t dom;
-int fast;
-
-if ( !PyArg_ParseTuple(args, "ii", &dom, &fast) )
-return NULL;
-
-if ( xc_domain_resume(self->xc_handle, dom, fast) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
 static PyObject *pyxc_vcpu_setaffinity(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -259,42 +126,6 @@ static PyObject *pyxc_vcpu_setaffinity(XcObject *self,
 return zero;
 }
 
-static PyObject *pyxc_domain_sethandle(XcObject *self, PyObject *args)
-{
-int i;
-uint32_t dom;
-PyObject *pyhandle;
-xen_domain_handle_t handle;
-

[Xen-devel] [PATCH 03/13] python: remove flask related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any flask related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 238 --
 1 file changed, 238 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index d75f98c..c904627 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -20,8 +20,6 @@
 #include 
 #include 
 
-#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
-
 /* Needed for Python versions earlier than 2.3. */
 #ifndef PyMODINIT_FUNC
 #define PyMODINIT_FUNC DL_EXPORT(void)
@@ -30,8 +28,6 @@
 #define PKG "xen.lowlevel.xc"
 #define CLS "xc"
 
-#define FLASK_CTX_LEN 1024
-
 static PyObject *xc_error_obj, *zero;
 
 typedef struct {
@@ -1855,187 +1851,6 @@ static PyObject *pyxc_cpupool_freeinfo(XcObject *self)
 return info;
 }
 
-static PyObject *pyflask_context_to_sid(PyObject *self, PyObject *args,
- PyObject 
*kwds)
-{
-xc_interface *xc_handle;
-char *ctx;
-uint32_t sid;
-int ret;
-
-static char *kwd_list[] = { "context", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "s", kwd_list,
-  &ctx) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_context_to_sid(xc_handle, ctx, strlen(ctx), &sid);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return PyInt_FromLong(sid);
-}
-
-static PyObject *pyflask_sid_to_context(PyObject *self, PyObject *args,
- PyObject 
*kwds)
-{
-xc_interface *xc_handle;
-uint32_t sid;
-char ctx[FLASK_CTX_LEN];
-uint32_t ctx_len = FLASK_CTX_LEN;
-int ret;
-
-static char *kwd_list[] = { "sid", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list,
-  &sid) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_sid_to_context(xc_handle, sid, ctx, ctx_len);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("s", ctx, ctx_len);
-}
-
-static PyObject *pyflask_load(PyObject *self, PyObject *args, PyObject *kwds)
-{
-xc_interface *xc_handle;
-char *policy;
-uint32_t len;
-int ret;
-
-static char *kwd_list[] = { "policy", NULL };
-  
-if( !PyArg_ParseTupleAndKeywords(args, kwds, "s#", kwd_list, &policy, 
&len) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_load(xc_handle, policy, len);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("i", ret);
-}
-
-static PyObject *pyflask_getenforce(PyObject *self)
-{
-xc_interface *xc_handle;
-int ret;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_getenforce(xc_handle);
-
-xc_interface_close(xc_handle);
-
-if ( ret < 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("i", ret);
-}
-
-static PyObject *pyflask_setenforce(PyObject *self, PyObject *args,
-PyObject *kwds)
-{
-xc_interface *xc_handle;
-int mode;
-int ret;
-
-static char *kwd_list[] = { "mode", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list,
-  &mode) )
-return NULL;
-
-xc_handle = xc_interface_open(0,0,0);
-if (!xc_handle) {
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-ret = xc_flask_setenforce(xc_handle, mode);
-
-xc_interface_close(xc_handle);
-
-if ( ret != 0 ) {
-errno = -ret;
-return PyErr_SetFromErrno(xc_error_obj);
-}
-
-return Py_BuildValue("i", ret);
-}
-
-static PyObject *pyflask_access(PyObject *self, PyObject *args,
-   PyObject *kwds)
-{
-xc_interface *xc_handle;
-char *tcon, *scon;
-uint16_t tclass;
-uint32_t req, allowed, decided, auditallow, auditdeny, seqno;
-int ret;
-
-static char *kwd_list[] = { "src_context", "tar_context", 
-

[Xen-devel] [PATCH 04/13] python: remove cpupool related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any cpupool related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 224 --
 1 file changed, 224 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index c904627..9d82579 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1682,175 +1682,6 @@ static PyObject *pyxc_dom_set_memshr(XcObject *self, 
PyObject *args)
 return zero;
 }
 
-static PyObject *cpumap_to_cpulist(XcObject *self, xc_cpumap_t cpumap)
-{
-PyObject *cpulist = NULL;
-int i;
-int nr_cpus;
-
-nr_cpus = xc_get_max_cpus(self->xc_handle);
-if ( nr_cpus < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-cpulist = PyList_New(0);
-for ( i = 0; i < nr_cpus; i++ )
-{
-if ( *cpumap & (1 << (i % 8)) )
-{
-PyObject* pyint = PyInt_FromLong(i);
-
-PyList_Append(cpulist, pyint);
-Py_DECREF(pyint);
-}
-if ( (i % 8) == 7 )
-cpumap++;
-}
-return cpulist;
-}
-
-static PyObject *pyxc_cpupool_create(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t cpupool = 0, sched = XEN_SCHEDULER_CREDIT;
-
-static char *kwd_list[] = { "pool", "sched", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|ii", kwd_list, &cpupool,
-  &sched))
-return NULL;
-
-if ( xc_cpupool_create(self->xc_handle, &cpupool, sched) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return PyInt_FromLong(cpupool);
-}
-
-static PyObject *pyxc_cpupool_destroy(XcObject *self,
-  PyObject *args)
-{
-uint32_t cpupool;
-
-if (!PyArg_ParseTuple(args, "i", &cpupool))
-return NULL;
-
-if (xc_cpupool_destroy(self->xc_handle, cpupool) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_getinfo(XcObject *self)
-{
-PyObject *list, *info_dict;
-
-uint32_t pool;
-xc_cpupoolinfo_t *info;
-
-list = PyList_New(0);
-for (pool = 0;;)
-{
-info = xc_cpupool_getinfo(self->xc_handle, pool);
-if (info == NULL)
-break;
-info_dict = Py_BuildValue(
-"{s:i,s:i,s:i,s:N}",
-"cpupool", (int)info->cpupool_id,
-"sched",   info->sched_id,
-"n_dom",   info->n_dom,
-"cpulist", cpumap_to_cpulist(self, info->cpumap));
-pool = info->cpupool_id + 1;
-xc_cpupool_infofree(self->xc_handle, info);
-
-if ( info_dict == NULL )
-{
-Py_DECREF(list);
-return NULL;
-}
-
-PyList_Append(list, info_dict);
-Py_DECREF(info_dict);
-}
-
-return list;
-}
-
-static PyObject *pyxc_cpupool_addcpu(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t cpupool;
-int cpu = -1;
-
-static char *kwd_list[] = { "cpupool", "cpu", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list,
-  &cpupool, &cpu) )
-return NULL;
-
-if (xc_cpupool_addcpu(self->xc_handle, cpupool, cpu) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_removecpu(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t cpupool;
-int cpu = -1;
-
-static char *kwd_list[] = { "cpupool", "cpu", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list,
-  &cpupool, &cpu) )
-return NULL;
-
-if (xc_cpupool_removecpu(self->xc_handle, cpupool, cpu) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_movedomain(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t cpupool, domid;
-
-static char *kwd_list[] = { "cpupool", "domid", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ii", kwd_list,
-  &cpupool, &domid) )
-return NULL;
-
-if (xc_cpupool_movedomain(self->xc_handle, cpupool, domid) != 0)
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_cpupool_freeinfo(XcObje

[Xen-devel] [PATCH 05/13] python: remove cpuid related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any cpuid related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 128 --
 1 file changed, 128 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 9d82579..7809fc6 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -658,105 +658,6 @@ static PyObject *pyxc_get_device_group(XcObject *self,
 }
 
 #if defined(__i386__) || defined(__x86_64__)
-static void pyxc_dom_extract_cpuid(PyObject *config,
-  char **regs)
-{
-const char *regs_extract[4] = { "eax", "ebx", "ecx", "edx" };
-PyObject *obj;
-int i;
-
-memset(regs, 0, 4*sizeof(*regs));
-
-if ( !PyDict_Check(config) )
-return;
-
-for ( i = 0; i < 4; i++ )
-if ( (obj = PyDict_GetItemString(config, regs_extract[i])) != NULL )
-regs[i] = PyString_AS_STRING(obj);
-}
-
-static PyObject *pyxc_create_cpuid_dict(char **regs)
-{
-   const char *regs_extract[4] = { "eax", "ebx", "ecx", "edx" };
-   PyObject *dict;
-   int i;
-
-   dict = PyDict_New();
-   for ( i = 0; i < 4; i++ )
-   {
-   if ( regs[i] == NULL )
-   continue;
-   PyDict_SetItemString(dict, regs_extract[i],
-PyString_FromString(regs[i]));
-   free(regs[i]);
-   regs[i] = NULL;
-   }
-   return dict;
-}
-
-static PyObject *pyxc_dom_check_cpuid(XcObject *self,
-  PyObject *args)
-{
-PyObject *sub_input, *config;
-unsigned int input[2];
-char *regs[4], *regs_transform[4];
-
-if ( !PyArg_ParseTuple(args, "iOO", &input[0], &sub_input, &config) )
-return NULL;
-
-pyxc_dom_extract_cpuid(config, regs);
-
-input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( PyLong_Check(sub_input) )
-input[1] = PyLong_AsUnsignedLong(sub_input);
-
-if ( xc_cpuid_check(self->xc_handle, input,
-(const char **)regs, regs_transform) )
-return pyxc_error_to_exception(self->xc_handle);
-
-return pyxc_create_cpuid_dict(regs_transform);
-}
-
-static PyObject *pyxc_dom_set_policy_cpuid(XcObject *self,
-   PyObject *args)
-{
-int domid;
-
-if ( !PyArg_ParseTuple(args, "i", &domid) )
-return NULL;
-
-if ( xc_cpuid_apply_policy(self->xc_handle, domid) )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-
-static PyObject *pyxc_dom_set_cpuid(XcObject *self,
-PyObject *args)
-{
-PyObject *sub_input, *config;
-unsigned int domid, input[2];
-char *regs[4], *regs_transform[4];
-
-if ( !PyArg_ParseTuple(args, "IIOO", &domid,
-   &input[0], &sub_input, &config) )
-return NULL;
-
-pyxc_dom_extract_cpuid(config, regs);
-
-input[1] = XEN_CPUID_INPUT_UNUSED;
-if ( PyLong_Check(sub_input) )
-input[1] = PyLong_AsUnsignedLong(sub_input);
-
-if ( xc_cpuid_set(self->xc_handle, domid, input, (const char **)regs,
-  regs_transform) )
-return pyxc_error_to_exception(self->xc_handle);
-
-return pyxc_create_cpuid_dict(regs_transform);
-}
-
 static PyObject *pyxc_dom_set_machine_address_size(XcObject *self,
   PyObject *args,
   PyObject *kwds)
@@ -2103,35 +2004,6 @@ static PyMethodDef pyxc_methods[] = {
   " keys[str]: String of keys to inject.\n" },
 
 #if defined(__i386__) || defined(__x86_64__)
-{ "domain_check_cpuid", 
-  (PyCFunction)pyxc_dom_check_cpuid, 
-  METH_VARARGS, "\n"
-  "Apply checks to host CPUID.\n"
-  " input [long]: Input for cpuid instruction (eax)\n"
-  " sub_input [long]: Second input (optional, may be None) for cpuid "
-  " instruction (ecx)\n"
-  " config [dict]: Dictionary of register\n"
-  " config [dict]: Dictionary of register, use for checking\n\n"
-  "Returns: [int] 0 on success; exception on error.\n" },
-
-{ "domain_set_cpuid", 
-  (PyCFunction)pyxc_dom_set_cpuid, 
-  METH_VARARGS, "\n"
-  "Set cpuid response for an input and a domain.\n"
-  " dom [int]: Identifier of domain.\n"
-  " input [long]: Input for cpuid instruction (eax)\n"
-  " sub_input [long]: Second input (optional, may be None) for cpuid "
-  " instruction (ecx)\n"
-  " config [dict]: Dictionary of register\n\n"
-  "Returns: [int] 0 on success; exception on error.\n" },
-
-{ "domain_set_policy_cpuid", 
-  (PyCFunction)pyxc_dom_set_policy_cpuid, 
-  METH_VARARGS, "\n"
-  "Set the default cpuid policy for a domain.\

[Xen-devel] [PATCH 08/13] python: remove unused memory related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of most memory related python binding left. Remove them.
Especially xc.domain_set_target_mem() and xc.domain_setmaxmem() will
not be removed as there are some out of tree users.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 92 ---
 1 file changed, 92 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 6c4ad18..02f1694 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -953,59 +953,6 @@ static PyObject *pyxc_xeninfo(XcObject *self)
  "cc_compile_date", xen_cc.compile_date);
 }
 
-static PyObject *pyxc_shadow_control(PyObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-
-uint32_t dom;
-int op=0;
-
-static char *kwd_list[] = { "dom", "op", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list, 
-  &dom, &op) )
-return NULL;
-
-if ( xc_shadow_control(xc->xc_handle, dom, op, NULL, 0, NULL, 0, NULL) 
- < 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_shadow_mem_control(PyObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-int op;
-uint32_t dom;
-int mbarg = -1;
-unsigned long mb;
-
-static char *kwd_list[] = { "dom", "mb", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list, 
-  &dom, &mbarg) )
-return NULL;
-
-if ( mbarg < 0 ) 
-op = XEN_DOMCTL_SHADOW_OP_GET_ALLOCATION;
-else 
-{
-mb = mbarg;
-op = XEN_DOMCTL_SHADOW_OP_SET_ALLOCATION;
-}
-if ( xc_shadow_control(xc->xc_handle, dom, op, NULL, 0, &mb, 0, NULL) < 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-mbarg = mb;
-return Py_BuildValue("i", mbarg);
-}
-
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
 uint32_t dom;
@@ -1039,21 +986,6 @@ static PyObject *pyxc_domain_set_target_mem(XcObject 
*self, PyObject *args)
 return zero;
 }
 
-static PyObject *pyxc_domain_set_memmap_limit(XcObject *self, PyObject *args)
-{
-uint32_t dom;
-unsigned int maplimit_kb;
-
-if ( !PyArg_ParseTuple(args, "ii", &dom, &maplimit_kb) )
-return NULL;
-
-if ( xc_domain_set_memmap_limit(self->xc_handle, dom, maplimit_kb) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
 static PyObject *pyxc_domain_ioport_permission(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -1530,22 +1462,6 @@ static PyMethodDef pyxc_methods[] = {
   "Returns [dict]: information about Xen"
   "[None]: on failure.\n" },
 
-{ "shadow_control", 
-  (PyCFunction)pyxc_shadow_control, 
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Set parameter for shadow pagetable interface\n"
-  " dom [int]:   Identifier of domain.\n"
-  " op [int, 0]: operation\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "shadow_mem_control", 
-  (PyCFunction)pyxc_shadow_mem_control, 
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Set or read shadow pagetable memory use\n"
-  " dom [int]:   Identifier of domain.\n"
-  " mb [int, -1]: MB of shadow memory this domain should have.\n\n"
-  "Returns: [int] MB of shadow memory in use by this domain.\n" },
-
 { "domain_setmaxmem", 
   (PyCFunction)pyxc_domain_setmaxmem, 
   METH_VARARGS, "\n"
@@ -1562,14 +1478,6 @@ static PyMethodDef pyxc_methods[] = {
   " mem_kb [int]: .\n"
   "Returns: [int] 0 on success; -1 on error.\n" },
 
-{ "domain_set_memmap_limit", 
-  (PyCFunction)pyxc_domain_set_memmap_limit, 
-  METH_VARARGS, "\n"
-  "Set a domain's physical memory mappping limit\n"
-  " dom [int]: Identifier of domain.\n"
-  " map_limitkb [int]: .\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
 { "domain_ioport_permission",
   (PyCFunction)pyxc_domain_ioport_permission,
   METH_VARARGS | METH_KEYWORDS, "\n"
-- 
2.1.4


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

[Xen-devel] [PATCH 11/13] python: remove hvm related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of hvm related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 92 ---
 1 file changed, 92 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 5fcee3f..c88386f 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -146,70 +146,6 @@ static PyObject *pyxc_domain_getinfo(XcObject *self,
 return list;
 }
 
-static PyObject *pyxc_hvm_param_get(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-int param;
-uint64_t value;
-
-static char *kwd_list[] = { "domid", "param", NULL }; 
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ii", kwd_list,
-  &dom, ¶m) )
-return NULL;
-
-if ( xc_hvm_param_get(self->xc_handle, dom, param, &value) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return PyLong_FromUnsignedLongLong(value);
-
-}
-
-static PyObject *pyxc_hvm_param_set(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-int param;
-uint64_t value;
-
-static char *kwd_list[] = { "domid", "param", "value", NULL }; 
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iiL", kwd_list,
-  &dom, ¶m, &value) )
-return NULL;
-
-if ( xc_hvm_param_set(self->xc_handle, dom, param, value) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_gnttab_hvm_seed(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t dom, console_domid, xenstore_domid;
-unsigned long xenstore_gmfn = 0;
-unsigned long console_gmfn = 0;
-static char *kwd_list[] = { "domid",
-   "console_gmfn", "xenstore_gmfn",
-   "console_domid", "xenstore_domid", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list,
-  &dom,
- &console_gmfn, &xenstore_gmfn,
- &console_domid, &xenstore_domid) )
-return NULL;
-
-if ( xc_dom_gnttab_hvm_seed(self->xc_handle, dom,
-   console_gmfn, xenstore_gmfn,
-   console_domid, xenstore_domid) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return Py_None;
-}
-
 static PyObject *pyxc_evtchn_alloc_unbound(XcObject *self,
PyObject *args,
PyObject *kwds)
@@ -897,34 +833,6 @@ static PyMethodDef pyxc_methods[] = {
   "reason why it shut itself down.\n"
   " cpupool  [int]   Id of cpupool domain is bound to.\n" },
 
-{ "gnttab_hvm_seed",
-  (PyCFunction)pyxc_gnttab_hvm_seed,
-  METH_KEYWORDS, "\n"
-  "Initialise HVM guest grant table.\n"
-  " dom [int]:  Identifier of domain to build into.\n"
-  " console_gmfn [int]: \n"
-  " xenstore_gmfn [int]: \n"
-  " console_domid [int]: \n"
-  " xenstore_domid [int]: \n"
-  "Returns: None on sucess. Raises exception on error.\n" },
-
-{ "hvm_get_param", 
-  (PyCFunction)pyxc_hvm_param_get,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "get a parameter of HVM guest OS.\n"
-  " dom [int]:  Identifier of domain to build into.\n"
-  " param   [int]:  No. of HVM param.\n"
-  "Returns: [long] value of the param.\n" },
-
-{ "hvm_set_param", 
-  (PyCFunction)pyxc_hvm_param_set,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "set a parameter of HVM guest OS.\n"
-  " dom [int]:  Identifier of domain to build into.\n"
-  " param   [int]:  No. of HVM param.\n"
-  " value   [long]: Value of param.\n"
-  "Returns: [int] 0 on success.\n" },
-
 { "evtchn_alloc_unbound", 
   (PyCFunction)pyxc_evtchn_alloc_unbound,
   METH_VARARGS | METH_KEYWORDS, "\n"
-- 
2.1.4


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

[Xen-devel] [PATCH 07/13] python: remove scheduler related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any scheduler related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 133 --
 1 file changed, 133 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index e0f1d7f..6c4ad18 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1006,97 +1006,6 @@ static PyObject *pyxc_shadow_mem_control(PyObject *self,
 return Py_BuildValue("i", mbarg);
 }
 
-static PyObject *pyxc_sched_id_get(XcObject *self) {
-
-int sched_id;
-if (xc_sched_id(self->xc_handle, &sched_id) != 0)
-return PyErr_SetFromErrno(xc_error_obj);
-
-return Py_BuildValue("i", sched_id);
-}
-
-static PyObject *pyxc_sched_credit_domain_set(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-uint32_t domid;
-uint16_t weight;
-uint16_t cap;
-static char *kwd_list[] = { "domid", "weight", "cap", NULL };
-static char kwd_type[] = "I|HH";
-struct xen_domctl_sched_credit sdom;
-
-weight = 0;
-cap = (uint16_t)~0U;
-if( !PyArg_ParseTupleAndKeywords(args, kwds, kwd_type, kwd_list, 
- &domid, &weight, &cap) )
-return NULL;
-
-sdom.weight = weight;
-sdom.cap = cap;
-
-if ( xc_sched_credit_domain_set(self->xc_handle, domid, &sdom) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_sched_credit_domain_get(XcObject *self, PyObject *args)
-{
-uint32_t domid;
-struct xen_domctl_sched_credit sdom;
-
-if( !PyArg_ParseTuple(args, "I", &domid) )
-return NULL;
-
-if ( xc_sched_credit_domain_get(self->xc_handle, domid, &sdom) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return Py_BuildValue("{s:H,s:H}",
- "weight",  sdom.weight,
- "cap", sdom.cap);
-}
-
-static PyObject *pyxc_sched_credit2_domain_set(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-uint32_t domid;
-uint16_t weight;
-static char *kwd_list[] = { "domid", "weight", NULL };
-static char kwd_type[] = "I|H";
-struct xen_domctl_sched_credit2 sdom;
-
-weight = 0;
-if( !PyArg_ParseTupleAndKeywords(args, kwds, kwd_type, kwd_list,
- &domid, &weight) )
-return NULL;
-
-sdom.weight = weight;
-
-if ( xc_sched_credit2_domain_set(self->xc_handle, domid, &sdom) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_sched_credit2_domain_get(XcObject *self, PyObject *args)
-{
-uint32_t domid;
-struct xen_domctl_sched_credit2 sdom;
-
-if( !PyArg_ParseTuple(args, "I", &domid) )
-return NULL;
-
-if ( xc_sched_credit2_domain_get(self->xc_handle, domid, &sdom) != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return Py_BuildValue("{s:H}",
- "weight",  sdom.weight);
-}
-
 static PyObject *pyxc_domain_setmaxmem(XcObject *self, PyObject *args)
 {
 uint32_t dom;
@@ -1545,48 +1454,6 @@ static PyMethodDef pyxc_methods[] = {
   " value   [long]: Value of param.\n"
   "Returns: [int] 0 on success.\n" },
 
-{ "sched_id_get",
-  (PyCFunction)pyxc_sched_id_get,
-  METH_NOARGS, "\n"
-  "Get the current scheduler type in use.\n"
-  "Returns: [int] sched_id.\n" },
-
-{ "sched_credit_domain_set",
-  (PyCFunction)pyxc_sched_credit_domain_set,
-  METH_KEYWORDS, "\n"
-  "Set the scheduling parameters for a domain when running with the\n"
-  "SMP credit scheduler.\n"
-  " domid [int]:   domain id to set\n"
-  " weight[short]: domain's scheduling weight\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "sched_credit_domain_get",
-  (PyCFunction)pyxc_sched_credit_domain_get,
-  METH_VARARGS, "\n"
-  "Get the scheduling parameters for a domain when running with the\n"
-  "SMP credit scheduler.\n"
-  " domid [int]:   domain id to get\n"
-  "Returns:   [dict]\n"
-  " weight[short]: domain's scheduling weight\n"},
-
-{ "sched_credit2_domain_set",
-  (PyCFunction)pyxc_sched_credit2_domain_set,
-  METH_KEYWORDS, "\n"
-  "Set the scheduling parameters for a domain when running with the\n"
-  "SMP credit2 scheduler.\n"
-  " domid [int]:   domain id to set\n"
-  " weight[short]: domain's scheduling weight\n"
-  "Returns: [int] 0 on success; -1 on error.

[Xen-devel] [PATCH 02/13] libxc: remove xc_get_bit_size() from tools/libxc/xc_dom_compat_linux.c

2015-10-23 Thread Juergen Gross

xc_get_bit_size() is being used by the unused python wrapper
xc.getBitSize() only. Remove the wrapper and xc_get_bit_size().

Signed-off-by: Juergen Gross 
---
 tools/libxc/include/xenguest.h|  4 
 tools/libxc/xc_dom_compat_linux.c | 25 -
 tools/python/xen/lowlevel/xc/xc.c | 28 
 3 files changed, 57 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index a9fa32c..8f918b1 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -184,10 +184,6 @@ int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, 
int suspend_evtchn);
 int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce,
 int domid, int port, int *lockfd);
 
-int xc_get_bit_size(xc_interface *xch,
-const char *image_name, const char *cmdline,
-const char *features, int *type);
-
 int xc_mark_page_online(xc_interface *xch, unsigned long start,
 unsigned long end, uint32_t *status);
 
diff --git a/tools/libxc/xc_dom_compat_linux.c 
b/tools/libxc/xc_dom_compat_linux.c
index 20521cf..abbc09f 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -34,31 +34,6 @@
 
 /*  */
 
-int xc_get_bit_size(xc_interface *xch,
-const char *image_name, const char *cmdline,
-const char *features, int *bit_size)
-{
-struct xc_dom_image *dom;
-int rc;
-*bit_size = 0;
-dom = xc_dom_allocate(xch, cmdline, features);
-if (dom == NULL)
-return -1;
-if ( (rc = xc_dom_kernel_file(dom, image_name)) != 0 )
-goto out;
-if ( (rc = xc_dom_parse_image(dom)) != 0 )
-goto out;
-if( dom->guest_type != NULL){
-if(strstr(dom->guest_type, "x86_64") != NULL)
-*bit_size = X86_64_B_SIZE; //64bit Guest
-if(strstr(dom->guest_type, "x86_32") != NULL)
-*bit_size = X86_32_B_SIZE; //32bit Guest
-}
- out:
-xc_dom_release(dom);
-return rc;
-}
-
 int xc_linux_build(xc_interface *xch, uint32_t domid,
unsigned int mem_mb,
const char *image_name,
diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 94f0a13..d75f98c 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -6,7 +6,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -431,26 +430,6 @@ static PyObject *pyxc_vcpu_getinfo(XcObject *self,
 return info_dict;
 }
 
-static PyObject *pyxc_getBitSize(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-PyObject *info_type;
-char *image = NULL, *cmdline = "", *features = NULL;
-int type = 0;
-static char *kwd_list[] = { "image", "cmdline", "features", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "sss", kwd_list,
-  &image, &cmdline, &features) )
-return NULL;
-
-xc_get_bit_size(self->xc_handle, image, cmdline, features, &type);
-if (type < 0)
-return pyxc_error_to_exception(self->xc_handle);
-info_type = Py_BuildValue("{s:i}",
-  "type", type);
-return info_type;
-}
-
 static PyObject *pyxc_hvm_param_get(XcObject *self,
 PyObject *args,
 PyObject *kwds)
@@ -2182,13 +2161,6 @@ static PyMethodDef pyxc_methods[] = {
   " cpumap   [int]:  Bitmap of CPUs this VCPU can run on\n"
   " cpu  [int]:  CPU that this VCPU is currently bound to\n" },
 
-{"getBitSize",
-  (PyCFunction)pyxc_getBitSize,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Get the bitsize of a guest OS.\n"
-  " image   [str]:  Name of kernel image file. May be gzipped.\n"
-  " cmdline [str, n/a]: Kernel parameters, if any.\n\n"},
-
 { "gnttab_hvm_seed",
   (PyCFunction)pyxc_gnttab_hvm_seed,
   METH_KEYWORDS, "\n"
-- 
2.1.4


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

[Xen-devel] [PATCH 13/13] python: remove unused other libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there are
only some few python bindings in use, most of the in out of tree
tools. Remove all unused libxc python bindings.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 484 --
 1 file changed, 484 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 5039f94..5d79b14 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -146,148 +146,11 @@ static PyObject *pyxc_domain_getinfo(XcObject *self,
 return list;
 }
 
-static PyObject *pyxc_evtchn_alloc_unbound(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom, remote_dom;
-int port;
-
-static char *kwd_list[] = { "domid", "remote_dom", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "ii", kwd_list,
-  &dom, &remote_dom) )
-return NULL;
-
-if ( (port = xc_evtchn_alloc_unbound(self->xc_handle, dom, remote_dom)) < 
0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-return PyInt_FromLong(port);
-}
-
-static PyObject *pyxc_evtchn_reset(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom;
-
-static char *kwd_list[] = { "dom", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list, &dom) )
-return NULL;
-
-if ( xc_evtchn_reset(self->xc_handle, dom) < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_physdev_map_pirq(PyObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-uint32_t dom;
-int index, pirq, ret;
-
-static char *kwd_list[] = {"domid", "index", "pirq", NULL};
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iii", kwd_list,
-  &dom, &index, &pirq) )
-return NULL;
-ret = xc_physdev_map_pirq(xc->xc_handle, dom, index, &pirq);
-if ( ret != 0 )
-  return pyxc_error_to_exception(xc->xc_handle);
-return PyLong_FromUnsignedLong(pirq);
-}
-
-static PyObject *pyxc_physdev_pci_access_modify(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-int bus, dev, func, enable, ret;
-
-static char *kwd_list[] = { "domid", "bus", "dev", "func", "enable", NULL 
};
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i", kwd_list, 
-  &dom, &bus, &dev, &func, &enable) )
-return NULL;
-
-ret = xc_physdev_pci_access_modify(
-self->xc_handle, dom, bus, dev, func, enable);
-if ( ret != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_readconsolering(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-unsigned int clear = 0, index = 0, incremental = 0;
-unsigned int count = 16384 + 1, size = count;
-char*str, *ptr;
-PyObject*obj;
-int  ret;
-
-static char *kwd_list[] = { "clear", "index", "incremental", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "|iii", kwd_list,
-  &clear, &index, &incremental) ||
- !(str = malloc(size)) )
-return NULL;
-
-ret = xc_readconsolering(self->xc_handle, str, &count, clear,
- incremental, &index);
-if ( ret < 0 ) {
-free(str);
-return pyxc_error_to_exception(self->xc_handle);
-}
-
-while ( !incremental && count == size && ret >= 0 )
-{
-size += count - 1;
-if ( size < count )
-break;
-
-ptr = realloc(str, size);
-if ( !ptr )
-break;
-
-str = ptr + count;
-count = size - count;
-ret = xc_readconsolering(self->xc_handle, str, &count, clear,
- 1, &index);
-count += str - ptr;
-str = ptr;
-}
-
-obj = PyString_FromStringAndSize(str, count);
-free(str);
-return obj;
-}
-
-
 static unsigned long pages_to_kib(unsigned long pages)
 {
 return pages * (XC_PAGE_SIZE / 1024);
 }
 
-
-static PyObject *pyxc_pages_to_kib(XcObject *self, PyObject *args)
-{
-unsigned long pages;
-
-if (!PyArg_ParseTuple(args, "l", &pages))
-return NULL;
-
-return PyLong_FromUnsignedLong(pages_to_kib(pages));
-}
-
 static PyObject *pyxc_physinfo(XcObject

[Xen-devel] [PATCH 06/13] python: remove device related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of any device related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 226 --
 1 file changed, 226 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 7809fc6..e0f1d7f 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -466,197 +466,6 @@ static PyObject *pyxc_hvm_param_set(XcObject *self,
 return zero;
 }
 
-static int token_value(char *token)
-{
-token = strchr(token, 'x') + 1;
-return strtol(token, NULL, 16);
-}
-
-static int next_bdf(char **str, int *seg, int *bus, int *dev, int *func)
-{
-char *token;
-
-if ( !(*str) || !strchr(*str, ',') )
-return 0;
-
-token = *str;
-*seg  = token_value(token);
-token = strchr(token, ',') + 1;
-*bus  = token_value(token);
-token = strchr(token, ',') + 1;
-*dev  = token_value(token);
-token = strchr(token, ',') + 1;
-*func  = token_value(token);
-token = strchr(token, ',');
-*str = token ? token + 1 : NULL;
-
-return 1;
-}
-
-static PyObject *pyxc_test_assign_device(XcObject *self,
- PyObject *args,
- PyObject *kwds)
-{
-uint32_t dom;
-char *pci_str;
-int32_t sbdf = 0;
-int seg, bus, dev, func;
-
-static char *kwd_list[] = { "domid", "pci", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
-  &dom, &pci_str) )
-return NULL;
-
-while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) )
-{
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-if ( xc_test_assign_device(self->xc_handle, dom, sbdf) != 0 )
-{
-if (errno == ENOSYS)
-sbdf = -1;
-break;
-}
-sbdf = 0;
-}
-
-return Py_BuildValue("i", sbdf);
-}
-
-static PyObject *pyxc_assign_device(XcObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-uint32_t dom;
-char *pci_str;
-int32_t sbdf = 0;
-int seg, bus, dev, func;
-
-static char *kwd_list[] = { "domid", "pci", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
-  &dom, &pci_str) )
-return NULL;
-
-while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) )
-{
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-if ( xc_assign_device(self->xc_handle, dom, sbdf, 0) != 0 )
-{
-if (errno == ENOSYS)
-sbdf = -1;
-break;
-}
-sbdf = 0;
-}
-
-return Py_BuildValue("i", sbdf);
-}
-
-static PyObject *pyxc_deassign_device(XcObject *self,
-  PyObject *args,
-  PyObject *kwds)
-{
-uint32_t dom;
-char *pci_str;
-int32_t sbdf = 0;
-int seg, bus, dev, func;
-
-static char *kwd_list[] = { "domid", "pci", NULL };
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "is", kwd_list,
-  &dom, &pci_str) )
-return NULL;
-
-while ( next_bdf(&pci_str, &seg, &bus, &dev, &func) )
-{
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-if ( xc_deassign_device(self->xc_handle, dom, sbdf) != 0 )
-{
-if (errno == ENOSYS)
-sbdf = -1;
-break;
-}
-sbdf = 0;
-}
-
-return Py_BuildValue("i", sbdf);
-}
-
-static PyObject *pyxc_get_device_group(XcObject *self,
- PyObject *args)
-{
-uint32_t sbdf;
-uint32_t max_sdevs, num_sdevs;
-int domid, seg, bus, dev, func, rc, i;
-PyObject *Pystr;
-char *group_str;
-char dev_str[9];
-uint32_t *sdev_array;
-
-if ( !PyArg_ParseTuple(args, "i", &domid, &seg, &bus, &dev, &func) )
-return NULL;
-
-/* Maximum allowed siblings device number per group */
-max_sdevs = 1024;
-
-sdev_array = calloc(max_sdevs, sizeof(*sdev_array));
-if (sdev_array == NULL)
-return PyErr_NoMemory();
-
-sbdf = seg << 16;
-sbdf |= (bus & 0xff) << 8;
-sbdf |= (dev & 0x1f) << 3;
-sbdf |= (func & 0x7);
-
-rc = xc_get_device_group(self->xc_handle,
-domid, sbdf, max_sdevs, &num_sdevs, sdev_array);
-
-if ( rc < 0 )
-{
-free(sdev_array); 
-return pyxc_error_to_exception(self->xc_handle);
-}
-
-if ( !num_sdevs )
-

[Xen-devel] [PATCH 10/13] python: remove vcpu related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of vcpu related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 134 --
 1 file changed, 134 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index 5146a2d..5fcee3f 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -75,57 +75,6 @@ static PyObject *pyxc_error_to_exception(xc_interface *xch)
 return NULL;
 }
 
-static PyObject *pyxc_vcpu_setaffinity(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom;
-int vcpu = 0, i;
-xc_cpumap_t cpumap;
-PyObject *cpulist = NULL;
-int nr_cpus;
-
-static char *kwd_list[] = { "domid", "vcpu", "cpumap", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|iO", kwd_list, 
-  &dom, &vcpu, &cpulist) )
-return NULL;
-
-nr_cpus = xc_get_max_cpus(self->xc_handle);
-if ( nr_cpus < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-cpumap = xc_cpumap_alloc(self->xc_handle);
-if(cpumap == NULL)
-return pyxc_error_to_exception(self->xc_handle);
-
-if ( (cpulist != NULL) && PyList_Check(cpulist) )
-{
-for ( i = 0; i < PyList_Size(cpulist); i++ ) 
-{
-long cpu = PyInt_AsLong(PyList_GetItem(cpulist, i));
-if ( cpu < 0 || cpu >= nr_cpus )
-{
-free(cpumap);
-errno = EINVAL;
-PyErr_SetFromErrno(xc_error_obj);
-return NULL;
-}
-cpumap[cpu / 8] |= 1 << (cpu % 8);
-}
-}
-  
-if ( xc_vcpu_setaffinity(self->xc_handle, dom, vcpu, cpumap,
- NULL, XEN_VCPUAFFINITY_HARD) != 0 )
-{
-free(cpumap);
-return pyxc_error_to_exception(self->xc_handle);
-}
-Py_INCREF(zero);
-free(cpumap); 
-return zero;
-}
-
 static PyObject *pyxc_domain_getinfo(XcObject *self,
  PyObject *args,
  PyObject *kwds)
@@ -197,66 +146,6 @@ static PyObject *pyxc_domain_getinfo(XcObject *self,
 return list;
 }
 
-static PyObject *pyxc_vcpu_getinfo(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-PyObject *info_dict, *cpulist;
-
-uint32_t dom, vcpu = 0;
-xc_vcpuinfo_t info;
-int rc, i;
-xc_cpumap_t cpumap;
-int nr_cpus;
-
-static char *kwd_list[] = { "domid", "vcpu", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "i|i", kwd_list,
-  &dom, &vcpu) )
-return NULL;
-
-nr_cpus = xc_get_max_cpus(self->xc_handle);
-if ( nr_cpus < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-rc = xc_vcpu_getinfo(self->xc_handle, dom, vcpu, &info);
-if ( rc < 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-cpumap = xc_cpumap_alloc(self->xc_handle);
-if(cpumap == NULL)
-return pyxc_error_to_exception(self->xc_handle);
-
-rc = xc_vcpu_getaffinity(self->xc_handle, dom, vcpu, cpumap,
- NULL, XEN_VCPUAFFINITY_HARD);
-if ( rc < 0 )
-{
-free(cpumap);
-return pyxc_error_to_exception(self->xc_handle);
-}
-
-info_dict = Py_BuildValue("{s:i,s:i,s:i,s:L,s:i}",
-  "online",   info.online,
-  "blocked",  info.blocked,
-  "running",  info.running,
-  "cpu_time", info.cpu_time,
-  "cpu",  info.cpu);
-cpulist = PyList_New(0);
-for ( i = 0; i < nr_cpus; i++ )
-{
-if (*(cpumap + i / 8) & 1 ) {
-PyObject *pyint = PyInt_FromLong(i);
-PyList_Append(cpulist, pyint);
-Py_DECREF(pyint);
-}
-cpumap[i / 8] >>= 1;
-}
-PyDict_SetItemString(info_dict, "cpumap", cpulist);
-Py_DECREF(cpulist);
-free(cpumap);
-return info_dict;
-}
-
 static PyObject *pyxc_hvm_param_get(XcObject *self,
 PyObject *args,
 PyObject *kwds)
@@ -982,15 +871,6 @@ static PyObject *pyxc_dom_set_memshr(XcObject *self, 
PyObject *args)
 }
 
 static PyMethodDef pyxc_methods[] = {
-{ "vcpu_setaffinity", 
-  (PyCFunction)pyxc_vcpu_setaffinity, 
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Pin a VCPU to a specified set CPUs.\n"
-  " dom [int]: Identifier of domain to which VCPU belongs.\n"
-  " vcpu [int, 0]: VCPU being pinned.\n"
-  " cpumap [list, []]: list of usable CPUs.

[Xen-devel] [PATCH 00/13] tools: do cleanups related to libxc python bindings

2015-10-23 Thread Juergen Gross

This series is a combination of my previous patches:

"libxc: remove most of tools/libxc/xc_dom_compat_linux.c" 
"tools: remove unused wrappers for python"

I have split it up as requested by Ian Campbell, thus it consists of
13 patches instead just of 2, but the functionality is roughly the
same. I have just kept more python bindings compared to the first
version, as there have been reports of some out of tree uses. Asking
for more such use case on xen-devel and xen-user didn't result in
requests for more interfaces to be kept, so I delete them.

Juergen Gross (13):
  libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  libxc: remove xc_get_bit_size() from tools/libxc/xc_dom_compat_linux.c
  python: remove flask related libxc python bindings
  python: remove cpupool related libxc python bindings
  python: remove cpuid related libxc python bindings
  python: remove device related libxc python bindings
  python: remove scheduler related libxc python bindings
  python: remove unused memory related libxc python bindings
  python: remove domain handling related libxc python bindings
  python: remove vcpu related libxc python bindings
  python: remove hvm related libxc python bindings
  python: remove  permission related libxc python bindings
  python: remove unused other libxc python bindings

 tools/libxc/include/xc_dom.h  |5 +
 tools/libxc/include/xenguest.h|   52 -
 tools/libxc/xc_dom_compat_linux.c |  142 +-
 tools/libxl/libxl_internal.h  |1 +
 tools/python/xen/lowlevel/xc/xc.c | 2624 +++--
 5 files changed, 170 insertions(+), 2654 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 12/13] python: remove permission related libxc python bindings

2015-10-23 Thread Juergen Gross

Mostly for historical reasons Xen includes Python bindings for libxc.
They have been used by xm/xend in the past but nowadays there is no
user of  permission related python binding left. Remove them.

Signed-off-by: Juergen Gross 
---
 tools/python/xen/lowlevel/xc/xc.c | 97 ---
 1 file changed, 97 deletions(-)

diff --git a/tools/python/xen/lowlevel/xc/xc.c 
b/tools/python/xen/lowlevel/xc/xc.c
index c88386f..5039f94 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -608,74 +608,6 @@ static PyObject *pyxc_domain_set_target_mem(XcObject 
*self, PyObject *args)
 return zero;
 }
 
-static PyObject *pyxc_domain_ioport_permission(XcObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-uint32_t dom;
-int first_port, nr_ports, allow_access, ret;
-
-static char *kwd_list[] = { "domid", "first_port", "nr_ports", 
"allow_access", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "", kwd_list, 
-  &dom, &first_port, &nr_ports, 
&allow_access) )
-return NULL;
-
-ret = xc_domain_ioport_permission(
-self->xc_handle, dom, first_port, nr_ports, allow_access);
-if ( ret != 0 )
-return pyxc_error_to_exception(self->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_irq_permission(PyObject *self,
-PyObject *args,
-PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-uint32_t dom;
-int pirq, allow_access, ret;
-
-static char *kwd_list[] = { "domid", "pirq", "allow_access", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "iii", kwd_list, 
-  &dom, &pirq, &allow_access) )
-return NULL;
-
-ret = xc_domain_irq_permission(
-xc->xc_handle, dom, pirq, allow_access);
-if ( ret != 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
-static PyObject *pyxc_domain_iomem_permission(PyObject *self,
-   PyObject *args,
-   PyObject *kwds)
-{
-XcObject *xc = (XcObject *)self;
-uint32_t dom;
-unsigned long first_pfn, nr_pfns, allow_access, ret;
-
-static char *kwd_list[] = { "domid", "first_pfn", "nr_pfns", 
"allow_access", NULL };
-
-if ( !PyArg_ParseTupleAndKeywords(args, kwds, "illi", kwd_list, 
-  &dom, &first_pfn, &nr_pfns, 
&allow_access) )
-return NULL;
-
-ret = xc_domain_iomem_permission(
-xc->xc_handle, dom, first_pfn, nr_pfns, allow_access);
-if ( ret != 0 )
-return pyxc_error_to_exception(xc->xc_handle);
-
-Py_INCREF(zero);
-return zero;
-}
-
 static PyObject *pyxc_domain_set_time_offset(XcObject *self, PyObject *args)
 {
 uint32_t dom;
@@ -925,35 +857,6 @@ static PyMethodDef pyxc_methods[] = {
   " mem_kb [int]: .\n"
   "Returns: [int] 0 on success; -1 on error.\n" },
 
-{ "domain_ioport_permission",
-  (PyCFunction)pyxc_domain_ioport_permission,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Allow a domain access to a range of IO ports\n"
-  " dom  [int]: Identifier of domain to be allowed access.\n"
-  " first_port   [int]: First IO port\n"
-  " nr_ports [int]: Number of IO ports\n"
-  " allow_access [int]: Non-zero means enable access; else disable 
access\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "domain_irq_permission",
-  (PyCFunction)pyxc_domain_irq_permission,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Allow a domain access to a physical IRQ\n"
-  " dom  [int]: Identifier of domain to be allowed access.\n"
-  " pirq [int]: The Physical IRQ\n"
-  " allow_access [int]: Non-zero means enable access; else disable 
access\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
-{ "domain_iomem_permission",
-  (PyCFunction)pyxc_domain_iomem_permission,
-  METH_VARARGS | METH_KEYWORDS, "\n"
-  "Allow a domain access to a range of IO memory pages\n"
-  " dom  [int]: Identifier of domain to be allowed access.\n"
-  " first_pfn   [long]: First page of I/O Memory\n"
-  " nr_pfns [long]: Number of pages of I/O Memory (>0)\n"
-  " allow_access [int]: Non-zero means enable access; else disable 
access\n\n"
-  "Returns: [int] 0 on success; -1 on error.\n" },
-
 { "pages_to_kib",
   (PyCFunction)pyxc_pages_to_kib,
   METH_VARARGS, "\n"
-- 
2.1.4


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

[Xen-devel] [PATCH] mm: hotplug: Don't release twice the resource on error

2015-10-23 Thread Julien Grall

The function add_memory_resource take in parameter a resource allocated
by the caller. On error, both add_memory_resource and the caller will
release the resource via release_memory_source.

This will result to Linux crashing when the caller is trying to release
the resource:

CPU: 1 PID: 45 Comm: xenwatch Not tainted 4.3.0-rc6-00043-g5e1d6ca-dirty #170
Hardware name: XENVM-4.7 (DT)
task: ffc1fb2421c0 ti: ffc1fb27 task.ti:
ffc1fb27
PC is at __release_resource+0x28/0x8c
LR is at __release_resource+0x24/0x8c

[...]

Call trace:
[] __release_resource+0x28/0x8c
[] release_resource+0x24/0x44
[] reserve_additional_memory+0x114/0x128
[] alloc_xenballooned_pages+0x98/0x16c
[] blkfront_gather_backend_features+0x14c/0xd68
[] blkback_changed+0x678/0x150c
[] xenbus_otherend_changed+0x9c/0xa4
[] backend_changed+0xc/0x18
[] xenwatch_thread+0xa0/0x13c
[] kthread+0xdc/0xf4

As the caller is allocating the resource, let him handle the release.
This has been introduced by commit b75351f "mm: memory hotplug with
an existing resource".

Signed-off-by: Julien Grall 

---
Cc: David Vrabel 
Cc: linux...@kvack.org

The patch who introduced this issue is in xentip/for-linus-4.4. So
this patch is a good candidate for Linus 4.4.
---
 mm/memory_hotplug.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 5f394e7..0780d11 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1298,7 +1298,6 @@ error:
/* rollback pgdat allocation and others */
if (new_pgdat)
rollback_node_hotadd(nid, pgdat);
-   release_memory_resource(res);
memblock_remove(start, size);
 
 out:
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 13:43 +0100, Stefano Stabellini wrote:
> > We have no existing stable baseline for that arch, and no testing or
> > reason to believe that cb9a7eb (the Config.mk version currently
> > referenced by 4.6) as being any good at all on that platform,
> > whether we backport a couple of fixes to it or not.
> 
> It is true that ovmf arm64 is not in osstest, but I ran the test
> manually and I know that cb9a7eb plus the one backport works, which is
> just a build fix. In addition the original work for arm64 support was
> done far earlier than cb9a7eb.

20% of the patches since then are ARM related and I'm not sure that a quick
smoke test is a high enough bar to add something in a stable point release
(it might suffice for adding to the development branch and subsequently
releasing, after plenty of time and -rc's, test days etc)

> > I'm not convinced that taking some arbitrary old (although not as old
> > as I
> > thought) OVMF tree which we have tested to our satisfaction and
> > released on
> > x86, slapping a couple of arm64 backports on it and saying "this is now
> > a
> > good and stable thing to use on arm64" makes it good enough to release
> > as
> > ovmf arm64 in 4.6.1, encouraging our users to go about using etc.
> > 
> > Far better to be honest about it for now and point arm64 users at a
> > more
> > bleeding edge ovmf release outside of our own stable releases and
> > prepare
> > to do something better in 4.7.
>  
> Are you suggesting we don't create an OVMF branch for 4.6 until the
> first backport request comes along which we think is appropriate, then
> we decide what to do?  I would rather have an OVMF branch for 4.6 now,
> even if it is just cb9a7eb with no backports.

I'm not against having an OVMF branch ready for any potential bug fixes
which might crop up in the feature set we released and in future we should
probably create one as a matter of course as part of branching.

What I don't like is adding OVMF/arm64 as a new feature in a point release
with very little of the usual confidence we would have in something we
would add in a 4.6.0, let alone a 4.6.1.

Ian.

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

Re: [Xen-devel] passthrough: improve interrupt injection locking

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 13:38 +0100, David Vrabel wrote:
> On 23/10/15 13:37, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
> > > When injecting an interrupt for a passthrough device into a guest,
> > > the
> > > per-domain event_lock is held, reducing performance when a guest has
> > > many VCPUs and high interrupt rates.
> > 
> > Did you CC me due to a possible impact on ARM? If so then I think since
> > ARM
> > lacks this "dpci" stuff none of these changes should have any impact on
> > that arch.
> > 
> > If you think I've missed something or you CCd me for some other reason
> > please let me know.
> 
> This series seems to fall into "THE REST" category.

Ah, only Jan and I were CCd so I didn't think of that.

I think despite the paths this ends up being x86 specific, so I'll leave it
to Jan.

Ian.

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

2015-10-23 Thread Stefano Stabellini

On Fri, 23 Oct 2015, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> > Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> > changeset"):
> > > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > > taking them
> > > > are explained in the referenced thread.
> > 
> > That explanation isn't very convincing to me.
> > 
> > > I cannot believe we are going to move forward without a way to
> > > introduce
> > > any OVMF fixes into the  stable branches.
> > 
> > It is fine to introduce OVMF fixes into stable branches, of course.
> > 
> > But it is not fine to introduce other upstream changes to OVMF,
> > willy-nilly.
> > 
> > Obviously these two requirements cannot be satisfied without there
> > being some branch of OVMF which contains the intended fixes, without
> > the unwanted upstream development.
> 
> For things which we released as part of a stable release I completely
> agree.
>
> But OVMF for aarch64 was not part of the 4.6 release.

What I asked is only one of the backports that might present themselves
in the future. Even if the backport request is rejected, I think we
should create an OVMF branch for 4.6 anyway.


> We have no existing stable baseline for that arch, and no testing or
> reason to believe that cb9a7eb (the Config.mk version currently
> referenced by 4.6) as being any good at all on that platform,
> whether we backport a couple of fixes to it or not.

It is true that ovmf arm64 is not in osstest, but I ran the test
manually and I know that cb9a7eb plus the one backport works, which is
just a build fix. In addition the original work for arm64 support was
done far earlier than cb9a7eb.


> I'm not convinced that taking some arbitrary old (although not as old as I
> thought) OVMF tree which we have tested to our satisfaction and released on
> x86, slapping a couple of arm64 backports on it and saying "this is now a
> good and stable thing to use on arm64" makes it good enough to release as
> ovmf arm64 in 4.6.1, encouraging our users to go about using etc.
> 
> Far better to be honest about it for now and point arm64 users at a more
> bleeding edge ovmf release outside of our own stable releases and prepare
> to do something better in 4.7.
 
Are you suggesting we don't create an OVMF branch for 4.6 until the
first backport request comes along which we think is appropriate, then
we decide what to do?  I would rather have an OVMF branch for 4.6 now,
even if it is just cb9a7eb with no backports.

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

Re: [Xen-devel] [PATCH QEMU-XEN v4 3/9] xen: Switch to libxengnttab interface for compat shims.

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 12:06 +0100, Stefano Stabellini wrote:
> On Wed, 21 Oct 2015, Ian Campbell wrote:
> > In Xen 4.7 we are refactoring parts libxenctrl into a number of
> > separate libraries which will provide backward and forward API and ABI
> > compatiblity.
> > 
> > One such library will be libxengnttab which provides access to grant
> > tables.
> > 
> > In preparation for this switch the compatibility layer in xen_common.h
> > (which support building with older versions of Xen) to use what will
> > be the new library API. This means that the gnttab shim will disappear
> > for versions of Xen which include libxengnttab.
> > 
> > To simplify things for the <= 4.0.0 support we wrap the int fd in a
> > malloc(sizeof int) such that the handle is always a pointer. This
> > leads to less typedef headaches and the need for
> > XC_HANDLER_INITIAL_VALUE etc for these interfaces.
> > 
> > Build tested with 4.0 and 4.5.
> > 
> > Note that this patch does not add any support for actually using
> > libxengnttab, it just adjusts the existing shims.
> > 
> > Signed-off-by: Ian Campbell 
> 
> The patch looks OK but doesn't apply cleanly to master, please rebase.
> After fixing it up, it fails my 4.0 build test (I probably made a
> mistake).

There was a new xc_gnttab_munmap which needed converting.

BTW, contrary to what every single commit message here says I'm actually
build testing on: xen with my other patches from this mega series, 4.6,
4.1, 4.0, 4.5, 4.4, 4.3, 4.2 and on my dev xen with pvbuilder forced to on.
I'm just going to drop all these "Build tested.." from the commit messages.

(the strange version ordering is so I test the different API classes first
and fail early on problems and then fill in the gaps).

Ian.

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

Re: [Xen-devel] passthrough: improve interrupt injection locking

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
> When injecting an interrupt for a passthrough device into a guest, the
> per-domain event_lock is held, reducing performance when a guest has
> many VCPUs and high interrupt rates.

Did you CC me due to a possible impact on ARM? If so then I think since ARM
lacks this "dpci" stuff none of these changes should have any impact on
that arch.

If you think I've missed something or you CCd me for some other reason
please let me know.

Thanks,
Ian.

> 
> By using a per-interrupt lock in the hot paths, this contention is
> eliminated and performance improves (a bit).
> 
> For testing, a 32 VCPU guest with an NVME device assigned to it was
> used.  Continual reads with small (512 B) blocks were performed on all
> 32 hardware queues simultaneously.
> 
> * Lock profiling:
> 
> Before (elapsed: 60 s):
> 
> (XEN) [ 3321.143155] Domain 1 event_lock:
> (XEN) [ 3321.143158]   lock:14411627(0005:90714AEF),
>   block: 6658599(0003:709F82BD)
> 
> After (elapsed: 60 s):
> 
> (XEN) [ 1253.921427] Domain 2 event_lock:
> (XEN) [ 1253.921429]   lock:8287(:01AE517C),
>   block:  67(:000D4C3A)
> 
> * Aggregate performance:
> 
> MB/s
> Before  60.8
> After   68.4
> 
> David
> 

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

Re: [Xen-devel] passthrough: improve interrupt injection locking

2015-10-23 Thread David Vrabel

On 23/10/15 13:37, Ian Campbell wrote:
> On Fri, 2015-10-23 at 12:05 +0100, David Vrabel wrote:
>> When injecting an interrupt for a passthrough device into a guest, the
>> per-domain event_lock is held, reducing performance when a guest has
>> many VCPUs and high interrupt rates.
> 
> Did you CC me due to a possible impact on ARM? If so then I think since ARM
> lacks this "dpci" stuff none of these changes should have any impact on
> that arch.
> 
> If you think I've missed something or you CCd me for some other reason
> please let me know.

This series seems to fall into "THE REST" category.

David

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

Re: [Xen-devel] [PATCH QEMU-XEN v4 7/9] xen: Use stable library interfaces when they are available.

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 12:31 +0100, Stefano Stabellini wrote:
> > diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
> > index 2a5f27a..38293b4 100644
> > --- a/include/hw/xen/xen_common.h
> > +++ b/include/hw/xen/xen_common.h
> > @@ -6,6 +6,17 @@
> >  #include 
> >  #include 
> >  
> > +#if CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470
> > +/*
> > + * If we have new enough libxenctrl then we do not want/need these compat
> > + * interfaces, despite what the user supplied cflags might say. They
> > + * must be undefined before including xenctrl.h
> > + */
> > +#undef XC_WANT_COMPAT_EVTCHN_API
> > +#undef XC_WANT_COMPAT_GNTTAB_API
> > +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> > +#endif
> 
> Can we always do the #under given that earlier libxenctrl versions will
> simple ignore them? I am asking because I would prefer to avoid
> introducing another ifdef here outside the sequence if ifdefs already
> present below.

Ah yes, we can indeed.

Ian.

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

Re: [Xen-devel] [PATCH QEMU-XEN v4 9/9] xen: make it possible to build without the Xen PV domain builder

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 12:35 +0100, Stefano Stabellini wrote:
> On Fri, 23 Oct 2015, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 12:12 +0100, Stefano Stabellini wrote:
> > > @@ -2113,6 +2117,15 @@ if test "$xen_pci_passthrough" != "no"; then
> > > >fi
> > > >  fi
> > > >  
> > > > +if test "$xen_pv_domain_build" != "no"; then
> > > > +  if test "$xen_pv_domain_build" = "yes" &&
> > > > + test "$xen" != "yes"; then
> > > > +  error_exit "User requested Xen PV domain builder support" \
> > > > +"which requires Xen support."
> > > > +  fi
> > > > +  xen_pv_domain_build=no
> > > > +fi
> > > 
> > > Can we simplify this to:
> > > 
> > >   if test "$xen_pv_domain_build" = "yes" &&
> > >test "$xen" != "yes"; then
> > > error_exit "User requested Xen PV domain builder support" \
> > >"which requires Xen support."
> > > fi
> > >   fi
> > > 
> > > and move xen_pv_domain_build=no at the beginning of the file?
> > 
> > I think so, I hadn't noticed the precedent for doing so further up in
> > the
> > file.
> > 
> > Just to check, is this still your preference after my earlier reply-to
> > -self
> > explaining why the code above is utter rubbish and proposing a
> > different
> > simplified version?
> 
> The simplified check is OK, but I would still prefer if you moved
> xen_pv_domain_build=no at the beginning of the file.

Ack, I'll do that then.
> 
> 
> > @@ -46,13 +43,22 @@ static void xen_init_pv(MachineState *machine)
> > > >  case XEN_ATTACH:
> > > >  /* nothing to do, xend handles everything */
> > > >  break;
> > > > -case XEN_CREATE:
> > > > +case XEN_CREATE: {
> > > > +#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
> > > > +const char *kernel_filename = machine->kernel_filename;
> > > > +const char *kernel_cmdline = machine->kernel_cmdline;
> > > > +const char *initrd_filename = machine->initrd_filename;
> > > >  if (xen_domain_build_pv(kernel_filename, initrd_filename,
> > > >  kernel_cmdline) < 0) {
> > > >  fprintf(stderr, "xen pv domain creation failed\n");
> > > >  exit(1);
> > > >  }
> > > > +#else
> > > > +fprintf(stderr, "xen pv domain creation not supported\n");
> > > > +exit(1);
> > > > +#endif
> > > >  break;
> > > > +}
> > > >  case XEN_EMULATE:
> > > >  fprintf(stderr, "xen emulation not implemented (yet)\n");
> > > >  exit(1);
> > > 
> > > Please add a default case with an error and place the XEN_CREATE
> > > entirely within the ifdef CONFIG_XEN_PV_DOMAIN_BUILD.
> > 
> > Will do.
> > 

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

Re: [Xen-devel] [PATCH] Config.mk: update OVMF changeset

2015-10-23 Thread Ian Campbell

On Fri, 2015-10-23 at 12:18 +0100, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [PATCH] Config.mk: update OVMF
> changeset"):
> > On Fri, 23 Oct 2015, Ian Campbell wrote:
> > > Yes. Those (that?) and the reasons why we aren't just trivially
> > > taking them
> > > are explained in the referenced thread.
> 
> That explanation isn't very convincing to me.
> 
> > I cannot believe we are going to move forward without a way to
> > introduce
> > any OVMF fixes into the  stable branches.
> 
> It is fine to introduce OVMF fixes into stable branches, of course.
> 
> But it is not fine to introduce other upstream changes to OVMF,
> willy-nilly.
> 
> Obviously these two requirements cannot be satisfied without there
> being some branch of OVMF which contains the intended fixes, without
> the unwanted upstream development.

For things which we released as part of a stable release I completely
agree.

But OVMF for aarch64 was not part of the 4.6 release. We have no existing
stable baseline for that arch, and no testing or reason to believe that
cb9a7eb (the Config.mk version currently referenced by 4.6) as being any
good at all on that platform, whether we backport a couple of fixes to it
or not.

I'm not convinced that taking some arbitrary old (although not as old as I
thought) OVMF tree which we have tested to our satisfaction and released on
x86, slapping a couple of arm64 backports on it and saying "this is now a
good and stable thing to use on arm64" makes it good enough to release as
ovmf arm64 in 4.6.1, encouraging our users to go about using etc.

Far better to be honest about it for now and point arm64 users at a more
bleeding edge ovmf release outside of our own stable releases and prepare
to do something better in 4.7.

> If OVMF upstream do not have such a branch, we need to create one.

Ian.

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

Re: [Xen-devel] [PATCH 3/3] xl: convert cpupool related return codes to EXIT_[SUCCESS|FAILURE]

2015-10-23 Thread Dario Faggioli

And here we are at the last patch of this series.

Allow me to say that this is quite good a first contribution! Thanks
for this, and I'm looking forward to seeing version 2!! :-D

About this patch, a few comments below.

On Fri, 2015-10-23 at 13:18 +0530, Harmandeep Kaur wrote:
> turning  cpupools related functions xl exit codes towards using the
> EXIT_[SUCCESS|FAILURE] macros, instead of instead of arbitrary
> numbers
> or libxl return codes.
> 
> Signed-off-by: Harmandeep Kaur 

> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -7497,7 +7497,7 @@ out:
>  free(name);
>  free(config_data);
>  free(extra_config);
> -return rc;
> +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
>  }
> 
I think you can just initialize rc with EXIT_FAILURE, assign
EXIT_SUCCESS to it near the end, if everything went ok, and then keep
the 'return rc';
  
>  int main_cpupooldestroy(int argc, char **argv)
> @@ -7580,13 +7580,13 @@ int main_cpupooldestroy(int argc, char
> **argv)
>  if (libxl_cpupool_qualifier_to_cpupoolid(ctx, pool, &poolid,
> NULL) ||
>  !libxl_cpupoolid_is_valid(ctx, poolid)) {
>  fprintf(stderr, "unknown cpupool '%s'\n", pool);
> -return 1;
> +return EXIT_FAILURE;
>  }
>  
>  if (libxl_cpupool_destroy(ctx, poolid))
> -return 1;
> +return EXIT_FAILURE;
>  
> -return 0;
> +return EXIT_SUCCESS;
>  }
> 
For this one: I've sent a patch for another reason yesterday, and while
there I did the exit code adjustment myself. So, update your tree and,
if my patch has been committed already, just skip this function.

 https://www.mail-archive.com/xen-devel@lists.xen.org/msg42850.html

Which brings up a question: what git tree are you using for
development? You should stay either on master or staging branches (and
I recommend staging) of the official repository:

 http://wiki.xenproject.org/wiki/Xen_Project_Repositories
 
> @@ -7653,7 +7653,7 @@ int main_cpupoolcpuadd(int argc, char **argv)
>  
>  out:
>  libxl_bitmap_dispose(&cpumap);
> -return rc;
> +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
>
Same as already said for main_cpupoolcreate, just us rc.

> @@ -7691,7 +7691,7 @@ int main_cpupoolcpuremove(int argc, char
> **argv)
>  
>  out:
>  libxl_bitmap_dispose(&cpumap);
> -return rc;
> +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
>
And here.

>  int main_cpupoolnumasplit(int argc, char **argv)
> @@ -7758,7 +7758,7 @@ int main_cpupoolnumasplit(int argc, char
> **argv)
>  poolinfo = libxl_list_cpupool(ctx, &n_pools);
>  if (!poolinfo) {
>  fprintf(stderr, "error getting cpupool info\n");
> -return 1;
> +return EXIT_FAILURE;
>  }
>  poolid = poolinfo[0].poolid;
>  sched = poolinfo[0].sched;
> @@ -7766,13 +7766,13 @@ int main_cpupoolnumasplit(int argc, char
> **argv)
>  
>  if (n_pools > 1) {
>  fprintf(stderr, "splitting not possible, already cpupools in
> use\n");
> -return 1;
> +return EXIT_FAILURE;
>  }
>  
>  topology = libxl_get_cpu_topology(ctx, &n_cpus);
>  if (topology == NULL) {
>  fprintf(stderr, "libxl_get_topologyinfo failed\n");
> -return 1;
> +return EXIT_FAILURE;
>  }
>  
>  if (libxl_cpu_bitmap_alloc(ctx, &cpumap, 0)) {
> @@ -7869,7 +7869,7 @@ out:
>  libxl_dominfo_dispose(&info);
>  free(name);
>  
> -return rc;
> +return rc ? EXIT_FAILURE : EXIT_SUCCESS;
>  }
> 
And here too.

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



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

1 2 >

1 - 100 of 197 matches

Mail list logo