flight 159052 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159052/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 broken
Hi!
all of a sudden (but only after a few days of running normally), on a stock
Ubuntu 18.04 (Bionic with 4.15.0 kernel) DomU I'm seeing Microsoft's .net
runtime go into a heave GC cycle and then freeze and die like what is
shown below. This is under stock Xen 4.14.0 on a pretty unremarkable
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Thanks for helping to figure out the problem. Unfortunately, I still see
reliably the WARN splat with the latest Linux
flight 159042 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159042/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsmbroken
On 06/02/2021 12:09, Jürgen Groß wrote:
On 06.02.21 12:20, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of
On 06.02.21 12:20, Julien Grall wrote:
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port.
The same applies to
Hi Juergen,
On 06/02/2021 10:49, Juergen Gross wrote:
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port.
The same applies to the affinity when onlining a vcpu: all
flight 159036 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159036/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 14 guest-start fail REGR. vs. 159013
Tests which did not
Hi Stefano,
On 06/02/2021 00:38, Stefano Stabellini wrote:
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
Doh :/.
The offending chunk is: >
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+
Add sysfs nodes for each xenbus device showing event statistics (number
of events and spurious events, number of associated event channels)
and for setting a spurious event threshold in case a frontend is
sending too many events without being rogue on purpose.
Signed-off-by: Juergen Gross
---
In evtchn_read() use READ_ONCE() for reading the producer index in
order to avoid the compiler generating multiple accesses.
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/evtchn.c b/drivers/xen/evtchn.c
In order to support the possibility of per-device event channel
settings (e.g. lateeoi spurious event thresholds) add a xenbus device
pointer to struct irq_info() and modify the related event channel
binding interfaces to take the pointer to the xenbus device as a
parameter instead of the domain
The ring buffer for user events is used in the local system only, so
smp barriers are fine for ensuring consistency.
Reported-by: Andrew Cooper
Signed-off-by: Juergen Gross
---
drivers/xen/evtchn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/evtchn.c
The first three patches are fixes for XSA-332. The avoid WARN splats
and a performance issue with interdomain events.
Patches 4 and 5 are some additions to event handling in order to add
some per pv-device statistics to sysfs and the ability to have a per
backend device spurious event delay
When having accepted an irq as result from receiving an event the
related event should be cleared. The lateeoi model is missing that,
resulting in a continuous stream of events being signalled.
Fixes: 54c9de89895e0a ("xen/events: add a new late EOI evtchn framework")
Cc: sta...@vger.kernel.org
When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port.
The same applies to the affinity when onlining a vcpu: all old
affinity settings for this vcpu must be reset. As
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 two different flags for each event channel
to be able to distinguish "normal" masking/unmasking from eoi related
masking/unmasking.
Hi Jan,
On 01/02/2021 14:56, Jan Beulich wrote:
Going through an intermediate *.new file requires telling the compiler
what the real target is, so that the inclusion of the resulting .*.d
file will actually be useful.
Fixes: 7d2d7a43d014 ("x86/build: limit rebuilding of asm-offsets.h")
Hi Stefano,
On 04/02/2021 22:39, Stefano Stabellini wrote:
After the discussion with Rob, it is clear that we have to add a check
on the node name for "pcie" in dt_bus_pci_match. However, that wouldn't
solve the problem reported by Elliot, because in this case the node name
is "pci" not "pcie".
flight 159032 qemu-mainline real [real]
flight 159068 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159032/
http://logs.test-lab.xenproject.org/osstest/logs/159068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not
flight 159040 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159040/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 0d96664df322d50e0ac54130e129c0bf4f2b72df
baseline version:
ovmf
21 matches
Mail list logo
