[Xen-devel] [xen-4.8-testing test] 116737: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  broken  in 116653

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd  4 host-install(4) broken in 116653 pass in 116737
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 116653 pass in 116737
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 116653 pass 
in 116737
 test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116719 pass 
in 116737
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail in 116719 
pass in 116737
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 116719 
pass in 116737
 test-xtf-amd64-amd64-2   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 116653
 test-amd64-amd64-xl-qemut-ws16-amd64 15 guest-saverestore.2 fail pass in 116719

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 116237
 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116653 like 
116221
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116653 
like 116237
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop  fail in 116653 like 116237
 test-xtf-amd64-amd64-4  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 116237
 test-xtf-amd64-amd64-3  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 116237
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 116237
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116237
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116237
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116237
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116237
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116237
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 116237
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-

[Xen-devel] [linux-linus bisection] complete test-amd64-i386-libvirt

[osstest service owner]

branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt
testid xen-boot

Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  linux 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
  Bug introduced:  4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
  Bug not present: b39545684a90ef3374abc0969d64c7bc540d128d
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/116769/


  (Revision log too long, omitted.)


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-i386-libvirt.xen-boot.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/linux-linus/test-amd64-i386-libvirt.xen-boot
 --summary-out=tmp/116769.bisection-summary --basis-template=115643 
--blessings=real,real-bisect linux-linus test-amd64-i386-libvirt xen-boot
Searching for failure / basis pass:
 116628 fail [host=merlot1] / 116550 [host=huxelrebe0] 116536 [host=italia1] 
116514 [host=fiano0] 116461 [host=baroque0] 116433 [host=baroque1] 116343 
[host=chardonnay1] 116316 [host=elbling1] 116268 [host=elbling0] 116226 
[host=chardonnay0] 116215 [host=italia0] 116182 [host=merlot0] 116164 
[host=nocera0] 116152 [host=huxelrebe0] 116136 [host=nocera1] 116119 
[host=fiano1] 116103 ok.
Failure / basis pass flights: 116628 / 116103
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 13d45b0dc25ed99a9da0704d01cf21c8fe99f951 
5e9abf87163ad4aeaefef0b02961f8674b0a4879 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
b79708a8ed1b3d18bee67baeaf33b3fa529493e2 
bf87b7f7d91a25404216e0a0f3e628ce9bf1f82e
Basis pass 1bf893406637e852daeaafec6617d3ee3716de25 
5e9abf87163ad4aeaefef0b02961f8674b0a4879 
7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0 
b39545684a90ef3374abc0969d64c7bc540d128d 
c530a75c1e6a472b0eb9558310b518f0dfcd8860 
c8ea0457495342c417c3dc033bba25148b279f60 
5cd7ce5dde3f228b3b669ed9ca432f588947bd40 
92f0d4392e73727819c5a83fcce447515efaf2f5
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/libvirt.git#1bf893406637e852daeaafec6617d3ee3716de25-13d45b0dc25ed99a9da0704d01cf21c8fe99f951
 
git://git.sv.gnu.org/gnulib.git#5e9abf87163ad4aeaefef0b02961f8674b0a4879-5e9abf87163ad4aeaefef0b02961f8674b0a4879
 
https://gitlab.com/keycodemap/keycodemapdb.git#7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0-7bf5710b22aa8d58b7eeaaf3dc6960c26cade4f0
 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#b39545684a90ef3374abc0969d64c7bc540d128d-4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
 
git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860
 
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#5cd7ce5dde3f228b3b669ed9ca432f588947bd40-b79708a8ed1b3d18bee67baeaf33b3fa529493e2
 
git://xenbits.xen.org/xen.git#92f0d4392e73727819c5a83fcce447515efaf2f5-bf87b7f7d91a25404216e0a0f3e628ce9bf1f82e
From git://cache:9419/git://xenbits.xen.org/libvirt
 * [new branch]  osstest/frozen/xen-4.0-testing -> 
origin/osstest/frozen/xen-4.0-testing
 * [new branch]  osstest/frozen/xen-4.1-testing -> 
origin/osstest/frozen/xen-4.1-testing
 * [new branch]  osstest/frozen/xen-4.10-testing -> 
origin/osstest/frozen/xen-4.10-testing
 * [new branch]  osstest/frozen/xen-4.2-testing -> 
origin/osstest/frozen/xen-4.2-testing
 * [new branch]  osstest/frozen/xen-4.3-testing -> 
origin/osstest/frozen/xen-4.3-testing
 * [new branch]  osstest/frozen/xen-4.4-testing -> 
origin/osstest/frozen/xen-4.4-testing
 * [new branch]  osstest/frozen/xen-4.5-testing -> 
origin/osstest/frozen/xen-4.5-testing
 * [new branch]  osstest/frozen/xen-4.6-test

Re: [Xen-devel] [RFC PATCH 06/31] cpufreq: make cpufreq driver more generalizable

[Stefano Stabellini]

On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn 
> 
> First implementation of the cpufreq driver has been
> written with x86 in mind. This patch makes possible
> the cpufreq driver be working on both x86 and arm
> architectures.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00932.html
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  xen/drivers/cpufreq/cpufreq.c| 81 
> +---
>  xen/include/public/platform.h|  1 +
>  xen/include/xen/processor_perf.h |  6 +++
>  3 files changed, 82 insertions(+), 6 deletions(-)
> 
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index ab909e2..64e1ae7 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -42,7 +42,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  static unsigned int __read_mostly usr_min_freq;
> @@ -206,6 +205,7 @@ int cpufreq_add_cpu(unsigned int cpu)
>  } else {
>  /* domain sanity check under whatever coordination type */
>  firstcpu = cpumask_first(cpufreq_dom->map);
> +#ifdef CONFIG_ACPI
>  if ((perf->domain_info.coord_type !=
>  processor_pminfo[firstcpu]->perf.domain_info.coord_type) ||
>  (perf->domain_info.num_processors !=
> @@ -221,6 +221,19 @@ int cpufreq_add_cpu(unsigned int cpu)
>  );
>  return -EINVAL;
>  }
> +#else /* !CONFIG_ACPI */
> +if ((perf->domain_info.num_processors !=
> +processor_pminfo[firstcpu]->perf.domain_info.num_processors)) {
> +
> +printk(KERN_WARNING "cpufreq fail to add CPU%d:"
> +   "incorrect num processors (%"PRIu64"), "
> +   "expect(%"PRIu64")\n",
> +   cpu, perf->domain_info.num_processors,
> +   
> processor_pminfo[firstcpu]->perf.domain_info.num_processors
> +);
> +return -EINVAL;
> +}
> +#endif /* CONFIG_ACPI */

Why is this necessary? I am asking this question, because I think it
would be best to avoid more #ifdef's if we can avoid them, and some of
the code #ifdef'ed doesn't look very acpi specific (at least at first
sight). It doesn't look like this change is very beneficial. What am I
missing?


>  }
>  
>  if (!domexist || hw_all) {
> @@ -380,6 +393,7 @@ int cpufreq_del_cpu(unsigned int cpu)
>  return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
>  static void print_PCT(struct xen_pct_register *ptr)
>  {
>  printk("\t_PCT: descriptor=%d, length=%d, space_id=%d, "
> @@ -387,12 +401,14 @@ static void print_PCT(struct xen_pct_register *ptr)
> ptr->descriptor, ptr->length, ptr->space_id, ptr->bit_width,
> ptr->bit_offset, ptr->reserved, ptr->address);
>  }
> +#endif /* CONFIG_ACPI */

same question


>  static void print_PSS(struct xen_processor_px *ptr, int count)
>  {
>  int i;
>  printk("\t_PSS: state_count=%d\n", count);
>  for (i=0; i +#ifdef CONFIG_ACPI
>  printk("\tState%d: %"PRId64"MHz %"PRId64"mW %"PRId64"us "
> "%"PRId64"us %#"PRIx64" %#"PRIx64"\n",
> i,
> @@ -402,15 +418,26 @@ static void print_PSS(struct xen_processor_px *ptr, int 
> count)
> ptr[i].bus_master_latency,
> ptr[i].control,
> ptr[i].status);
> +#else /* !CONFIG_ACPI */
> +printk("\tState%d: %"PRId64"MHz %"PRId64"us\n",
> +   i,
> +   ptr[i].core_frequency,
> +   ptr[i].transition_latency);
> +#endif /* CONFIG_ACPI */
>  }
>  }
  
same question


>  static void print_PSD( struct xen_psd_package *ptr)
>  {
> +#ifdef CONFIG_ACPI
>  printk("\t_PSD: num_entries=%"PRId64" rev=%"PRId64
> " domain=%"PRId64" coord_type=%"PRId64" 
> num_processors=%"PRId64"\n",
> ptr->num_entries, ptr->revision, ptr->domain, ptr->coord_type,
> ptr->num_processors);
> +#else /* !CONFIG_ACPI */
> +printk("\t_PSD:  domain=%"PRId64" num_processors=%"PRId64"\n",
> +   ptr->domain, ptr->num_processors);
> +#endif /* CONFIG_ACPI */
>  }

same question


>  static void print_PPC(unsigned int platform_limit)
> @@ -418,13 +445,53 @@ static void print_PPC(unsigned int platform_limit)
>  printk("\t_PPC: %d\n", platform_limit);
>  }
>  
> +static inline bool is_pss_data(struct xen_processor_performance *px)
> +{
> +#ifdef CONFIG_ACPI
> +return px->flags & XEN_PX_PSS;
> +#else
> +return px->flags == XEN_PX_DATA;
> +#endif
> +}
> +
> +static inline bool is_psd_data(struct xen_processor_performance *px)
> +{
> +#ifdef CONFIG_ACPI
> +return px->flags & XEN_PX_PSD;
> +#else
> +return px->flags == XEN_PX_DATA;
> +#endif
> +}
> +
> +static inline bool is_ppc_data(struct xen_

Re: [Xen-devel] [RFC PATCH 07/31] xenpm: Clarify xenpm usage

[Stefano Stabellini]

On Thu, 9 Nov 2017, Wei Liu wrote:
> On Thu, Nov 09, 2017 at 07:09:57PM +0200, Oleksandr Tyshchenko wrote:
> > From: Oleksandr Tyshchenko 
> > 
> > CPU frequencies are in kHz. So, correct displayed text.
> > 
> > Signed-off-by: Oleksandr Tyshchenko 
> > CC: Ian Jackson 
> > CC: Wei Liu 
> > CC: Stefano Stabellini 
> > CC: Julien Grall 
> > ---
> >  tools/misc/xenpm.c | 6 +++---
> 
> Acked-by: Wei Liu 

Acked-by: Stefano Stabellini 

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

Re: [Xen-devel] [RFC PATCH 05/31] pmstat: make pmstat functions more generalizable

[Stefano Stabellini]

On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn 
> 
> ACPI-specific parts are moved under appropriate ifdefs.
> Now pmstat functions can be used in ARM platform.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00941.html

My first maybe naive question is: why do we want to disable the C-states
and not the P-states? After all, they are both defined in ACPI?

The second question is: instead of #ifdef'ing everything C-states,
couldn't we just rely on XEN_PROCESSOR_PM_CX not being available?


> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  xen/drivers/pm/stat.c| 8 +++-
>  xen/include/xen/pmstat.h | 2 ++
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
> index 133e64d..986ba41 100644
> --- a/xen/drivers/pm/stat.c
> +++ b/xen/drivers/pm/stat.c
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  
>  #include 
>  #include 
> @@ -132,6 +131,8 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>  break;
>  }
>  
> +/* For now those operations can be used only when ACPI is enabled */
> +#ifdef CONFIG_ACPI
>  case PMSTAT_get_max_cx:
>  {
>  op->u.getcx.nr = pmstat_get_cx_nr(op->cpuid);
> @@ -150,6 +151,7 @@ int do_get_pm_info(struct xen_sysctl_get_pmstat *op)
>  ret = pmstat_reset_cx_stat(op->cpuid);
>  break;
>  }
> +#endif /* CONFIG_ACPI */
>  
>  default:
>  printk("not defined sub-hypercall @ do_get_pm_info\n");
> @@ -465,6 +467,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
>  break;
>  }
>  
> +#ifdef CONFIG_ACPI
>  case XEN_SYSCTL_pm_op_get_max_cstate:
>  {
>  op->u.get_max_cstate = acpi_get_cstate_limit();
> @@ -476,6 +479,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
>  acpi_set_cstate_limit(op->u.set_max_cstate);
>  break;
>  }
> +#endif /* CONFIG_ACPI */
>  
>  #ifdef CONFIG_HAS_CPU_TURBO
>  case XEN_SYSCTL_pm_op_enable_turbo:
> @@ -500,6 +504,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
>  return ret;
>  }
>  
> +#ifdef CONFIG_ACPI
>  int acpi_set_pdc_bits(u32 acpi_id, XEN_GUEST_HANDLE_PARAM(uint32) pdc)
>  {
>  u32 bits[3];
> @@ -530,3 +535,4 @@ int acpi_set_pdc_bits(u32 acpi_id, 
> XEN_GUEST_HANDLE_PARAM(uint32) pdc)
>  
>  return ret;
>  }
> +#endif /* CONFIG_ACPI */
> diff --git a/xen/include/xen/pmstat.h b/xen/include/xen/pmstat.h
> index 266bc16..a870c8a 100644
> --- a/xen/include/xen/pmstat.h
> +++ b/xen/include/xen/pmstat.h
> @@ -6,10 +6,12 @@
>  #include/* for struct pm_cx_stat */
>  
>  int set_px_pminfo(uint32_t cpu, struct xen_processor_performance *perf);
> +#ifdef CONFIG_ACPI
>  long set_cx_pminfo(uint32_t cpu, struct xen_processor_power *power);
>  uint32_t pmstat_get_cx_nr(uint32_t cpuid);
>  int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat);
>  int pmstat_reset_cx_stat(uint32_t cpuid);
> +#endif
>  
>  int do_get_pm_info(struct xen_sysctl_get_pmstat *op);
>  int do_pm_op(struct xen_sysctl_pm_op *op);
> -- 
> 2.7.4
> 

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

Re: [Xen-devel] [RFC PATCH 04/31] cpufreq: make turbo settings to be configurable

[Stefano Stabellini]

