[xen-unstable-coverity test] 154954: trouble: broken

[xen-unstable-coverity test] 154954: trouble: broken

[osstest service owner]

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

Failures and problems with tests :-(

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

version targeted for testing:
 xen                  5bcac985498ed83d89666959175ca9c9ed561ae1
baseline version:
 xen                  2785b2a9e04abc148e1c5259f4faee708ea356f4

Last test of basis   154638  2020-09-23 09:18:27 Z    4 days
Testing same since   154954  2020-09-27 09:18:27 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Andrew Cooper <andrew.cooper3@citrix.com>
  Jan Beulich <jbeulich@suse.com>
  Julien Grall <jgrall@amazon.com>
  Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
  Stefano Stabellini <sstabellini@kernel.org>

jobs:
 coverity-amd64                                               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 5bcac985498ed83d89666959175ca9c9ed561ae1
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Mon Jun 29 11:32:37 2020 +0100

    x86/pv: Don't clobber NT on return-to-guest
    
    A 64bit IRET can restore NT - the faulting case is when NT is set in the live
    flags.  This change had an unintended consequence of causing the NT flag to
    spontaneously disappear from guest context whenever a interrupt/exception
    occurred.
    
    In combination with a SYSENTER which sets both TF and NT, Xen's handling of
    the #DB exceptions clears NT before it is even recorded suitably in the guest
    kernel's view of what userspace was doing.
    
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Fixes: 0e47f92b0 ("x86: force EFLAGS.IF on when exiting to PV guests")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit 61d4a04349895edc5a5868274b906ba61ef24f47
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Fri Jun 26 14:56:23 2020 +0100

    x86/pv: Don't deliver #GP for a SYSENTER with NT set
    
    It is a matter of guest kernel policy what to do with offending userspace, and
    terminating said userspace may not be the action chosen.
    
    Linux explicitly tolerates this case.
    
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Fixes: fdac951560 ("x86: clear EFLAGS.NT in SYSENTER entry path")
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Reviewed-by: Jan Beulich <jbeulich@suse.com>

commit af3c913f03b5f9eab15b168ef87cde80f9addc6e
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date:   Tue Sep 22 20:05:22 2020 +0100

    x86/msi: Fold pci_conf_write16() calls in write_msi_msg()
    
    In addition, this removes the unqualified 0/1 passed to msi_data_reg()
    
    No functional change.
    
    Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
    Acked-by: Jan Beulich <jbeulich@suse.com>

commit 5a37207df52066efefe419c677b089a654d37afc
Author: Julien Grall <jgrall@amazon.com>
Date:   Fri Sep 18 18:11:16 2020 +0100

    xen/arm: bootfdt: Ignore empty memory bank
    
    At the moment, Xen will stop processing the Device Tree if a memory
    bank is empty (size == 0).
    
    Unfortunately, some of the Device Tree (such as on Colibri imx8qxp)
    may contain such a bank. This means Xen will not be able to boot
    properly.
    
    Relax the check to just ignore the banks. FWIW this also seems to be the
    behavior adopted by Linux.
    
    Reported-by: Daniel Wagner <Daniel.Wagner2@itk-engineering.de>
    Signed-off-by: Julien Grall <jgrall@amazon.com>
    Reviewed-by: Bertrand Marquis <bertrand.marquis@arm.com>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>

commit a6732807d335239fc29bd953538affc458bcc197
Author: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date:   Sat Sep 19 20:21:22 2020 +0300

    SUPPORT.md: Update status of Renesas IPMMU-VMSA (Arm)
    
    Mark Renesas IPMMU-VMSA as "Supported, not security supported"
    and remove dependencies on CONFIG_EXPERT.
    
    We can't treat the IOMMU driver as "Supported" since the device
    passthrough feature is not security supported on Arm today.
    
    Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
    Acked-by: Julien Grall <jgrall@amazon.com>
    Acked-by: Stefano Stabellini <sstabellini@kernel.org>
(qemu changes not included)