[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xen-unstable-smoke test] 114332: regressions - FAIL



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl           7 xen-boot                 fail REGR. vs. 114299

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt     13 migrate-support-check        fail   never pass

version targeted for testing:
 xen                  f17d2cd2ffeda70aba8788910e9d088415562c8b
baseline version:
 xen                  3b40cfcd1a1912c2e4c4eb353dc77cbf35c63c3a

Last test of basis   114299  2017-10-10 21:02:54 Z    0 days
Failing since        114308  2017-10-10 23:01:10 Z    0 days    3 attempts
Testing same since   114318  2017-10-11 02:19:34 Z    0 days    2 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andre Przywara <andre.przywara@xxxxxxx>
  Julien Grall <julien.grall@xxxxxxx>
  Stefano Stabellini <sstabellini@xxxxxxxxxx>

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-amd64-libvirt                                          pass    
 test-armhf-armhf-xl                                          fail    
 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


Not pushing.

------------------------------------------------------------
commit f17d2cd2ffeda70aba8788910e9d088415562c8b
Author: Andre Przywara <andre.przywara@xxxxxxx>
Date:   Sat Oct 7 01:06:40 2017 +0100

    ARM: sunxi: support more Allwinner SoCs
    
    So far we only supported the Allwinner A20 SoC. Add support for most
    of the other virtualization capable Allwinner SoCs by:
    - supporting the watchdog in newer (sun8i) SoCs
    - getting the watchdog address from DT
    - adding compatible strings for other 32-bit SoCs
    - adding compatible strings for 64-bit SoCs
    
    As all 64-bit SoCs support system reset via PSCI, we don't use the
    platform specific reset routine there. Should the 32-bit SoCs start to
    properly support the PSCI 0.2 SYSTEM_RESET call, we will use it for them
    automatically, as we try PSCI first, then fall back to platform reset.
    
    Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
    Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit e2dfe4a037b0c6ccfd2375e4b60668109a0118e5
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:41 2017 +0100

    xen/arm: mm: Use memory flags for modify_xen_mappings rather than custom one
    
    This will help to consolidate the page-table code and avoid different
    path depending on the action to perform.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

commit 6b88beed40c756aaff018d286f4de31351240a93
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:40 2017 +0100

    xen/arm: mm: Handle permission flags when adding a new mapping
    
    Currently, all the new mappings will be read-write non-executable. Allow the
    caller to use other permissions.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 28f2ad440a08908010abec43b7ccc3283051e943
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:39 2017 +0100

    xen/arm: mm: Embed permission in the flags
    
    Currently, it is not possible to specify the permission of a new
    mapping. It would be necessary to use the function modify_xen_mappings
    with a different set of flags.
    
    Introduce a couple of new flags for the permissions (Non-eXecutable,
    Read-Only) and also provides definition that combine the memory attribute
    and permission for common combinations.
    
    PAGE_HYPERVISOR is now an alias to PAGE_HYPERVISOR_RW (read-write,
    non-executable mappings). This does not affect the current mapping using
    PAGE_HYPERVISOR because Xen is currently forcing all the mapping to be
    non-executable by default (see mfn_to_xen_entry).
    
    A follow-up patch will change modify_xen_mappings to use the new flags.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
    Signed-off-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 5f3edb5f32e511b915d173403d0b7b5ea38e00ad
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:38 2017 +0100

    xen/arm: page: Describe the layout of flags used to update page tables
    
    Currently, the flags used to update page tables (i.e PAGE_HYPERVISOR_*)
    only contains the memory attribute index. Follow-up patches will add
    more information in it. So document the current layout.
    
    At the same time introduce PAGE_AI_MASK to get the memory attribute
    index easily.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 7d68c8db25f0ffc7f39af2fc929f1c77c1affa01
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:37 2017 +0100

    xen/arm: mm: Use PAGE_HYPERVISOR_* instead of MT_* when calling set_fixmap
    
    At the moment, PAGE_HYPERVISOR_* and MT_* have exactly the same value.
    In a follow-up patch the former will be extended to carry more
    information.
    
    It looks like the caller of set_fixmap are mixing the both. Stay
    consistent and only use PAGE_HYPERVISOR_*. This is also match the
    behavior of create_xen_entries and would potentially allow to share some
    part in the future.
    
    Also rename the parameter 'attributes' to 'flags' so it is clearer what
    is the interface.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit b797f4d03bed21ff643a93909abdd58107b6c8cf
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:36 2017 +0100

    xen/arm: mm: Rename 'ai' into 'flags' in create_xen_entries
    
    The parameter 'ai' is used either for attribute index or for
    permissions. Follow-up patch will rework that parameters to carry more
    information. So rename the parameter to 'flags'.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit fc24d616beda7b0d9a96c588b06862f46b189181
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:35 2017 +0100

    xen/arm: Switch to SYS_STATE_boot just after end_boot_allocator()
    
    We should consider the early boot period to end when we stop using the
    boot allocator. This is inline with x86 and will be helpful to know
    whether we should allocate memory from the boot allocator or xenheap.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 9a7f6dd6d2244993968569deb9963934add0a50d
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:34 2017 +0100

    xen/arm: mm: Rename and clarify AP[1] in the stage-1 page table
    
    The description of AP[1] in Xen is based on testing rather than the ARM
    ARM.
    
    Per the ARM ARM, on EL2 stage-1 page table, AP[1] is RES1 as the
    translation regime applies to only one exception level (see D4.4.4 and
    G4.6.1 in ARM DDI 0487B.a).
    
    Update the comment and also rename the field to match the description in
    the ARM ARM.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Andre Przywara <andre.przywara@xxxxxxx>
    Acked-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit a0543df403d457e139069d3356d42a89b25d11df
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:33 2017 +0100

    xen/arm: page: Clean-up the definition of MAIRVAL
    
    Currently MAIRVAL is defined in term of MAIR0VAL and MAIR1VAL which are
    both hardcoded value. This makes quite difficult to understand the value
    written in both registers.
    
    Rework the definition by using value of each attribute shifted by their
    associated index.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>

commit 70a3bd02f963d60cab30a2d6e6589ac477132d7c
Author: Julien Grall <julien.grall@xxxxxxx>
Date:   Mon Oct 9 14:23:32 2017 +0100

    xen/arm: page: Use ARMv8 naming to improve readability
    
    This is based on the Linux ARMv8 naming scheme (see arch/arm64/mm/proc.S). 
Each
    type will contain "NORMAL" or "DEVICE" to make clear whether each attribute
    targets device or normal memory.
    
    Signed-off-by: Julien Grall <julien.grall@xxxxxxx>
    Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
(qemu changes not included)

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.