On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn 
> 
> This settings is not needed for some architectures.
> So make it to be configurable and use it for x86
> architecture.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00942.html
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 
> ---
>  xen/arch/x86/Kconfig  |  1 +
>  xen/drivers/cpufreq/Kconfig   |  3 +++
>  xen/drivers/cpufreq/utility.c | 11 ++-
>  xen/drivers/pm/stat.c |  6 ++
>  xen/include/xen/cpufreq.h |  6 ++
>  5 files changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 86c8eca..c1eac1d 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -24,6 +24,7 @@ config X86
>   select NUMA
>   select VGA
>   select HAS_PM
> + select HAS_CPU_TURBO
>  
>  config ARCH_DEFCONFIG
>   string
> diff --git a/xen/drivers/cpufreq/Kconfig b/xen/drivers/cpufreq/Kconfig
> index cce80f4..427ea2a 100644
> --- a/xen/drivers/cpufreq/Kconfig
> +++ b/xen/drivers/cpufreq/Kconfig
> @@ -1,3 +1,6 @@
>  
>  config HAS_CPUFREQ
>   bool
> +
> +config HAS_CPU_TURBO
> + bool
> diff --git a/xen/drivers/cpufreq/utility.c b/xen/drivers/cpufreq/utility.c
> index a687e5a..25bf983 100644
> --- a/xen/drivers/cpufreq/utility.c
> +++ b/xen/drivers/cpufreq/utility.c
> @@ -209,7 +209,9 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy 
> *policy,
>  {
>  unsigned int min_freq = ~0;
>  unsigned int max_freq = 0;
> +#ifdef CONFIG_HAS_CPU_TURBO
>  unsigned int second_max_freq = 0;
> +#endif
>  unsigned int i;
>  
>  for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
> @@ -221,6 +223,7 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy 
> *policy,
>  if (freq > max_freq)
>  max_freq = freq;
>  }
> +#ifdef CONFIG_HAS_CPU_TURBO
>  for (i=0; (table[i].frequency != CPUFREQ_TABLE_END); i++) {
>  unsigned int freq = table[i].frequency;
>  if (freq == CPUFREQ_ENTRY_INVALID || freq == max_freq)
> @@ -234,9 +237,13 @@ int cpufreq_frequency_table_cpuinfo(struct 
> cpufreq_policy *policy,
>  printk("max_freq: %usecond_max_freq: %u\n",
> max_freq, second_max_freq);
>  
> +policy->cpuinfo.second_max_freq = second_max_freq;
> +#else /* !CONFIG_HAS_CPU_TURBO */
> +if (cpufreq_verbose)
> +printk("max_freq: %u\n", max_freq);
> +#endif /* CONFIG_HAS_CPU_TURBO */
>  policy->min = policy->cpuinfo.min_freq = min_freq;
>  policy->max = policy->cpuinfo.max_freq = max_freq;
> -policy->cpuinfo.second_max_freq = second_max_freq;
>  
>  if (policy->min == ~0)
>  return -EINVAL;
> @@ -390,6 +397,7 @@ int cpufreq_driver_getavg(unsigned int cpu, unsigned int 
> flag)
>  return policy->cur;
>  }
>  
> +#ifdef CONFIG_HAS_CPU_TURBO
>  int cpufreq_update_turbo(int cpuid, int new_state)
>  {
>  struct cpufreq_policy *policy;
> @@ -430,6 +438,7 @@ int cpufreq_get_turbo_status(int cpuid)
>  policy = per_cpu(cpufreq_cpu_policy, cpuid);
>  return policy && policy->turbo == CPUFREQ_TURBO_ENABLED;
>  }
> +#endif /* CONFIG_HAS_CPU_TURBO */
>  
>  /*
>   * POLICY*

I am wondering if we need to go as far as #ifdef'ing
cpufreq_update_turbo. For the sake of reducing the number if #ifdef's,
would it be enough if we only make sure it is disabled?

In other words, I would keep the changes to stat.c but I would leave
utility.c and cpufreq.h pretty much untouched.


> diff --git a/xen/drivers/pm/stat.c b/xen/drivers/pm/stat.c
> index 2dbde1c..133e64d 100644
> --- a/xen/drivers/pm/stat.c
> +++ b/xen/drivers/pm/stat.c
> @@ -290,7 +290,11 @@ static int get_cpufreq_para(struct xen_sysctl_pm_op *op)
>  &op->u.get_para.u.ondemand.sampling_rate,
>  &op->u.get_para.u.ondemand.up_threshold);
>  }
> +#ifdef CONFIG_HAS_CPU_TURBO
>  op->u.get_para.turbo_enabled = cpufreq_get_turbo_status(op->cpuid);
> +#else
> +op->u.get_para.turbo_enabled = 0;
> +#endif
>  
>  return ret;
>  }
> @@ -473,6 +477,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
>  break;
>  }
>  
> +#ifdef CONFIG_HAS_CPU_TURBO
>  case XEN_SYSCTL_pm_op_enable_turbo:
>  {
>  ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_ENABLED);
> @@ -484,6 +489,7 @@ int do_pm_op(struct xen_sysctl_pm_op *op)
>  ret = cpufreq_update_turbo(op->cpuid, CPUFREQ_TURBO_DISABLED);
>  break;
>  }
> +#endif /* CONFIG_HAS_CPU_TURBO */
>  
>  default:
>  printk("not defined sub-hypercall @ do_pm_op\n");
> diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
> inde

Re: [Xen-devel] [RFC PATCH 03/31] pmstat: move pmstat.c file to the xen/drivers/pm/stat.c location

[Stefano Stabellini]

On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn 
> 
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00935.html
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  MAINTAINERS   |   1 +
>  xen/arch/x86/Kconfig  |   1 +
>  xen/common/sysctl.c   |   2 +-
>  xen/drivers/Kconfig   |   2 +
>  xen/drivers/Makefile  |   1 +
>  xen/drivers/acpi/Makefile |   1 -
>  xen/drivers/acpi/pmstat.c | 526 
> --
>  xen/drivers/pm/Kconfig|   3 +
>  xen/drivers/pm/Makefile   |   1 +
>  xen/drivers/pm/stat.c | 526 
> ++
>  10 files changed, 536 insertions(+), 528 deletions(-)
>  delete mode 100644 xen/drivers/acpi/pmstat.c
>  create mode 100644 xen/drivers/pm/Kconfig
>  create mode 100644 xen/drivers/pm/Makefile
>  create mode 100644 xen/drivers/pm/stat.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9794a81..87ade6f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -294,6 +294,7 @@ F:xen/arch/x86/acpi/
>  X:   xen/arch/x86/acpi/boot.c
>  X:   xen/arch/x86/acpi/lib.c
>  F:   xen/drivers/cpufreq/
> +F:   xen/drivers/pm/
>  F:   xen/include/xen/cpufreq.h
>  F:   xen/include/xen/processor_perf.h
>  
> diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
> index 30c2769..86c8eca 100644
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -23,6 +23,7 @@ config X86
>   select HAS_PDX
>   select NUMA
>   select VGA
> + select HAS_PM
>  
>  config ARCH_DEFCONFIG
>   string
> diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
> index a6882d1..ac96347 100644
> --- a/xen/common/sysctl.c
> +++ b/xen/common/sysctl.c
> @@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) 
> u_sysctl)
>  op->u.availheap.avail_bytes <<= PAGE_SHIFT;
>  break;
>  
> -#if defined (CONFIG_ACPI) && defined (CONFIG_HAS_CPUFREQ)
> +#if defined (CONFIG_HAS_PM) && defined (CONFIG_HAS_CPUFREQ)
>  case XEN_SYSCTL_get_pmstat:
>  ret = do_get_pm_info(&op->u.get_pmstat);
>  break;
> diff --git a/xen/drivers/Kconfig b/xen/drivers/Kconfig
> index bc3a54f..ddaec11 100644
> --- a/xen/drivers/Kconfig
> +++ b/xen/drivers/Kconfig
> @@ -12,4 +12,6 @@ source "drivers/pci/Kconfig"
>  
>  source "drivers/video/Kconfig"
>  
> +source "drivers/pm/Kconfig"
> +
>  endmenu
> diff --git a/xen/drivers/Makefile b/xen/drivers/Makefile
> index 1939180..dd0b496 100644
> --- a/xen/drivers/Makefile
> +++ b/xen/drivers/Makefile
> @@ -4,3 +4,4 @@ subdir-$(CONFIG_HAS_PCI) += pci
>  subdir-$(CONFIG_HAS_PASSTHROUGH) += passthrough
>  subdir-$(CONFIG_ACPI) += acpi
>  subdir-$(CONFIG_VIDEO) += video
> +subdir-$(CONFIG_HAS_PM) += pm
> diff --git a/xen/drivers/acpi/Makefile b/xen/drivers/acpi/Makefile
> index 444b11d..6f6470a 100644
> --- a/xen/drivers/acpi/Makefile
> +++ b/xen/drivers/acpi/Makefile
> @@ -5,7 +5,6 @@ subdir-$(CONFIG_X86) += apei
>  obj-bin-y += tables.init.o
>  obj-$(CONFIG_NUMA) += numa.o
>  obj-y += osl.o
> -obj-$(CONFIG_HAS_CPUFREQ) += pmstat.o
>  
>  obj-$(CONFIG_X86) += hwregs.o
>  obj-$(CONFIG_X86) += reboot.o
> diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
> deleted file mode 100644
> index 2dbde1c..000
> --- a/xen/drivers/acpi/pmstat.c
> +++ /dev/null
> @@ -1,526 +0,0 @@
> -/*
> -#  pmstat.c - Power Management statistic information (Px/Cx/Tx, etc.)
> -#
> -#  Copyright (c) 2008, Liu Jinsong 
> -#
> -# This program is free software; you can redistribute it and/or modify it 
> -# under the terms of the GNU General Public License as published by the Free 
> -# Software Foundation; either version 2 of the License, or (at your option) 
> -# any later version.
> -#
> -# This program is distributed in the hope that it will be useful, but 
> WITHOUT 
> -# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
> -# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for 
> -# more details.
> -#
> -# You should have received a copy of the GNU General Public License along 
> with
> -# this program; If not, see .
> -#
> -# The full GNU General Public License is included in this distribution in the
> -# file called LICENSE.
> -#
> -*/
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 
> -#inc

Re: [Xen-devel] [RFC PATCH 02/31] pm: move processor_perf.h file to the xen/include/xen location

[Stefano Stabellini]

On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn 
> 
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00934.html
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  MAINTAINERS   |  2 +-
>  xen/arch/x86/platform_hypercall.c |  2 +-
>  xen/include/acpi/cpufreq/processor_perf.h | 63 
> ---
>  xen/include/xen/cpufreq.h |  2 +-
>  xen/include/xen/processor_perf.h  | 63 
> +++
>  5 files changed, 66 insertions(+), 66 deletions(-)
>  delete mode 100644 xen/include/acpi/cpufreq/processor_perf.h
>  create mode 100644 xen/include/xen/processor_perf.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 524e067..9794a81 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -294,8 +294,8 @@ F:xen/arch/x86/acpi/
>  X:   xen/arch/x86/acpi/boot.c
>  X:   xen/arch/x86/acpi/lib.c
>  F:   xen/drivers/cpufreq/
> -F:   xen/include/acpi/cpufreq/
>  F:   xen/include/xen/cpufreq.h
> +F:   xen/include/xen/processor_perf.h
>  
>  PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
>  M:  Konrad Rzeszutek Wilk 
> diff --git a/xen/arch/x86/platform_hypercall.c 
> b/xen/arch/x86/platform_hypercall.c
> index ebc2f39..17c8304 100644
> --- a/xen/arch/x86/platform_hypercall.c
> +++ b/xen/arch/x86/platform_hypercall.c
> @@ -25,7 +25,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/include/acpi/cpufreq/processor_perf.h 
> b/xen/include/acpi/cpufreq/processor_perf.h
> deleted file mode 100644
> index d8a1ba6..000
> --- a/xen/include/acpi/cpufreq/processor_perf.h
> +++ /dev/null
> @@ -1,63 +0,0 @@
> -#ifndef __XEN_PROCESSOR_PM_H__
> -#define __XEN_PROCESSOR_PM_H__
> -
> -#include 
> -#include 
> -#include 
> -
> -#define XEN_PX_INIT 0x8000
> -
> -int powernow_cpufreq_init(void);
> -unsigned int powernow_register_driver(void);
> -unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
> -void cpufreq_residency_update(unsigned int, uint8_t);
> -void cpufreq_statistic_update(unsigned int, uint8_t, uint8_t);
> -int  cpufreq_statistic_init(unsigned int);
> -void cpufreq_statistic_exit(unsigned int);
> -void cpufreq_statistic_reset(unsigned int);
> -
> -int  cpufreq_limit_change(unsigned int);
> -
> -int  cpufreq_add_cpu(unsigned int);
> -int  cpufreq_del_cpu(unsigned int);
> -
> -struct processor_performance {
> -uint32_t state;
> -uint32_t platform_limit;
> -struct xen_pct_register control_register;
> -struct xen_pct_register status_register;
> -uint32_t state_count;
> -struct xen_processor_px *states;
> -struct xen_psd_package domain_info;
> -uint32_t shared_type;
> -
> -uint32_t init;
> -};
> -
> -struct processor_pminfo {
> -uint32_t acpi_id;
> -uint32_t id;
> -struct processor_performanceperf;
> -};
> -
> -extern struct processor_pminfo *processor_pminfo[NR_CPUS];
> -
> -struct px_stat {
> -uint8_t total;/* total Px states */
> -uint8_t usable;   /* usable Px states */
> -uint8_t last; /* last Px state */
> -uint8_t cur;  /* current Px state */
> -uint64_t *trans_pt;   /* Px transition table */
> -pm_px_val_t *pt;
> -};
> -
> -struct pm_px {
> -struct px_stat u;
> -uint64_t prev_state_wall;
> -uint64_t prev_idle_wall;
> -};
> -
> -DECLARE_PER_CPU(struct pm_px *, cpufreq_statistic_data);
> -
> -int cpufreq_cpu_init(unsigned int cpuid);
> -#endif /* __XEN_PROCESSOR_PM_H__ */
> diff --git a/xen/include/xen/cpufreq.h b/xen/include/xen/cpufreq.h
> index ed38a6c..30c70c9 100644
> --- a/xen/include/xen/cpufreq.h
> +++ b/xen/include/xen/cpufreq.h
> @@ -21,7 +21,7 @@
>  #include 
>  #include 
>  
> -#include 
> +#include 
>  
>  DECLARE_PER_CPU(spinlock_t, cpufreq_statistic_lock);
>  
> diff --git a/xen/include/xen/processor_perf.h 
> b/xen/include/xen/processor_perf.h
> new file mode 100644
> index 000..d8a1ba6
> --- /dev/null
> +++ b/xen/include/xen/processor_perf.h
> @@ -0,0 +1,63 @@
> +#ifndef __XEN_PROCESSOR_PM_H__
> +#define __XEN_PROCESSOR_PM_H__
> +
> +#include 
> +#include 
> +#include 
> +
> +#define XEN_PX_INIT 0x8000
> +
> +int powernow_cpufreq_init(void);
> +unsigned int powernow_register_driver(void);
> +unsigned int get_measured_perf(unsigned int cpu, unsigned int flag);
> +void cpufreq_residency_update(unsigned int, uint8_t);
> +void cpufreq_statistic_update(unsigned int, uint8_t, uint8_t);
> +int  cpufreq_statistic_init(unsigned int);
> +void cpufreq_statistic_exit(unsigned int);
> +void cpufreq_statistic_reset(unsigned int);

[Xen-devel] [seabios test] 116733: regressions - FAIL

[osstest service owner]

flight 116733 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/116733/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop   fail REGR. vs. 115539

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail pass in 
116714

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail in 116714 like 115539
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 115539
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 115539
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 seabios  df46d10c8a7b88eb82f3ceb2aa31782dee15593d
baseline version:
 seabios  0ca6d6277dfafc671a5b3718cbeb5c78e2a888ea

Last test of basis   115539  2017-11-03 20:48:58 Z   28 days
Failing since115733  2017-11-10 17:19:59 Z   21 days   36 attempts
Testing same since   116211  2017-11-16 00:20:45 Z   16 days   26 attempts


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

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-xl-qemuu-ws16-amd64 fail
 test-amd64-i386-xl-qemuu-ws16-amd64  fail
 test-amd64-amd64-xl-qemuu-win10-i386 fail
 test-amd64-i386-xl-qemuu-win10-i386  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass



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

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

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

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


Not pushing.


commit df46d10c8a7b88eb82f3ceb2aa31782dee15593d
Author: Stefan Berger 
Date:   Tue Nov 14 15:03:47 2017 -0500

tpm: Add support for TPM2 ACPI table

Add support for the TPM2 ACPI table. If we find it and its
of the appropriate size, we can get the log_area_start_address
and log_area_minimum_size from it.

The latest version of the spec can be found here:

https://trustedcomputinggroup.org/tcg-acpi-specification/

Signed-off-by: Stefan Berger 

commit 0541f2f0f246e77d7c726926976920e8072d1119
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:20:35 2017 -0500

paravirt: Only enable sercon in NOGRAPHIC mode if no other console specified

Signed-off-by: Kevin O'Connor 

commit 9ce6778f08c632c52b25bc8f754291ef18710d53
Author: Kevin O'Connor 
Date:   Fri Nov 10 12:16:36 2017 -0500

docs: Add sercon-port to Runtime_config.md documentation

Signed-off-by: Kevin O'Connor 

commit 63451fca13c75870e1703eb3e20584d9

Re: [Xen-devel] [RFC PATCH 01/31] cpufreq: move cpufreq.h file to the xen/include/xen location

[Stefano Stabellini]

On Thu, 9 Nov 2017, Oleksandr Tyshchenko wrote:
> From: Oleksandr Dmytryshyn 
> 
> Cpufreq driver should be more generalizable (not ACPI-specific).
> Thus this file should be placed to more convenient location.
> 
> This is a rebased version of the original patch:
> https://lists.xen.org/archives/html/xen-devel/2014-11/msg00938.html
> 
> Signed-off-by: Oleksandr Dmytryshyn 
> Signed-off-by: Oleksandr Tyshchenko 
> CC: Jan Beulich 
> CC: Andrew Cooper 
> CC: Stefano Stabellini 
> CC: Julien Grall 

Reviewed-by: Stefano Stabellini 


