flight 159483 qemu-mainline real [real]
flight 159488 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159483/
http://logs.test-lab.xenproject.org/osstest/logs/159488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
flight 159484 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit1 broken
test-amd64-i386-xl-xsm7 xen-instal
Hi Juergen,
On 19/02/2021 15:40, Juergen Gross wrote:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to be able to distinguish "normal
Hi Juergen,
On 19/02/2021 15:40, Juergen Gross wrote:
When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.
Avoid that by adding an "event active" flag to the per-event data and
From: Julien Grall
Currently, Xen will send a data abort to a guest trying to write to the
ISPENDR.
Unfortunately, recent version of Linux (at least 5.9+) will start
writing to the register if the interrupt needs to be re-triggered
(see the callback irq_retrigger). This can happen when a driver
On Fri, 2021-02-19 at 16:47 +, Ian Jackson wrote:
>
> OPEN ISSUES AND BLOCKERS
>
>
> F. BUG: credit=sched2 machine hang when using DRAKVUF
>
> Information from
> Dario Faggioli
> References
> https://lists.xen.org/archives/html/xen-devel/2020-05/msg01985.html
>
On 19/02/2021 23:12, Julien Grall wrote:
Hi all,
On Fri, 19 Feb 2021 at 22:19, osstest service owner
wrote:
flight 159463 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159463/
[...]
test-arm64-arm64-xl-seattle fail
[...]
flight 159487 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 19 xtf/test-pv32pae-selftest fail REGR. vs. 159475
test-amd64-i386-xl
From: Julien Grall
At the moment, flush_page_to_ram() is both cleaning and invalidate to
PoC the page. However, the cache line can be speculated and pull in the
cache right after as it is part of the direct map.
So it is pointless to try to invalidate the line in the data cache.
Signed-off-by:
From: Julien Grall
The comment in vcpu_block() states that the events should be checked
/after/ blocking to avoids wakeup waiting race. However, from a generic
perspective, set_bit() doesn't prevent re-ordering. So the following
could happen:
CPU0 (blocking vCPU A) | CPU1 ( unblock vC
flight 159489 qemu-mainline real [real]
flight 159495 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159489/
http://logs.test-lab.xenproject.org/osstest/logs/159495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 2/19/21 10:40 AM, Juergen Gross wrote:
> For avoiding read- and write-tearing by the compiler use READ_ONCE()
> and WRITE_ONCE() for accessing the ring indices in evtchn.c.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Boris Ostrovsky
The expected behavior while using xen-vmtrace is to get a clean start, even if
the tool was used previously on the same VM.
Signed-off-by: Tamas K Lengyel
---
tools/misc/xen-vmtrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xen-vmtrace.c b/tools/misc/xen-vm
flight 159493 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159493/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 44ae214591e58af468eacb7b873eaa0bc187c4fa
baseline version:
ovmf 4f4d862c1c7232a183476
flight 159490 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159490/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm broken
test-arm64-arm64-xl-credit1
From: Nadav Amit
The series improves TLB shootdown by flushing the local TLB concurrently
with remote TLBs, overlapping the IPI delivery time with the local
flush. Performance numbers can be found in the previous version [1].
v5 was rebased on 5.11 (long time after v4), and had some bugs and
emb
From: Nadav Amit
To improve TLB shootdown performance, flush the remote and local TLBs
concurrently. Introduce flush_tlb_multi() that does so. Introduce
paravirtual versions of flush_tlb_multi() for KVM, Xen and hyper-v (Xen
and hyper-v are only compile-tested).
While the updated smp infrastruct
flight 159491 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 19 xtf/test-pv32pae-selftest fail REGR. vs. 159475
test-amd64-i386-xl
flight 159507 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159507/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
19 matches
Mail list logo
