[xen-unstable-smoke test] 145806: tolerable all pass

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

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm      13 migrate-support-check        fail   never pass
 test-arm64-arm64-xl-xsm      14 saverestore-support-check    fail   never pass
 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                  3840e98f3e72b7b92071089a042cd7cf5be72732
baseline version:
 xen                  4dde27b6e0a0b0dcb8fdfc7580fbd9c976aa103f

Last test of basis   145752  2020-01-07 18:00:34 Z    0 days
Testing same since   145806  2020-01-08 15:00:58 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  George Dunlap <george.dunlap@xxxxxxxxxx>
  Jan Beulich <jbeulich@xxxxxxxx>
  Juergen Gross <jgross@xxxxxxxx>
  Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  Wei Liu <wl@xxxxxxx>

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


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

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

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

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


Pushing revision :

ssh: Could not resolve hostname xenbits.xen.org: Temporary failure in name 
resolution
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
------------------------------------------------------------
commit 3840e98f3e72b7b92071089a042cd7cf5be72732
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Jan 8 15:04:36 2020 +0100

    libxl: don't needlessly report "highmem" in use
    
    Due to the unconditional updating of dom->highmem_end in
    libxl__domain_device_construct_rdm() I've observed on a 2Gb HVM guest
    with a passed through device (without overly large BARs, and with no RDM
    ranges at all)
    
    (d2) RAM in high memory; setting high_mem resource base to 100000000
    ...
    (d2) E820 table:
    (d2)  [00]: 00000000:00000000 - 00000000:000a0000: RAM
    (d2)  HOLE: 00000000:000a0000 - 00000000:000d0000
    (d2)  [01]: 00000000:000d0000 - 00000000:00100000: RESERVED
    (d2)  [02]: 00000000:00100000 - 00000000:7f800000: RAM
    (d2)  HOLE: 00000000:7f800000 - 00000000:fc000000
    (d2)  [03]: 00000000:fc000000 - 00000001:00000000: RESERVED
    (d2)  [04]: 00000001:00000000 - 00000001:00000000: RAM
    
    both of which aren't really appropriate in this case. Arrange for this
    to not happen.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Wei Liu <wl@xxxxxxx>

commit fe4df51ff776c8e543879ed552ace34d217e048d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Jan 8 15:03:58 2020 +0100

    x86/mm: re-order a few conditionals
    
    is_{hvm,pv}_*() can be expensive now, so where possible evaluate cheaper
    conditions first.
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Acked-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit a4cde0266d4287650ec62d8f850e4f84359e5e4f
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Jan 8 15:03:19 2020 +0100

    x86/mm: rename and tidy create_pae_xen_mappings()
    
    After dad74b0f9e ("i386: fix handling of Xen entries in final L2 page
    table") and the removal of 32-bit support the function doesn't modify
    state anymore, and hence its name has been misleading. Change its name,
    constify parameters and a local variable, and make it return bool.
    
    Also drop the call to it from mod_l3_entry(): The function explicitly
    disallows 32-bit domains to modify slot 3. This way we also won't
    re-check slot 3 when a slot other than slot 3 changes. Doing so has
    needlessly disallowed making some L2 table recursively link back to an
    L2 used in some L3's 3rd slot, as we check for the type ref count to be
    1. (Note that allowing dynamic changes of L3 entries in the way we do is
    bogus anyway, as that's not how L3s behave in the native and EPT cases:
    They get re-evaluated only upon CR3 reloads. NPT is different in this
    regard.)
    
    As a result of this we no longer need to play games to get at the start
    of the L3 table.
    
    Additionally move the single remaining call site, allowing to drop one
    is_pv_32bit_domain() invocation and a _PAGE_PRESENT check (in the
    function itself) as well as to exit the loop early (remaining entries
    have all been set to empty just ahead of this loop).
    
    Further move a BUG_ON() such that in the common case its condition
    wouldn't need evaluating.
    
    Finally, since we're at it, move init_xen_pae_l2_slots() next to the
    renamed function, as they really belong together (in fact
    init_xen_pae_l2_slots() was [indirectly] broken out of this function).
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit 8931fc9a1d7c7f4afd339b314fe7881fc06e2f5d
Author: Jan Beulich <jbeulich@xxxxxxxx>
Date:   Wed Jan 8 15:02:26 2020 +0100

    x86/mm: mod_l<N>_entry() have no need to use __copy_from_user()
    
    mod_l1_entry()'s need to do so went away with commit 2d0557c5cb ("x86:
    Fold page_info lock into type_info"), and the other three never had such
    a need, at least going back as far as 3.2.0. Replace the uses by
    l<N>e_read_atomic().
    
    Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
    Reviewed-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

commit d7f3c76317108ee9989f00545d394fa495fba752
Author: Juergen Gross <jgross@xxxxxxxx>
Date:   Wed Jan 8 14:59:25 2020 +0100

    sched: fix resuming from S3 with smt=0
    
    When resuming from S3 and smt=0 or maxcpus= are specified we must not
    do anything in cpu_schedule_callback(). This is not true today for
    taking down a cpu during resume.
    
    If anything goes wrong during resume all the scheduler related error
    handling is in cpupool.c, so we can just bail out early from
    cpu_schedule_callback() when suspending or resuming.
    
    This fixes commit 0763cd2687897b55e7 ("xen/sched: don't disable
    scheduler on cpus during suspend").
    
    Reported-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
    Tested-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
    Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
(qemu changes not included)

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/osstest-output