> ---
>  MAINTAINERS  |   1 +
>  xen/arch/x86/acpi/cpu_idle.c |   2 +-
>  xen/arch/x86/acpi/cpufreq/cpufreq.c  |   2 +-
>  xen/arch/x86/acpi/cpufreq/powernow.c |   2 +-
>  xen/arch/x86/acpi/power.c|   2 +-
>  xen/arch/x86/cpu/mwait-idle.c|   2 +-
>  xen/drivers/acpi/pmstat.c|   2 +-
>  xen/drivers/cpufreq/cpufreq.c|   2 +-
>  xen/drivers/cpufreq/cpufreq_misc_governors.c |   2 +-
>  xen/drivers/cpufreq/cpufreq_ondemand.c   |   4 +-
>  xen/drivers/cpufreq/utility.c|   2 +-
>  xen/include/acpi/cpufreq/cpufreq.h   | 245 --
>  xen/include/xen/cpufreq.h| 248 
> +++
>  13 files changed, 260 insertions(+), 256 deletions(-)
>  delete mode 100644 xen/include/acpi/cpufreq/cpufreq.h
>  create mode 100644 xen/include/xen/cpufreq.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5b9e123..524e067 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -295,6 +295,7 @@ X:xen/arch/x86/acpi/boot.c
>  X:   xen/arch/x86/acpi/lib.c
>  F:   xen/drivers/cpufreq/
>  F:   xen/include/acpi/cpufreq/
> +F:   xen/include/xen/cpufreq.h
>  
>  PUBLIC I/O INTERFACES AND PV DRIVERS DESIGNS
>  M:  Konrad Rzeszutek Wilk 
> diff --git a/xen/arch/x86/acpi/cpu_idle.c b/xen/arch/x86/acpi/cpu_idle.c
> index 482b8a7..c66622e 100644
> --- a/xen/arch/x86/acpi/cpu_idle.c
> +++ b/xen/arch/x86/acpi/cpu_idle.c
> @@ -49,7 +49,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/xen/arch/x86/acpi/cpufreq/cpufreq.c 
> b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> index 1f8d02a..bd82025 100644
> --- a/xen/arch/x86/acpi/cpufreq/cpufreq.c
> +++ b/xen/arch/x86/acpi/cpufreq/cpufreq.c
> @@ -41,7 +41,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  enum {
>  UNDEFINED_CAPABLE = 0,
> diff --git a/xen/arch/x86/acpi/cpufreq/powernow.c 
> b/xen/arch/x86/acpi/cpufreq/powernow.c
> index 8f1ac74..79f55a3 100644
> --- a/xen/arch/x86/acpi/cpufreq/powernow.c
> +++ b/xen/arch/x86/acpi/cpufreq/powernow.c
> @@ -35,7 +35,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define CPUID_FREQ_VOLT_CAPABILITIES0x8007
>  #define CPB_CAPABLE 0x0200
> diff --git a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> index 1e4e568..beebd5a 100644
> --- a/xen/arch/x86/acpi/power.c
> +++ b/xen/arch/x86/acpi/power.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  uint32_t system_reset_counter = 1;
>  
> diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
> index 762dff1..29f0286 100644
> --- a/xen/arch/x86/cpu/mwait-idle.c
> +++ b/xen/arch/x86/cpu/mwait-idle.c
> @@ -58,7 +58,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  #define MWAIT_IDLE_VERSION "0.4.1"
>  #undef PREFIX
> diff --git a/xen/drivers/acpi/pmstat.c b/xen/drivers/acpi/pmstat.c
> index 2a6c4c7..2dbde1c 100644
> --- a/xen/drivers/acpi/pmstat.c
> +++ b/xen/drivers/acpi/pmstat.c
> @@ -38,7 +38,7 @@
>  #include 
>  
>  #include 
> -#include 
> +#include 
>  #include 
>  
>  DEFINE_PER_CPU_READ_MOSTLY(struct pm_px *, cpufreq_statistic_data);
> diff --git a/xen/drivers/cpufreq/cpufreq.c b/xen/drivers/cpufreq/cpufreq.c
> index 212f48f..ab909e2 100644
> --- a/xen/drivers/cpufreq/cpufreq.c
> +++ b/xen/drivers/cpufreq/cpufreq.c
> @@ -43,7 +43,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  static unsigned int __read_mostly usr_min_freq;
>  static unsigned int __read_mostly usr_max_freq;
> diff --git a/xen/drivers/cpufreq/cpufreq_misc_governors.c 
> b/xen/drivers/cpufreq/cpufreq_misc_governors.c
> index 746bbcd..4a5510c 100644
> --- a/xen/drivers/cpufreq/cpufreq_misc_governors.c
> +++ b/xen/drivers/cpufreq/cpufreq_misc_governors.c
> @@ -18,7 +18,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  
>  /*
>   * cpufreq userspace governor
> diff --git a/xen/drivers/cpufreq/cpufreq_ondemand.c 
> b/xen/drivers/cpufreq/cpufreq_ondemand.c
> index fe6c63d..1c384ec 100644
> --- a/xen/drivers/cpufreq/cpufreq_ondemand.c
> +++ b/xen/drivers/cpufreq/cpufreq_ondemand.c
> @@ -1,5 +1,5 @@
>  /*
> - *  xen/arch/x86/acpi/cpufreq/cpufreq_ondemand.c
> + *  xen/drivers/cpufreq/cpufreq_ondemand.c
>   *

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  4cd0fad64590ff8cfce6fa549cee15f8b07b664c
baseline version:
 xen  1002f1a21bfb67bcca27532e7f7c35b1ac8ee1dd

Last test of basis   116757  2017-12-01 18:01:35 Z0 days
Testing same since   116764  2017-12-01 22:17:01 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Boris Ostrovsky 
  Brian Woods 
  Euan Harris 
  Haozhong Zhang 
  Jan Beulich 
  Kevin Tian 
  Paul Durrant 
  Sergey Dyasli 

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



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

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

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

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


Pushing revision :

To osst...@xenbits.xen.org:/home/xen/git/xen.git
   1002f1a..4cd0fad  4cd0fad64590ff8cfce6fa549cee15f8b07b664c -> smoke

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2  broken  in 116625
 build-armhf-pvopsbroken  in 116711
 build-armhf-xsm  broken  in 116711
 build-armhf-xsm 2 hosts-allocate broken in 116711 REGR. vs. 116350
 build-armhf-pvops   2 hosts-allocate broken in 116711 REGR. vs. 116350
 build-armhf-libvirt   7 capture-logs broken in 116711 REGR. vs. 116350
 build-armhf-libvirt   6 libvirt-build  fail in 116711 REGR. vs. 116325
 test-armhf-armhf-xl-multivcpu  1 build-check(1)  running in 116711
 test-armhf-armhf-libvirt  1 build-check(1)   running in 116711
 test-armhf-armhf-libvirt-raw  1 build-check(1)   running in 116711
 test-armhf-armhf-xl   1 build-check(1)   running in 116711
 test-armhf-armhf-xl-vhd   1 build-check(1)   running in 116711
 test-armhf-armhf-xl-credit2   1 build-check(1)   running in 116711
 test-armhf-armhf-xl-cubietruck  1 build-check(1) running in 116711
 test-armhf-armhf-xl-rtds  1 build-check(1)   running in 116711
 test-armhf-armhf-xl-arndale   1 build-check(1)   running in 116711
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   running in 116711
 test-armhf-armhf-xl-xsm   1 build-check(1)   running in 116711
 build-armhf-libvirt   3 syslog-serverrunning in 116711

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  4 host-install(4) broken in 116625 pass in 116731
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 116671 pass in 116625
 test-armhf-armhf-xl-xsm   6 xen-installfail pass in 116671
 test-armhf-armhf-xl-rtds  7 xen-boot   fail pass in 116671
 test-xtf-amd64-amd64-4 21 xtf/test-hvm32-invlpg~shadow fail pass in 116711
 test-xtf-amd64-amd64-4  36 xtf/test-hvm32pae-invlpg~shadow fail pass in 116711
 test-xtf-amd64-amd64-4 48 xtf/test-hvm64-invlpg~shadow fail pass in 116711

Tests which did not succeed, but are not blocking:
 build-armhf-xsm  3 capture-logs broken in 116711 blocked in 116350
 build-armhf-pvops3 capture-logs broken in 116711 blocked in 116350
 test-xtf-amd64-amd64-4 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116625 like 
116305
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116625 
like 116325
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 116625 like 
116350
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 116625 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 116625 never pass
 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116671 like 
116250
 test-armhf-armhf-xl-xsm 13 migrate-support-check fail in 116671 never pass
 test-armhf-armhf-xl-xsm 14 saverestore-support-check fail in 116671 never pass
 test-xtf-amd64-amd64-2 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116711 like 
116250
 test-xtf-amd64-amd64-1 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116711 like 
116350
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail in 116711 like 116350
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 116222
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116325
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116325
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116325
 test-xtf-amd64-amd64-3  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 116350
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 116350
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116350
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116350
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116350
 test-xtf-amd64-amd64-3   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-5   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-4   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-xtf-amd64-amd64-1   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-xtf-amd64-amd64-2   73 xtf/test-pv32pae-xsa-194 fail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  

Re: [Xen-devel] [RFC] WIP: optee: add OP-TEE mediator

[Stefano Stabellini]

On Mon, 27 Nov 2017, Volodymyr Babchuk wrote:
> This is follow-up to our conversation during community call.
> You asked me to send OP-TEE mediator as a patch, so we can
> discuss it in the mailing list. So, there it is. I squashed
> two patches into one and skipped patches that we already
> discussed.
> 
> So, this is basically all what is needed to support OP-TEE in XEN.
> There are some TODOs left all over the code. But, I don't
> expect that TODOs implementation would significantly
> increase codebase. Currently mediator parses requests to perform
> addresses translation and that's all what is should be done
> to allow guests to work with OP-TEE.
> 
> This become possible because I completely revisited virtualization
> support in OP-TEE. I have found way to enforce complete isolation
> between different guest states. This lifts many questions like usage
> quotas, RPC routing, sudden guest death, data isolation, etc.
> 
> I'm aware that I didn't addressed all comments from previous
> discussion. Sorry for this. I'm currently busy with OP-TEE,
> and I think proper mediator implementation will be possible
> only after I'll stabilize OP-TEE part.
> 
> So I don't ask anybody to do thorough review. I just want to
> share my status and discuss this code a whole.

Thank you for sharing! Actually, I think it is not too bad as a starting
point.

I'll also try to summarize some key concept we have been discussing
about OP-TEE support in Xen.


= Xen cannot protect the system from a broken/insecure OP-TEE =

OP-TEE runs at a higher privilege level than Xen, thus, we can't really
expect Xen to protect the system from a broken OP-TEE. Also, Xen cannot
really protect OP-TEE from a malicious caller.

What we can and should do is to protect Xen, the OP-TEE mediator in Xen
specifically, from malicious attackers.

In other words, we are not responsible if a call, forwarded to OP-TEE by
Xen, ends up crashing OP-TEE, therefore taking down the system.

However, we have to pay special care to avoid callers to crash or take
over the mediator in Xen. We also have to pay attention so that a caller
won't be able to exhaust Xen resources or DOS Xen (allocate too much
memory, infinite loops in Xen, etc). This brings me to the next topic.


= Error checking / DOS protection =

We need powerful checks on arguments passed by the caller and evaluated
by the mediator.

For example, we cannot expect the guest to actually pass arguments in
the format expected by translate_params. ctx->xen_arg could be
gibberish.

From the resource allocation point of view, it looks like every
handle_std_call allocates a new context; every copy_std_request
allocates a new Xen page. It would be easy to exhaust Xen resources.
Maybe we need a max concurrent request limit or max page allocation per
domain or something of the kind.


= Locks and Lists =

The current lock and list is global. Do you think it should actually be
global or per-domain? I do realize that only dom0 is allowed to make
calls now so the question for the moment is not too useful.


= Xen command forwarding =

In the code below, it looks like Xen is forwarding everything to OP-TEE.
Are there some commands Xen should avoid forwarding? Should we have a
whitelist or a blacklist?


= Long running OP-TEE commands and interruptions =

I have been told that some OP-TEE RPC commands might take long to
complete. Is that right? Like for example one of the
OPTEE_MSG_RPC_CMD_*?

If so, we need to think what to do in those cases. Specifically, do we
need a technique to restart certain commands in Xen, so that when they
run for too long and get interrupted by something (such as an
interrupt) we know how to restart them? In fact, do we need to setup a
timer interrupt to make sure the command doesn't block Xen for too long,
consuming the next vcpu's slot as well?


= Page pinning =

Guest pages passed to OP-TEE need to be pinned (otherwise Xen doesn't
guarantee they'll be available). I think the right function to call for
that is get_page_from_gfn or get_page.



> ---
> 
> Add OP-TEE mediator as an example how TEE mediator framework
> works.
> 
> OP-TEE mediator support address translation for DomUs.
> It tracks execution of STD calls, correctly handles memory-related RPC
> requests, tracks buffer allocated for RPCs.
> 
> With this patch OP-TEE successfully passes own tests, while client is
> running in DomU. Currently it lacks some code for exceptional cases,
> because this patch was used mostly to debug virtualization in OP-TEE.
> Nevertheless, it provides all features needed for OP-TEE mediation.
> 
> WARNING: This is a development patch, it does not cover all corner
> cases, so, please don't use it in production.
> 
> It was tested on RCAR Salvator-M3 board.
> 
> Signed-off-by: Volodymyr Babchuk 
> ---
>  xen/arch/arm/tee/Kconfig |   4 +
>  xen/arch/arm/tee/Makefile|   1 +
>  xen/arch/arm/tee/optee.c | 765 
> +++
>  xen/arch/arm/tee/optee_smc.h |  5

[Xen-devel] [xen-unstable baseline-only test] 72506: regressions - FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-examine 11 examine-serial/bootloader fail REGR. vs. 72503
 test-armhf-armhf-examine 12 examine-serial/kernel fail REGR. vs. 72503
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail 
REGR. vs. 72503
 test-amd64-i386-freebsd10-i386 19 guest-start/freebsd.repeat fail REGR. vs. 
72503
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-saverestore fail REGR. vs. 72503
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 21 leak-check/check fail REGR. vs. 
72503

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 72503
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail like 72503
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail like 72503
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   like 72503
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   like 72503
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   like 72503
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail like 72503
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail like 72503
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 72503
 test-amd64-amd64-examine  4 memdisk-try-append   fail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 10 windows-install fail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win10-i386 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 17 guest-stop fail never pass

version targeted for testing:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e
baseline version:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c

Last test of basis72503  2017-11-30 12:18:52 Z1 days
Testing same since72506  2017-12-01 13:45:48 Z0 days1 attempts


People who touched revisions under test:
  Andre Przywara 
  Andrew Cooper 
  Stewart Hildebrand 

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

Re: [Xen-devel] [PATCH 2/2] gnttab: improve GNTTABOP_cache_flush locking

[Stefano Stabellini]

On Thu, 30 Nov 2017, Jan Beulich wrote:
> Dropping the lock before returning from grant_map_exists() means handing
> possibly stale information back to the caller. Return back the pointer
> to the active entry instead, for the caller to release the lock once
> done.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Stefano Stabellini 


> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -786,10 +786,10 @@ static int _set_status(unsigned gt_versi
>  return _set_status_v2(domid, readonly, mapflag, shah, act, status);
>  }
>  
> -static int grant_map_exists(const struct domain *ld,
> -struct grant_table *rgt,
> -unsigned long mfn,
> -grant_ref_t *cur_ref)
> +static struct active_grant_entry *grant_map_exists(const struct domain *ld,
> +   struct grant_table *rgt,
> +   unsigned long mfn,
> +   grant_ref_t *cur_ref)
>  {
>  grant_ref_t ref, max_iter;
>  
> @@ -805,28 +805,20 @@ static int grant_map_exists(const struct
> nr_grant_entries(rgt));
>  for ( ref = *cur_ref; ref < max_iter; ref++ )
>  {
> -struct active_grant_entry *act;
> -bool_t exists;
> -
> -act = active_entry_acquire(rgt, ref);
> -
> -exists = act->pin
> -&& act->domid == ld->domain_id
> -&& act->frame == mfn;
> +struct active_grant_entry *act = active_entry_acquire(rgt, ref);
>  
> +if ( act->pin && act->domid == ld->domain_id && act->frame == mfn )
> +return act;
>  active_entry_release(act);
> -
> -if ( exists )
> -return 0;
>  }
>  
>  if ( ref < nr_grant_entries(rgt) )
>  {
>  *cur_ref = ref;
> -return 1;
> +return NULL;
>  }
>  
> -return -EINVAL;
> +return ERR_PTR(-EINVAL);
>  }
>  
>  #define MAPKIND_READ 1
> @@ -3213,6 +3205,7 @@ static int cache_flush(const gnttab_cach
>  struct domain *d, *owner;
>  struct page_info *page;
>  unsigned long mfn;
> +struct active_grant_entry *act = NULL;
>  void *v;
>  int ret;
>  
> @@ -3250,13 +3243,13 @@ static int cache_flush(const gnttab_cach
>  {
>  grant_read_lock(owner->grant_table);
>  
> -ret = grant_map_exists(d, owner->grant_table, mfn, cur_ref);
> -if ( ret != 0 )
> +act = grant_map_exists(d, owner->grant_table, mfn, cur_ref);
> +if ( IS_ERR_OR_NULL(act) )
>  {
>  grant_read_unlock(owner->grant_table);
>  rcu_unlock_domain(d);
>  put_page(page);
> -return ret;
> +return act ? PTR_ERR(act) : 1;
>  }
>  }
>  
> @@ -3273,7 +3266,11 @@ static int cache_flush(const gnttab_cach
>  ret = 0;
>  
>  if ( d != owner )
> +{
> +active_entry_release(act);
>  grant_read_unlock(owner->grant_table);
> +}
> +
>  unmap_domain_page(v);
>  put_page(page);
>  
> 
> 
> 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  1002f1a21bfb67bcca27532e7f7c35b1ac8ee1dd
baseline version:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e

Last test of basis   116673  2017-11-29 13:02:46 Z2 days
Testing same since   116752  2017-12-01 16:02:04 Z0 days2 attempts


People who touched revisions under test:
  Ian Jackson 

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 :

To osst...@xenbits.xen.org:/home/xen/git/xen.git
   6da091d..1002f1a  1002f1a21bfb67bcca27532e7f7c35b1ac8ee1dd -> smoke

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

Re: [Xen-devel] [PATCH 1/2] gnttab: correct GNTTABOP_cache_flush empty batch handling

[Stefano Stabellini]

On Thu, 30 Nov 2017, Jan Beulich wrote:
> Jann validly points out that with a caller bogusly requesting a zero-
> element batch with non-zero high command bits (the ones used for
> continuation encoding), the assertion right before the call to
> hypercall_create_continuation() would trigger. A similar situation would
> arise afaict for non-empty batches with op and/or length zero in every
> element.
> 
> While we want the former to succeed (as we do elsewhere for similar
> no-op requests), the latter can clearly be converted to an error, as
> this is a state that can't be the result of a prior operation.
> 
> Take the opportunity and also correct the order of argument checks:
> We shouldn't accept zero-length elements with unknown bits set in "op".
> Also constify cache_flush()'s first parameter.
> 
> Reported-by: Jann Horn 
> Signed-off-by: Jan Beulich 

Acked-by: Stefano Stabellini 


> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3208,7 +3208,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_P
>  return 0;
>  }
>  
> -static int cache_flush(gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
> +static int cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t 
> *cur_ref)
>  {
>  struct domain *d, *owner;
>  struct page_info *page;
> @@ -3218,19 +3218,17 @@ static int cache_flush(gnttab_cache_flus
>  
>  if ( (cflush->offset >= PAGE_SIZE) ||
>   (cflush->length > PAGE_SIZE) ||
> - (cflush->offset + cflush->length > PAGE_SIZE) )
> + (cflush->offset + cflush->length > PAGE_SIZE) ||
> + (cflush->op & ~(GNTTAB_CACHE_INVAL | GNTTAB_CACHE_CLEAN)) )
>  return -EINVAL;
>  
>  if ( cflush->length == 0 || cflush->op == 0 )
> -return 0;
> +return !*cur_ref ? 0 : -EILSEQ;
>  
>  /* currently unimplemented */
>  if ( cflush->op & GNTTAB_CACHE_SOURCE_GREF )
>  return -EOPNOTSUPP;
>  
> -if ( cflush->op & ~(GNTTAB_CACHE_INVAL|GNTTAB_CACHE_CLEAN) )
> -return -EINVAL;
> -
>  d = rcu_lock_current_domain();
>  mfn = cflush->a.dev_bus_addr >> PAGE_SHIFT;
>  
> @@ -3310,6 +3308,9 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARA
>  *cur_ref = 0;
>  guest_handle_add_offset(uop, 1);
>  }
> +
> +*cur_ref = 0;
> +
>  return 0;
>  }
>  
> 
> 
> 

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

