flight 148393 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/148393/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 148323
test-amd64-amd64-libvirt 18 guest-start/debian.repeat fail REGR. vs. 148323
test-armhf-armhf-xl 16 guest-start/debian.repeat fail REGR. vs. 148323
Tests which did not succeed, but are not blocking:
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 e19d3a942e4b6f6c5b19287a4a6f5020bdab2936
baseline version:
xen 99f1c935190986068a36fb5e78a00e6b71b08f25
Last test of basis 148323 2020-03-09 15:01:29 Z 1 days
Failing since 148381 2020-03-10 15:05:53 Z 0 days 2 attempts
Testing same since 148393 2020-03-10 19:01:05 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeul...@suse.com>
Paul Durrant <p...@xen.org>
Roger Pau Monné <roger....@citrix.com>
Ross Lagerwall <ross.lagerw...@citrix.com>
Tamas K Lengyel <ta...@tklengyel.com>
Tim Deegan <t...@xen.org>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl fail
test-arm64-arm64-xl-xsm fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-libvirt 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.
------------------------------------------------------------
commit e19d3a942e4b6f6c5b19287a4a6f5020bdab2936
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 17:06:57 2020 +0100
memaccess: reduce include dependencies
The common header doesn't itself need to include public/vm_event.h nor
public/memory.h. Drop their inclusion. This requires using the non-
typedef names in two prototypes and an inline function; by not changing
the callers and function definitions at the same time it'll remain
certain that the build would fail if the typedef itself was changed.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Tamas K Lengyel <ta...@tklengyel.com>
commit 15b6242230ba1cf92c774ad2b14f4f25411aa644
Author: Paul Durrant <p...@xen.org>
Date: Tue Mar 10 17:06:09 2020 +0100
x86 / p2m: replace page_list check in p2m_alloc_table...
... with a check of domain_tot_pages().
The check of page_list prevents the prior allocation of PGC_extra pages,
whereas what the code is trying to verify is that the toolstack has not
already RAM for the domain.
Signed-off-by: Paul Durrant <p...@xen.org>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
commit 0198960edbf0e681cef59fd81c994643e7b148e0
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:38:25 2020 +0100
vmevent: reduce include dependencies
There's no need for virtually everything to include public/vm_event.h.
Move its inclusion out of sched.h. This requires using the non-typedef
name in p2m_mem_paging_resume()'s prototype; by not changing the
function definition at the same time it'll remain certain that the build
would fail if the typedef itself was changed.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Ross Lagerwall <ross.lagerw...@citrix.com>
Reviewed-by: Alexandru Isaila <aisa...@bitdefender.com>
Acked-by: Tamas K Lengyel <ta...@tklengyel.com>
commit 0604e1549ac522443f01d49774f73cfa67561358
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:37:30 2020 +0100
IOMMU: iommu_snoop is x86-only
In fact it's VT-d specific, but we don't have a way yet to build code
for just one vendor. Provide a #define for the opposite case.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
Reviewed-by: Paul Durrant <p...@xen.org>
commit 0de9500d1c2c3f37b3cd86b180dc1d2aafa2ad1b
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:36:45 2020 +0100
IOMMU: iommu_qinval is x86-only
In fact it's VT-d specific, but we don't have a way yet to build code
for just one vendor.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
Reviewed-by: Paul Durrant <p...@xen.org>
commit cd550c3963ea521205e80df935c17d4cdee02844
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:35:57 2020 +0100
IOMMU: iommu_igfx is x86-only
In fact it's VT-d specific, but we don't have a way yet to build code
for just one vendor.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
Reviewed-by: Paul Durrant <p...@xen.org>
commit 4ccbb9c337de30f4b5fd9caf87c673200cb19de9
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:33:56 2020 +0100
IOMMU: iommu_intpost is x86/HVM-only
Provide a #define for all other cases.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
Reviewed-by: Paul Durrant <p...@xen.org>
commit 5f62fdcb4c7c63205abfe5a5cbf77025cb9fd431
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:32:16 2020 +0100
IOMMU: iommu_intremap is x86-only
Provide a #define for other cases; it didn't seem worthwhile to me to
introduce an IOMMU_INTREMAP Kconfig option at this point.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
Reviewed-by: Paul Durrant <p...@xen.org>
commit c9495bd7dff587ce770b2318037d6a1d0511bd72
Author: Roger Pau Monné <roger....@citrix.com>
Date: Tue Mar 10 15:30:27 2020 +0100
x86/hap: improve hypervisor assisted guest TLB flush
The current implementation of the hypervisor assisted flush for HAP is
extremely inefficient.
First of all there's no need to call paging_update_cr3, as the only
relevant part of that function when doing a flush is the ASID vCPU
flush, so just call that function directly.
Since hvm_asid_flush_vcpu is protected against concurrent callers by
using atomic operations there's no need anymore to pause the affected
vCPUs.
Finally the global TLB flush performed by flush_tlb_mask is also not
necessary, since we only want to flush the guest TLB state it's enough
to trigger a vmexit on the pCPUs currently holding any vCPU state, as
such vmexit will already perform an ASID/VPID update, and thus clear
the guest TLB.
Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Reviewed-by: Wei Liu <w...@xen.org>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
commit 920d5f31883c9c4c4e8092a693572fe01b6f7270
Author: Roger Pau Monné <roger....@citrix.com>
Date: Tue Mar 10 15:29:24 2020 +0100
x86/paging: add TLB flush hook
Add shadow and hap implementation specific helpers to perform guest
TLB flushes. Note that the code for both is exactly the same at the
moment, and is copied from hvm_flush_vcpu_tlb. This will be changed by
further patches that will add implementation specific optimizations to
them.
No functional change intended.
Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Reviewed-by: Wei Liu <w...@xen.org>
Acked-by: Tim Deegan <t...@xen.org>
Reviewed-by: Paul Durrant <pdurr...@amzn.com> [viridian]
Reviewed-by: Jan Beulich <jbeul...@suse.com>
commit 261ef8ccbd28526d69c3a6c5944709f81624741a
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:27:56 2020 +0100
x86: refine APIC ID restriction
Now that we distinguish "restricted" and "full" interrupt remapping
mode, the 8-bit-APIC-ID restriction also needs to be enforced for
"restricted".
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Roger Pau Monné <roger....@citrix.com>
commit 1ba66a870eba43d52d3e5e7af1a055bf5b16b30d
Author: Jan Beulich <jbeul...@suse.com>
Date: Tue Mar 10 15:25:58 2020 +0100
AMD/IOMMU: without XT, x2APIC needs to be forced into physical mode
The wider cluster mode APIC IDs aren't generally representable. Convert
the iommu_intremap variable into a tristate, allowing the AMD IOMMU
driver to signal this special restriction to the apic_x2apic_probe().
(Note: assignments to the variable get adjusted, while existing
consumers - all assuming a boolean property - are left alone.)
While we are not aware of any hardware/firmware with this as a
restriction, it is a situation which could be created on fully x2apic-
capable systems via firmware settings.
Signed-off-by: Jan Beulich <jbeul...@suse.com>
Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Roger Pau Monné <roger....@citrix.com>
Reviewed-by: Kevin Tian <kevin.t...@intel.com>
(qemu changes not included)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
