[Xen-devel] [xen-unstable-smoke test] 122612: trouble: blocked/broken/pass

[osstest service owner <osstest-admin@xxxxxxxxxxxxxx>]

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

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-arm64-xsm                 <job status>                 broken
 build-arm64-xsm               4 host-install(4)        broken REGR. vs. 122587

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm       1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          13 migrate-support-check        fail   never pass
 test-armhf-armhf-xl          14 saverestore-support-check    fail   never pass

version targeted for testing:
 xen                  e38e285a51c805cfeee4693962df23e39b3c3bd7
baseline version:
 xen                  4611f529c0e39493a3945641cc161967a864d6b5

Last test of basis   122587  2018-05-03 16:00:26 Z    1 days
Testing same since   122602  2018-05-04 18:01:13 Z    0 days    7 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Wei Liu <wei.liu2@xxxxxxxxxx>

jobs:
 build-arm64-xsm                                              broken  
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          pass    
 test-arm64-arm64-xl-xsm                                      blocked 
 test-amd64-amd64-xl-qemuu-debianhvm-i386                     pass    
 test-amd64-amd64-libvirt                                     pass    


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

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

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

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

broken-job build-arm64-xsm broken
broken-step build-arm64-xsm host-install(4)

Not pushing.

------------------------------------------------------------
commit e38e285a51c805cfeee4693962df23e39b3c3bd7
Author: Wei Liu <wei.liu2@xxxxxxxxxx>
Date:   Fri May 4 16:08:04 2018 +0100

    docs: fix xpti command line option doc
    
    Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
    Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 5c81d260c244026ea74632faa3c6d0a00cc76469
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:18 2018 +0200

    xen/x86: use PCID feature
    
    Avoid flushing the complete TLB when switching %cr3 for mitigation of
    Meltdown by using the PCID feature if available.
    
    We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
    2 values for the non-XPTI case:
    
    - guest active and in kernel mode
    - guest active and in user mode
    - hypervisor active and guest in user mode (XPTI only)
    - hypervisor active and guest in kernel mode (XPTI only)
    
    We use PCID only if PCID _and_ INVPCID are supported. With PCID in use
    we disable global pages in cr4. A command line parameter controls in
    which cases PCID is being used.
    
    As the non-XPTI case has shown not to perform better with PCID at least
    on some machines the default is to use PCID only for domains subject to
    XPTI.
    
    With PCID enabled we always disable global pages. This avoids having to
    either flush the complete TLB or do a cycle through all PCID values
    when invalidating a single global page.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 1a32c9868711b4ee883ebb6f8807e08d70a920be
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:17 2018 +0200

    xen/x86: add some cr3 helpers
    
    Add some helper macros to access the address and pcid parts of cr3.
    
    Use those helpers where appropriate.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit a5407c1d8c6c0cac96d3e84e7b2b25b18fa2bf4d
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:16 2018 +0200

    xen/x86: convert pv_guest_cr4_to_real_cr4() to a function
    
    pv_guest_cr4_to_real_cr4() is becoming more and more complex. Convert
    it from a macro to an ordinary function.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 065a499f78d5b644fa586e3e66f88949821e4f8c
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:15 2018 +0200

    xen/x86: use flag byte for decision whether xen_cr3 is valid
    
    Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to
    be switched on entry to Xen, or negative for keeping the value while
    indicating not to restore %cr3, or positive in case %cr3 is to be
    restored.
    
    Switch to use a flag byte instead of a negative xen_cr3 value in order
    to allow %cr3 values with the high bit set in case we want to keep TLB
    entries when using the PCID feature.
    
    This reduces the number of branches in interrupt handling and results
    in better performance (e.g. parallel make of the Xen hypervisor on my
    system was using about 3% less system time).
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit d543fa409358a9128d3629dcb28daae28c2d150f
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:14 2018 +0200

    xen/x86: disable global pages for domains with XPTI active
    
    Instead of flushing the TLB from global pages when switching address
    spaces with XPTI being active just disable global pages via %cr4
    completely when a domain subject to XPTI is active. This avoids the
    need for extra TLB flushes as loading %cr3 will remove all TLB
    entries.
    
    In order to avoid states with cr3/cr4 having inconsistent values
    (e.g. global pages being activated while cr3 already specifies a XPTI
    address space) move loading of the new cr4 value to write_ptbase()
    (actually to switch_cr3_cr4() called by write_ptbase()).
    
    This requires to use switch_cr3_cr4() instead of write_ptbase() when
    building dom0 in order to avoid setting cr4 with cr4.smap set.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 94a992bccdbf656a5a7a0b585c9f140fccc02674
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:13 2018 +0200

    xen/x86: use invpcid for flushing the TLB
    
    If possible use the INVPCID instruction for flushing the TLB instead of
    toggling cr4.pge for that purpose.
    
    While at it remove the dependency on cr4.pge being required for mtrr
    loading, as this will be required later anyway.
    
    Add a command line option "invpcid" for controlling the use of
    INVPCID (default to true).
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 0d3e7f0b6bf01fbd6250fd3408a22fead1601bf0
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:12 2018 +0200

    xen/x86: support per-domain flag for xpti
    
    Instead of switching XPTI globally on or off add a per-domain flag for
    that purpose. This allows to modify the xpti boot parameter to support
    running dom0 without Meltdown mitigations. Using "xpti=no-dom0" as boot
    parameter will achieve that.
    
    Move the xpti boot parameter handling to xen/arch/x86/pv/domain.c as
    it is pv-domain specific.
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit cda05dcae6732fc9c5b782a97a09b5a0f0dd4b81
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:11 2018 +0200

    xen/x86: add a function for modifying cr3
    
    Instead of having multiple places with more or less identical asm
    statements just have one function doing a write to cr3.
    
    As this function should be named write_cr3() rename the current
    write_cr3() function to switch_cr3().
    
    Suggested-by: Andrew Copper <andrew.cooper3@xxxxxxxxxx>
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>

commit 18173843a573a2691121d34780a011ce1dd5138c
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Thu Apr 26 13:33:10 2018 +0200

    x86/xpti: avoid copying L4 page table contents when possible
    
    For mitigation of Meltdown the current L4 page table is copied to the
    cpu local root page table each time a 64 bit pv guest is entered.
    
    Copying can be avoided in cases where the guest L4 page table hasn't
    been modified while running the hypervisor, e.g. when handling
    interrupts or any hypercall not modifying the L4 page table or %cr3.
    
    So add a per-cpu flag indicating whether the copying should be
    performed and set that flag only when loading a new %cr3 or modifying
    the L4 page table.  This includes synchronization of the cpu local
    root page table with other cpus, so add a special synchronization flag
    for that case.
    
    A simple performance check (compiling the hypervisor via "make -j 4")
    in dom0 with 4 vcpus shows a significant improvement:
    
    - real time drops from 112 seconds to 103 seconds
    - system time drops from 142 seconds to 131 seconds
    
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>
(qemu changes not included)

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