Re: [Xen-devel] unable to start VM after xen upgrade to 4.8.2

[Alex Braunegg]

Hi Paul,

> That's QEMU failing to start which is, most likely, an incompatibility
between libxl and the QEMU command line. With any luck you should have a log

> file called /var/log/xen/qemu-dm-.log which in which QEMU
should say what it is unhappy about.

On checking the suggested log there is the following entry:

qemu-system-i386: -vnc 0.0.0.0:0,websocket,x509=/etc/pki/xen,password,to=99:
Failed to start VNC server: address resolution failed for 0.0.0.0:on:
Servname not supported for ai_socktype

As I use websockets to present the display via a HTML5 canvas it appears
that I have been hit with a QEMU regression due to the bundled version
(2.7.0) of QEMU with xen 4.8.2:

https://github.com/qemu/qemu/commit/1b1aeb5828c978af2ec4478e552884004f23c470
#diff-446cee24164cdeb527aa48c13210c9c2

Applying that fix resolves the guest failing to start, however websockets is
still not fully functional unlike when using 4.6.6. Will have to downgrade /
upgrade the bundled version of QEMU locally.

Thanks for the advice,

Alex


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

[Xen-devel] [xen-4.10-testing baseline test] 116747: tolerable FAIL

[osstest service owner]

"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate.  The baseline, if
any, is the most recent actually tested revision.

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-xl-qemut-debianhvm-amd64 16 guest-localmigrate/x10 fail never 
pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail   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-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e
baseline version:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e

Last test of basis   116747  2017-12-01 15:16:16 Z0 days
Testing same since  (not found) 0 attempts

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

[Xen-devel] [PATCH v3] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

[Boris Ostrovsky]

Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
guests looking at IF flag directly will always see it set, resulting
in 'ud2'.

Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
when running paravirt.

Signed-off-by: Boris Ostrovsky 
---
V3:
* Use CLBR_RAX to preserve all registers except %rax


 arch/x86/entry/entry_64.S|7 ---
 arch/x86/include/asm/irqflags.h  |3 +++
 arch/x86/include/asm/paravirt.h  |9 +
 arch/x86/kernel/asm-offsets_64.c |3 +++
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index f81d50d..18474bb 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -466,12 +466,13 @@ END(irq_entries_start)
 
 .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
 #ifdef CONFIG_DEBUG_ENTRY
-   pushfq
-   testl $X86_EFLAGS_IF, (%rsp)
+   pushq %rax
+   SAVE_FLAGS(CLBR_RAX)
+   testl $X86_EFLAGS_IF, %eax
jz .Lokay_\@
ud2
 .Lokay_\@:
-   addq $8, %rsp
+   popq %rax
 #endif
 .endm
 
diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
index c8ef23f..89f0895 100644
--- a/arch/x86/include/asm/irqflags.h
+++ b/arch/x86/include/asm/irqflags.h
@@ -142,6 +142,9 @@ static inline notrace unsigned long 
arch_local_irq_save(void)
swapgs; \
sysretl
 
+#ifdef CONFIG_DEBUG_ENTRY
+#define SAVE_FLAGS(x)  pushfq; popq %rax
+#endif
 #else
 #define INTERRUPT_RETURN   iret
 #define ENABLE_INTERRUPTS_SYSEXIT  sti; sysexit
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 283efca..892df37 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -927,6 +927,15 @@ static inline notrace unsigned long 
arch_local_irq_save(void)
PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64),   \
  CLBR_NONE,\
  jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret64))
+
+#ifdef CONFIG_DEBUG_ENTRY
+#define SAVE_FLAGS(clobbers)\
+   PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_save_fl), clobbers, \
+ PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\
+ call PARA_INDIRECT(pv_irq_ops+PV_IRQ_save_fl);\
+ PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);)
+#endif
+
 #endif /* CONFIG_X86_32 */
 
 #endif /* __ASSEMBLY__ */
diff --git a/arch/x86/kernel/asm-offsets_64.c b/arch/x86/kernel/asm-offsets_64.c
index 630212f..e3a5175 100644
--- a/arch/x86/kernel/asm-offsets_64.c
+++ b/arch/x86/kernel/asm-offsets_64.c
@@ -23,6 +23,9 @@ int main(void)
 #ifdef CONFIG_PARAVIRT
OFFSET(PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);
OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
+#ifdef CONFIG_DEBUG_ENTRY
+   OFFSET(PV_IRQ_save_fl, pv_irq_ops, save_fl);
+#endif
BLANK();
 #endif
 
-- 
1.7.1


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

[Xen-devel] [linux-3.18 test] 116728: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 16 
guest-localmigrate/x10 fail REGR. vs. 116501

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116501
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116501
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116501
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116501
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116501
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116501
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116501
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxb42518053ffd221d79cff2df8c0257db88a71334
baseline version:
 linux7166ceea0a4eba3f8c86925ad60e6f0543db6234

Last test of basis   116501  2017-11-24 09:56:28 Z7 days
Testing same since   116707  2017-11-30 09:15:35 Z1 days2 attempts


People who touched revisions under test:
  Aaron Brown 
  Al Viro 
  Amit Pundir 
  Andreas Rohner 
  Andrew Bowers 
  Andrew Elble 
  Andrew Morton 
  Anna Schumaker 
  Arnd Bergmann 
  Bart Van Assche 
  Ben Hutchings 
  Benjamin Poirier 
  Bjorn Helgaas 
  Boris Brezillon 
  Brent Taylor 
  Brian King 
  Chuck Lever 
  Coly Li 
  Cong Wang 
  Dan Carpenter 
  Daniel Vetter 
  Daniel Vetter 
  David Ahern 
  David S. Miller 
  David Sterba 
  Doug Ledford 
  Eric Biggers 
  Florian Westphal 
  Gabriele Mazzotta 
  Greg Kroah-Hartman 
  Hans Verkuil 
  Harsh Shandilya 
  Heiko Carstens 
  Helge Deller 
  Herbert Xu 
  Hou Tao 
  Ian Ke

[Xen-devel] [libvirt test] 116732: tolerable all pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 libvirt  adcc31bb89e47ef642cbcfcff372131db7cd8d8b
baseline version:
 libvirt  681bc423e823ab86b20748db311721bdef20defe

Last test of basis   116698  2017-11-30 04:26:19 Z1 days
Testing same since   116732  2017-12-01 04:44:32 Z0 days1 attempts


People who touched revisions under test:
  Daniel P. Berrange 
  Ján Tomko 
  Pavel Hrdina 
  Peter Krempa 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-amd64-i386-libvirt-qcow2pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd 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 :

To osst...@xenbits.xen.org:/home/xen/git/libvirt.git
   681bc42..adcc31b  adcc31bb89e47ef642cbcfcff372131db7cd8d8b -> 
xen-tested-master

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

Re: [Xen-devel] [PATCH 7/9] x86/vvmx: Use correct sizes when reading operands

[Andrew Cooper]

On 28/11/17 08:32, Jan Beulich wrote:
 On 26.10.17 at 19:03,  wrote:
>> * invvpid has a 128-bit memory operand but we only require the VPID value
>>   which lies in the lower 64 bits.
> The memory operand (wrongly) isn't being read at all - I don't
> understand the above bullet point for that reason.
>
>> @@ -464,6 +462,8 @@ static int decode_vmx_inst(struct cpu_user_regs *regs,
>>  unsigned long base, index, seg_base, disp, offset;
>>  int scale, size;
>>  
>> +unsigned int bytes = vmx_guest_x86_mode(v);
>> +
> Except in extraordinary circumstances please don't add blank lines in
> the middle of declarations.
>
> Also - don't you get 2 here for 16-bit protected mode, which you'd
> need to convert to 4?

We can never reach this point from a 16 bit segment.  All VMX
instructions #UD if executed outside of a 64bit (in long mode) or 32bit
(outside of long mode) segment.

>
>> @@ -1801,7 +1803,7 @@ int nvmx_handle_vmptrst(struct cpu_user_regs *regs)
>>  gpa = nvcpu->nv_vvmcxaddr;
>>  
>>  rc = hvm_copy_to_guest_linear(decode.op[0].mem, &gpa,
>> -  decode.op[0].len, 0, &pfinfo);
>> +  decode.op[0].bytes, 0, &pfinfo);
> Just like for vmptrld the operand size is uniformly 64 bits here.
>
>> @@ -1987,9 +1989,9 @@ int nvmx_handle_invept(struct cpu_user_regs *regs)
>>  {
>>  case INVEPT_SINGLE_CONTEXT:
>>  {
>> -unsigned long eptp;
>> +uint64_t eptp;
>>  
>> -ret = operand_read(&eptp, &decode.op[0], regs, decode.op[0].len);
>> +ret = operand_read(&eptp, &decode.op[0], regs, sizeof(eptp));
> I think you should read the full 128 bits for correct faulting behavior
> (also for invvpid). I also can't derive from the SDM that this reading
> won't occur for the INVEPT_ALL_CONTEXT case. Sadly the SDM
> doesn't say whether the reserved upper half is enforced to be zero
> (which we would then need to emulate), or whether it is being
> ignored. For invvpid however it does state that bits 16:63 are being
> checked.

Observations on real hardware to the contrary.  Each of the generations
I've tried never read the operand, or the part of the operand that they
don't need.

It makes sense from a performance point of view.  No point having
microcode make unnecessary memory accesses.

~Andrew

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

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Andrew Cooper]

On 01/12/17 16:55, Jan Beulich wrote:
 Julien Grall  12/01/17 5:14 PM >>>
>> On 30/11/17 14:28, Jan Beulich wrote:
>> On 28.11.17 at 15:05,  wrote:
 A call to handle_hvm_io_completion() is needed for completing I/O
 that requires external emulation. Such completion should be requested when
 hvm_vcpu_io_need_completion() returns true after hvm_emulate_once() has
 completed. This is indicative of the underlying I/O emulation having
 returned X86EMUL_RETRY and hence a re-emulation of the instruction is
 needed to pick up the result of the I/O.

 A call to handle_hvm_io_completion() is NOT needed when the underlying
 I/O has not returned X86EMUL_RETRY since there will be no result to pick
 up. Hence it bogus to request such completion when mmio_retry is set,
 since this can only happen if the underlying I/O emulation has returned
 X86EMUL_OKAY (meaning the I/O has completed successfully).

 Reported-by: Andrew Cooper 
 Signed-off-by: Paul Durrant 
 Reviewed-by: Jan Beulich 
>>> Hmm, I notice Paul didn't Cc you on this one - despite it getting late,
>>> this is still something to be considered for 4.10. It's certainly going
>>> to be a backporting candidate.
>> Release-acked-by: Julien Grall 
> Thanks.
>
>> Could this be committed today?
> Not by me; I'm not in the office anymore. Perhaps Andrew could, together with
> the other (his) one you've sent an ack for.

I'll get these sorted, and put onto the 4.10 branch.

~Andrew

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

Re: [Xen-devel] [PATCH v2] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

[Andy Lutomirski]

On Fri, Dec 1, 2017 at 8:57 AM, Boris Ostrovsky
 wrote:
> On 12/01/2017 11:22 AM, Andy Lutomirski wrote:
>> On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
>>  wrote:
>>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>>> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
>>> eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
>>> guests looking at IF flag directly will always see it set, resulting
>>> in 'ud2'.
>>>
>>> Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
>>> when running paravirt.
>>>
>>> Signed-off-by: Boris Ostrovsky 
>>> ---
>>> V2:
>>> * Preserve %rax in DEBUG_ENTRY_ASSERT_IRQS_OFF
>>> * Return (pop) %rax in SAVE_FLAGS for !CONFIG_PARAVIRT (irqflags.h)
>>>
>>>  arch/x86/entry/entry_64.S|7 ---
>>>  arch/x86/include/asm/irqflags.h  |3 +++
>>>  arch/x86/include/asm/paravirt.h  |9 +
>>>  arch/x86/kernel/asm-offsets_64.c |3 +++
>>>  4 files changed, 19 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>>> index f81d50d..c208dc1 100644
>>> --- a/arch/x86/entry/entry_64.S
>>> +++ b/arch/x86/entry/entry_64.S
>>> @@ -466,12 +466,13 @@ END(irq_entries_start)
>>>
>>>  .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
>>>  #ifdef CONFIG_DEBUG_ENTRY
>>> -   pushfq
>>> -   testl $X86_EFLAGS_IF, (%rsp)
>>> +   pushq %rax
>>> +   SAVE_FLAGS(CLBR_ANY)
>>> +   testl $X86_EFLAGS_IF, %eax
>> Confused.  You're both using CLBR_ANY and RAX.  Did you perhaps mean 
>> CLBR_NONE?
>
> CLBR_NONE will restore all registers, won't it? So it should be
> CLBR_RAX, should it? Otherwise we'll lose return value.

Ugh, probably right.  I've never grokked exactly what CLBR_ does.

>
> -boris
>
>>
>>> jz .Lokay_\@
>>> ud2
>>>  .Lokay_\@:
>>> -   addq $8, %rsp
>>> +   popq %rax
>>>  #endif
>>>  .endm
>>>
>>>
>

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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-debianhvm-i386 16 guest-localmigrate/x10 fail REGR. 
vs. 116673

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

version targeted for testing:
 xen  1002f1a21bfb67bcca27532e7f7c35b1ac8ee1dd
baseline version:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e

Last test of basis   116673  2017-11-29 13:02:46 Z2 days
Testing same since   116752  2017-12-01 16:02:04 Z0 days1 attempts


People who touched revisions under test:
  Ian Jackson 

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



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

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

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

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


Not pushing.


commit 1002f1a21bfb67bcca27532e7f7c35b1ac8ee1dd
Author: Ian Jackson 
Date:   Fri Dec 1 15:06:11 2017 +

README, Makefiles, Config.mk: Update for branching 4.10 vs 4.11-unstable

Signed-off-by: Ian Jackson 
(qemu changes not included)

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

Re: [Xen-devel] [systemd-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Lennart Poettering]

On Fr, 01.12.17 12:04, Olaf Hering (o...@aepfle.de) wrote:

> Am Fri, 1 Dec 2017 10:21:46 +
> schrieb Wei Liu :
> 
> > In Olaf's case, he cares about knowing whether the domain runs the
> > controlling toolstack, he doesn't care about if it is the hardware
> > domain or not, so my conclusion was using that flag was wrong.
> 
> I think this is not entirely accurate. Right now the term "dom0" is 
> a mix of "has access to host (IO) hardware" and "runs the toolstack".
> 
> ConditionVirtualization= today lacks such details as well.
> "xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
> so that all services that want access to "host hardware" can start.
> 
> One could argue that passing a PCI device to a domU may also require
> .service files to manage that PCI device in some way. The specifc case
> which triggered all the suggested changes was smartd, which is not
> supposed to run in "VMs". If a SATA card is provided to a domU it may
> be a good idea to monitor the attached disks as well.
> 
> So in some way Jan is correct with his suggestion to use XENFEAT_dom0
> instead of "control_d". I will do some research about when it became available
> and update the patch description.

To make this clear: systemd is only interested in a very high-level
view on things: all it wants to know if we are payload of some kind of
virtualization, or not. We aren't interested in details, and what kind
of virtualization logic Xen precisely deploys is an implementation
detail from our point of view, that we aren't interested in. If
services need to know in all detail what kind of system they run on,
then ConditionVirtualization=/AssertVirtualization= is really not for
them, and they should just run their own code, and figure out things
on their own.

I don't care much where precisely the line is drawn, when a Xen
environment is considered "host" and when "guest", I'll let you guys
figure that out. Only for the latter ConditionVirtualization=guest
should hold, for the latter it should not.

Lennart

-- 
Lennart Poettering, Red Hat

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

Re: [Xen-devel] [PATCH v2] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

[Boris Ostrovsky]

On 12/01/2017 11:22 AM, Andy Lutomirski wrote:
> On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
>  wrote:
>> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
>> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
>> eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
>> guests looking at IF flag directly will always see it set, resulting
>> in 'ud2'.
>>
>> Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
>> when running paravirt.
>>
>> Signed-off-by: Boris Ostrovsky 
>> ---
>> V2:
>> * Preserve %rax in DEBUG_ENTRY_ASSERT_IRQS_OFF
>> * Return (pop) %rax in SAVE_FLAGS for !CONFIG_PARAVIRT (irqflags.h)
>>
>>  arch/x86/entry/entry_64.S|7 ---
>>  arch/x86/include/asm/irqflags.h  |3 +++
>>  arch/x86/include/asm/paravirt.h  |9 +
>>  arch/x86/kernel/asm-offsets_64.c |3 +++
>>  4 files changed, 19 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>> index f81d50d..c208dc1 100644
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -466,12 +466,13 @@ END(irq_entries_start)
>>
>>  .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
>>  #ifdef CONFIG_DEBUG_ENTRY
>> -   pushfq
>> -   testl $X86_EFLAGS_IF, (%rsp)
>> +   pushq %rax
>> +   SAVE_FLAGS(CLBR_ANY)
>> +   testl $X86_EFLAGS_IF, %eax
> Confused.  You're both using CLBR_ANY and RAX.  Did you perhaps mean 
> CLBR_NONE?

CLBR_NONE will restore all registers, won't it? So it should be
CLBR_RAX, should it? Otherwise we'll lose return value.

-boris

>
>> jz .Lokay_\@
>> ud2
>>  .Lokay_\@:
>> -   addq $8, %rsp
>> +   popq %rax
>>  #endif
>>  .endm
>>
>>


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

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Jan Beulich]

