[Xen-devel] [xtf test] 111348: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111348 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111348/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   33 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   27 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

2017-07-02 Thread Chao Gao
On Fri, Jun 30, 2017 at 05:19:52PM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Friday, June 30, 2017 9:17 AM
>> 
>> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>> we would wrongly use 00:00.0 to search VT-d unit.
>> 
>> From SRIOV spec REV 1.0 section 3.7.3, it says:
>> "ARI is not applicable to Root Complex integrated Endpoints; all other
>> SR-IOV Capable Devices (Devices that include at least one PF) shall
>> implement the ARI Capability in each Function.". So PFs can be classified to
>> two kinds: one is RC integrated PF and the other is non-RC integrated PF. The
>> former can't support ARI and the latter shall support ARI. For Extended
>> Functions, one traditional function's BDF should be used to search VT-d unit.
>> And according to PCIe spec, Extened Function means within an ARI device, a
>> Function whose Function Number is greater than 7. Thus, the former can't be
>> an
>> extended function, while the latter is as long as its devfn > 7, this check 
>> is
>> exactly what the original code did; The original code wasn't aware the 
>> former.
>> 
>> This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
>> to decide whether the PF is a extended function.
>
>Above description looks like the bug is caused by ARI problem. But
>if you look at the original code (and the problem you described), it's
>not related to ARI. ARI comes just when adding a clean fix, so please 
>revise the description to make that part clear
>

How about this:

The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
we would wrongly use 00:00.0 to search VT-d unit.

If a PF is an extended function, a traditional function's BDF should be
used to search VT-d unit. Previous code only checks whether Function
Number is greater than 7, without checking the prerequisite that the
function should be within an ARI device. This incurs wrongly using
traditional function's BDF when the PF is RC integrated and thus cannot
be within an ARI device.

Considering 'is_extfn' field of struct pci_dev has been passed down from
Domain0 to indicate whether the function is an extended function, this
patch just looks up that field of PF's struct pci_dev and adjust BDF
used to search VT-d unit accordingly. 

Thanks
Chao

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