>>> Julien Grall  12/01/17 5:14 PM >>>
>On 30/11/17 14:28, Jan Beulich wrote:
> On 28.11.17 at 15:05,  wrote:
>>> A call to handle_hvm_io_completion() is needed for completing I/O
>>> that requires external emulation. Such completion should be requested when
>>> hvm_vcpu_io_need_completion() returns true after hvm_emulate_once() has
>>> completed. This is indicative of the underlying I/O emulation having
>>> returned X86EMUL_RETRY and hence a re-emulation of the instruction is
>>> needed to pick up the result of the I/O.
>>>
>>> A call to handle_hvm_io_completion() is NOT needed when the underlying
>>> I/O has not returned X86EMUL_RETRY since there will be no result to pick
>>> up. Hence it bogus to request such completion when mmio_retry is set,
>>> since this can only happen if the underlying I/O emulation has returned
>>> X86EMUL_OKAY (meaning the I/O has completed successfully).
>>>
>>> Reported-by: Andrew Cooper 
>>> Signed-off-by: Paul Durrant 
>>> Reviewed-by: Jan Beulich 
>> 
>> Hmm, I notice Paul didn't Cc you on this one - despite it getting late,
>> this is still something to be considered for 4.10. It's certainly going
>> to be a backporting candidate.
>
>Release-acked-by: Julien Grall 

Thanks.

>Could this be committed today?

Not by me; I'm not in the office anymore. Perhaps Andrew could, together with
the other (his) one you've sent an ack for.

Jan


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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Jan Beulich]

>>> Wei Liu  12/01/17 1:30 PM >>>
>On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 13:15,  wrote:
>> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >> >>> On 01.12.17 at 12:48,  wrote:
>> >> > Suppose at one point we split hardware domain and control domain, which
>> >> > one will you call Dom0? Which one will get the flag?
>> >> 
>> >> There can only be one hardware domain, which will continue to
>> >> be the one getting XENFEAT_dom0. There could be any number
>> >> of control domains (perhaps with some coordination between
>> >> them).
>> > 
>> > Right. So XENFEAT_dom0 is not really what Olaf needs. 
>> 
>> Sigh. What does "has access to all the hardware" translate to
>> for you?
>
>That would mean hardware domain.
>
>But Olaf needs to know if some of the services like xenconsoled or
>xenstored should be started, and if some of the special file systems
>should be mounted, right? Those aren't tied to hardware in anyway. In my
>view that's the responsibility of the toolstack control domain.
>
>Can you point me to the start of your discussion with Olaf so that I can
>check what the disagreement between you and Olaf is about?

The start of the discussion is the root of this thread. Olaf somewhere in
the middle pointed to another discussion which you appear to have been
involved in.

I'm also not sure there's actual disagreement here - I was merely pointing
out that strictly following what was written in the description of the patch
there may not be a need to consult /proc/xen, and hence no need to
mount it early.

Jan


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

[Xen-devel] [linux-4.9 test] 116725: regressions - FAIL

[osstest service owner]

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

Regressions :-(

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

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop  fail blocked in 116531
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116531
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 116531
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116531
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 116531
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux8743ce3d7c9698285310920c443c086e337aef44
baseline version:
 linux133e6ccf46f1704a4a680ef45565e970ac9a7f9c

Last test of basis   116531  2017-11-25 16:32:41 Z5 days
Testing same since   116704  2017-11-30 09:15:59 Z1 days2 attempts


People who touched revisions under test:
  Aaron Brown 
  Abhishek Sahu 
  Al Viro 
  Alexey Khoroshilov 
  Alistair Hamilton 
  Amit Pundir 
  Amitkumar Karwar 
  Andreas Rohner 
  Andrew Bowers 
  Andrew Elble 
  Andrew Morton 
  Andrey Konovalov 
  Andy Lutomirski 
  Anna Schumaker 
  Arnd Bergmann 
  Avinash Repaka 
  Bart Van Assche 
  Bartosz Golaszewski 
  Bartosz Markowski 
  Benjamin Poirier 
  Bjorn Helgaas 
  Boris Brezillon 
  Brent Taylor 
  Brian King 
  Catalin Marinas 
  chenxiang (M) 
  Chris Wilson 
  Christian Lamparter 
  Christoph Hellwig 
  Christophe JAILLET 
  Chuck Lever 
  Colin Ian King 
  Coly Li 
  Cong Wang 
  Dan Carpenter 
  Dan 

Re: [Xen-devel] [PATCH v2] x86/entry/64/paravirt: Use paravirt-safe macro to access eflags

[Andy Lutomirski]

On Tue, Nov 28, 2017 at 7:28 AM, Boris Ostrovsky
 wrote:
> Commit 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make
> them NMI-safe") added DEBUG_ENTRY_ASSERT_IRQS_OFF macro that acceses
> eflags using 'pushfq' instruction when testing for IF bit. On PV Xen
> guests looking at IF flag directly will always see it set, resulting
> in 'ud2'.
>
> Introduce SAVE_FLAGS() macro that will use appropriate save_fl pv op
> when running paravirt.
>
> Signed-off-by: Boris Ostrovsky 
> ---
> V2:
> * Preserve %rax in DEBUG_ENTRY_ASSERT_IRQS_OFF
> * Return (pop) %rax in SAVE_FLAGS for !CONFIG_PARAVIRT (irqflags.h)
>
>  arch/x86/entry/entry_64.S|7 ---
>  arch/x86/include/asm/irqflags.h  |3 +++
>  arch/x86/include/asm/paravirt.h  |9 +
>  arch/x86/kernel/asm-offsets_64.c |3 +++
>  4 files changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index f81d50d..c208dc1 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -466,12 +466,13 @@ END(irq_entries_start)
>
>  .macro DEBUG_ENTRY_ASSERT_IRQS_OFF
>  #ifdef CONFIG_DEBUG_ENTRY
> -   pushfq
> -   testl $X86_EFLAGS_IF, (%rsp)
> +   pushq %rax
> +   SAVE_FLAGS(CLBR_ANY)
> +   testl $X86_EFLAGS_IF, %eax

Confused.  You're both using CLBR_ANY and RAX.  Did you perhaps mean CLBR_NONE?

> jz .Lokay_\@
> ud2
>  .Lokay_\@:
> -   addq $8, %rsp
> +   popq %rax
>  #endif
>  .endm
>
> diff --git a/arch/x86/include/asm/irqflags.h b/arch/x86/include/asm/irqflags.h
> index c8ef23f..89f0895 100644
> --- a/arch/x86/include/asm/irqflags.h
> +++ b/arch/x86/include/asm/irqflags.h
> @@ -142,6 +142,9 @@ static inline notrace unsigned long 
> arch_local_irq_save(void)
> swapgs; \
> sysretl
>
> +#ifdef CONFIG_DEBUG_ENTRY
> +#define SAVE_FLAGS(x)  pushfq; popq %rax
> +#endif
>  #else
>  #define INTERRUPT_RETURN   iret
>  #define ENABLE_INTERRUPTS_SYSEXIT  sti; sysexit
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 283efca..892df37 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -927,6 +927,15 @@ static inline notrace unsigned long 
> arch_local_irq_save(void)
> PARA_SITE(PARA_PATCH(pv_cpu_ops, PV_CPU_usergs_sysret64),   \
>   CLBR_NONE,\
>   jmp PARA_INDIRECT(pv_cpu_ops+PV_CPU_usergs_sysret64))
> +
> +#ifdef CONFIG_DEBUG_ENTRY
> +#define SAVE_FLAGS(clobbers)\
> +   PARA_SITE(PARA_PATCH(pv_irq_ops, PV_IRQ_save_fl), clobbers, \
> + PV_SAVE_REGS(clobbers | CLBR_CALLEE_SAVE);\
> + call PARA_INDIRECT(pv_irq_ops+PV_IRQ_save_fl);\
> + PV_RESTORE_REGS(clobbers | CLBR_CALLEE_SAVE);)
> +#endif
> +
>  #endif /* CONFIG_X86_32 */
>
>  #endif /* __ASSEMBLY__ */
> diff --git a/arch/x86/kernel/asm-offsets_64.c 
> b/arch/x86/kernel/asm-offsets_64.c
> index 630212f..e3a5175 100644
> --- a/arch/x86/kernel/asm-offsets_64.c
> +++ b/arch/x86/kernel/asm-offsets_64.c
> @@ -23,6 +23,9 @@ int main(void)
>  #ifdef CONFIG_PARAVIRT
> OFFSET(PV_CPU_usergs_sysret64, pv_cpu_ops, usergs_sysret64);
> OFFSET(PV_CPU_swapgs, pv_cpu_ops, swapgs);
> +#ifdef CONFIG_DEBUG_ENTRY
> +   OFFSET(PV_IRQ_save_fl, pv_irq_ops, save_fl);
> +#endif
> BLANK();
>  #endif
>
> --
> 1.7.1
>

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

Re: [Xen-devel] [PATCH] migration, xen: Fix block image lock issue on live migration

[Julien Grall]

Hi Anthony,

On 29/11/17 15:06, Anthony PERARD wrote:

On Wed, Nov 29, 2017 at 12:28:39PM +, Julien Grall wrote:

+ Stefano

On 11/27/2017 03:00 PM, Anthony PERARD wrote:

Hi Julien,


Hi Anthony,



Can I get a release-ack for this patch?

This fix local live migration of HVM guest when the disk backend is
qdisk.  osstest doesn't report a regression because the kernel or the
glibc is just a bit too old.


When does that regression happen? I am considering to release Xen 4.10 soon
and would need more details to decide the inclusion of the patch.


That can happen when an API call Open File Description Locks
(F_OFD_GETLK and F_OFD_SETLK) is available. There are since Linux 3.15
and glibc 2.20.

When this API is available, QEMU is going to set a lock on the file open
for a block device. When we try to live migrate a guest and the lock is
set, the new QEMU is going to fail to open the disk with an error
message that say something like "file locked", and migration fail.

The scenario when the lock is an issue are:
- an HVM guest which us qdisk for disk backend. (Like when the disk
   image is in a format different than raw. e.g. qcow2)
- an HVM guest which only use emulated disk.


BUT I can't reproduce the issue with the QEMU we are going to release...
so there is probably a race involve. I guess the patch can wait.


I will defer it to Xen 4.11. We might want to Release notes thought.

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH V2] Xen/pciback: Implement PCI slot or bus reset with 'do_flr' SysFS attribute

[Govinda Tatti]

On 11/30/2017 8:46 AM, Jan Beulich wrote:

On 30.11.17 at 15:15,  wrote:

On 11/30/2017 2:27 AM, Jan Beulich wrote:

On 29.11.17 at 18:38,  wrote:
In the case of bus or slot reset, our goal is to reset connected PCIe
fabric/card/endpoint.
The connected card/endpoint can be multi-function device. So, same
walk-through and checking
is needed irrespective of type of reset being used.

I don't follow: The scope of other devices/functions possibly
affected by a reset depends on the type of reset, doesn't it?

For PCIe platforms, both slot and bus reset endup resetting all connected
device/functions on thesecondary bus (behind the root-port or
downstream-port).

According to my understanding this contradicts the comment
ahead of pci_reset_slot(), which talks of multiple slots per bus.
In such a setup, I can't see why resetting on slot would affect
other slots on the same bus. At the same time the comment
says that the slot reset may resolve to a bus one when there's
just a single slot on the bus.

For legacy PCI/PCI-X, we can have multiple slots per bus but not with
PCI-Express
(each link will be on a separate bus).

Is that true even for root complex integrated end points? A
random system's lspci output doesn't seem to agree with what
you say. A typical example would be USB controllers all sitting
on bus 0, but having different slot numbers. You clearly won't
be able to ever bus-reset these, and if you checked all devices
on bus 0 you would then also not be able to slot-reset them.

Here, slot reset refers to any PCIe slot that implements or supports
hotplug feature. The slot reset ultimately invokes "pciehp_reset_slot()".
W.r.t integrated endpoints, these can be reset either through FLR or
secondary bus reset methods only.

Cheers
GOVINDA

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

Re: [Xen-devel] [PATCH v2 for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting

[Julien Grall]

Hi Jan,

On 01/12/17 11:21, Jan Beulich wrote:

On 30.11.17 at 19:54,  wrote:

On 27/11/17 14:41, Jan Beulich wrote:

On 27.11.17 at 14:02,  wrote:

Xen 4.8 and later virtualises CPUID Faulting support for guests.  However,

the

value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
that the current cpuid faulting setting is lost on migrate/suspend/resume.

To move this MSR, use the new guest_{rd,wr}msr() infrastructure.  This

avoids

duplicating or opencoding the feature check and value logic, as well as
abstracting away the internal value representation.  One small adjustment to
guest_wrmsr() is required to cope with being called in toolstack context.

Signed-off-by: Andrew Cooper 

With the further intentions mentioned in the description (as a
justification for some of the earlier requested changes to not
be done), as indicated in a late response to v1
Reviewed-by: Jan Beulich 


I thought that was already clear from the second paragraph.  Either way,
how about this?


Yes, I like this new version better. Thanks.


Release-acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2] x86/hvm: fix interaction between internal and external emulation

[Julien Grall]

Hi,

On 30/11/17 14:28, Jan Beulich wrote:

On 28.11.17 at 15:05,  wrote:

A call to handle_hvm_io_completion() is needed for completing I/O
that requires external emulation. Such completion should be requested when
hvm_vcpu_io_need_completion() returns true after hvm_emulate_once() has
completed. This is indicative of the underlying I/O emulation having
returned X86EMUL_RETRY and hence a re-emulation of the instruction is
needed to pick up the result of the I/O.

A call to handle_hvm_io_completion() is NOT needed when the underlying
I/O has not returned X86EMUL_RETRY since there will be no result to pick
up. Hence it bogus to request such completion when mmio_retry is set,
since this can only happen if the underlying I/O emulation has returned
X86EMUL_OKAY (meaning the I/O has completed successfully).

Reported-by: Andrew Cooper 
Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 


Hmm, I notice Paul didn't Cc you on this one - despite it getting late,
this is still something to be considered for 4.10. It's certainly going
to be a backporting candidate.


Release-acked-by: Julien Grall 

Could this be committed today?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] Commit moratorium for branching Xen 4.10

[Julien Grall]

Hi,

On 01/12/17 15:23, Ian Jackson wrote:

Julien Grall writes ("Commit moratorium for branching Xen 4.10"):

Xen tree is going to branch at RC7. I don't want to branch when
master != staging, so please avoid committing new patches to staging now
to let master catch up with staging. Another announcement will be made
when the moratorium is lifted.


4.10 is now branched off from unstable.

I have set a baseline osstest run off (116747) by hand.  (osstest will
only start regularly testing the 4.10 branches when the osstest commit
that adds the 4.10 branch makes it through the push gate, so there
will be a delay unless I force push it.)

I have pushed to staging-4.10 the commit to disable debug.  (As
discussed above, this will not receive a test run immediately.)

Both branches can now be committed to without interfering with the
branching process.  However, both branches are currently still owned
by Julien as Release Manager.

Julien, please advise committers what kinds of commits each branch is
open for, if any.


All patches for 4.10 will still require a release-acked. Those patches 
should be first merged in staging, then backport to staging-4.10. We are 
planning to release in about a week.


Regarding staging, it is now re-opened. Although please be mindful when 
committing in staging to avoid diverging to much and making difficult 
backport.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Wei Liu]

On Fri, Dec 01, 2017 at 04:49:01PM +0100, Olaf Hering wrote:
> On Fri, Dec 01, Wei Liu wrote:
> 
> > What information do you need? For a moment let's skip using the fuzzy
> > "Dom0" term and try to be precise. Like "I would like to know if that
> > domain has access to all hardware" or something else.
> 
> That depends on the .service files. This is the list of openSUSE Tumbleweed:
> 
> dev-hugepages.mount:ConditionVirtualization=!private-users
> haveged.service:ConditionVirtualization=!container
> hv_fcopy_daemon.service:ConditionVirtualization=microsoft
> hv_kvp_daemon.service:ConditionVirtualization=microsoft
> hv_vss_daemon.service:ConditionVirtualization=microsoft
> irqd.service:ConditionVirtualization=!container
> ksm.service:ConditionVirtualization=no
> lxcfs.service:ConditionVirtualization=!container
> mcelog.service:ConditionVirtualization=false
> ntp-wait.service:ConditionVirtualization=!container
> ntpd.service:ConditionVirtualization=!container
> rng-tools.service:ConditionVirtualization=!container
> smartd.service:ConditionVirtualization=false
> sys-fs-fuse-connections.mount:ConditionVirtualization=!private-users
> systemd-random-seed.service:ConditionVirtualization=!container
> systemd-timesyncd.service:ConditionVirtualization=!container
> vgauthd.service:ConditionVirtualization=vmware
> vmblock-fuse.service:ConditionVirtualization=vmware
> vmtoolsd.service:ConditionVirtualization=vmware
> xendriverdomain.service:ConditionVirtualization=xen
> 
> I think the relevant services are ksm,mcelog and smartd. Each one likely
> wants the "hardware domain" rather than the "toolstack domain".

Thanks. This is much clearer. And I agree with your conclusion here.

> IMO what
> systemd today sees as "dom0" should be set based on "XENFEAT_dom0".
> 

I'm fine with this. Keeping the semantics the same as Xen's is good.
We don't want to create more confusion.

To summarise:

1. You need XENFEAT_dom0 for hardware domain;
2. You need something else (missing atm?) for control domain.

Wei.

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Olaf Hering]

On Fri, Dec 01, Wei Liu wrote:

> What information do you need? For a moment let's skip using the fuzzy
> "Dom0" term and try to be precise. Like "I would like to know if that
> domain has access to all hardware" or something else.

That depends on the .service files. This is the list of openSUSE Tumbleweed:

dev-hugepages.mount:ConditionVirtualization=!private-users
haveged.service:ConditionVirtualization=!container
hv_fcopy_daemon.service:ConditionVirtualization=microsoft
hv_kvp_daemon.service:ConditionVirtualization=microsoft
hv_vss_daemon.service:ConditionVirtualization=microsoft
irqd.service:ConditionVirtualization=!container
ksm.service:ConditionVirtualization=no
lxcfs.service:ConditionVirtualization=!container
mcelog.service:ConditionVirtualization=false
ntp-wait.service:ConditionVirtualization=!container
ntpd.service:ConditionVirtualization=!container
rng-tools.service:ConditionVirtualization=!container
smartd.service:ConditionVirtualization=false
sys-fs-fuse-connections.mount:ConditionVirtualization=!private-users
systemd-random-seed.service:ConditionVirtualization=!container
systemd-timesyncd.service:ConditionVirtualization=!container
vgauthd.service:ConditionVirtualization=vmware
vmblock-fuse.service:ConditionVirtualization=vmware
vmtoolsd.service:ConditionVirtualization=vmware
xendriverdomain.service:ConditionVirtualization=xen

I think the relevant services are ksm,mcelog and smartd. Each one likely
wants the "hardware domain" rather than the "toolstack domain". IMO what
systemd today sees as "dom0" should be set based on "XENFEAT_dom0".

Olaf


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH 2/2] gnttab: improve GNTTABOP_cache_flush locking

[Andre Przywara]

Hi,

On 30/11/17 14:32, Jan Beulich wrote:
> Dropping the lock before returning from grant_map_exists() means handing
> possibly stale information back to the caller. Return back the pointer
> to the active entry instead, for the caller to release the lock once
> done.

I don't know enough about grant tables to reason about the deeper
meaning of this patch, but at least I can confirm that the amended
locking scheme seems to be correct (now).
I just wonder if it's worthwhile to add a comment that the function
takes a lock, but leaves it up to the caller to drop it. Since there is
only one caller, this might be overkill, though.

> Signed-off-by: Jan Beulich 

Reviewed-by: Andre Przywara 

Cheers,
Andre.