Re: [Xen-devel] [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 03:18 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:


xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus
which initializes interrupt itself.

Touching the intr_mode_init causes unexpected results on the system.

Bypass it in enlighten_pv system.


So that's the wrong patch order then. You broke XEN at some point with your
changes. You need to prevent that breakage upfront not after the fact.


Yes, I have considered to prevent that breakage in the patchset.

Actually, Until the 11th patch, we put the intr_mode_init ahead of
time, which will break XEN.

Before the 11th patch, we just unify the code and do the preparation,
Kernel will do the intr_mode_init like before, which will have no
influence on XEN.

So we put the patch here before 11th patch.

Thanks,

dou.



Thanks,

tglx







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


[Xen-devel] [PATCH v5 00/11] Add LMCE support

2017-07-02 Thread Haozhong Zhang
Changes in v5:
 * Patch 1: add missing historical commit id in commit message
 * Patch 2: invert parameter "nowait" to "wait"
 * Patch 2: let caller pass in mce_broadcast
 * Patch 3: adapt for changes of patch 2
 * Patch 3: add comment in mctelem_defer()
 * Patch 8: take Wei's A-b

Haozhong Zhang (11):
  [N  A] 01/11 xen/mce: fix comment of struct mc_telem_cpu_ctl
  [NM  ] 02/11 xen/mce: allow mce_barrier_{enter,exit} to return without waiting
  [NM  ] 03/11 x86/mce: handle host LMCE
  [  R ] 04/11 x86/mce_intel: detect and enable LMCE on Intel host
  [  R ] 05/11 x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL
  [  R ] 06/11 x86/vmce: emulate MSR_IA32_MCG_EXT_CTL
  [  R ] 07/11 x86/vmce: enable injecting LMCE to guest on Intel host
  [  RA] 08/11 x86/vmce, tools/libxl: expose LMCE capability in guest 
MSR_IA32_MCG_CAP
  [  R ] 09/11 xen/mce: add support of vLMCE injection to XEN_MC_inject_v2
  [  A ] 10/11 tools/libxc: add support of injecting MC# to specified CPUs
  [  A ] 11/11 tools/xen-mceinj: add support of injecting LMCE

 N: new in this version
 M: modified in this version
 R: got R-b
 A: got A-b

 docs/man/xl.cfg.pod.5.in|  24 +++
 tools/libxc/include/xenctrl.h   |   2 +
 tools/libxc/xc_misc.c   |  52 ++-
 tools/libxc/xc_sr_save_x86_hvm.c|   1 +
 tools/libxl/libxl.h |   7 +++
 tools/libxl/libxl_dom.c |  15 +
 tools/libxl/libxl_types.idl |   1 +
 tools/tests/mce-test/tools/xen-mceinj.c |  50 ++-
 tools/xl/xl_parse.c |  31 -
 xen/arch/x86/cpu/mcheck/barrier.c   |  12 ++--
 xen/arch/x86/cpu/mcheck/barrier.h   |  14 -
 xen/arch/x86/cpu/mcheck/mcaction.c  |  21 +--
 xen/arch/x86/cpu/mcheck/mce.c   |  92 ++-
 xen/arch/x86/cpu/mcheck/mce.h   |   2 +
 xen/arch/x86/cpu/mcheck/mce_intel.c |  50 +--
 xen/arch/x86/cpu/mcheck/mctelem.c   | 108 +---
 xen/arch/x86/cpu/mcheck/mctelem.h   |   5 +-
 xen/arch/x86/cpu/mcheck/vmce.c  |  64 ++-
 xen/arch/x86/cpu/mcheck/vmce.h  |   2 +-
 xen/arch/x86/cpu/mcheck/x86_mca.h   |   9 ++-
 xen/arch/x86/hvm/hvm.c  |   5 ++
 xen/arch/x86/hvm/vmx/vmx.c  |   9 +++
 xen/arch/x86/hvm/vmx/vvmx.c |   4 --
 xen/include/asm-x86/mce.h   |   3 +
 xen/include/asm-x86/msr-index.h |   2 +
 xen/include/public/arch-x86/hvm/save.h  |   1 +
 xen/include/public/arch-x86/xen-mca.h   |   1 +
 xen/include/public/hvm/params.h |   7 ++-
 28 files changed, 519 insertions(+), 75 deletions(-)

-- 
2.11.0


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


[Xen-devel] [PATCH v5 11/11] tools/xen-mceinj: add support of injecting LMCE

2017-07-02 Thread Haozhong Zhang
If option '-l' or '--lmce' is specified and the host supports LMCE,
xen-mceinj will inject LMCE to CPU specified by '-c' (or CPU0 if '-c'
is not present).

Signed-off-by: Haozhong Zhang 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/tests/mce-test/tools/xen-mceinj.c | 50 +++--
 1 file changed, 48 insertions(+), 2 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index bae5a46eb5..380e42190c 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -56,6 +56,8 @@
 #define MSR_IA32_MC0_MISC0x0403
 #define MSR_IA32_MC0_CTL20x0280
 
+#define MCG_STATUS_LMCE  0x8
+
 struct mce_info {
 const char *description;
 uint8_t mcg_stat;
@@ -113,6 +115,7 @@ static struct mce_info mce_table[] = {
 #define LOGFILE stdout
 
 int dump;
+int lmce;
 struct xen_mc_msrinject msr_inj;
 
 static void Lprintf(const char *fmt, ...)
@@ -212,6 +215,35 @@ static int inject_mce(xc_interface *xc_handle, int cpu_nr)
 return xc_mca_op(xc_handle, );
 }
 
+static int inject_lmce(xc_interface *xc_handle, unsigned int cpu)
+{
+uint8_t *cpumap = NULL;
+size_t cpumap_size, line, shift;
+unsigned int nr_cpus;
+int ret;
+
+nr_cpus = mca_cpuinfo(xc_handle);
+if ( !nr_cpus )
+err(xc_handle, "Failed to get mca_cpuinfo");
+if ( cpu >= nr_cpus )
+err(xc_handle, "-c %u is larger than %u", cpu, nr_cpus - 1);
+
+cpumap_size = (nr_cpus + 7) / 8;
+cpumap = malloc(cpumap_size);
+if ( !cpumap )
+err(xc_handle, "Failed to allocate cpumap\n");
+memset(cpumap, 0, cpumap_size);
+line = cpu / 8;
+shift = cpu % 8;
+memset(cpumap + line, 1 << shift, 1);
+
+ret = xc_mca_op_inject_v2(xc_handle, XEN_MC_INJECT_TYPE_LMCE,
+  cpumap, cpumap_size * 8);
+
+free(cpumap);
+return ret;
+}
+
 static uint64_t bank_addr(int bank, int type)
 {
 uint64_t addr;
@@ -330,8 +362,15 @@ static int inject(xc_interface *xc_handle, struct mce_info 
*mce,
   uint32_t cpu_nr, uint32_t domain, uint64_t gaddr)
 {
 int ret = 0;
+uint8_t mcg_status = mce->mcg_stat;
 
-ret = inject_mcg_status(xc_handle, cpu_nr, mce->mcg_stat, domain);
+if ( lmce )
+{
+if ( mce->cmci )
+err(xc_handle, "No support to inject CMCI as LMCE");
+mcg_status |= MCG_STATUS_LMCE;
+}
+ret = inject_mcg_status(xc_handle, cpu_nr, mcg_status, domain);
 if ( ret )
 err(xc_handle, "Failed to inject MCG_STATUS MSR");
 
@@ -354,6 +393,8 @@ static int inject(xc_interface *xc_handle, struct mce_info 
*mce,
 err(xc_handle, "Failed to inject MSR");
 if ( mce->cmci )
 ret = inject_cmci(xc_handle, cpu_nr);
+else if ( lmce )
+ret = inject_lmce(xc_handle, cpu_nr);
 else
 ret = inject_mce(xc_handle, cpu_nr);
 if ( ret )
@@ -393,6 +434,7 @@ static struct option opts[] = {
 {"dump", 0, 0, 'D'},
 {"help", 0, 0, 'h'},
 {"page", 0, 0, 'p'},
+{"lmce", 0, 0, 'l'},
 {"", 0, 0, '\0'}
 };
 
@@ -409,6 +451,7 @@ static void help(void)
"  -d, --domain=DOMID   target domain, the default is Xen itself\n"
"  -h, --help   print this page\n"
"  -p, --page=ADDR  physical address to report\n"
+   "  -l, --lmce   inject as LMCE (Intel only)\n"
"  -t, --type=ERROR error type\n");
 
 for ( i = 0; i < MCE_TABLE_SIZE; i++ )
@@ -438,7 +481,7 @@ int main(int argc, char *argv[])
 }
 
 while ( 1 ) {
-c = getopt_long(argc, argv, "c:Dd:t:hp:", opts, _index);
+c = getopt_long(argc, argv, "c:Dd:t:hp:l", opts, _index);
 if ( c == -1 )
 break;
 switch ( c ) {
@@ -463,6 +506,9 @@ int main(int argc, char *argv[])
 case 't':
 type = strtol(optarg, NULL, 0);
 break;
+case 'l':
+lmce = 1;
+break;
 case 'h':
 default:
 help();
-- 
2.11.0


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


[Xen-devel] [PATCH v5 07/11] x86/vmce: enable injecting LMCE to guest on Intel host

2017-07-02 Thread Haozhong Zhang
Inject LMCE to guest if the host MCE is LMCE and the affected vcpu is
known. Otherwise, broadcast MCE to all vcpus on Intel host.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mcaction.c | 23 ---
 xen/arch/x86/cpu/mcheck/vmce.c | 11 ++-
 xen/arch/x86/cpu/mcheck/vmce.h |  2 +-
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mcaction.c 
b/xen/arch/x86/cpu/mcheck/mcaction.c
index ca17d22bd8..f959bed2cb 100644
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -44,6 +44,7 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
 unsigned long mfn, gfn;
 uint32_t status;
 int vmce_vcpuid;
+unsigned int mc_vcpuid;
 
 if (!mc_check_addr(bank->mc_status, bank->mc_misc, MC_ADDR_PHYSICAL)) {
 dprintk(XENLOG_WARNING,
@@ -88,18 +89,26 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
 goto vmce_failed;
 }
 
-if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL ||
-global->mc_vcpuid == XEN_MC_VCPUID_INVALID)
+mc_vcpuid = global->mc_vcpuid;
+if (mc_vcpuid == XEN_MC_VCPUID_INVALID ||
+/*
+ * Because MC# may happen asynchronously with the actual
+ * operation that triggers the error, the domain ID as
+ * well as the vCPU ID collected in 'global' at MC# are
+ * not always precise. In that case, fallback to broadcast.
+ */
+global->mc_domid != bank->mc_domid ||
+(boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+ (!(global->mc_gstatus & MCG_STATUS_LMCE) ||
+  !(d->vcpu[mc_vcpuid]->arch.vmce.mcg_ext_ctl &
+MCG_EXT_CTL_LMCE_EN
 vmce_vcpuid = VMCE_INJECT_BROADCAST;
 else
-vmce_vcpuid = global->mc_vcpuid;
+vmce_vcpuid = mc_vcpuid;
 
 bank->mc_addr = gfn << PAGE_SHIFT |
   (bank->mc_addr & (PAGE_SIZE -1 ));
-/* TODO: support injecting LMCE */
-if (fill_vmsr_data(bank, d,
-   global->mc_gstatus & ~MCG_STATUS_LMCE,
-   vmce_vcpuid == VMCE_INJECT_BROADCAST))
+if (fill_vmsr_data(bank, d, global->mc_gstatus, vmce_vcpuid))
 {
 mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d "
   "failed\n", bank->mc_domid);
diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 210670638f..9830835c5a 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -464,14 +464,23 @@ static int vcpu_fill_mc_msrs(struct vcpu *v, uint64_t 
mcg_status,
 }
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-   uint64_t gstatus, bool broadcast)
+   uint64_t gstatus, int vmce_vcpuid)
 {
 struct vcpu *v = d->vcpu[0];
+bool broadcast = (vmce_vcpuid == VMCE_INJECT_BROADCAST);
 int ret, err;
 
 if ( mc_bank->mc_domid == DOMID_INVALID )
 return -EINVAL;
 
+if ( broadcast )
+gstatus &= ~MCG_STATUS_LMCE;
+else if ( gstatus & MCG_STATUS_LMCE )
+{
+ASSERT(vmce_vcpuid >= 0 && vmce_vcpuid < d->max_vcpus);
+v = d->vcpu[vmce_vcpuid];
+}
+
 /*
  * vMCE with the actual error information is injected to vCPU0,
  * and, if broadcast is required, we choose to inject less severe
diff --git a/xen/arch/x86/cpu/mcheck/vmce.h b/xen/arch/x86/cpu/mcheck/vmce.h
index 74f6381460..2797e00275 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.h
+++ b/xen/arch/x86/cpu/mcheck/vmce.h
@@ -17,7 +17,7 @@ int vmce_amd_rdmsr(const struct vcpu *, uint32_t msr, 
uint64_t *val);
 int vmce_amd_wrmsr(struct vcpu *, uint32_t msr, uint64_t val);
 
 int fill_vmsr_data(struct mcinfo_bank *mc_bank, struct domain *d,
-   uint64_t gstatus, bool broadcast);
+   uint64_t gstatus, int vmce_vcpuid);
 
 #define VMCE_INJECT_BROADCAST (-1)
 int inject_vmce(struct domain *d, int vcpu);
-- 
2.11.0


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


[Xen-devel] [PATCH v5 04/11] x86/mce_intel: detect and enable LMCE on Intel host

2017-07-02 Thread Haozhong Zhang
Enable LMCE if it's supported by the host CPU. If Xen boot parameter
"mce_fb = 1" is present, LMCE will be disabled forcibly.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mce_intel.c | 46 -
 xen/arch/x86/cpu/mcheck/x86_mca.h   |  5 
 xen/include/asm-x86/msr-index.h |  2 ++
 3 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c 
b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 4e976c45f8..020b02deff 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -29,6 +29,9 @@ boolean_param("mce_fb", mce_force_broadcast);
 
 static int __read_mostly nr_intel_ext_msrs;
 
+/* If mce_force_broadcast == 1, lmce_support will be disabled forcibly. */
+static bool __read_mostly lmce_support;
+
 /* Intel SDM define bit15~bit0 of IA32_MCi_STATUS as the MC error code */
 #define INTEL_MCCOD_MASK 0x
 
@@ -698,10 +701,34 @@ static bool mce_is_broadcast(struct cpuinfo_x86 *c)
 return false;
 }
 
+static bool intel_enable_lmce(void)
+{
+uint64_t msr_content;
+
+/*
+ * Section "Enabling Local Machine Check" in Intel SDM Vol 3
+ * requires software must ensure the LOCK bit and LMCE_ON bit
+ * of MSR_IA32_FEATURE_CONTROL are set before setting
+ * MSR_IA32_MCG_EXT_CTL.LMCE_EN.
+ */
+
+if ( rdmsr_safe(MSR_IA32_FEATURE_CONTROL, msr_content) )
+return false;
+
+if ( (msr_content & IA32_FEATURE_CONTROL_LOCK) &&
+ (msr_content & IA32_FEATURE_CONTROL_LMCE_ON) )
+{
+wrmsrl(MSR_IA32_MCG_EXT_CTL, MCG_EXT_CTL_LMCE_EN);
+return true;
+}
+
+return false;
+}
+
 /* Check and init MCA */
 static void intel_init_mca(struct cpuinfo_x86 *c)
 {
-bool broadcast, cmci = false, ser = false;
+bool broadcast, cmci = false, ser = false, lmce = false;
 int ext_num = 0, first;
 uint64_t msr_content;
 
@@ -721,33 +748,40 @@ static void intel_init_mca(struct cpuinfo_x86 *c)
 
 first = mce_firstbank(c);
 
+if (!mce_force_broadcast && (msr_content & MCG_LMCE_P))
+lmce = intel_enable_lmce();
+
 #define CAP(enabled, name) ((enabled) ? ", " name : "")
 if (smp_processor_id() == 0)
 {
 dprintk(XENLOG_INFO,
-"MCA capability: firstbank %d, %d ext MSRs%s%s%s\n",
+"MCA Capability: firstbank %d, extended MCE MSR %d%s%s%s%s\n",
 first, ext_num,
 CAP(broadcast, "BCAST"),
 CAP(ser, "SER"),
-CAP(cmci, "CMCI"));
+CAP(cmci, "CMCI"),
+CAP(lmce, "LMCE"));
 
 mce_broadcast = broadcast;
 cmci_support = cmci;
 ser_support = ser;
+lmce_support = lmce;
 nr_intel_ext_msrs = ext_num;
 firstbank = first;
 }
 else if (cmci != cmci_support || ser != ser_support ||
  broadcast != mce_broadcast ||
- first != firstbank || ext_num != nr_intel_ext_msrs)
+ first != firstbank || ext_num != nr_intel_ext_msrs ||
+ lmce != lmce_support)
 dprintk(XENLOG_WARNING,
 "CPU%u has different MCA capability "
-"(firstbank %d, %d ext MSRs%s%s%s)"
+"(firstbank %d, extended MCE MSR %d%s%s%s%s)"
 " than BSP, may cause undetermined result!!!\n",
 smp_processor_id(), first, ext_num,
 CAP(broadcast, "BCAST"),
 CAP(ser, "SER"),
-CAP(cmci, "CMCI"));
+CAP(cmci, "CMCI"),
+CAP(lmce, "LMCE"));
 #undef CAP
 }
 
diff --git a/xen/arch/x86/cpu/mcheck/x86_mca.h 
b/xen/arch/x86/cpu/mcheck/x86_mca.h
index de03f829c3..0f87bcf63e 100644
--- a/xen/arch/x86/cpu/mcheck/x86_mca.h
+++ b/xen/arch/x86/cpu/mcheck/x86_mca.h
@@ -36,6 +36,7 @@
 #define MCG_TES_P   (1ULL<<11) /* Intel specific */
 #define MCG_EXT_CNT 16 /* Intel specific */
 #define MCG_SER_P   (1ULL<<24) /* Intel specific */
+#define MCG_LMCE_P  (1ULL<<27) /* Intel specific */
 /* Other bits are reserved */
 
 /* Bitfield of the MSR_IA32_MCG_STATUS register */
@@ -46,6 +47,10 @@
 /* Bits 3-63 are reserved on CPU not supporting LMCE */
 /* Bits 4-63 are reserved on CPU supporting LMCE */
 
+/* Bitfield of MSR_IA32_MCG_EXT_CTL register (Intel Specific) */
+#define MCG_EXT_CTL_LMCE_EN (1ULL<<0)
+/* Other bits are reserved */
+
 /* Bitfield of MSR_K8_MCi_STATUS registers */
 /* MCA error code */
 #define MCi_STATUS_MCA  0xULL
diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
index 771e7500af..756b23d19e 100644
--- a/xen/include/asm-x86/msr-index.h
+++ b/xen/include/asm-x86/msr-index.h
@@ -51,6 +51,7 @@
 #define MSR_IA32_MCG_CAP   

[Xen-devel] [PATCH v5 05/11] x86/vmx: expose LMCE feature via guest MSR_IA32_FEATURE_CONTROL

2017-07-02 Thread Haozhong Zhang
If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then set LMCE and
LOCK bits in guest MSR_IA32_FEATURE_CONTROL. Intel SDM requires those
bits are set before SW can enable LMCE.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Kevin Tian 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Jun Nakajima 
Cc: Kevin Tian 
---
 xen/arch/x86/cpu/mcheck/mce_intel.c | 4 
 xen/arch/x86/hvm/vmx/vmx.c  | 9 +
 xen/arch/x86/hvm/vmx/vvmx.c | 4 
 xen/include/asm-x86/mce.h   | 1 +
 4 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce_intel.c 
b/xen/arch/x86/cpu/mcheck/mce_intel.c
index 020b02deff..5cb49ca697 100644
--- a/xen/arch/x86/cpu/mcheck/mce_intel.c
+++ b/xen/arch/x86/cpu/mcheck/mce_intel.c
@@ -946,3 +946,7 @@ int vmce_intel_rdmsr(const struct vcpu *v, uint32_t msr, 
uint64_t *val)
 return 1;
 }
 
+bool vmce_has_lmce(const struct vcpu *v)
+{
+return v->arch.vmce.mcg_cap & MCG_LMCE_P;
+}
diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
index c53b24955a..6a193ef9d4 100644
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -2856,6 +2857,8 @@ static int is_last_branch_msr(u32 ecx)
 
 static int vmx_msr_read_intercept(unsigned int msr, uint64_t *msr_content)
 {
+const struct vcpu *curr = current;
+
 HVM_DBG_LOG(DBG_LEVEL_MSR, "ecx=%#x", msr);
 
 switch ( msr )
@@ -2873,6 +2876,12 @@ static int vmx_msr_read_intercept(unsigned int msr, 
uint64_t *msr_content)
 __vmread(GUEST_IA32_DEBUGCTL, msr_content);
 break;
 case MSR_IA32_FEATURE_CONTROL:
+*msr_content = IA32_FEATURE_CONTROL_LOCK;
+if ( vmce_has_lmce(curr) )
+*msr_content |= IA32_FEATURE_CONTROL_LMCE_ON;
+if ( nestedhvm_enabled(curr->domain) )
+*msr_content |= IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX;
+break;
 case MSR_IA32_VMX_BASIC...MSR_IA32_VMX_VMFUNC:
 if ( !nvmx_msr_read_intercept(msr, msr_content) )
 goto gp_fault;
diff --git a/xen/arch/x86/hvm/vmx/vvmx.c b/xen/arch/x86/hvm/vmx/vvmx.c
index 3560faec6d..f451935ea6 100644
--- a/xen/arch/x86/hvm/vmx/vvmx.c
+++ b/xen/arch/x86/hvm/vmx/vvmx.c
@@ -2084,10 +2084,6 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 
*msr_content)
 data = gen_vmx_msr(data, VMX_ENTRY_CTLS_DEFAULT1, host_data);
 break;
 
-case MSR_IA32_FEATURE_CONTROL:
-data = IA32_FEATURE_CONTROL_LOCK |
-   IA32_FEATURE_CONTROL_ENABLE_VMXON_OUTSIDE_SMX;
-break;
 case MSR_IA32_VMX_VMCS_ENUM:
 /* The max index of VVMCS encoding is 0x1f. */
 data = 0x1f << 1;
diff --git a/xen/include/asm-x86/mce.h b/xen/include/asm-x86/mce.h
index 549bef3ebe..56ad1f92dd 100644
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -36,6 +36,7 @@ extern void vmce_init_vcpu(struct vcpu *);
 extern int vmce_restore_vcpu(struct vcpu *, const struct hvm_vmce_vcpu *);
 extern int vmce_wrmsr(uint32_t msr, uint64_t val);
 extern int vmce_rdmsr(uint32_t msr, uint64_t *val);
+extern bool vmce_has_lmce(const struct vcpu *v);
 
 extern unsigned int nr_mce_banks;
 
-- 
2.11.0


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


[Xen-devel] [PATCH v5 10/11] tools/libxc: add support of injecting MC# to specified CPUs

2017-07-02 Thread Haozhong Zhang
Though XEN_MC_inject_v2 allows injecting MC# to specified CPUs, the
current xc_mca_op() does not use this feature and not provide an
interface to callers. This commit add a new xc_mca_op_inject_v2() that
receives a cpumap providing the set of target CPUs.

Signed-off-by: Haozhong Zhang 
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Wei Liu 
---
 tools/libxc/include/xenctrl.h |  2 ++
 tools/libxc/xc_misc.c | 52 ++-
 2 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1629f412dd..85169b0553 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1799,6 +1799,8 @@ int xc_cpuid_apply_policy(xc_interface *xch,
 void xc_cpuid_to_str(const unsigned int *regs,
  char **strs); /* some strs[] may be NULL if ENOMEM */
 int xc_mca_op(xc_interface *xch, struct xen_mc *mc);
+int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
+xc_cpumap_t cpumap, unsigned int nr_cpus);
 #endif
 
 struct xc_px_val {
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 88084fde30..2303293c6c 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -341,7 +341,57 @@ int xc_mca_op(xc_interface *xch, struct xen_mc *mc)
 xc_hypercall_bounce_post(xch, mc);
 return ret;
 }
-#endif
+
+int xc_mca_op_inject_v2(xc_interface *xch, unsigned int flags,
+xc_cpumap_t cpumap, unsigned int nr_bits)
+{
+int ret = -1;
+struct xen_mc mc_buf, *mc = _buf;
+struct xen_mc_inject_v2 *inject = >u.mc_inject_v2;
+
+DECLARE_HYPERCALL_BOUNCE(cpumap, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+DECLARE_HYPERCALL_BOUNCE(mc, sizeof(*mc), XC_HYPERCALL_BUFFER_BOUNCE_BOTH);
+
+memset(mc, 0, sizeof(*mc));
+
+if ( cpumap )
+{
+if ( !nr_bits )
+{
+errno = EINVAL;
+goto out;
+}
+
+HYPERCALL_BOUNCE_SET_SIZE(cpumap, (nr_bits + 7) / 8);
+if ( xc_hypercall_bounce_pre(xch, cpumap) )
+{
+PERROR("Could not bounce cpumap memory buffer");
+goto out;
+}
+set_xen_guest_handle(inject->cpumap.bitmap, cpumap);
+inject->cpumap.nr_bits = nr_bits;
+}
+
+inject->flags = flags;
+mc->cmd = XEN_MC_inject_v2;
+mc->interface_version = XEN_MCA_INTERFACE_VERSION;
+
+if ( xc_hypercall_bounce_pre(xch, mc) )
+{
+PERROR("Could not bounce xen_mc memory buffer");
+goto out_free_cpumap;
+}
+
+ret = xencall1(xch->xcall, __HYPERVISOR_mca, HYPERCALL_BUFFER_AS_ARG(mc));
+
+xc_hypercall_bounce_post(xch, mc);
+out_free_cpumap:
+if ( cpumap )
+xc_hypercall_bounce_post(xch, cpumap);
+out:
+return ret;
+}
+#endif /* __i386__ || __x86_64__ */
 
 int xc_perfc_reset(xc_interface *xch)
 {
-- 
2.11.0


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


[Xen-devel] [PATCH v5 08/11] x86/vmce, tools/libxl: expose LMCE capability in guest MSR_IA32_MCG_CAP

2017-07-02 Thread Haozhong Zhang
If LMCE is supported by host and ' mca_caps = [ "lmce" ] ' is present
in xl config, the LMCE capability will be exposed in guest MSR_IA32_MCG_CAP.
By default, LMCE is not exposed to guest so as to keep the backwards migration
compatibility.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich  for hypervisor side
Acked-by: Wei Liu 
---
Cc: Ian Jackson 
Cc: Wei Liu 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 docs/man/xl.cfg.pod.5.in| 24 
 tools/libxc/xc_sr_save_x86_hvm.c|  1 +
 tools/libxl/libxl.h |  7 +++
 tools/libxl/libxl_dom.c | 15 +++
 tools/libxl/libxl_types.idl |  1 +
 tools/xl/xl_parse.c | 31 +--
 xen/arch/x86/cpu/mcheck/mce.h   |  1 +
 xen/arch/x86/cpu/mcheck/mce_intel.c |  2 +-
 xen/arch/x86/cpu/mcheck/vmce.c  | 19 ++-
 xen/arch/x86/hvm/hvm.c  |  5 +
 xen/include/asm-x86/mce.h   |  1 +
 xen/include/public/hvm/params.h |  7 ++-
 12 files changed, 109 insertions(+), 5 deletions(-)

diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/xl.cfg.pod.5.in
index 38084c723a..51ec74325d 100644
--- a/docs/man/xl.cfg.pod.5.in
+++ b/docs/man/xl.cfg.pod.5.in
@@ -2168,6 +2168,30 @@ natively or via hardware backwards compatibility support.
 
 =back
 
+=head3 x86
+
+=over 4
+
+=item 

[Xen-devel] [PATCH v5 02/11] xen/mce: allow mce_barrier_{enter, exit} to return without waiting

2017-07-02 Thread Haozhong Zhang
Add a 'wait' argument to mce_barrier_{enter,exit}() to specify whether
the barrier functions should return immediately without waiting
mce_barrier_{enter,exit}() on other CPUs. This is useful when handling
LMCE, where mce_barrier_{enter,exit} are called only on one CPU.

Signed-off-by: Haozhong Zhang 
---
Changes in v5:
 * Invert paremeter "nowait" to "wait".
 * Let callers pass in "mce_broadcast" explicitly.

Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/barrier.c | 12 ++--
 xen/arch/x86/cpu/mcheck/barrier.h | 14 --
 xen/arch/x86/cpu/mcheck/mce.c | 20 ++--
 3 files changed, 28 insertions(+), 18 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/barrier.c 
b/xen/arch/x86/cpu/mcheck/barrier.c
index 5dce1fb9b9..7de8e45e8c 100644
--- a/xen/arch/x86/cpu/mcheck/barrier.c
+++ b/xen/arch/x86/cpu/mcheck/barrier.c
@@ -16,11 +16,11 @@ void mce_barrier_dec(struct mce_softirq_barrier *bar)
 atomic_dec(>val);
 }
 
-void mce_barrier_enter(struct mce_softirq_barrier *bar)
+void mce_barrier_enter(struct mce_softirq_barrier *bar, bool wait)
 {
 int gen;
 
-if (!mce_broadcast)
+if ( !wait )
 return;
 atomic_inc(>ingen);
 gen = atomic_read(>outgen);
@@ -34,11 +34,11 @@ void mce_barrier_enter(struct mce_softirq_barrier *bar)
 }
 }
 
-void mce_barrier_exit(struct mce_softirq_barrier *bar)
+void mce_barrier_exit(struct mce_softirq_barrier *bar, bool wait)
 {
 int gen;
 
-if ( !mce_broadcast )
+if ( !wait )
 return;
 atomic_inc(>outgen);
 gen = atomic_read(>ingen);
@@ -54,6 +54,6 @@ void mce_barrier_exit(struct mce_softirq_barrier *bar)
 
 void mce_barrier(struct mce_softirq_barrier *bar)
 {
-mce_barrier_enter(bar);
-mce_barrier_exit(bar);
+mce_barrier_enter(bar, mce_broadcast);
+mce_barrier_exit(bar, mce_broadcast);
 }
diff --git a/xen/arch/x86/cpu/mcheck/barrier.h 
b/xen/arch/x86/cpu/mcheck/barrier.h
index d3ccf8b15f..c4d52b6192 100644
--- a/xen/arch/x86/cpu/mcheck/barrier.h
+++ b/xen/arch/x86/cpu/mcheck/barrier.h
@@ -32,6 +32,16 @@ void mce_barrier_init(struct mce_softirq_barrier *);
 void mce_barrier_dec(struct mce_softirq_barrier *);
 
 /*
+ * If @wait is false, mce_barrier_enter/exit() will return immediately
+ * without touching the barrier. It's used when handling a
+ * non-broadcasting MCE (e.g. MCE on some old Intel CPU, MCE on AMD
+ * CPU and LMCE on Intel Skylake-server CPU) which is received on only
+ * one CPU and thus does not invoke mce_barrier_enter/exit() calls on
+ * all CPUs.
+ *
+ * If @wait is true, mce_barrier_enter/exit() will handle the given
+ * barrier as below.
+ *
  * Increment the generation number and the value. The generation number
  * is incremented when entering a barrier. This way, it can be checked
  * on exit if a CPU is trying to re-enter the barrier. This can happen
@@ -43,8 +53,8 @@ void mce_barrier_dec(struct mce_softirq_barrier *);
  * These barrier functions should always be paired, so that the
  * counter value will reach 0 again after all CPUs have exited.
  */
-void mce_barrier_enter(struct mce_softirq_barrier *);
-void mce_barrier_exit(struct mce_softirq_barrier *);
+void mce_barrier_enter(struct mce_softirq_barrier *, bool wait);
+void mce_barrier_exit(struct mce_softirq_barrier *, bool wait);
 
 void mce_barrier(struct mce_softirq_barrier *);
 
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 54fd000aa0..d247d6e198 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -497,15 +497,15 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 }
 mce_spin_unlock(_logout_lock);
 
-mce_barrier_enter(_trap_bar);
+mce_barrier_enter(_trap_bar, mce_broadcast);
 if ( mctc != NULL && mce_urgent_action(regs, mctc))
 cpumask_set_cpu(smp_processor_id(), _fatal_cpus);
-mce_barrier_exit(_trap_bar);
+mce_barrier_exit(_trap_bar, mce_broadcast);
 
 /*
  * Wait until everybody has processed the trap.
  */
-mce_barrier_enter(_trap_bar);
+mce_barrier_enter(_trap_bar, mce_broadcast);
 if (atomic_read(_cpu) == smp_processor_id())
 {
 /* According to SDM, if no error bank found on any cpus,
@@ -524,16 +524,16 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 atomic_set(_error, 0);
 atomic_set(_cpu, -1);
 }
-mce_barrier_exit(_trap_bar);
+mce_barrier_exit(_trap_bar, mce_broadcast);
 
 /* Clear flags after above fatal check */
-mce_barrier_enter(_trap_bar);
+mce_barrier_enter(_trap_bar, mce_broadcast);
 gstatus = mca_rdmsr(MSR_IA32_MCG_STATUS);
 if ((gstatus & MCG_STATUS_MCIP) != 0) {
 mce_printk(MCE_CRITICAL, "MCE: Clear MCIP@ last step");
 mca_wrmsr(MSR_IA32_MCG_STATUS, 0);
 }
-mce_barrier_exit(_trap_bar);
+mce_barrier_exit(_trap_bar, mce_broadcast);
 
 

[Xen-devel] [PATCH v5 09/11] xen/mce: add support of vLMCE injection to XEN_MC_inject_v2

2017-07-02 Thread Haozhong Zhang
Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mce.c | 24 +++-
 xen/include/public/arch-x86/xen-mca.h |  1 +
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 0e17fb707a..e835ea7943 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -1486,11 +1486,12 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 {
 const cpumask_t *cpumap;
 cpumask_var_t cmv;
+bool broadcast = op->u.mc_inject_v2.flags & 
XEN_MC_INJECT_CPU_BROADCAST;
 
 if (nr_mce_banks == 0)
 return x86_mcerr("do_mca #MC", -ENODEV);
 
-if ( op->u.mc_inject_v2.flags & XEN_MC_INJECT_CPU_BROADCAST )
+if ( broadcast )
 cpumap = _online_map;
 else
 {
@@ -1530,6 +1531,27 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 }
 break;
 
+case XEN_MC_INJECT_TYPE_LMCE:
+if ( !lmce_support )
+{
+ret = x86_mcerr("No LMCE support", -EINVAL);
+break;
+}
+if ( broadcast )
+{
+ret = x86_mcerr("Broadcast cannot be used with LMCE", -EINVAL);
+break;
+}
+/* Ensure at most one CPU is specified. */
+if ( nr_cpu_ids > cpumask_next(cpumask_first(cpumap), cpumap) )
+{
+ret = x86_mcerr("More than one CPU specified for LMCE",
+-EINVAL);
+break;
+}
+on_selected_cpus(cpumap, x86_mc_mceinject, NULL, 1);
+break;
+
 default:
 ret = x86_mcerr("Wrong mca type\n", -EINVAL);
 break;
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index 7db990723b..dc35267249 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -414,6 +414,7 @@ struct xen_mc_mceinject {
 #define XEN_MC_INJECT_TYPE_MASK 0x7
 #define XEN_MC_INJECT_TYPE_MCE  0x0
 #define XEN_MC_INJECT_TYPE_CMCI 0x1
+#define XEN_MC_INJECT_TYPE_LMCE 0x2
 
 #define XEN_MC_INJECT_CPU_BROADCAST 0x8
 
-- 
2.11.0


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


[Xen-devel] [PATCH v5 01/11] xen/mce: fix comment of struct mc_telem_cpu_ctl

2017-07-02 Thread Haozhong Zhang
Since c/s cbc585158f ("x86/mce: eliminate unnecessary NR_CPUS-sized
arrays"), struct mc_telem_cpu_ctl was introduced and has been used as
the type of per-cpu variables rather than global variables. However,
some comments within it have not been updated accordingly.

Signed-off-by: Haozhong Zhang 
Acked-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mctelem.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mctelem.c 
b/xen/arch/x86/cpu/mcheck/mctelem.c
index 96048ebcc0..57abeab357 100644
--- a/xen/arch/x86/cpu/mcheck/mctelem.c
+++ b/xen/arch/x86/cpu/mcheck/mctelem.c
@@ -108,9 +108,7 @@ static struct mc_telem_ctl {
 struct mc_telem_cpu_ctl {
/*
 * Per-CPU processing lists, used for deferred (softirq)
-* processing of telemetry. @pending is indexed by the
-* CPU that the telemetry belongs to. @processing is indexed
-* by the CPU that is processing the telemetry.
+* processing of telemetry.
 */
struct mctelem_ent *pending;
struct mctelem_ent *processing;
-- 
2.11.0


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


[Xen-devel] [PATCH v5 06/11] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

2017-07-02 Thread Haozhong Zhang
If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
to read/write MSR_IA32_MCG_EXT_CTL.

Signed-off-by: Haozhong Zhang 
Reviewed-by: Jan Beulich 
---
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/vmce.c | 34 +-
 xen/include/asm-x86/mce.h  |  1 +
 xen/include/public/arch-x86/hvm/save.h |  1 +
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index d591d31600..210670638f 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -90,6 +90,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct 
hvm_vmce_vcpu *ctxt)
 v->arch.vmce.mcg_cap = ctxt->caps;
 v->arch.vmce.bank[0].mci_ctl2 = ctxt->mci_ctl2_bank0;
 v->arch.vmce.bank[1].mci_ctl2 = ctxt->mci_ctl2_bank1;
+v->arch.vmce.mcg_ext_ctl = ctxt->mcg_ext_ctl;
 
 return 0;
 }
@@ -199,6 +200,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *val)
 mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_CTL %#"PRIx64"\n", cur, 
*val);
 break;
 
+case MSR_IA32_MCG_EXT_CTL:
+/*
+ * If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, the LMCE and 
LOCK
+ * bits are always set in guest MSR_IA32_FEATURE_CONTROL by Xen, so it
+ * does not need to check them here.
+ */
+if ( cur->arch.vmce.mcg_cap & MCG_LMCE_P )
+{
+*val = cur->arch.vmce.mcg_ext_ctl;
+mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_EXT_CTL %#"PRIx64"\n",
+   cur, *val);
+}
+else
+{
+ret = -1;
+mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_EXT_CTL, not 
supported\n",
+   cur);
+}
+break;
+
 default:
 ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
 break;
@@ -308,6 +329,16 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 mce_printk(MCE_VERBOSE, "MCE: %pv: MCG_CAP is r/o\n", cur);
 break;
 
+case MSR_IA32_MCG_EXT_CTL:
+if ( (cur->arch.vmce.mcg_cap & MCG_LMCE_P) &&
+ !(val & ~MCG_EXT_CTL_LMCE_EN) )
+cur->arch.vmce.mcg_ext_ctl = val;
+else
+ret = -1;
+mce_printk(MCE_VERBOSE, "MCE: %pv: wr MCG_EXT_CTL %"PRIx64"%s\n",
+   cur, val, (ret == -1) ? ", not supported" : "");
+break;
+
 default:
 ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
 break;
@@ -326,7 +357,8 @@ static int vmce_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 struct hvm_vmce_vcpu ctxt = {
 .caps = v->arch.vmce.mcg_cap,
 .mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2,
-.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2
+.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2,
+.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl,
 };
 
 err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
diff --git a/xen/include/asm-x86/mce.h b/xen/include/asm-x86/mce.h
index 56ad1f92dd..35f9962638 100644
--- a/xen/include/asm-x86/mce.h
+++ b/xen/include/asm-x86/mce.h
@@ -27,6 +27,7 @@ struct vmce_bank {
 struct vmce {
 uint64_t mcg_cap;
 uint64_t mcg_status;
+uint64_t mcg_ext_ctl;
 spinlock_t lock;
 struct vmce_bank bank[GUEST_MC_BANK_NUM];
 };
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index 816973b9c2..fd7bf3fb38 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -610,6 +610,7 @@ struct hvm_vmce_vcpu {
 uint64_t caps;
 uint64_t mci_ctl2_bank0;
 uint64_t mci_ctl2_bank1;
+uint64_t mcg_ext_ctl;
 };
 
 DECLARE_HVM_SAVE_TYPE(VMCE_VCPU, 18, struct hvm_vmce_vcpu);
-- 
2.11.0


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


[Xen-devel] [PATCH v5 03/11] x86/mce: handle host LMCE

2017-07-02 Thread Haozhong Zhang
A round of mce_softirq() may handle multiple deferred MCE's.
 1/ If all of them are LMCE's, then mce_softirq() is called on one CPU
and should not wait for others.
 2/ If at least one of them is non-local MCE, then mce_softirq()
should sync with other CPUs. mce_softirq() should check those two
cases and handle them accordingly.

Because mce_softirq() can be interrupted by MC# again, we should also
ensure the deferred MCE handling in mce_softirq() is immutable to the
change of the checking result.

A per-cpu list 'lmce_pending' is introduced to 'struct mc_telem_cpu_ctl'
along with the existing per-cpu list 'pending' for LMCE handling.

MC# handler mcheck_cmn_handler() ensures that
 1/ if all deferred MCE's on a CPU are LMCE's, then all of their
telemetries will be only in 'lmce_pending' on that CPU;
 2/ if at least one of deferred MCE on a CPU is not LMCE, then all
telemetries of deferred MCE's on that CPU will be only in
'pending' on that CPU.

Therefore, the non-empty of 'lmce_pending' can be used to determine
whether it's the former of the beginning two cases in MCE softirq
handler mce_softirq().

mce_softirq() atomically moves deferred MCE's from either list
'lmce_pending' on the current CPU or lists 'pending' on the current or
other CPUs to list 'processing' in the current CPU, and then handles
deferred MCE's in list 'processing'.  New coming MC# before and after
the atomic move, which change the result of the check, do not change
whether MCE's in 'processing' are LMCE or not, so mce_softirq() can
still handle 'processing' according to the result of previous check.

Signed-off-by: Haozhong Zhang 
---
Changes in v5:
 * Adapt for changes in Patch 2.
 * Add comment in mctelem_defer() to explain why the two separate exchanges
   togerther can be treated as atomic.

Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/cpu/mcheck/mcaction.c |   4 +-
 xen/arch/x86/cpu/mcheck/mce.c  |  68 ++--
 xen/arch/x86/cpu/mcheck/mce.h  |   1 +
 xen/arch/x86/cpu/mcheck/mctelem.c  | 104 ++---
 xen/arch/x86/cpu/mcheck/mctelem.h  |   5 +-
 xen/arch/x86/cpu/mcheck/x86_mca.h  |   4 +-
 6 files changed, 147 insertions(+), 39 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mcaction.c 
b/xen/arch/x86/cpu/mcheck/mcaction.c
index dab9eac306..ca17d22bd8 100644
--- a/xen/arch/x86/cpu/mcheck/mcaction.c
+++ b/xen/arch/x86/cpu/mcheck/mcaction.c
@@ -96,7 +96,9 @@ mc_memerr_dhandler(struct mca_binfo *binfo,
 
 bank->mc_addr = gfn << PAGE_SHIFT |
   (bank->mc_addr & (PAGE_SIZE -1 ));
-if (fill_vmsr_data(bank, d, global->mc_gstatus,
+/* TODO: support injecting LMCE */
+if (fill_vmsr_data(bank, d,
+   global->mc_gstatus & ~MCG_STATUS_LMCE,
vmce_vcpuid == VMCE_INJECT_BROADCAST))
 {
 mce_printk(MCE_QUIET, "Fill vMCE# data for DOM%d "
diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index d247d6e198..0e17fb707a 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -387,6 +387,7 @@ mcheck_mca_logout(enum mca_source who, struct mca_banks 
*bankmask,
 sp->errcnt = errcnt;
 sp->ripv = (gstatus & MCG_STATUS_RIPV) != 0;
 sp->eipv = (gstatus & MCG_STATUS_EIPV) != 0;
+sp->lmce = (gstatus & MCG_STATUS_LMCE) != 0;
 sp->uc = uc;
 sp->pcc = pcc;
 sp->recoverable = recover;
@@ -454,6 +455,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 uint64_t gstatus;
 mctelem_cookie_t mctc = NULL;
 struct mca_summary bs;
+bool wait, lmce;
 
 mce_spin_lock(_logout_lock);
 
@@ -462,6 +464,8 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 sizeof(long) * BITS_TO_LONGS(clear_bank->num));
 }
 mctc = mcheck_mca_logout(MCA_MCE_SCAN, bankmask, , clear_bank);
+lmce = bs.lmce;
+wait = mce_broadcast && !lmce;
 
 if (bs.errcnt) {
 /*
@@ -470,7 +474,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 if (bs.uc || bs.pcc) {
 add_taint(TAINT_MACHINE_CHECK);
 if (mctc != NULL)
-mctelem_defer(mctc);
+mctelem_defer(mctc, lmce);
 /*
  * For PCC=1 and can't be recovered, context is lost, so
  * reboot now without clearing the banks, and deal with
@@ -497,16 +501,16 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 }
 mce_spin_unlock(_logout_lock);
 
-mce_barrier_enter(_trap_bar, mce_broadcast);
+mce_barrier_enter(_trap_bar, wait);
 if ( mctc != NULL && mce_urgent_action(regs, mctc))
 cpumask_set_cpu(smp_processor_id(), _fatal_cpus);
-mce_barrier_exit(_trap_bar, mce_broadcast);
+

[Xen-devel] [xtf test] 111345: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111345 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111345/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   32 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   26 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

Re: [Xen-devel] [PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 03:16 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

Add an unconditional x86_init_ops function which defaults to the
standard function and can be overridden by the early platform code.


That changelog describes WHAT the patch does, but not WHY. That's useless
as we can see WHAT the patch does from the patch itself. The WHY is the
really important information.



Understood, I will add the WHY description in the next version.

Thank,

dou.


Thanks,

tglx







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


Re: [Xen-devel] [PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 03:15 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

+static void __init delay_with_tsc(void)
+{
+   unsigned long long start, now;
+   unsigned long ticks = jiffies;


Please make that

   unsigned long end = jiffies + 4;

ticks really means: number of ticks. But that variable is doing something
different.


um, I see. Will use 'end' instead.




+   start = rdtsc();
+
+   /*
+* We don't know the TSC frequency yet, but waiting for
+* 400/HZ TSC cycles is safe:
+* 4 GHz == 10 jiffies
+* 1 GHz == 40 jiffies
+*/
+   do {
+   rep_nop();
+   now = rdtsc();
+   } while ((now - start) < 400UL / HZ &&
+   time_before_eq(jiffies, ticks + 4));
+}
+
+static void __init delay_without_tsc(void)
+{
+   int band = 1;
+   unsigned long ticks = jiffies;


Please sort variables in reverse fir tree order

unsigned long end = jiffies + 4;
int band = 1;



OK, I will.


+
+   /*
+* We don't know any frequency yet, but waiting for
+* 4094000/HZ cycles is safe:
+* 4 GHz == 10 jiffies
+* 1 GHz == 40 jiffies
+* 1 << 1 + 1 << 2 +...+ 1 << 11 = 4094
+*/
+   do {
+   __delay(((1 << band++) * 1000UL) / HZ);


  s/1/1U/



Got it!

Thanks,

dou.



+   } while (band < 12 && time_before_eq(jiffies, ticks + 4));
+}


Thanks,

tglx







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


Re: [Xen-devel] [PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 02:19 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

 static inline int apic_force_enable(unsigned long addr)
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 0601054..9bf7e95 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -1198,6 +1198,10 @@ static int __init apic_intr_mode_select(int *upmode)
}
 #endif

+#ifdef CONFIG_UP_LATE_INIT
+   *upmode = true;
+#endif


This is really wrong. The upmode decision, which is required for calling
apic_bsp_setup() should not happen here, really. As I told you in the
previous patch, use the return code and then you can make further decisions
in apic_intr_mode_init().


Really thanks for your detail explaining, I learned more than i read
from books about the programming skill.



And you do it there w/o any ifdeffery:

static void apic_intr_mode_init(void)
{
bool upmode = IS_ENABLED(CONFIG_UP_LATE_INIT);

switch () {
case :
upmode = true;

}
apic_bsp_setup(upmode);
}


This looks more beautiful than mine.  I will use it in the next version.

Thanks,

dou.



Thanks,

tglx







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


Re: [Xen-devel] [PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 02:07 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

-static int __init apic_intr_mode_select(void)
+static int __init apic_intr_mode_select(int *upmode)
 {
/* Check kernel option */
if (disable_apic) {
@@ -1206,12 +1208,30 @@ static int __init apic_intr_mode_select(void)
if (!smp_found_config) {
disable_ioapic_support();

-   if (!acpi_lapic)
+   if (!acpi_lapic) {
pr_info("APIC: ACPI MADT or MP tables are not 
detected\n");
+   *upmode = true;


That store and extra argument is pointless.


+
+   return APIC_VIRTUAL_WIRE_NO_CONFIG;


You added an extra return code, which you can use exactly for that purpose
at the callsite.



Actually indeed. Great! Why didn't I think of that?



Aside of that, if you use int * then use numbers, if you use bool then use
true/false. But mixing that is horrible.



Yes, it is, I will remove the 'upmode' argument.


Thanks,

dou.


+   }


Thanks,

tglx







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


[Xen-devel] [PATCH v2 1/2] tools/libxl/libxl_pci.c: Extract sysfs_dev_get_class from libxl__grant_vga_iomem_permission

2017-07-02 Thread Xiong Zhang
No functional change. Just extract this function for next patch and avoid
code repetition.

Signed-off-by: Xiong Zhang 
---
Changes in v2:
-Add No functional change in commit message
-Use 'goto out' style error handling
---
 tools/libxl/libxl_pci.c | 47 +--
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index b14df16..d109930 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -531,6 +531,34 @@ static uint16_t sysfs_dev_get_device(libxl__gc *gc, 
libxl_device_pci *pcidev)
 return pci_device_device;
 }
 
+static int sysfs_dev_get_class(libxl__gc *gc, libxl_device_pci *pcidev,
+   unsigned long *class)
+{
+char *pci_device_class_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/class",
+ pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+int read_items, ret = 0;
+
+FILE *f = fopen(pci_device_class_path, "r");
+if (!f) {
+LOGE(ERROR,
+ "pci device "PCI_BDF" does not have class attribute",
+ pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+ret = ERROR_FAIL;
+goto out;
+}
+read_items = fscanf(f, "0x%lx\n", class);
+fclose(f);
+if (read_items != 1) {
+LOGE(ERROR,
+ "cannot read class of pci device "PCI_BDF,
+ pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+ret = ERROR_FAIL;
+}
+
+out:
+return ret;
+}
+
 typedef struct {
 uint16_t vendor;
 uint16_t device;
@@ -1652,27 +1680,10 @@ int libxl__grant_vga_iomem_permission(libxl__gc *gc, 
const uint32_t domid,
 uint64_t vga_iomem_start = 0xa >> XC_PAGE_SHIFT;
 uint32_t stubdom_domid;
 libxl_device_pci *pcidev = _config->pcidevs[i];
-char *pci_device_class_path =
-GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/class",
-  pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
-int read_items;
 unsigned long pci_device_class;
 
-FILE *f = fopen(pci_device_class_path, "r");
-if (!f) {
-LOGED(ERROR, domid,
-  "pci device "PCI_BDF" does not have class attribute",
-  pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
+if (sysfs_dev_get_class(gc, pcidev, _device_class))
 continue;
-}
-read_items = fscanf(f, "0x%lx\n", _device_class);
-fclose(f);
-if (read_items != 1) {
-LOGED(ERROR, domid,
-  "cannot read class of pci device "PCI_BDF,
-  pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
-continue;
-}
 if (pci_device_class != 0x03) /* VGA class */
 continue;
 
-- 
2.7.4


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


[Xen-devel] [PATCH v2 2/2] tools/libxl/libxl_pci.c: Judge igd through class code instead of device ID

2017-07-02 Thread Xiong Zhang
IGD passthrough couldn't work on Skylake and Kabylake, because their
Device ID aren't in fixup_ids[]. Currently we need to add every intel
graphic ID into fixup_ids[], it is hard to maintain.

This patch judge intel graphics through vendor id (0x8086) and class
code(0x03), this could support both the old and new intel graphics,
and reduce maintain work in future.

Signed-off-by: Xiong Zhang 
Acked-by: Wei Liu 
---
Changes in v2:
-Add Acked-by: Wei Liu 
---
 tools/libxl/libxl_pci.c | 59 -
 1 file changed, 9 insertions(+), 50 deletions(-)

diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index d109930..65ad5e5 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -559,46 +559,6 @@ out:
 return ret;
 }
 
-typedef struct {
-uint16_t vendor;
-uint16_t device;
-} pci_info;
-
-static const pci_info fixup_ids[] = {
-/* Intel HSW Classic */
-{0x8086, 0x0402}, /* HSWGT1D, HSWD_w7 */
-{0x8086, 0x0406}, /* HSWGT1M, HSWM_w7 */
-{0x8086, 0x0412}, /* HSWGT2D, HSWD_w7 */
-{0x8086, 0x0416}, /* HSWGT2M, HSWM_w7 */
-{0x8086, 0x041E}, /* HSWGT15D, HSWD_w7 */
-/* Intel HSW ULT */
-{0x8086, 0x0A06}, /* HSWGT1UT, HSWM_w7 */
-{0x8086, 0x0A16}, /* HSWGT2UT, HSWM_w7 */
-{0x8086, 0x0A26}, /* HSWGT3UT, HSWM_w7 */
-{0x8086, 0x0A2E}, /* HSWGT3UT28W, HSWM_w7 */
-{0x8086, 0x0A1E}, /* HSWGT2UX, HSWM_w7 */
-{0x8086, 0x0A0E}, /* HSWGT1ULX, HSWM_w7 */
-/* Intel HSW CRW */
-{0x8086, 0x0D26}, /* HSWGT3CW, HSWM_w7 */
-{0x8086, 0x0D22}, /* HSWGT3CWDT, HSWD_w7 */
-/* Intel HSW Server */
-{0x8086, 0x041A}, /* HSWSVGT2, HSWD_w7 */
-/* Intel HSW SRVR */
-{0x8086, 0x040A}, /* HSWSVGT1, HSWD_w7 */
-/* Intel BSW */
-{0x8086, 0x1606}, /* BDWULTGT1, BDWM_w7 */
-{0x8086, 0x1616}, /* BDWULTGT2, BDWM_w7 */
-{0x8086, 0x1626}, /* BDWULTGT3, BDWM_w7 */
-{0x8086, 0x160E}, /* BDWULXGT1, BDWM_w7 */
-{0x8086, 0x161E}, /* BDWULXGT2, BDWM_w7 */
-{0x8086, 0x1602}, /* BDWHALOGT1, BDWM_w7 */
-{0x8086, 0x1612}, /* BDWHALOGT2, BDWM_w7 */
-{0x8086, 0x1622}, /* BDWHALOGT3, BDWM_w7 */
-{0x8086, 0x162B}, /* BDWHALO28W, BDWM_w7 */
-{0x8086, 0x162A}, /* BDWGT3WRKS, BDWM_w7 */
-{0x8086, 0x162D}, /* BDWGT3SRVR, BDWM_w7 */
-};
-
 /*
  * Some devices may need some ways to work well. Here like IGD,
  * we have to pass a specific option to qemu.
@@ -606,24 +566,23 @@ static const pci_info fixup_ids[] = {
 bool libxl__is_igd_vga_passthru(libxl__gc *gc,
 const libxl_domain_config *d_config)
 {
-unsigned int i, j, num = ARRAY_SIZE(fixup_ids);
-uint16_t vendor, device, pt_vendor, pt_device;
+unsigned int i;
+uint16_t pt_vendor, pt_device;
+unsigned long class;
 
 for (i = 0 ; i < d_config->num_pcidevs ; i++) {
 libxl_device_pci *pcidev = _config->pcidevs[i];
 pt_vendor = sysfs_dev_get_vendor(gc, pcidev);
 pt_device = sysfs_dev_get_device(gc, pcidev);
 
-if (pt_vendor == 0x || pt_device == 0x)
+if (pt_vendor == 0x || pt_device == 0x ||
+pt_vendor != 0x8086)
 continue;
 
-for (j = 0 ; j < num ; j++) {
-vendor = fixup_ids[j].vendor;
-device = fixup_ids[j].device;
-
-if (pt_vendor == vendor &&  pt_device == device)
-return true;
-}
+if (sysfs_dev_get_class(gc, pcidev, ))
+continue;
+if (class == 0x03)
+return true;
 }
 
 return false;
-- 
2.7.4


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


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

2017-07-02 Thread osstest service owner
flight 111311 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111311/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255 
REGR. vs. 110441

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10 fail in 111255 pass 
in 111311
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 111255 
pass in 111311
 test-armhf-armhf-xl-multivcpu  7 xen-boot  fail pass in 111255
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111255
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111255

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255 
blocked in 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111255 
like 110441
 test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail in 111255 never 
pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail in 111255 
never pass
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-xsm 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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-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-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-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-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-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
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux985c6fe6e0357c79642bc506f15932983571ce93
baseline version:
 linux8366868460f8784e30302f441546a9d72ffe1236

Last test of basis   110441  2017-06-14 13:16:35 Z   18 days
Failing since111069  2017-06-26 05:55:00 Z  

[Xen-devel] [xtf test] 111341: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111341 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111341/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   31 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   25 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

Re: [Xen-devel] [PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

2017-07-02 Thread Dou Liyang

Hi, Thomas

At 07/03/2017 01:54 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

 /*
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 93f0cda..d6721f0 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1347,8 +1347,11 @@ void __init native_smp_prepare_cpus(unsigned int 
max_cpus)
}

default_setup_apic_routing();
-   cpu0_logical_apicid = apic_bsp_setup(false);
-
+   apic_bsp_setup(false);
+   if (x2apic_mode)
+   cpu0_logical_apicid = apic_read(APIC_LDR);
+   else
+   cpu0_logical_apicid = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR));


Can you please move that into a seperate helper function?



Yes, it will be a separate helper function in the next version.

Thanks,

dou.




/* Setup local timer */
x86_init.timers.setup_percpu_clockev();

--
2.5.5












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


Re: [Xen-devel] [PATCH v5 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 01:47 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

+/* Init the interrupt delivery mode for the BSP */
+void __init apic_intr_mode_init(void)
+{
+   switch (apic_intr_mode_select()) {
+   case APIC_PIC:
+   apic_printk(APIC_VERBOSE, KERN_INFO
+   "Keep in PIC mode(8259)\n");


Please do not proliferate that APIC_VERBOSE, KERN_INFO mess. Clean up the
apic_printk() macro first. Either change printk() to pr_info() or make the
printk level dependent on the APIC verbosity.


Oops, I understood, How about the following:

pr_info("APIC: keep in PIC mode(8259)\n");


Thanks,

dou.



Thanks,

tglx







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


Re: [Xen-devel] [PATCH v5 01/12] x86/apic: Construct a selector for the interrupt delivery mode

2017-07-02 Thread Dou Liyang

Hi Thomas,

At 07/03/2017 01:37 AM, Thomas Gleixner wrote:

On Fri, 30 Jun 2017, Dou Liyang wrote:

+static int __init apic_intr_mode_select(void)
+{
+   /* Check kernel option */
+   if (disable_apic) {
+   pr_info("APIC disabled via kernel command line\n");
+   return APIC_PIC;
+   }
+
+   /* Check BIOS */
+#ifdef CONFIG_X86_64
+   /* On 64-bit, the APIC must be integrated, Check local APIC only */
+   if (!boot_cpu_has(X86_FEATURE_APIC)) {
+   disable_apic = 1;
+   pr_info("APIC disabled by BIOS\n");
+   return APIC_PIC;
+   }
+#else
+   /*
+* On 32-bit, check whether there is a separate chip or integrated
+* APIC
+*/
+
+   /* Has a local APIC ? */
+   if (!boot_cpu_has(X86_FEATURE_APIC) &&
+   APIC_INTEGRATED(boot_cpu_apic_version)) {


This looks wrong. The existing logic is:

if (!boot_cpu_has(X86_FEATURE_APIC) && !smp_found_config)
return -1;

if (!boot_cpu_has(X86_FEATURE_APIC) &&
APIC_INTEGRATED(boot_cpu_apic_version)) {
pr_err();

I know that this is magically the same because boot_cpu_apic_version is 0
in the !boot_cpu_has(X86_FEATURE_APIC) && !smp_found_config case, so you
don't fall into that conditional,


I see, it an unnecessary and surplus thing I did.

 but it's completely non obvious and does

not really make the code more understandable. Quite the contrary.


You are right.




+   disable_apic = 1;
+   pr_err(FW_BUG "Local APIC %d not detected, force emulation\n",
+  boot_cpu_physical_apicid);
+   return APIC_PIC;
+   }
+
+   /* Has a separate chip ? */
+   if (!boot_cpu_has(X86_FEATURE_APIC) && !smp_found_config) {
+   disable_apic = 1;
+
+   return APIC_PIC;
+   }


So if you move exactly that check above the other then it's clear what's
going on.


Will keep the order like the existing logic you gave above.




+#endif
+
+   /* Check MP table or ACPI MADT configuration */
+   if (!smp_found_config) {
+   disable_ioapic_support();
+
+   if (!acpi_lapic)
+   pr_info("APIC: ACPI MADT or MP tables are not 
detected\n");
+
+   return APIC_VIRTUAL_WIRE;
+   }
+
+   /* Other checks of APIC options will be done in each setup function */
+


Please remove the extra new line. It's not helping readability.


Yes, remove right now.

Thanks,
dou.




+   return APIC_SYMMETRIC_IO;
+}


Thanks,

tglx







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


[Xen-devel] [seabios baseline-only test] 71624: regressions - FAIL

2017-07-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stopfail blocked in 71564
 build-amd64-libvirt   5 libvirt-buildfail   like 71564
 build-i386-libvirt5 libvirt-buildfail   like 71564
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 71564

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 seabios  b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0
baseline version:
 seabios  7759d3a5be049eb8d0b4f7c6b1f1a0ba5e871cf3

Last test of basis71564  2017-06-14 18:50:04 Z   18 days
Testing same since71624  2017-07-02 21:19:47 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Zeh, Werner 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 build-amd64-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   blocked 
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmblocked 
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
 test-amd64-amd64-qemuu-nested-amdfail
 test-amd64-i386-qemuu-rhel6hvm-amd   pass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
 test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
 test-amd64-amd64-xl-qemuu-win7-amd64 fail
 test-amd64-i386-xl-qemuu-win7-amd64  fail
 test-amd64-amd64-qemuu-nested-intel  pass
 test-amd64-i386-qemuu-rhel6hvm-intel pass
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
 test-amd64-amd64-xl-qemuu-winxpsp3   pass
 test-amd64-i386-xl-qemuu-winxpsp3fail



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

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

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


Push not applicable.


commit b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0
Author: Zeh, Werner 
Date:   Fri Jun 23 07:18:04 2017 +

ahci: Disable Native Command Queueing

The AHCI driver currently sets the NCQ bit for every command that is
issued to the SATA drive.  This is not needed as there is always only
one command active at a time and in turn can lead to a hanging AHCI
controller (true for Marvel 88SE9170). The following patch disables
the usage of NCQ completely. With this patch the Marvel AHCI
controller works just fine without any issues.

Signed-off-by: Kevin O'Connor 

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


[Xen-devel] [xtf test] 111339: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111339 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111339/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   30 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   24 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

[Xen-devel] [PATCH v2 1/2] tools/libxc: add interface for GNTTABOP_query_size

2017-07-02 Thread Dongli Zhang
This patch adds new interface for GNTTABOP_query_size in libxc to help
query the current grant table frames and maximum grant table frames for a
specific domain.

Signed-off-by: Dongli Zhang 
---
Changed since v1:
  * Change %d to %u in ERROR()

---
 tools/libxc/include/xenctrl.h |  1 +
 tools/libxc/xc_gnttab.c   | 12 
 2 files changed, 13 insertions(+)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 1629f41..155c69e 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1597,6 +1597,7 @@ int xc_gnttab_op(xc_interface *xch, int cmd,
  void * op, int op_size, int count);
 /* Logs iff hypercall bounce fails, otherwise doesn't. */
 
+int xc_gnttab_query_size(xc_interface *xch, struct gnttab_query_size *query);
 int xc_gnttab_get_version(xc_interface *xch, int domid); /* Never logs */
 grant_entry_v1_t *xc_gnttab_map_table_v1(xc_interface *xch, int domid, int 
*gnt_num);
 grant_entry_v2_t *xc_gnttab_map_table_v2(xc_interface *xch, int domid, int 
*gnt_num);
diff --git a/tools/libxc/xc_gnttab.c b/tools/libxc/xc_gnttab.c
index af53fac..9e6f1fb 100644
--- a/tools/libxc/xc_gnttab.c
+++ b/tools/libxc/xc_gnttab.c
@@ -38,6 +38,18 @@ int xc_gnttab_op(xc_interface *xch, int cmd, void * op, int 
op_size, int count)
 return ret;
 }
 
+int xc_gnttab_query_size(xc_interface *xch, struct gnttab_query_size *query)
+{
+int rc;
+
+rc = xc_gnttab_op(xch, GNTTABOP_query_size, query, sizeof(*query), 1);
+
+if ( rc || (query->status != GNTST_okay) )
+ERROR("Could not query dom %u's grant size\n", query->dom);
+
+return rc;
+}
+
 int xc_gnttab_get_version(xc_interface *xch, int domid)
 {
 struct gnttab_get_version query;
-- 
2.7.4


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


[Xen-devel] [PATCH v2 2/2] tools: utility to dump guest grant table info

2017-07-02 Thread Dongli Zhang
As both xen-netfront and xen-blkfront support multi-queue, they would
consume a lot of grant table references when there are many paravirtual
devices and vcpus assigned to guest. Guest domU might panic or hang due to
grant allocation failure when nr_grant_frames in guest has reached its max
value.

This utility would help the administrators to diagnose xen issue. There is
only one command gnttab_query_size so far to monitor the guest grant table
frame usage on dom0 side so that it is not required to debug on guest
kernel side for crash/hang analysis anymore.

It is extensible for adding new commands for more diagnostic functions and
the framework of xen-diag.c is from xen-livepatch.c.

Signed-off-by: Dongli Zhang 
---
Changed since v1:
  * rewrite xen-gnttab-query.c to xen-diag.c based on livepatch.c framework

---
 tools/misc/Makefile   |   4 ++
 tools/misc/xen-diag.c | 129 ++
 2 files changed, 133 insertions(+)
 create mode 100644 tools/misc/xen-diag.c

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index 8152f7b..c1113b9 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -31,6 +31,7 @@ INSTALL_SBIN   += xenperf
 INSTALL_SBIN   += xenpm
 INSTALL_SBIN   += xenwatchdogd
 INSTALL_SBIN   += xen-livepatch
+INSTALL_SBIN   += xen-diag
 INSTALL_SBIN += $(INSTALL_SBIN-y)
 
 # Everything to be installed in a private bin/
@@ -102,6 +103,9 @@ xenwatchdogd: xenwatchdogd.o
 xen-livepatch: xen-livepatch.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
 
+xen-diag: xen-diag.o
+   $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
 xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) 
$(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
 
diff --git a/tools/misc/xen-diag.c b/tools/misc/xen-diag.c
new file mode 100644
index 000..1da50e1
--- /dev/null
+++ b/tools/misc/xen-diag.c
@@ -0,0 +1,129 @@
+/*
+ * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static xc_interface *xch;
+
+#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
+
+void show_help(void)
+{
+fprintf(stderr,
+"xen-diag: xen diagnostic utility\n"
+"Usage: xen-diag command [args]\n"
+"Commands:\n"
+"  help   display this help\n"
+"  gnttab_query_size   dump the current and max grant 
frames for \n");
+}
+
+/* wrapper function */
+static int help_func(int argc, char *argv[])
+{
+show_help();
+return 0;
+}
+
+static int gnttab_query_size_func(int argc, char *argv[])
+{
+int domid, rc = 1;
+struct gnttab_query_size query;
+
+if ( argc != 1 )
+{
+show_help();
+return rc;
+}
+
+domid = strtol(argv[0], NULL, 10);
+query.dom = domid;
+rc = xc_gnttab_query_size(xch, );
+
+if ( rc == 0 && (query.status == GNTST_okay) )
+printf("domid=%d: nr_frames=%d, max_nr_frames=%d\n",
+   query.dom, query.nr_frames, query.max_nr_frames);
+
+return rc == 0 && (query.status == GNTST_okay) ? 0 : 1;
+}
+
+struct {
+const char *name;
+int (*function)(int argc, char *argv[]);
+} main_options[] = {
+{ "help", help_func },
+{ "gnttab_query_size", gnttab_query_size_func},
+};
+
+int main(int argc, char *argv[])
+{
+int ret, i;
+
+/*
+ * Set stdout to be unbuffered to avoid having to fflush when
+ * printing without a newline.
+ */
+setvbuf(stdout, NULL, _IONBF, 0);
+
+if ( argc <= 1 )
+{
+show_help();
+return 0;
+}
+
+for ( i = 0; i < ARRAY_SIZE(main_options); i++ )
+if ( !strncmp(main_options[i].name, argv[1], strlen(argv[1])) )
+break;
+
+if ( i == ARRAY_SIZE(main_options) )
+{
+show_help();
+return 0;
+}
+else
+{
+xch = xc_interface_open(0, 0, 0);
+if ( !xch )
+{
+fprintf(stderr, "failed to get the handler\n");
+return 0;
+}
+
+ret = main_options[i].function(argc - 2, argv + 2);
+
+xc_interface_close(xch);
+}
+
+/*
+ * Exitcode 0 for success.
+ * Exitcode 1 for an error.
+ * Exitcode 2 if the operation should be retried for any reason (e.g. a
+ * timeout or because another operation was in progress).
+ */
+
+#define EXIT_TIMEOUT (EXIT_FAILURE + 1)
+
+BUILD_BUG_ON(EXIT_SUCCESS != 0);
+BUILD_BUG_ON(EXIT_FAILURE != 1);
+BUILD_BUG_ON(EXIT_TIMEOUT != 2);
+
+switch ( ret )
+{
+case 0:
+return EXIT_SUCCESS;
+case EAGAIN:
+case EBUSY:
+return EXIT_TIMEOUT;
+default:
+return EXIT_FAILURE;
+}
+}
-- 
2.7.4


___

[Xen-devel] [xtf test] 111334: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111334 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111334/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   29 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   23 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

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

2017-07-02 Thread osstest service owner
flight 111294 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111294/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-xsm   6 xen-build  fail in 111228 REGR. vs. 111054

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 84 
pass in 111294
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111228 pass in 
84
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 15 guest-stop fail pass in 
111228
 test-armhf-armhf-xl-rtds 10 debian-install fail pass in 111228

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked in 111228 n/a
 test-armhf-armhf-xl-xsm   1 build-check(1)   blocked in 111228 n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 111054
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 84 
like 111027
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail in 111228 like 
111054
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111228 
like 111054
 test-armhf-armhf-xl-rtds13 migrate-support-check fail in 111228 never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-check fail in 111228 never pass
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 111054
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 111054
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 111054
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   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-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   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-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-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-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 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-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat  fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-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-amd64-i386-xl-qemut-win10-i386 10 

[Xen-devel] [seabios test] 111330: tolerable FAIL - PUSHED

2017-07-02 Thread osstest service owner
flight 111330 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111330/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 110421
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 110421
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-xl-qemuu-ws16-amd64 13 guest-saverestore   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  b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0
baseline version:
 seabios  7759d3a5be049eb8d0b4f7c6b1f1a0ba5e871cf3

Last test of basis   110421  2017-06-14 01:14:48 Z   18 days
Testing same since   111330  2017-07-02 17:15:59 Z0 days1 attempts


People who touched revisions under test:
  Kevin O'Connor 
  Zeh, Werner 

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


Pushing revision :

+ branch=seabios
+ revision=b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push seabios 
b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0
+ branch=seabios
+ revision=b3a9f27fb1f63e9b6bf5ca424d31e23bd5b4c2f0
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' 

Re: [Xen-devel] [PATCH v2 4/4] vsmc: psci: remove 64 bit mode check

2017-07-02 Thread Julien Grall

Hi,

On 06/30/2017 10:19 PM, Stefano Stabellini wrote:

On Thu, 22 Jun 2017, Volodymyr Babchuk wrote:

PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:

  - Generic handler checks that 64 bit calls can be made only by
64 bit guests.

  - SMCCC requires that 64-bit handler should support both 32 and 64 bit
calls even if they originate from 64 bit caller.

This patch removes that extra check.

Signed-off-by: Volodymyr Babchuk 
---
  xen/arch/arm/vsmc.c | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 5f10fd1..1983e0e 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -98,12 +98,6 @@ static bool handle_arch(struct cpu_user_regs *regs)
  return false;
  }
  
-/* helper function for checking arm mode 32/64 bit */

-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
-}
-
  /* PSCI 2.0 interface */
  static bool handle_ssc(struct cpu_user_regs *regs)
  {
@@ -125,8 +119,7 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU):
  perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
+set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_SYSTEM_OFF):
  perfc_incr(vpsci_system_off);
@@ -140,7 +133,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_ON):
  perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )


I would prefer if the `return true' was within the { } block. But anyway
it's just a code style issue, so:


Well, I think we should keep the coding style consistent within 
arch/arm. If we have the return true within {} in other place. Then this 
should be done here.


In general, { } should only be used to en-globe everything in a case or 
for if/else/while/for with more than a line. All the other kind of { } 
should be avoided. I particularly dislike any code doing


code

{
   variable definition;

   code
}

code

Unless you have a strong reason to do it (avoiding reworking the code is 
not one), I will nack any code resulting to that.


Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v2 4/4] vsmc: psci: remove 64 bit mode check

2017-07-02 Thread Julien Grall



On 07/02/2017 08:34 PM, Julien Grall wrote:

Hi Volodymyr

On 06/22/2017 05:25 PM, Volodymyr Babchuk wrote:

PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:

  - Generic handler checks that 64 bit calls can be made only by
64 bit guests.

  - SMCCC requires that 64-bit handler should support both 32 and 64 bit
calls even if they originate from 64 bit caller.

This patch removes that extra check.

Signed-off-by: Volodymyr Babchuk 
---
  xen/arch/arm/vsmc.c | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 5f10fd1..1983e0e 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -98,12 +98,6 @@ static bool handle_arch(struct cpu_user_regs *regs)
  return false;
  }
-/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
-}
-
  /* PSCI 2.0 interface */
  static bool handle_ssc(struct cpu_user_regs *regs)
  {
@@ -125,8 +119,7 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU):
  perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
+set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_SYSTEM_OFF):
  perfc_incr(vpsci_system_off);
@@ -140,7 +133,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_ON):
  perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )


Please re-indent/re-organize the code correctly rather than just 
dropping. We want to keep the code nice even if it requires more changes.


*dropping the if.


  {
  register_t vcpuid = get_user_reg(regs, 1);
  register_t epoint = get_user_reg(regs, 2);
@@ -151,7 +143,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_SUSPEND):
  perfc_incr(vpsci_cpu_suspend);
-if ( psci_mode_check(current->domain, fid) )


Ditto


  {
  uint32_t pstate = get_user_reg(regs, 1);
  register_t epoint = get_user_reg(regs, 2);
@@ -162,7 +153,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_AFFINITY_INFO):
  perfc_incr(vpsci_cpu_affinity_info);
-if ( psci_mode_check(current->domain, fid) )


Ditto


  {
  register_t taff = get_user_reg(regs, 1);
  uint32_t laff = get_user_reg(regs,2);
@@ -172,7 +162,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE):
  perfc_incr(vpsci_cpu_migrate);
-if ( psci_mode_check(current->domain, fid) )


Ditto


  {
  uint32_t tcpu = get_user_reg(regs, 1);
  set_user_reg(regs, 0, do_psci_0_2_migrate(tcpu));





--
Julien Grall

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


Re: [Xen-devel] [PATCH v2 4/4] vsmc: psci: remove 64 bit mode check

2017-07-02 Thread Julien Grall

Hi Volodymyr

On 06/22/2017 05:25 PM, Volodymyr Babchuk wrote:

PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:

  - Generic handler checks that 64 bit calls can be made only by
64 bit guests.

  - SMCCC requires that 64-bit handler should support both 32 and 64 bit
calls even if they originate from 64 bit caller.

This patch removes that extra check.

Signed-off-by: Volodymyr Babchuk 
---
  xen/arch/arm/vsmc.c | 13 +
  1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 5f10fd1..1983e0e 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -98,12 +98,6 @@ static bool handle_arch(struct cpu_user_regs *regs)
  return false;
  }
  
-/* helper function for checking arm mode 32/64 bit */

-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
-}
-
  /* PSCI 2.0 interface */
  static bool handle_ssc(struct cpu_user_regs *regs)
  {
@@ -125,8 +119,7 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU):
  perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
+set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_SYSTEM_OFF):
  perfc_incr(vpsci_system_off);
@@ -140,7 +133,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_ON):
  perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )


Please re-indent/re-organize the code correctly rather than just 
dropping. We want to keep the code nice even if it requires more changes.



  {
  register_t vcpuid = get_user_reg(regs, 1);
  register_t epoint = get_user_reg(regs, 2);
@@ -151,7 +143,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_SUSPEND):
  perfc_incr(vpsci_cpu_suspend);
-if ( psci_mode_check(current->domain, fid) )


Ditto


  {
  uint32_t pstate = get_user_reg(regs, 1);
  register_t epoint = get_user_reg(regs, 2);
@@ -162,7 +153,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_AFFINITY_INFO):
  perfc_incr(vpsci_cpu_affinity_info);
-if ( psci_mode_check(current->domain, fid) )


Ditto


  {
  register_t taff = get_user_reg(regs, 1);
  uint32_t laff = get_user_reg(regs,2);
@@ -172,7 +162,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
  return true;
  case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE):
  perfc_incr(vpsci_cpu_migrate);
-if ( psci_mode_check(current->domain, fid) )


Ditto


  {
  uint32_t tcpu = get_user_reg(regs, 1);
  set_user_reg(regs, 0, do_psci_0_2_migrate(tcpu));



--
Julien Grall

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


Re: [Xen-devel] [PATCH v2 3/4] arm: traps: handle PSCI calls inside `vsmc.c`

2017-07-02 Thread Julien Grall

Hi,

On 06/30/2017 10:13 PM, Stefano Stabellini wrote:

On Thu, 22 Jun 2017, Volodymyr Babchuk wrote:

+}
+return false;
+}
+
+/* helper function for checking arm mode 32/64 bit */
+static inline int psci_mode_check(struct domain *d, register_t fid)
+{
+return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
+}
+
+/* PSCI 2.0 interface */
+static bool handle_ssc(struct cpu_user_regs *regs)
+{
+register_t fid = get_user_reg(regs, 0);
+
+switch ( ARM_SMCCC_FUNC_NUM(fid) )
+{
+case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_PSCI_VERSION):


As we are not using the PSCI_0_2_FN64_* definitions anymore, it would
make sense to add a comment in psci.h on top of them to explain why they
are not used (the function number is the same as the 32-bit
counterpart).


Well they are not unused (see arch/arm/psci.c).  But I think it is quite 
confusing to use ARM_SMCC_FUNC_NUM(PSCI_0_2_PSCI_VERSION) to extract the 
function number from the 32-bit version.


It would be much better macro for the function number (i.e abstracting 
0, 1, 2,...).


Cheers,

--
Julien Grall

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


Re: [Xen-devel] [PATCH v5 10/12] x86/xen: Bypass intr mode setup in enlighten_pv system

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:

> xen_smp_ops overwrites smp_prepare_cpus to xen_pv_smp_prepare_cpus
> which initializes interrupt itself.
> 
> Touching the intr_mode_init causes unexpected results on the system.
> 
> Bypass it in enlighten_pv system.

So that's the wrong patch order then. You broke XEN at some point with your
changes. You need to prevent that breakage upfront not after the fact.

Thanks,

tglx

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


Re: [Xen-devel] [PATCH v5 09/12] x86/init: add intr_mode_init to x86_init_ops

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
> Add an unconditional x86_init_ops function which defaults to the
> standard function and can be overridden by the early platform code.

That changelog describes WHAT the patch does, but not WHY. That's useless
as we can see WHAT the patch does from the patch itself. The WHY is the
really important information.

Thanks,

tglx

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


Re: [Xen-devel] [PATCH v5 08/12] x86/ioapic: Refactor the delay logic in timer_irq_works()

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
> +static void __init delay_with_tsc(void)
> +{
> + unsigned long long start, now;
> + unsigned long ticks = jiffies;

Please make that

   unsigned long end = jiffies + 4;

ticks really means: number of ticks. But that variable is doing something
different.

> + start = rdtsc();
> +
> + /*
> +  * We don't know the TSC frequency yet, but waiting for
> +  * 400/HZ TSC cycles is safe:
> +  * 4 GHz == 10 jiffies
> +  * 1 GHz == 40 jiffies
> +  */
> + do {
> + rep_nop();
> + now = rdtsc();
> + } while ((now - start) < 400UL / HZ &&
> + time_before_eq(jiffies, ticks + 4));
> +}
> +
> +static void __init delay_without_tsc(void)
> +{
> + int band = 1;
> + unsigned long ticks = jiffies;

Please sort variables in reverse fir tree order

unsigned long end = jiffies + 4;
int band = 1;

> +
> + /*
> +  * We don't know any frequency yet, but waiting for
> +  * 4094000/HZ cycles is safe:
> +  * 4 GHz == 10 jiffies
> +  * 1 GHz == 40 jiffies
> +  * 1 << 1 + 1 << 2 +...+ 1 << 11 = 4094
> +  */
> + do {
> + __delay(((1 << band++) * 1000UL) / HZ);

  s/1/1U/

> + } while (band < 12 && time_before_eq(jiffies, ticks + 4));
> +}

Thanks,

tglx

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


[Xen-devel] [xtf test] 111329: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111329 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111329/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   28 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   22 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

[Xen-devel] [qemu-mainline baseline-only test] 71623: tolerable trouble: blocked/broken/fail/pass

2017-07-02 Thread Platform Team regression test user
This run is configured for baseline tests only.

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

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  9 debian-installfail REGR. vs. 71617
 build-armhf-libvirt   5 libvirt-buildfail   like 71617
 build-i386-libvirt5 libvirt-buildfail   like 71617
 build-amd64-libvirt   5 libvirt-buildfail   like 71617
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail like 
71617
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail like 71617
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 71617

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 qemuu82d76dc7fc19a5eb9f731d7faed1792bb97214e0
baseline version:
 qemuu577caa2672ccde7352fda3ef17e44993de862f0e

Last test of basis71617  2017-06-30 04:44:47 Z2 days
Testing same since71623  2017-07-02 13:15:00 Z0 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Andrea Bolognani 
  Anthony PERARD 
  Bharata B Rao 
  Bruce Rogers 
  Daniel Henrique Barboza 
  David Gibson 
  Dr. David Alan Gilbert 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Halil Pasic 

Re: [Xen-devel] [PATCH v5 07/12] x86/apic: Unify interrupt mode setup for UP system

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
>  static inline int apic_force_enable(unsigned long addr)
> diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> index 0601054..9bf7e95 100644
> --- a/arch/x86/kernel/apic/apic.c
> +++ b/arch/x86/kernel/apic/apic.c
> @@ -1198,6 +1198,10 @@ static int __init apic_intr_mode_select(int *upmode)
>   }
>  #endif
>  
> +#ifdef CONFIG_UP_LATE_INIT
> + *upmode = true;
> +#endif

This is really wrong. The upmode decision, which is required for calling
apic_bsp_setup() should not happen here, really. As I told you in the
previous patch, use the return code and then you can make further decisions
in apic_intr_mode_init().

And you do it there w/o any ifdeffery:

static void apic_intr_mode_init(void)
{
bool upmode = IS_ENABLED(CONFIG_UP_LATE_INIT);

switch () {
case :
upmode = true;

}
apic_bsp_setup(upmode);
}

Thanks,

tglx

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


Re: [Xen-devel] [PATCH v5 05/12] x86/apic: Unify interrupt mode setup for SMP-capable system

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
> -static int __init apic_intr_mode_select(void)
> +static int __init apic_intr_mode_select(int *upmode)
>  {
>   /* Check kernel option */
>   if (disable_apic) {
> @@ -1206,12 +1208,30 @@ static int __init apic_intr_mode_select(void)
>   if (!smp_found_config) {
>   disable_ioapic_support();
>  
> - if (!acpi_lapic)
> + if (!acpi_lapic) {
>   pr_info("APIC: ACPI MADT or MP tables are not 
> detected\n");
> + *upmode = true;

That store and extra argument is pointless. 

> +
> + return APIC_VIRTUAL_WIRE_NO_CONFIG;

You added an extra return code, which you can use exactly for that purpose
at the callsite.


Aside of that, if you use int * then use numbers, if you use bool then use
true/false. But mixing that is horrible.

> + }

Thanks,

tglx

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


Re: [Xen-devel] [PATCH v5 04/12] x86/apic: Move logical APIC ID away from apic_bsp_setup()

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
>  /*
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index 93f0cda..d6721f0 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1347,8 +1347,11 @@ void __init native_smp_prepare_cpus(unsigned int 
> max_cpus)
>   }
>  
>   default_setup_apic_routing();
> - cpu0_logical_apicid = apic_bsp_setup(false);
> -
> + apic_bsp_setup(false);
> + if (x2apic_mode)
> + cpu0_logical_apicid = apic_read(APIC_LDR);
> + else
> + cpu0_logical_apicid = GET_APIC_LOGICAL_ID(apic_read(APIC_LDR));

Can you please move that into a seperate helper function?

>   /* Setup local timer */
>   x86_init.timers.setup_percpu_clockev();
>  
> -- 
> 2.5.5
> 
> 
> 
> 

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


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

2017-07-02 Thread osstest service owner
flight 111280 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111280/

Regressions :-(

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

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 110515

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail blocked in 
110515
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110515
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 110515
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 110515
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110515
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail 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-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-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-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  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-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-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linuxc0a0c7a4e1200bfea439b9444e6d6b4bede9db23
baseline version:
 linux1439ccf73d9c07654fdd5b4969fd53c2feb8684d

Last test of basis   110515  2017-06-17 06:48:56 Z   15 days
Failing since110536  2017-06-17 23:48:13 Z   14 days   15 attempts
Testing same since   111280  2017-07-01 16:01:19 Z1 days1 attempts


People who touched revisions under test:
  "Eric W. Biederman" 
  "H.J. Lu" 

Re: [Xen-devel] [PATCH v5 02/12] x86/apic: Prepare for unifying the interrupt delivery modes setup

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
> +/* Init the interrupt delivery mode for the BSP */
> +void __init apic_intr_mode_init(void)
> +{
> + switch (apic_intr_mode_select()) {
> + case APIC_PIC:
> + apic_printk(APIC_VERBOSE, KERN_INFO
> + "Keep in PIC mode(8259)\n");

Please do not proliferate that APIC_VERBOSE, KERN_INFO mess. Clean up the
apic_printk() macro first. Either change printk() to pr_info() or make the
printk level dependent on the APIC verbosity.

Thanks,

tglx

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


Re: [Xen-devel] [PATCH v5 01/12] x86/apic: Construct a selector for the interrupt delivery mode

2017-07-02 Thread Thomas Gleixner
On Fri, 30 Jun 2017, Dou Liyang wrote:
> +static int __init apic_intr_mode_select(void)
> +{
> + /* Check kernel option */
> + if (disable_apic) {
> + pr_info("APIC disabled via kernel command line\n");
> + return APIC_PIC;
> + }
> +
> + /* Check BIOS */
> +#ifdef CONFIG_X86_64
> + /* On 64-bit, the APIC must be integrated, Check local APIC only */
> + if (!boot_cpu_has(X86_FEATURE_APIC)) {
> + disable_apic = 1;
> + pr_info("APIC disabled by BIOS\n");
> + return APIC_PIC;
> + }
> +#else
> + /*
> +  * On 32-bit, check whether there is a separate chip or integrated
> +  * APIC
> +  */
> +
> + /* Has a local APIC ? */
> + if (!boot_cpu_has(X86_FEATURE_APIC) &&
> + APIC_INTEGRATED(boot_cpu_apic_version)) {

This looks wrong. The existing logic is:

if (!boot_cpu_has(X86_FEATURE_APIC) && !smp_found_config)
return -1;

if (!boot_cpu_has(X86_FEATURE_APIC) &&
APIC_INTEGRATED(boot_cpu_apic_version)) {
pr_err();

I know that this is magically the same because boot_cpu_apic_version is 0
in the !boot_cpu_has(X86_FEATURE_APIC) && !smp_found_config case, so you
don't fall into that conditional, but it's completely non obvious and does
not really make the code more understandable. Quite the contrary.

> + disable_apic = 1;
> + pr_err(FW_BUG "Local APIC %d not detected, force emulation\n",
> +boot_cpu_physical_apicid);
> + return APIC_PIC;
> + }
> +
> + /* Has a separate chip ? */
> + if (!boot_cpu_has(X86_FEATURE_APIC) && !smp_found_config) {
> + disable_apic = 1;
> +
> + return APIC_PIC;
> + }

So if you move exactly that check above the other then it's clear what's
going on.

> +#endif
> +
> + /* Check MP table or ACPI MADT configuration */
> + if (!smp_found_config) {
> + disable_ioapic_support();
> +
> + if (!acpi_lapic)
> + pr_info("APIC: ACPI MADT or MP tables are not 
> detected\n");
> +
> + return APIC_VIRTUAL_WIRE;
> + }
> +
> + /* Other checks of APIC options will be done in each setup function */
> +

Please remove the extra new line. It's not helping readability.

> + return APIC_SYMMETRIC_IO;
> +}

Thanks,

tglx

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


Re: [Xen-devel] [PATCH v3 12/16] xen/arm: p2m: Move lpae_* helpers in lpae.h

2017-07-02 Thread Sergej Proskurin
Hi Julien,

On 06/30/2017 05:54 PM, Julien Grall wrote:
> lpae_* helpers can work on any LPAE translation tables. Move them in
> lpae.h to allow other part of Xen to use them.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Stefano Stabellini 
> ---
> 
> Cc: prosku...@sec.in.tum.de
> 
> Changes in v2:
> - Patch added
> 
> Changes in v3:
> - Add Stefano's reviewed-by


Reviewed-by: Sergej Proskurin 


> ---
>  xen/arch/arm/p2m.c | 23 ---
>  xen/include/asm-arm/lpae.h | 25 +
>  2 files changed, 25 insertions(+), 23 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 381df1f237..9b7a580a87 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -52,29 +52,6 @@ static const paddr_t level_masks[] =
>  static const uint8_t level_orders[] =
>  { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>  
> -static inline bool_t lpae_valid(lpae_t pte)
> -{
> -return pte.walk.valid;
> -}
> -/*
> - * These two can only be used on L0..L2 ptes because L3 mappings set
> - * the table bit and therefore these would return the opposite to what
> - * you would expect.
> - */
> -static inline bool_t lpae_table(lpae_t pte)
> -{
> -return lpae_valid(pte) && pte.walk.table;
> -}
> -static inline bool_t lpae_mapping(lpae_t pte)
> -{
> -return lpae_valid(pte) && !pte.walk.table;
> -}
> -
> -static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
> -{
> -return (level < 3) && lpae_mapping(pte);
> -}
> -
>  static void p2m_flush_tlb(struct p2m_domain *p2m);
>  
>  /* Unlock the flush and do a P2M TLB flush if necessary */
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index aa85cb8112..6fbf7c606c 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -126,6 +126,31 @@ typedef union {
>  lpae_walk_t walk;
>  } lpae_t;
>  
> +static inline bool_t lpae_valid(lpae_t pte)
> +{
> +return pte.walk.valid;
> +}
> +
> +/*
> + * These two can only be used on L0..L2 ptes because L3 mappings set
> + * the table bit and therefore these would return the opposite to what
> + * you would expect.
> + */
> +static inline bool_t lpae_table(lpae_t pte)
> +{
> +return lpae_valid(pte) && pte.walk.table;
> +}
> +
> +static inline bool_t lpae_mapping(lpae_t pte)
> +{
> +return lpae_valid(pte) && !pte.walk.table;
> +}
> +
> +static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
> +{
> +return (level < 3) && lpae_mapping(pte);
> +}
> +
>  #endif /* __ASSEMBLY__ */
>  
>  /*
> 

Cheers,
~Sergej

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


Re: [Xen-devel] [PATCH v3 11/16] xen/arm: p2m: Rename p2m_valid, p2m_table, p2m_mapping and p2m_is_superpage

2017-07-02 Thread Sergej Proskurin
Hi Julien,

On 06/30/2017 05:54 PM, Julien Grall wrote:
> The helpers p2m_valid, p2m_table, p2m_mapping and p2m_is_superpage are
> not specific to the stage-2 translation tables. They can also work on
> any LPAE translation tables. So rename then to lpae_* and use pte.walk
> to look for the value of the field.
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Stefano Stabellini 
> ---
> 
> Cc: prosku...@sec.in.tum.de
> 
> s/bool_t/bool/ will be done in a separate patch
> 
> Changes in v2:
> - Patch added
> 
> Changes in v3:
> - Add Stefano's reviewed-by


Reviewed-by: Sergej Proskurin 


> ---
>  xen/arch/arm/p2m.c | 45 +++--
>  1 file changed, 23 insertions(+), 22 deletions(-)
> 
> diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
> index 3e20a1ec82..381df1f237 100644
> --- a/xen/arch/arm/p2m.c
> +++ b/xen/arch/arm/p2m.c
> @@ -52,27 +52,27 @@ static const paddr_t level_masks[] =
>  static const uint8_t level_orders[] =
>  { ZEROETH_ORDER, FIRST_ORDER, SECOND_ORDER, THIRD_ORDER };
>  
> -static inline bool_t p2m_valid(lpae_t pte)
> +static inline bool_t lpae_valid(lpae_t pte)
>  {
> -return pte.p2m.valid;
> +return pte.walk.valid;
>  }
>  /*
>   * These two can only be used on L0..L2 ptes because L3 mappings set
>   * the table bit and therefore these would return the opposite to what
>   * you would expect.
>   */
> -static inline bool_t p2m_table(lpae_t pte)
> +static inline bool_t lpae_table(lpae_t pte)
>  {
> -return p2m_valid(pte) && pte.p2m.table;
> +return lpae_valid(pte) && pte.walk.table;
>  }
> -static inline bool_t p2m_mapping(lpae_t pte)
> +static inline bool_t lpae_mapping(lpae_t pte)
>  {
> -return p2m_valid(pte) && !pte.p2m.table;
> +return lpae_valid(pte) && !pte.walk.table;
>  }
>  
> -static inline bool p2m_is_superpage(lpae_t pte, unsigned int level)
> +static inline bool lpae_is_superpage(lpae_t pte, unsigned int level)
>  {
> -return (level < 3) && p2m_mapping(pte);
> +return (level < 3) && lpae_mapping(pte);
>  }
>  
>  static void p2m_flush_tlb(struct p2m_domain *p2m);
> @@ -281,7 +281,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  
>  entry = *table + offset;
>  
> -if ( !p2m_valid(*entry) )
> +if ( !lpae_valid(*entry) )
>  {
>  if ( read_only )
>  return GUEST_TABLE_MAP_FAILED;
> @@ -292,7 +292,7 @@ static int p2m_next_level(struct p2m_domain *p2m, bool 
> read_only,
>  }
>  
>  /* The function p2m_next_level is never called at the 3rd level */
> -if ( p2m_mapping(*entry) )
> +if ( lpae_mapping(*entry) )
>  return GUEST_TABLE_SUPER_PAGE;
>  
>  mfn = _mfn(entry->p2m.base);
> @@ -372,7 +372,7 @@ mfn_t p2m_get_entry(struct p2m_domain *p2m, gfn_t gfn,
>  
>  entry = table[offsets[level]];
>  
> -if ( p2m_valid(entry) )
> +if ( lpae_valid(entry) )
>  {
>  *t = entry.p2m.type;
>  
> @@ -577,7 +577,7 @@ static int p2m_create_table(struct p2m_domain *p2m, 
> lpae_t *entry)
>  lpae_t *p;
>  lpae_t pte;
>  
> -ASSERT(!p2m_valid(*entry));
> +ASSERT(!lpae_valid(*entry));
>  
>  page = alloc_domheap_page(NULL, 0);
>  if ( page == NULL )
> @@ -645,7 +645,7 @@ enum p2m_operation {
>   */
>  static void p2m_put_l3_page(const lpae_t pte)
>  {
> -ASSERT(p2m_valid(pte));
> +ASSERT(lpae_valid(pte));
>  
>  /*
>   * TODO: Handle other p2m types
> @@ -673,11 +673,11 @@ static void p2m_free_entry(struct p2m_domain *p2m,
>  struct page_info *pg;
>  
>  /* Nothing to do if the entry is invalid. */
> -if ( !p2m_valid(entry) )
> +if ( !lpae_valid(entry) )
>  return;
>  
>  /* Nothing to do but updating the stats if the entry is a super-page. */
> -if ( p2m_is_superpage(entry, level) )
> +if ( lpae_is_superpage(entry, level) )
>  {
>  p2m->stats.mappings[level]--;
>  return;
> @@ -733,7 +733,7 @@ static bool p2m_split_superpage(struct p2m_domain *p2m, 
> lpae_t *entry,
>   * a superpage.
>   */
>  ASSERT(level < target);
> -ASSERT(p2m_is_superpage(*entry, level));
> +ASSERT(lpae_is_superpage(*entry, level));
>  
>  page = alloc_domheap_page(NULL, 0);
>  if ( !page )
> @@ -870,7 +870,7 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>  /* We need to split the original page. */
>  lpae_t split_pte = *entry;
>  
> -ASSERT(p2m_is_superpage(*entry, level));
> +ASSERT(lpae_is_superpage(*entry, level));
>  
>  if ( !p2m_split_superpage(p2m, _pte, level, target, offsets) )
>  {
> @@ -944,12 +944,12 @@ static int __p2m_set_entry(struct p2m_domain *p2m,
>   * sequence when updating the translation table (D4.7.1 in ARM DDI
>   * 0487A.j).
>   */
> -if ( p2m_valid(orig_pte) )
> +if ( lpae_valid(orig_pte) )
>  

[Xen-devel] [xtf test] 111326: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111326 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111326/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   27 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   21 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

Re: [Xen-devel] [PATCH v3 10/16] xen/arm: lpae: Fix comments coding style

2017-07-02 Thread Sergej Proskurin
Hi Julien,

On 06/30/2017 05:54 PM, Julien Grall wrote:
> Also adding one missing full stop + fix description
> 
> Signed-off-by: Julien Grall 
> Reviewed-by: Stefano Stabellini 
> ---
> 
> Cc: prosku...@sec.in.tum.de
> 
> I haven't retained Stefano's reviewed-by because of the description
> update.
> 
>Changes in v2:
> - Fix description regarding x86 page-table
> 
> Changes in v3:
> - Add Stefano's reviewed-by


Reviewed-by: Sergej Proskurin 


> ---
>  xen/include/asm-arm/lpae.h | 49 
> ++
>  1 file changed, 32 insertions(+), 17 deletions(-)
> 
> diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
> index ad8c571ea5..aa85cb8112 100644
> --- a/xen/include/asm-arm/lpae.h
> +++ b/xen/include/asm-arm/lpae.h
> @@ -3,10 +3,12 @@
>  
>  #ifndef __ASSEMBLY__
>  
> -/* WARNING!  Unlike the Intel pagetable code, where l1 is the lowest
> - * level and l4 is the root of the trie, the ARM pagetables follow ARM's
> - * documentation: the levels are called first, second  in the order
> - * that the MMU walks them (i.e. "first" is the root of the trie). */
> +/*
> + * WARNING!  Unlike the x86 pagetable code, where l1 is the lowest level and
> + * l4 is the root of the trie, the ARM pagetables follow ARM's documentation:
> + * the levels are called first, second  in the order that the MMU walks 
> them
> + * (i.e. "first" is the root of the trie).
> + */
>  
>  
> /**
>   * ARMv7-A LPAE pagetables: 3-level trie, mapping 40-bit input to
> @@ -17,15 +19,18 @@
>   * different place from those in leaf nodes seems to be to allow linear
>   * pagetable tricks.  If we're not doing that then the set of permission
>   * bits that's not in use in a given node type can be used as
> - * extra software-defined bits. */
> + * extra software-defined bits.
> + */
>  
>  typedef struct __packed {
>  /* These are used in all kinds of entry. */
>  unsigned long valid:1;  /* Valid mapping */
>  unsigned long table:1;  /* == 1 in 4k map entries too */
>  
> -/* These ten bits are only used in Block entries and are ignored
> - * in Table entries. */
> +/*
> + * These ten bits are only used in Block entries and are ignored
> + * in Table entries.
> + */
>  unsigned long ai:3; /* Attribute Index */
>  unsigned long ns:1; /* Not-Secure */
>  unsigned long user:1;   /* User-visible */
> @@ -38,30 +43,38 @@ typedef struct __packed {
>  unsigned long long base:36; /* Base address of block or next table */
>  unsigned long sbz:4;/* Must be zero */
>  
> -/* These seven bits are only used in Block entries and are ignored
> - * in Table entries. */
> +/*
> + * These seven bits are only used in Block entries and are ignored
> + * in Table entries.
> + */
>  unsigned long contig:1; /* In a block of 16 contiguous entries */
>  unsigned long pxn:1;/* Privileged-XN */
>  unsigned long xn:1; /* eXecute-Never */
>  unsigned long avail:4;  /* Ignored by hardware */
>  
> -/* These 5 bits are only used in Table entries and are ignored in
> - * Block entries */
> +/*
> + * These 5 bits are only used in Table entries and are ignored in
> + * Block entries.
> + */
>  unsigned long pxnt:1;   /* Privileged-XN */
>  unsigned long xnt:1;/* eXecute-Never */
>  unsigned long apt:2;/* Access Permissions */
>  unsigned long nst:1;/* Not-Secure */
>  } lpae_pt_t;
>  
> -/* The p2m tables have almost the same layout, but some of the permission
> - * and cache-control bits are laid out differently (or missing) */
> +/*
> + * The p2m tables have almost the same layout, but some of the permission
> + * and cache-control bits are laid out differently (or missing).
> + */
>  typedef struct __packed {
>  /* These are used in all kinds of entry. */
>  unsigned long valid:1;  /* Valid mapping */
>  unsigned long table:1;  /* == 1 in 4k map entries too */
>  
> -/* These ten bits are only used in Block entries and are ignored
> - * in Table entries. */
> +/*
> + * These ten bits are only used in Block entries and are ignored
> + * in Table entries.
> + */
>  unsigned long mattr:4;  /* Memory Attributes */
>  unsigned long read:1;   /* Read access */
>  unsigned long write:1;  /* Write access */
> @@ -73,8 +86,10 @@ typedef struct __packed {
>  unsigned long long base:36; /* Base address of block or next table */
>  unsigned long sbz3:4;
>  
> -/* These seven bits are only used in Block entries and are ignored
> - * in Table entries. */
> +/*
> + * These seven bits are only used in Block entries and are ignored
> + * in Table 

[Xen-devel] [xtf test] 111321: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111321 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111321/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z6 days
Failing since44  2017-06-28 10:53:08 Z4 days   26 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   20 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

[Xen-devel] [xtf test] 111312: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111312 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111312/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z5 days
Failing since44  2017-06-28 10:53:08 Z4 days   25 attempts
Testing same since   111230  2017-06-30 13:18:23 Z2 days   19 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of 

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

2017-07-02 Thread osstest service owner
flight 111265 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111265/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 77
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 77
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 77
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 77
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 77
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 77
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 77
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  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-xl-xsm  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-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 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-raw 12 migrate-support-checkfail   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:
 qemuu82d76dc7fc19a5eb9f731d7faed1792bb97214e0
baseline version:
 qemuu577caa2672ccde7352fda3ef17e44993de862f0e

Last test of basis   77  2017-06-29 06:48:31 Z3 days
Failing since111211  2017-06-30 04:51:44 Z2 days2 attempts
Testing same since   111265  2017-07-01 10:02:26 Z1 days1 attempts


People who touched revisions under test:
  Aaron Larson 
  Andrea Bolognani 
  Anthony PERARD 
  Bharata B Rao 
  Bruce Rogers 
  Daniel Henrique Barboza 
  David Gibson 
  Dr. David Alan Gilbert 
  Eric Blake 
  Fam Zheng 
  Greg Kurz 
  Halil Pasic 
  Haozhong Zhang 
  Jan Beulich 
  John Arbuckle 
  Juan Quintela 

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

2017-07-02 Thread osstest service owner
flight 111258 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111258/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-libvirt  6 xen-install  fail REGR. vs. 111209

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

version targeted for testing:
 libvirt  b0d4ea32923e008c5b46edbe9f7d323c4fa7ba5d
baseline version:
 libvirt  e007e764e19a498873eff4b342f09c7644fd8717

Last test of basis   111209  2017-06-30 04:20:13 Z2 days
Testing same since   111258  2017-07-01 06:17:56 Z1 days1 attempts


People who touched revisions under test:
  Martin Kletzander 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-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-arm64-arm64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 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


Not pushing.


[Xen-devel] [xen-unstable-coverity test] 111315: regressions - ALL FAIL

2017-07-02 Thread osstest service owner
flight 111315 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111315/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 coverity-amd646 coverity-build   fail REGR. vs. 40

version targeted for testing:
 xen  d468f4299cef469d882f4bed8530fca53ebf2ebd
baseline version:
 xen  8b9793bfe614ee53029d2b1672e1080170809dcd

Last test of basis   40  2017-06-28 10:06:03 Z3 days
Testing same since   111315  2017-07-02 09:22:26 Z0 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Igor Druzhinin 
  Jan Beulich 
  Julien Grall 
  Kevin Tian 
  Konrad Rzeszutek Wilk 
  Marek Marczykowski-Górecki 
  Sergey Dyasli 
  Stefano Stabellini 
  Tim Deegan 
  Wei Liu 
  Zhongze Liu 

jobs:
 coverity-amd64   fail



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

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

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

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


Not pushing.

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

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


Re: [Xen-devel] offtopic: handling patches

2017-07-02 Thread Marek Marczykowski-Górecki
On Fri, Jun 30, 2017 at 06:18:11PM +0100, Andrew Cooper wrote:
> On 30/06/17 17:57, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > How you guys handle patches with emails? I know git am and git
> > format-patch/send-email, but those tools are quite limited, especially
> > when handling patch series, subsequent versions etc.
> > What I miss there:
> >  - patch versioning (git notes could be used, but it doesn't survive git
> >commit --amend, nor git rebase)
> >  - keeping/versioning cover email
> >  - collecting Cc: from all patches in series into cover email
> >  - adding Reviewed-by, Acked-by etc tags
> >
> > I can't believe you all do this all manually ;)
> > Is there any commonly available tool I can't find, or everyone have own
> > scripts?
> 
> Manually, I'm afraid.  I've never found anything more automatic which works.
> 
> My general workflow is a single git branch which is always rebased onto
> staging.
> 
> Patch version information lives in the commit message under a --- line,

This is excellent idea! I don't know why never thought of it...

> and I am frequent user of `git commit --fixup/--squash` and `git rebase
> --interactive`.

Me too :)

> I've a separate directory tree where I format patch series including
> cover letters, before using `git send-email --dry-run *.patch` to send
> them.  These get recycled in a lazy fashon, typically once the series
> has been committed, but the old cover letters generally available in an
> adjacent directory when sending a newer series.

I've found git-series[1] tool. From the above list it allow you to diff
between series versions, and more importantly - keep cover letter in
git!

> For collecting and reviewing tags, look at the PatchWork `pwclient`
> utility.  Its `git-am` mode automagically collects tags, which is
> fantastically useful for applying a patch for committing.  (Then again,
> I do always manually check the conversation on list before actually
> committing the series.)

Thanks, indeed looks interesting.
BTW is this[2] the right instance? It doesn't looks to notice applied
patches.


[1] https://github.com/git-series/git-series
[2] https://patchwork.kernel.org/project/xen-devel/list
-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?


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


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

2017-07-02 Thread osstest service owner
flight 111255 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111255/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
110441
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail REGR. vs. 
110441

Tests which are failing intermittently (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail in 111215 pass in 
111255
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111215 pass in 
111255
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10  fail pass in 111215

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-armhf-armhf-xl-multivcpu 4 host-install(4) broken in 111215 blocked in 
110441
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail blocked in 
110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 111215 blocked in 
110441
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 111215 
like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-i386-libvirt  13 migrate-support-checkfail   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-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail 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-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 test-armhf-armhf-libvirt 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-libvirt-xsm 13 migrate-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-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-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-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-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
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux985c6fe6e0357c79642bc506f15932983571ce93
baseline version:
 linux8366868460f8784e30302f441546a9d72ffe1236

Last test of basis   110441  2017-06-14 13:16:35 Z   17 days

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

2017-07-02 Thread osstest service owner
flight 111249 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111249/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-xsm   5 host-ping-check-native   fail REGR. vs. 110465
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110465
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110465
 test-arm64-arm64-xl  10 debian-install   fail REGR. vs. 110465

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop   fail REGR. vs. 110465

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110465
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110465
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 110465
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110465
 test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail  like 110465
 test-amd64-amd64-xl-rtds 10 debian-install   fail  like 110465
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail 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-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-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-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-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-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail 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-libvirt-xsm 13 migrate-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-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   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-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-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:
 xen  d468f4299cef469d882f4bed8530fca53ebf2ebd
baseline version:
 xen  695bb5f504ab48c1d546446f104c1b6c0ead126d

Last test of basis   110465  2017-06-15 09:46:33 Z   16 days
Failing since110484  2017-06-16 09:32:22 Z   15 days   16 attempts
Testing same since   111249  2017-07-01 01:17:34 Z1 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Andrew Morton 
  Artem Bityutskiy 
  Bernhard M. 

[Xen-devel] [xtf test] 111305: regressions - trouble: broken/pass

2017-07-02 Thread osstest service owner
flight 111305 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/111305/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-xtf-amd64-amd64-4   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-5   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-3   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-2   59 leak-check/check fail REGR. vs. 111074
 test-xtf-amd64-amd64-1   59 leak-check/check fail REGR. vs. 111074

Tests which did not succeed, but are not blocking:
 test-xtf-amd64-amd64-4   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-5   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-3   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-2   58 xtf/test-hvm64-xsa-221   fail   never pass
 test-xtf-amd64-amd64-1   58 xtf/test-hvm64-xsa-221   fail   never pass

version targeted for testing:
 xtf  0d6dddbd5a5666cb7d052688724662214a771033
baseline version:
 xtf  6723a66fe3e2a60793ec4fdbcd67250c954fe5d9

Last test of basis   111074  2017-06-26 14:44:07 Z5 days
Failing since44  2017-06-28 10:53:08 Z3 days   24 attempts
Testing same since   111230  2017-06-30 13:18:23 Z1 days   18 attempts


People who touched revisions under test:
  Andrew Cooper 
  Haozhong Zhang 

jobs:
 build-amd64-xtf  pass
 build-amd64  pass
 build-amd64-pvopspass
 test-xtf-amd64-amd64-1   broken  
 test-xtf-amd64-amd64-2   broken  
 test-xtf-amd64-amd64-3   broken  
 test-xtf-amd64-amd64-4   broken  
 test-xtf-amd64-amd64-5   broken  



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 0d6dddbd5a5666cb7d052688724662214a771033
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:48 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/ current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 23ce3ed364ffc850f6f239b056f45d66f7d24a5f
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:47 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/ current VMCS

VMfailvalid() is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit aaadefde675900471464c7c174248dc9cd14f3db
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:46 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 3 and w/o current VMCS

Fault #GP(0) is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit bf97d4fb323194bff1d92f2ed52dcaeedcf4c39e
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:45 2016 +0800

vvmx: Test vmxon in VMX root w/ CPL = 0 and w/o current VMCS

VMfailInvalid is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit 6c9b86ca32ef8a375cd4346ba71d0e2b039d120b
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:44 2016 +0800

vvmx: Test the correct vmxon

No error is expected in this test.

Signed-off-by: Haozhong Zhang 
Rebase and cleanup.
Signed-off-by: Andrew Cooper 

commit b7972eae5aa91c72c3db2ac991b9317c88f30ff5
Author: Haozhong Zhang 
Date:   Fri Dec 16 21:43:43 2016 +0800

vvmx: Test vmxon with bit 31 of