> 
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -786,10 +786,10 @@ static int _set_status(unsigned gt_versi
>  return _set_status_v2(domid, readonly, mapflag, shah, act, status);
>  }
>  
> -static int grant_map_exists(const struct domain *ld,
> -struct grant_table *rgt,
> -unsigned long mfn,
> -grant_ref_t *cur_ref)
> +static struct active_grant_entry *grant_map_exists(const struct domain *ld,
> +   struct grant_table *rgt,
> +   unsigned long mfn,
> +   grant_ref_t *cur_ref)
>  {
>  grant_ref_t ref, max_iter;
>  
> @@ -805,28 +805,20 @@ static int grant_map_exists(const struct
> nr_grant_entries(rgt));
>  for ( ref = *cur_ref; ref < max_iter; ref++ )
>  {
> -struct active_grant_entry *act;
> -bool_t exists;
> -
> -act = active_entry_acquire(rgt, ref);
> -
> -exists = act->pin
> -&& act->domid == ld->domain_id
> -&& act->frame == mfn;
> +struct active_grant_entry *act = active_entry_acquire(rgt, ref);
>  
> +if ( act->pin && act->domid == ld->domain_id && act->frame == mfn )
> +return act;
>  active_entry_release(act);
> -
> -if ( exists )
> -return 0;
>  }
>  
>  if ( ref < nr_grant_entries(rgt) )
>  {
>  *cur_ref = ref;
> -return 1;
> +return NULL;
>  }
>  
> -return -EINVAL;
> +return ERR_PTR(-EINVAL);
>  }
>  
>  #define MAPKIND_READ 1
> @@ -3213,6 +3205,7 @@ static int cache_flush(const gnttab_cach
>  struct domain *d, *owner;
>  struct page_info *page;
>  unsigned long mfn;
> +struct active_grant_entry *act = NULL;
>  void *v;
>  int ret;
>  
> @@ -3250,13 +3243,13 @@ static int cache_flush(const gnttab_cach
>  {
>  grant_read_lock(owner->grant_table);
>  
> -ret = grant_map_exists(d, owner->grant_table, mfn, cur_ref);
> -if ( ret != 0 )
> +act = grant_map_exists(d, owner->grant_table, mfn, cur_ref);
> +if ( IS_ERR_OR_NULL(act) )
>  {
>  grant_read_unlock(owner->grant_table);
>  rcu_unlock_domain(d);
>  put_page(page);
> -return ret;
> +return act ? PTR_ERR(act) : 1;
>  }
>  }
>  
> @@ -3273,7 +3266,11 @@ static int cache_flush(const gnttab_cach
>  ret = 0;
>  
>  if ( d != owner )
> +{
> +active_entry_release(act);
>  grant_read_unlock(owner->grant_table);
> +}
> +
>  unmap_domain_page(v);
>  put_page(page);
>  

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

Re: [Xen-devel] [PATCH 1/2] gnttab: correct GNTTABOP_cache_flush empty batch handling

[Andre Przywara]

Hi,

On 30/11/17 14:31, Jan Beulich wrote:
> Jann validly points out that with a caller bogusly requesting a zero-
> element batch with non-zero high command bits (the ones used for
> continuation encoding), the assertion right before the call to
> hypercall_create_continuation() would trigger. A similar situation would
> arise afaict for non-empty batches with op and/or length zero in every
> element.
> 
> While we want the former to succeed (as we do elsewhere for similar
> no-op requests), the latter can clearly be converted to an error, as
> this is a state that can't be the result of a prior operation.
> 
> Take the opportunity and also correct the order of argument checks:
> We shouldn't accept zero-length elements with unknown bits set in "op".
> Also constify cache_flush()'s first parameter.
> 
> Reported-by: Jann Horn 
> Signed-off-by: Jan Beulich 

Took me a while to wrap my head around it, because the actual fix is
just the "*cur_ref = 0;" line, I think.
But this looks correct to me.

Signed-off-by: Andre Przywara 

> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@ -3208,7 +3208,7 @@ gnttab_swap_grant_ref(XEN_GUEST_HANDLE_P
>  return 0;
>  }
>  
> -static int cache_flush(gnttab_cache_flush_t *cflush, grant_ref_t *cur_ref)
> +static int cache_flush(const gnttab_cache_flush_t *cflush, grant_ref_t 
> *cur_ref)
>  {
>  struct domain *d, *owner;
>  struct page_info *page;
> @@ -3218,19 +3218,17 @@ static int cache_flush(gnttab_cache_flus
>  
>  if ( (cflush->offset >= PAGE_SIZE) ||
>   (cflush->length > PAGE_SIZE) ||
> - (cflush->offset + cflush->length > PAGE_SIZE) )
> + (cflush->offset + cflush->length > PAGE_SIZE) ||
> + (cflush->op & ~(GNTTAB_CACHE_INVAL | GNTTAB_CACHE_CLEAN)) )
>  return -EINVAL;
>  
>  if ( cflush->length == 0 || cflush->op == 0 )
> -return 0;
> +return !*cur_ref ? 0 : -EILSEQ;
>  
>  /* currently unimplemented */
>  if ( cflush->op & GNTTAB_CACHE_SOURCE_GREF )
>  return -EOPNOTSUPP;
>  
> -if ( cflush->op & ~(GNTTAB_CACHE_INVAL|GNTTAB_CACHE_CLEAN) )
> -return -EINVAL;
> -
>  d = rcu_lock_current_domain();
>  mfn = cflush->a.dev_bus_addr >> PAGE_SHIFT;
>  
> @@ -3310,6 +3308,9 @@ gnttab_cache_flush(XEN_GUEST_HANDLE_PARA
>  *cur_ref = 0;
>  guest_handle_add_offset(uop, 1);
>  }
> +
> +*cur_ref = 0;
> +
>  return 0;
>  }
>  

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

Re: [Xen-devel] [PATCH for-unstable] docs/process/release-checklist.txt: New instructions for disabling debug

[Wei Liu]

On Fri, Dec 01, 2017 at 03:20:06PM +, Ian Jackson wrote:
> The old instructions were obsolete.  Here are the details I used when
> branching for 4.10.
> 
> CC: Julien Grall 
> CC: Wei Liu 
> Signed-off-by: Ian Jackson 

Acked-by: Wei Liu 

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

Re: [Xen-devel] Commit moratorium for branching Xen 4.10

[Ian Jackson]

Julien Grall writes ("Commit moratorium for branching Xen 4.10"):
> Xen tree is going to branch at RC7. I don't want to branch when
> master != staging, so please avoid committing new patches to staging now
> to let master catch up with staging. Another announcement will be made
> when the moratorium is lifted.

4.10 is now branched off from unstable.

I have set a baseline osstest run off (116747) by hand.  (osstest will
only start regularly testing the 4.10 branches when the osstest commit
that adds the 4.10 branch makes it through the push gate, so there
will be a delay unless I force push it.)

I have pushed to staging-4.10 the commit to disable debug.  (As
discussed above, this will not receive a test run immediately.)

Both branches can now be committed to without interfering with the
branching process.  However, both branches are currently still owned
by Julien as Release Manager.

Julien, please advise committers what kinds of commits each branch is
open for, if any.

Ian.

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

[Xen-devel] [PATCH for-unstable] docs/process/release-checklist.txt: New instructions for disabling debug

[Ian Jackson]

The old instructions were obsolete.  Here are the details I used when
branching for 4.10.

CC: Julien Grall 
CC: Wei Liu 
Signed-off-by: Ian Jackson 
---
 docs/process/release-checklist.txt | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/docs/process/release-checklist.txt 
b/docs/process/release-checklist.txt
index b96964e..c83ff7f 100644
--- a/docs/process/release-checklist.txt
+++ b/docs/process/release-checklist.txt
@@ -54,8 +54,9 @@ t=RELEASE-$r
 # if main version number has changed (eg 4.7 -> 4.8) rerun ./autogen.sh
 * rerun ./autogen.sh to update version number in configure
 #- XEN_EXTRAVERSION should be `.0-rc$(XEN_VENDORVERSION)'
-#- debug ?= n on stable branches
-#- Kconfig.debug default n on stable branches
+#- turn off debug on stable branches
+#   - tools/Rules.mk debug ?= n
+#   - Kconfig.debug default n
 * tag xen-unstable
 
 # In xen.git
-- 
2.1.4


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

[Xen-devel] [PATCH v2] libxl: put RSDP for PVH guest near 4GB

[Juergen Gross]

Instead of locating the RSDP table below 1MB put it just below 4GB
like the rest of the ACPI tables in case of PVH guests. This will
avoid punching more holes than necessary into the memory map.

Signed-off-by: Juergen Gross 
Acked-by: Wei Liu 
---
 tools/libxc/xc_dom_hvmloader.c | 2 +-
 tools/libxl/libxl_x86_acpi.c   | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/tools/libxc/xc_dom_hvmloader.c b/tools/libxc/xc_dom_hvmloader.c
index 59f94e51e5..3f0bd65547 100644
--- a/tools/libxc/xc_dom_hvmloader.c
+++ b/tools/libxc/xc_dom_hvmloader.c
@@ -136,7 +136,7 @@ static int module_init_one(struct xc_dom_image *dom,
 struct xc_dom_seg seg;
 void *dest;
 
-if ( module->length )
+if ( module->length && !module->guest_addr_out )
 {
 if ( xc_dom_alloc_segment(dom, &seg, name, 0, module->length) )
 goto err;
diff --git a/tools/libxl/libxl_x86_acpi.c b/tools/libxl/libxl_x86_acpi.c
index 9a7c90467d..fe87418bc1 100644
--- a/tools/libxl/libxl_x86_acpi.c
+++ b/tools/libxl/libxl_x86_acpi.c
@@ -22,8 +22,6 @@
 
  /* Number of pages holding ACPI tables */
 #define NUM_ACPI_PAGES 16
-/* Store RSDP in the last 64 bytes of BIOS RO memory */
-#define RSDP_ADDRESS (0x10 - 64)
 #define ACPI_INFO_PHYSICAL_ADDRESS 0xfc00
 
 struct libxl_acpi_ctxt {
@@ -220,7 +218,8 @@ int libxl__dom_load_acpi(libxl__gc *gc,
 
 dom->acpi_modules[0].data = (void *)config.rsdp;
 dom->acpi_modules[0].length = 64;
-dom->acpi_modules[0].guest_addr_out = RSDP_ADDRESS;
+dom->acpi_modules[0].guest_addr_out = ACPI_INFO_PHYSICAL_ADDRESS +
+(1 + acpi_pages_num) * libxl_ctxt.page_size;
 
 dom->acpi_modules[1].data = (void *)config.infop;
 dom->acpi_modules[1].length = 4096;
-- 
2.12.3


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

Re: [Xen-devel] [PATCH] libxl: put RSDP for PVH guest near 4GB

[Wei Liu]

On Wed, Nov 29, 2017 at 03:13:16PM +0100, Juergen Gross wrote:
> Instead of locating the RSDP table below 1MB put it just below 4GB
> like the rest of the ACPI tables in case of PVH guests. This will
> avoid punching more holes than necessary into the memory map.
> 
> Signed-off-by: Juergen Gross 

With Jan's comment addressed:

Acked-by: Wei Liu 

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

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

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 116642
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail blocked in 116642
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 116642
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 116642
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116642
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116642
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116642
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116642
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 116642
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116642
 test-amd64-amd64-xl-pvhv2-intel 12 guest-start fail never pass
 test-amd64-amd64-xl-pvhv2-amd 12 guest-start  fail  never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 xen  6da091d95dfcbe00daf91308d044ee5151b1ac9e
baseline version:
 xen  9976f3874d4cca829f2d2916feab18615337bb5c

Last test of basis   116642  2017-11-29 00:00:00 Z2 days
Testing same since   116692  2017-11-30 00:10:56 Z1 days2 attempts


People who touched revisions under test:
  Andre Przywara 
  Andrew Cooper 
  Stewart Hildebrand 

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Wei Liu]

On Fri, Dec 01, 2017 at 01:38:48PM +0100, Olaf Hering wrote:
> Am Fri, 1 Dec 2017 12:29:24 +
> schrieb Wei Liu :
> 
> > But Olaf needs to know if some of the services like xenconsoled or
> > xenstored should be started, and if some of the special file systems
> > should be mounted, right? Those aren't tied to hardware in anyway. In my
> > view that's the responsibility of the toolstack control domain.
> 
> No, I did not intent to make use of ConditionVirtualization= in the
> xen*.service files in tools/hotplug/Linux/. That variable can not be used
> for this purpose, and the patch would not change that.
> 
> In case you refer to the "proc-xen.mount" change from a few days/weeks ago,
> this was all about avoiding the error when xenfs becomes an "API filesystem".
> With this suggested change the existing "proc-xen.mount units would not fail
> anymore because /proc/xen is added to the ignore list.
> 

Yes, but then there are further services that depend on proc-xen.mount.
Say, xenstored and xenconsoled. That's why I came to the conclusion that
XENFEAT_dom0 (denoting hardware domain, as Jan said, could be a
different domain from control domain down the road) wasn't what you
want.

Quote from the first email in this thread that I'm CC'ed:

>> Ah, I see. But then still I don't see why at least on half way
>> recent Xen /sys/hypervisor/properties/features wouldn't have
>> the information you're after (and even more precise, because
>> down the road control domain and hardware domain may be
>> separate entities).
>
> Per discussion in https://github.com/systemd/systemd/pull/6662, the
> feature bits should not be used for dom0 detection.

Obv. Jan thinks sysfs contains what you want, but afaict I had a
different conclusion.

I don't think there is misunderstanding as to what that flag means.  I
sense that there is misunderstanding as what you want to achieve.
Or maybe Jan means the flag (or the absence of it) can already give you
the information you need?

What information do you need? For a moment let's skip using the fuzzy
"Dom0" term and try to be precise. Like "I would like to know if that
domain has access to all hardware" or something else.

Wei.

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Olaf Hering]

Am Fri, 1 Dec 2017 12:29:24 +
schrieb Wei Liu :

> But Olaf needs to know if some of the services like xenconsoled or
> xenstored should be started, and if some of the special file systems
> should be mounted, right? Those aren't tied to hardware in anyway. In my
> view that's the responsibility of the toolstack control domain.

No, I did not intent to make use of ConditionVirtualization= in the
xen*.service files in tools/hotplug/Linux/. That variable can not be used
for this purpose, and the patch would not change that.

In case you refer to the "proc-xen.mount" change from a few days/weeks ago,
this was all about avoiding the error when xenfs becomes an "API filesystem".
With this suggested change the existing "proc-xen.mount units would not fail
anymore because /proc/xen is added to the ignore list.

Olaf


pgpb45ooDWFP7.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Wei Liu]

On Fri, Dec 01, 2017 at 05:23:16AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 13:15,  wrote:
> > On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
> >> >>> On 01.12.17 at 12:48,  wrote:
> >> > Suppose at one point we split hardware domain and control domain, which
> >> > one will you call Dom0? Which one will get the flag?
> >> 
> >> There can only be one hardware domain, which will continue to
> >> be the one getting XENFEAT_dom0. There could be any number
> >> of control domains (perhaps with some coordination between
> >> them).
> > 
> > Right. So XENFEAT_dom0 is not really what Olaf needs. 
> 
> Sigh. What does "has access to all the hardware" translate to
> for you?

That would mean hardware domain.

But Olaf needs to know if some of the services like xenconsoled or
xenstored should be started, and if some of the special file systems
should be mounted, right? Those aren't tied to hardware in anyway. In my
view that's the responsibility of the toolstack control domain.

Can you point me to the start of your discussion with Olaf so that I can
check what the disagreement between you and Olaf is about?

Wei.

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

Re: [Xen-devel] Xen Security Advisory 245 (CVE-2017-17046) - ARM: Some memory not scrubbed at boot

[Jan Beulich]

>>> On 30.11.17 at 20:32,  wrote:
> List,
> this XSA-245 appears in the xen-devel ML, but unlike XSA-246,247 it never 
> appears in the git logs.
> Was it ever committed?

Yes. Did you perhaps scan for "XSA-245" in the description, which
may have been omitted in this case?

Jan


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

[Xen-devel] [PATCH v17 19/19] osstest: use -DWITHOUT_AUTO_OBJ with FreeBSD release targets

[Roger Pau Monne]

Due to a recent FreeBSD change the default output directory of the release
targets is changed to the object directory instead of the source
directory. Use WITHOUT_AUTO_OBJ to restore previous behavior. This is
harmless if used with previous versions, it will be ignored.

Signed-off-by: Roger Pau Monné 
---
 ts-freebsd-build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ts-freebsd-build b/ts-freebsd-build
index 5e7e1078..5d82d809 100755
--- a/ts-freebsd-build
+++ b/ts-freebsd-build
@@ -78,7 +78,7 @@ sub build_release ($$$) {
 
 buildcmd_stamped_logged_root($time, 'freebsd', "release-$target",
  $prefix, 

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Jan Beulich]

>>> On 01.12.17 at 13:15,  wrote:
> On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
>> >>> On 01.12.17 at 12:48,  wrote:
>> > Suppose at one point we split hardware domain and control domain, which
>> > one will you call Dom0? Which one will get the flag?
>> 
>> There can only be one hardware domain, which will continue to
>> be the one getting XENFEAT_dom0. There could be any number
>> of control domains (perhaps with some coordination between
>> them).
> 
> Right. So XENFEAT_dom0 is not really what Olaf needs. 

Sigh. What does "has access to all the hardware" translate to
for you?

Jan


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

[Xen-devel] [PATCH v17 17/19] osstest: remove the loader timeout from the install image

[Roger Pau Monne]

When the FreeBSD installer is booted on the godello{0/1} boxes it
receives spurious key strokes. This doesn't happen so far when booted
from disk, or with any other boxes.

In order to cope with this remove the loader timeout on the install
image. Note that failure to boot will still drop the loader into a
manual prompt.

Signed-off-by: Roger Pau Monné 
---
 ts-freebsd-build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-freebsd-build b/ts-freebsd-build
index 54cb5902..5e7e1078 100755
--- a/ts-freebsd-build
+++ b/ts-freebsd-build
@@ -135,7 +135,7 @@ chmod 0600 etc/ssh/ssh_host_*_key
 chmod 0644 etc/ssh/ssh_host_*_key.pub
 
 # Setup serial console output for stage1
-printf "%s" "-h -S$bauds" >> boot.config
+printf "%s" "-hn -S$bauds" >> boot.config
 cat << ENDBOOT >> boot/loader.conf
 # Serial console configuration
 boot_serial="YES"
@@ -143,6 +143,7 @@ comconsole_speed="$bauds"
 console="comconsole"
 boot_verbose="YES"
 beastie_disable="YES"
+autoboot_delay="-1"
 
 # mfs boot parameters
 mfs_load="YES"
-- 
2.13.6 (Apple Git-96)


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

[Xen-devel] [PATCH v17 18/19] osstest: expand the list of tested disk controllers

[Roger Pau Monne]

The Mass osstest instance has a more diverse list of hardware disk
controllers, so expand the list in order to include all the possible
disk drivers.

For the record, this list can be found at:

usr.sbin/bsdconfig/share/device.subr

In the FreeBSD source tree.

Signed-off-by: Roger Pau Monné 
---
 ts-freebsd-host-install | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ts-freebsd-host-install b/ts-freebsd-host-install
index 573245ad..a12591cb 100755
--- a/ts-freebsd-host-install
+++ b/ts-freebsd-host-install
@@ -122,7 +122,8 @@ sub install () {
 my $authkeys = authorized_keys();
 my $knownhosts = known_hosts();
 my $sshd_keys_url = create_ssh_overlay();
-my @disk_names = qw(ada0 da0 ad0);
+my @disk_names =
+qw(ada0 da0 ad0 aacd0 amrd0 idad0 ipsd0 mfid0 mlxd0 twed0);
 my $target_sets = "/root/osstest_sets";
 my $disk;
 my $nic;
-- 
2.13.6 (Apple Git-96)


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

[Xen-devel] [PATCH v17 00/19] osstest: initial FreeBSD support

[Roger Pau Monne]

Hello,

This are again the remaining non-acked patches of the FreeBSD osstest
series. The two patches sent with this cover letter fix two issues
found on the Mass colo.

Patch 17 fixes an issue where the FreeBSD installer bootloader
receives random keystrokes on the console, thus aborting the automatic
boot. The solution is to create an installer that doesn't wait for any
keystrokes and just boots into the default kernel. FWIW this only
happens when booting the installer image from pxelinux + memdisk, I
haven't seen it happening when booting FreeBSD once installed to disk.
In some spare free time I might try to figure out what's actually
going on, but this bodge seems like the easiest solution ATM.

Patch 18 adds more disk controllers to the list of proved devices in
order to find the hard drive. This was found while trying to install
on nobling, which has some kind of RAID controller. Now all the
possible disk drivers have been added to the list, so we shouldn't
expect further problems for the time being.

Finally patch 19 fixes an issue when using recent FreeBSD sources, that
changed the default position of the output produced by the release
targets.

I've pushed the whole series to:

git://xenbits.xen.org/people/royger/osstest.git freebsd_v17

A successful FreeBSD flight can be found in the Massachusetts colo, it's
flight 116709 (not public) which is based on the same code found in the
freebsd_v17 branch.

Let me know if there's anything missing.

Thanks, Roger.

Roger Pau Monne (19):
  osstest: make built_stash_file store a path_ runvar for each file
  osstest: move known_hosts generation to TestSupport
  osstest: add executive prefix to resource_shared_mark_ready
  osstest: introduce host_shared_mark_ready
  osstest: introduce build helpers for FreeBSD
  osstest: add prototypes to target_install_packages{_norec}
  osstest: introduce an OS $ho field
  osstest: add support for the FreeBSD package manager
  osstest: introduce a FreeBSD build script
  osstest: add support for runtime_IDENT_hostflags
  osstest: introduce a script to set the runtime hostflags runvar for
FreeBSD jobs
  osstest: add script to install build dependencies on FreeBSD
  osstest: change the meaning of need_build_host
  osstest: add support for FreeBSD buildjobs to sg-run-job
  osstest: introduce a script to create a FreeBSD flight
  osstest: hook FreeBSD flight into cr-daily-branch
  osstest: remove the loader timeout from the install image
  osstest: expand the list of tested disk controllers
  osstest: use -DWITHOUT_AUTO_OBJ with FreeBSD release targets

 Osstest/BuildSupport.pm|  26 +++-
 Osstest/Debian.pm  |  36 +
 Osstest/Executive.pm   |   5 +-
 Osstest/JobDB/Executive.pm |   2 +-
 Osstest/TestSupport.pm | 139 ---
 README |  16 +++
 ap-common  |   5 +
 ap-fetch-version   |   8 ++
 ap-fetch-version-old   |   9 ++
 ap-print-url   |   3 +
 ap-push|   9 ++
 cr-daily-branch|  17 +++
 cr-for-branches|   2 +-
 cri-common |   1 +
 daily-cron-email-adhoc--freebsd-master |   1 +
 daily-cron-email-play--freebsd-master  |   1 +
 daily-cron-email-real--freebsd-master  |   4 +
 make-freebsd-flight|  95 +
 sg-run-job |  50 ---
 ts-build-prep-freebsd  |  37 +
 ts-freebsd-build   | 240 +
 ts-freebsd-host-install|   6 +-
 ts-freebsd-set-hostflags   |  78 +++
 ts-kernel-build|   4 +-
 ts-xen-build   |   8 +-
 ts-xen-build-prep  |   4 +-
 26 files changed, 716 insertions(+), 90 deletions(-)
 create mode 100644 daily-cron-email-adhoc--freebsd-master
 create mode 100644 daily-cron-email-play--freebsd-master
 create mode 100644 daily-cron-email-real--freebsd-master
 create mode 100755 make-freebsd-flight
 create mode 100755 ts-build-prep-freebsd
 create mode 100755 ts-freebsd-build
 create mode 100755 ts-freebsd-set-hostflags

-- 
2.13.6 (Apple Git-96)


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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Wei Liu]

On Fri, Dec 01, 2017 at 05:11:45AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 12:48,  wrote:
> > Suppose at one point we split hardware domain and control domain, which
> > one will you call Dom0? Which one will get the flag?
> 
> There can only be one hardware domain, which will continue to
> be the one getting XENFEAT_dom0. There could be any number
> of control domains (perhaps with some coordination between
> them).
> 

Right. So XENFEAT_dom0 is not really what Olaf needs. 

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

Re: [Xen-devel] [PATCH v2 for-next 1/9] kconfig/gcov: remove gcc version choice from kconfig

[Wei Liu]

On Thu, Nov 09, 2017 at 11:13:41AM +, Roger Pau Monne wrote:
> Use autodetect only.
> 
> Signed-off-by: Roger Pau Monné 

Acked-by: Wei Liu 

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Jan Beulich]

>>> On 01.12.17 at 12:48,  wrote:
> Suppose at one point we split hardware domain and control domain, which
> one will you call Dom0? Which one will get the flag?

There can only be one hardware domain, which will continue to
be the one getting XENFEAT_dom0. There could be any number
of control domains (perhaps with some coordination between
them).

Jan


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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Wei Liu]

On Fri, Dec 01, 2017 at 04:39:30AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 11:21,  wrote:
> > On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.17 at 09:23,  wrote:
> >> > On Wed, Nov 29, Jan Beulich wrote:
> >> > 
> >> >> Ah, I see. But then still I don't see why at least on half way
> >> >> recent Xen /sys/hypervisor/properties/features wouldn't have
> >> >> the information you're after (and even more precise, because
> >> >> down the road control domain and hardware domain may be
> >> >> separate entities).
> >> > 
> >> > Per discussion in https://github.com/systemd/systemd/pull/6662, the
> >> > feature bits should not be used for dom0 detection.
> >> 
> >> I can't seem to interpret that discussion the way you do. In fact
> >> (as I've said before) using the feature flag is more reliable, as it
> >> being set implies this is the hardware domain (rather than the
> >> more fuzzy "control domain" implied by "control_d").
> >> 
> >> Wei, your comments there from Oct 27 and 30 are what I think
> >> Olaf refers to. Could you clarify this?
> >> 
> > 
> > Judging from the snippet here I don't quite understand what your
> > disagreement is. You already said control domain and hardware domain
> > could be separate entities in the future.
> > 
> > The XENFEAT_dom0 flag currently denotes hardware domain. It boils down
> > to whether we want Dom0 to mean hardware domain, control domain or just
> > "A domain that has domid 0".
> > 
> > In Olaf's case, he cares about knowing whether the domain runs the
> > controlling toolstack, he doesn't care about if it is the hardware
> > domain or not, so my conclusion was using that flag was wrong.
> 
> I understood it exactly the other way around: The question is
> whether to treat things the same as without Xen:
> "dom0 has to be handled as "no virtualization" because it has access to
>  all hardware, all services depending on "native" have to run in dom0."
> Sound like hardware domain to me, not control domain.
> 

Software services needed to run a Xen system are handled by sysmted/sysv
init. They depend on the detection of control domain, not hardware
domain. I think that's what Olaf is after mostly.

Suppose at one point we split hardware domain and control domain, which
one will you call Dom0? Which one will get the flag?

Wei.

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Jan Beulich]

>>> On 01.12.17 at 11:21,  wrote:
> On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
>> >>> On 30.11.17 at 09:23,  wrote:
>> > On Wed, Nov 29, Jan Beulich wrote:
>> > 
>> >> Ah, I see. But then still I don't see why at least on half way
>> >> recent Xen /sys/hypervisor/properties/features wouldn't have
>> >> the information you're after (and even more precise, because
>> >> down the road control domain and hardware domain may be
>> >> separate entities).
>> > 
>> > Per discussion in https://github.com/systemd/systemd/pull/6662, the
>> > feature bits should not be used for dom0 detection.
>> 
>> I can't seem to interpret that discussion the way you do. In fact
>> (as I've said before) using the feature flag is more reliable, as it
>> being set implies this is the hardware domain (rather than the
>> more fuzzy "control domain" implied by "control_d").
>> 
>> Wei, your comments there from Oct 27 and 30 are what I think
>> Olaf refers to. Could you clarify this?
>> 
> 
> Judging from the snippet here I don't quite understand what your
> disagreement is. You already said control domain and hardware domain
> could be separate entities in the future.
> 
> The XENFEAT_dom0 flag currently denotes hardware domain. It boils down
> to whether we want Dom0 to mean hardware domain, control domain or just
> "A domain that has domid 0".
> 
> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.

I understood it exactly the other way around: The question is
whether to treat things the same as without Xen:
"dom0 has to be handled as "no virtualization" because it has access to
 all hardware, all services depending on "native" have to run in dom0."
Sound like hardware domain to me, not control domain.

Jan


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

Re: [Xen-devel] [PATCH v2 for-4.10] x86: Avoid corruption on migrate for vcpus using CPUID Faulting

[Jan Beulich]

>>> On 30.11.17 at 19:54,  wrote:
> On 27/11/17 14:41, Jan Beulich wrote:
> On 27.11.17 at 14:02,  wrote:
>>> Xen 4.8 and later virtualises CPUID Faulting support for guests.  However, 
> the
>>> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
>>> that the current cpuid faulting setting is lost on migrate/suspend/resume.
>>>
>>> To move this MSR, use the new guest_{rd,wr}msr() infrastructure.  This 
> avoids
>>> duplicating or opencoding the feature check and value logic, as well as
>>> abstracting away the internal value representation.  One small adjustment to
>>> guest_wrmsr() is required to cope with being called in toolstack context.
>>>
>>> Signed-off-by: Andrew Cooper 
>> With the further intentions mentioned in the description (as a
>> justification for some of the earlier requested changes to not
>> be done), as indicated in a late response to v1
>> Reviewed-by: Jan Beulich 
> 
> I thought that was already clear from the second paragraph.  Either way,
> how about this?

Yes, I like this new version better. Thanks.

Jan

> Xen 4.8 and later virtualises CPUID Faulting support for guests. 
> However, the
> value of MSR_MISC_FEATURES_ENABLES is omitted from the vcpu state, meaning
> that the current cpuid faulting setting is lost on migrate/suspend/resume.
> 
> Instead of following the MSR status quo, take the opportunity to make the
> logic more generic, and in particular, trivial to extend for future MSRs.
> 
> This is done by discarding the notion of optional MSRs, and requiring the
> toolstack to be prepared to move all of the MSRs, although only a subset
> will
> typically need to move.
> 
> This allows for the use of guest_{rd,wr}msr() alone to evaluate whether
> an MSR
> needs moving.  This is a benefit because it means there is a single piece of
> logic responsible for evaluating whether a guest can use an MSR, and which
> values are acceptable.
> 
> One small adjustment to guest_wrmsr() is required to cope with being
> called in
> toolstack context.
> 
> Signed-off-by: Andrew Cooper 




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

[Xen-devel] [OSSTEST PATCH 2/2] README: Do not recommend cs-flight-create

[Ian Jackson]

This is not a normal way to carry on.  Far too much like hard work.
Recommend make-flight or cs-adjust-flight new: instead.

CC: Julien Grall 
Signed-off-by: Ian Jackson 
---
 README | 49 +
 1 file changed, 17 insertions(+), 32 deletions(-)

diff --git a/README b/README
index 93129e3..9d97c61 100644
--- a/README
+++ b/README
@@ -680,39 +680,23 @@ operation.
 However it can be useful to create a custom flight "by-hand" in order
 to repeatedly test one aspect or to facilitate adhoc tests etc.
 
-A fresh empty flight is created by using the "cs-flight-create"
-script. It takes as arguments a "blessing" and a "branch" and on
-success prints the new flight number.
+The usual way to do this is to use cs-adjust-flight.  This utility can
+create completely new flights using existing ones as templates, as
+well as "edit" existing ones.
 
-The blessing should almost always be "play". The branch doesn't
-really matter, if you are testing something related to a failure on a
-given branch you may as well use that, otherwise "play" or
-"xen-unstable" is a reasonably fallback.
+If you wanted to simply copy a single job from an existing flight, you
+could do something like this:
 
-Thus the normal way to invoke cs-flight-create is:
+$ ./cs-adjust-flight new:play copy-jobs $template  \
+  runvar-build-set . . . "$template."
 
-$ flight=`./cs-flight-create play play`
+The blessing should almost always be "play".
 
-Which results in a $flight which can be used for the remainder of the
-configuration.
-
-Once you have an empty flights there are two main ways to populate it
-with jobs. Firstly you can create jobs from scratch using
-cs-job-create or secondly by copying one or more jobs from an existing
-template flight using "cs-adjust-flight copy-jobs". In either case the
-job can then be further customised using cs-adjust-flight to add and
-remove runvars etc.
-
-cs-job-create requires a flight ($flight from above), a job name (any
-string), a recipe (either custom, see below, or from any
-run-job/ in sg-run-job) and then the runvars in key=value
-form. Deciding on the runvars in particular can be tricky, it is
-usually easiest to copy an existing job.
-
-A job can be copied from a template flight using cs-adjust-flight
-copy-jobs e.g.:
-
-$ ./cs-adjust-flight $flight copy-jobs $template 
+It is also possible to take full manual control and create an empty
+flight with cs-flight-create and then populate it with jobs using
+cs-job-create.  But, if you need jobs which are not copies or
+near-copies of existing jobs, it is normally easier to use
+`make-flight' (or one of its friends).
 
 Having created (or copied) a job then you may wish to customise, which
 can be done using cs-adjust-flight. In particular you can add or
@@ -720,11 +704,12 @@ remove runvars, see the doc comment at the top of the 
script. Most
 commonly you may which to preset the host ident to a specific if you
 are tracking down a host specific issue.
 
-You will also want to provide the necessary buildjobs for the job. You
-can do so by also copying the build jobs from your template job or by
+You will want to provide the necessary buildjobs for the job. You can
+do so by also copying the build jobs from your template job or by
 creating them by hand, or by setting the buildjob to reuse the builds
 done by the template, by setting the appropriate buildjob runvar to
-"$template.$job" . See "Common/Special Runvars" above for more.
+"$template.$job", as is done by the example above.
+See "Common/Special Runvars" above for more.
 
 Custom recipes can be placed in sg-run-job-adhoc and will be
 automatically included. At a minimum you will need to provide "proc
-- 
2.1.4


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

[Xen-devel] [OSSTEST PATCH 1/2] cs-adjust-flight: Correct pseudo-BNF synopsys for runvar-build-set

[Ian Jackson]

In 497b2c6c933d13a05b01c6a654ce470be16dd78a
  cs-adjust-flight: Rework runvar-build-set new value handling
the interpretation of this parameter was changed completely, but the
synopsis was not updated and thus became wrong.

Signed-off-by: Ian Jackson 
---
 cs-adjust-flight | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index f443cfd..afb81cb 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -14,7 +14,7 @@
 #   runvar-del  
 #   runvar-change
 #   runvar-perlop   
-#   runvar-build-set[.]
+#   runvar-build-set|.
 #   recipe-set  
 #   intended-blessing 
 #   branch-set 
@@ -29,9 +29,10 @@
 #
 # runvar-build-set  always only affects runvars m/buildjob$/
 #and may be further limited by ;
-#   and,  is matched against a value
-#containing the being-manipulated flight name
-#even if the actual runvar value omits it
+#   and,  is the old value but matches
+#against values containing the being-manipulated
+#flight name even if the actual runvar values
+#omits it
 #   and, if  ends in ., it is
 #completed with the 's job name
 #
-- 
2.1.4


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

Re: [Xen-devel] [PATCH 0/8] xen: add pvh guest support

[Daniel Kiper]

On Fri, Dec 01, 2017 at 06:37:37AM +0100, Juergen Gross wrote:
> On 30/11/17 22:03, Daniel Kiper wrote:
> > On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
> >> This patch series adds support for booting Linux as PVH guest.
> >>
> >> Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
> >> platform grub is booted as a standalone image directly by Xen.
> >>
> >> For booting Linux kernel it is using the standard linux kernel
> >> loader. The only modification of the linux loader is to pass the
> >> ACPI RSDP address via boot parameters to the kernel, as that table
> >> might not be located at the usual physical address just below 1MB.
> >>
> >> As the related Linux kernel patches are not yet accepted please
> >> wait for this to happen before applying the series.
> >
> > So, may I review the patches or should I hold on? And could you
> > provide a link to the "Linux kernel patches" mentioned above?
>
> Please review!

Will do in a week or so.

> The Linux patches are available at:
>
> https://lists.xen.org/archives/html/xen-devel/2017-11/msg01681.html
>
> With the additional Xen patch
>
> https://lists.xen.org/archives/html/xen-devel/2017-11/msg01807.html
>
> the complete setup can be tested.

Thanks,

Daniel

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

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Olaf Hering]

Am Fri, 1 Dec 2017 10:21:46 +
schrieb Wei Liu :

> In Olaf's case, he cares about knowing whether the domain runs the
> controlling toolstack, he doesn't care about if it is the hardware
> domain or not, so my conclusion was using that flag was wrong.

I think this is not entirely accurate. Right now the term "dom0" is 
a mix of "has access to host (IO) hardware" and "runs the toolstack".

ConditionVirtualization= today lacks such details as well.
"xen" means domU, and "none" is dom0, simply to handle "dom0" like "native"
so that all services that want access to "host hardware" can start.

One could argue that passing a PCI device to a domU may also require
.service files to manage that PCI device in some way. The specifc case
which triggered all the suggested changes was smartd, which is not
supposed to run in "VMs". If a SATA card is provided to a domU it may
be a good idea to monitor the attached disks as well.

So in some way Jan is correct with his suggestion to use XENFEAT_dom0
instead of "control_d". I will do some research about when it became available
and update the patch description.

Olaf


pgpaFvuVD3Dz0.pgp
Description: Digitale Signatur von OpenPGP
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v1] core: mount xenfs, ignore proc-xen.mount (#6442, #6662)

[Wei Liu]

On Thu, Nov 30, 2017 at 01:35:45AM -0700, Jan Beulich wrote:
> >>> On 30.11.17 at 09:23,  wrote:
> > On Wed, Nov 29, Jan Beulich wrote:
> > 
> >> Ah, I see. But then still I don't see why at least on half way
> >> recent Xen /sys/hypervisor/properties/features wouldn't have
> >> the information you're after (and even more precise, because
> >> down the road control domain and hardware domain may be
> >> separate entities).
> > 
> > Per discussion in https://github.com/systemd/systemd/pull/6662, the
> > feature bits should not be used for dom0 detection.
> 
> I can't seem to interpret that discussion the way you do. In fact
> (as I've said before) using the feature flag is more reliable, as it
> being set implies this is the hardware domain (rather than the
> more fuzzy "control domain" implied by "control_d").
> 
> Wei, your comments there from Oct 27 and 30 are what I think
> Olaf refers to. Could you clarify this?
> 

Judging from the snippet here I don't quite understand what your
disagreement is. You already said control domain and hardware domain
could be separate entities in the future.

The XENFEAT_dom0 flag currently denotes hardware domain. It boils down
to whether we want Dom0 to mean hardware domain, control domain or just
"A domain that has domid 0".

In Olaf's case, he cares about knowing whether the domain runs the
controlling toolstack, he doesn't care about if it is the hardware
domain or not, so my conclusion was using that flag was wrong.

Wei.

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

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

[Platform Team regression test user]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-armhf-jessie-netboot-pygrub 12 migrate-support-check fail 
like 72489
 test-armhf-armhf-armhf-jessie-netboot-pygrub 13 saverestore-support-check fail 
like 72489

baseline version:
 flight   72489

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



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

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

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


Push not applicable.


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

Re: [Xen-devel] unable to start VM after xen upgrade to 4.8.2

[Paul Durrant]

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Alex Braunegg
> Sent: 01 December 2017 02:01
> To: xen-devel@lists.xenproject.org
> Subject: [Xen-devel] unable to start VM after xen upgrade to 4.8.2
> 
> Hi all,
> 
> I recently updated from xen-4.6.6 to xen-4.8.2 and I am unable to start any
> guest that previously worked without issue under 4.6.6. The create process
> fails with the following:
> 
>   libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch
> w=0x9cea28 wpath=/local/domain/0/device-model/1/state token=3/1:
> register
> slotnum=3
>   libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x9cea28
> wpath=/local/domain/0/device-model/1/state token=3/1: event
> epath=/local/domain/0/device-model/1/state
>   libxl: debug: libxl_exec.c:398:spawn_watch_event: domain 1 device
> model: spawn watch p=(null)
>   libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch
> w=0x9cea28 wpath=/local/domain/0/device-model/1/state token=3/1:
> deregister
> slotnum=3
>   libxl: error: libxl_dm.c:2189:device_model_spawn_outcome: domain
> 1
> device model: spawn failed (rc=-3)
>   libxl: error: libxl_create.c:1504:domcreate_devmodel_started: device
> model did not start: -3
> 

That's QEMU failing to start which is, most likely, an incompatibility between 
libxl and the QEMU command line. With any luck you should have a log file 
called /var/log/xen/qemu-dm-.log which in which QEMU should say 
what it is unhappy about.

  Paul

> Reading on similar issues in the past, I have validated that the versions of
> xen libraries are all 4.8.2:
> 
> xen-runtime-4.8.2-3.el6.x86_64
> xen-ocaml-4.8.2-3.el6.x86_64
> xen-libs-4.8.2-3.el6.x86_64
> xen-doc-4.8.2-3.el6.x86_64
> xen-4.8.2-3.el6.x86_64
> xen-licenses-4.8.2-3.el6.x86_64
> xen-hypervisor-4.8.2-3.el6.x86_64
> 
> xl info:
> 
> host   : intel-s5000xvn.
> release: 4.4.102-1.el6.x86_64
> version: #1 SMP Fri Dec 1 08:17:06 EST 2017
> machine: x86_64
> nr_cpus: 8
> max_cpu_id : 7
> nr_nodes   : 1
> cores_per_socket   : 4
> threads_per_core   : 1
> cpu_mhz: 1861
> hw_caps:
> b7ebfbff:0004e3bd:20100800:0001::::000
> 0
> virt_caps  : hvm
> total_memory   : 8165
> free_memory: 6022
> sharing_freed_memory   : 0
> sharing_used_memory: 0
> outstanding_claims : 0
> free_cpus  : 0
> xen_major  : 4
> xen_minor  : 8
> xen_extra  : .2
> xen_version: 4.8.2
> xen_caps   : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> hvm-3.0-x86_32p hvm-3.0-x86_64
> xen_scheduler  : credit
> xen_pagesize   : 4096
> platform_params: virt_start=0x8000
> xen_changeset  :
> xen_commandline: dom0_mem=2048M,max:2048M cpufreq=xen
> dom0_max_vcpus=1 dom0_vcpus_pin
> cc_compiler: gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1)
> cc_compile_by  : mockbuild
> cc_compile_domain  : 
> cc_compile_date: Fri Dec  1 12:00:55 EST 2017
> build_id   : 419c922ca399ca987e0d19bef7e8823f5711ee54
> xend_config_format : 4
> 
> If I roll back to my 4.6.6 version of xen using the same kernel (4.4.102),
> the guest starts without issue.
> 
> Attached is the full output from "xl - create" when using xen 4.8.2. Any
> suggestions is greatly appreciated.
> 
> Best regards,
> 
> Alex

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

[Xen-devel] [xen-4.8-testing test] 116719: FAIL

[osstest service owner]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-vhd  broken  in 116653
 test-amd64-i386-xl-qemut-win10-i386   broken in 116695
 test-amd64-amd64-xl-qemut-ws16-amd64  broken in 116695

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-vhd  4 host-install(4) broken in 116653 pass in 116719
 test-amd64-i386-xl-qemut-win10-i386 4 host-install(4) broken in 116695 pass in 
116719
 test-amd64-i386-xl-qemut-win10-i386 3 syslog-server broken in 116695 pass in 
116719
 test-armhf-armhf-xl-rtds 12 guest-start  fail in 116653 pass in 116719
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail in 116653 pass 
in 116719
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 116695 
pass in 116719
 test-amd64-amd64-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail in 116695 
pass in 116719
 test-xtf-amd64-amd64-1   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 116653
 test-xtf-amd64-amd64-2   49 xtf/test-hvm64-lbr-tsx-vmentry fail pass in 116653
 test-amd64-amd64-xl-qemuu-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
116695
 test-amd64-i386-xl-qemut-ws16-amd64 16 guest-localmigrate/x10 fail pass in 
116695

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemut-win10-i386 5 capture-logs(5) broken in 116695 never 
pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 capture-logs(17) broken in 116695 
never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop  fail blocked in 116237
 test-xtf-amd64-amd64-5 49 xtf/test-hvm64-lbr-tsx-vmentry fail in 116653 like 
116221
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 116653 
like 116237
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop  fail in 116653 like 116237
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop   fail in 116653 like 116237
 test-xtf-amd64-amd64-3  49 xtf/test-hvm64-lbr-tsx-vmentry fail like 116237
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 116237
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 116237
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 116237
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 116237
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 116237
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail like 116237
 build-i386-prev   7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 build-amd64-prev  7 xen-build/dist-test  fail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl

Re: [Xen-devel] [RFC PATCH] KVM: x86: Allow Qemu/KVM to use PVH entry point

[Paolo Bonzini]

On 30/11/2017 19:23, Maran Wilson wrote:
> Are you saying the Linux PVH entry code (such as init_pvh_bootparams())
> should use the fw_cfg interface to read the e820 memory map data and put
> it into the zeropage? Basically, keeping the patch very much like it
> already is, just extracting the e820 data via the fw_cfg interface
> instead of from the second module of start_info struct?

Yes.

> If that is the case, I guess I'm a bit hesitant to throw the QEMU
> specific fw_cfg interface into the mix on the Linux PVH side when the
> existing PVH ABI already seems to contain an interface for passing
> modules/blobs to the guest. But if you feel there is a compelling reason
> to use the fw_cfg interface here, I'm happy to explore that approach
> further.

I think the same holds true for Xen, but it is still using a hypercall 
to get the memory map.  In the end, using fw_cfg seems closest to what 
the Xen code does.

There are other possibilities:

1) defining a v2 PVH ABI that includes the e820 map would also be a 
possibility.

2) modify enlighten_pvh.c to get the start info in multiboot format,
something like:

diff --git a/arch/x86/xen/enlighten_pvh.c b/arch/x86/xen/enlighten_pvh.c
index 98ab17673454..656e41449db0 100644
--- a/arch/x86/xen/enlighten_pvh.c
+++ b/arch/x86/xen/enlighten_pvh.c
@@ -88,19 +88,22 @@ void __init xen_prepare_pvh(void)
u32 msr;
u64 pfn;
 
-   if (pvh_start_info.magic != XEN_HVM_START_MAGIC_VALUE) {
+   if (pvh_start_info.magic == XEN_HVM_START_MAGIC_VALUE) {
+   xen_pvh = 1;
+
+   init_pvh_bootparams_xen();
+
+   msr = cpuid_ebx(xen_cpuid_base() + 2);
+   pfn = __pa(hypercall_page);
+   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
+
+   x86_init.oem.arch_setup = xen_pvh_arch_setup;
+   } else if (pvh_start_info.magic == MULTIBOOT_INFO_MAGIC_VALUE) {
+   init_pvh_bootparams_multiboot();
+
+   } else {
xen_raw_printk("Error: Unexpected magic value (0x%08x)\n",
pvh_start_info.magic);
BUG();
}
-
-   xen_pvh = 1;
-
-   msr = cpuid_ebx(xen_cpuid_base() + 2);
-   pfn = __pa(hypercall_page);
-   wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32));
-
-   init_pvh_bootparams();
-
-   x86_init.oem.arch_setup = xen_pvh_arch_setup;
 }


Note that this would *not* be a multiboot-format kernel, as it would
still have the Xen PVH ELF note.  It would just reuse the format of
the start info struct.

However, I think it is simpler to just use the e820 memory map from
fw_cfg.

Paolo

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