flight 171451 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171451/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
flight 171442 xen-unstable real [real]
flight 171449 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171442/
http://logs.test-lab.xenproject.org/osstest/logs/171449/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
flight 171447 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171447/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 171446 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171446/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e1eef3a8b01a25e75abf63d15bdc90157a74cba9
baseline version:
ovmf 70586d4e3af67dcc4fa2c
Some architectures and irqchip drivers modify the cpumask returned by
irq_data_get_affinity_mask, usually by copying in to it. This is
problematic for uniprocessor configurations, where the affinity mask
should be constant, as it is known at compile time.
Add and use a setter for the affinity mask
IRQ affinity masks are not allocated in uniprocessor configurations.
This requires special case non-SMP code in drivers for irqchips which
have per-CPU enable or mask registers.
Since IRQ affinity is always the same in a uniprocessor configuration,
we can provide a correct affinity mask without al
It does exactly the same thing as irq_data_update_effective_affinity.
Signed-off-by: Samuel Holland
---
Changes in v3:
- New patch to drop irq_init_effective_affinity
kernel/irq/manage.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel
An IRQ's effective affinity can only be different from its configured
affinity if there are multiple CPUs. Make it clear that this option is
only meaningful when SMP is enabled. Most of the relevant code in
irqdesc.c is already hidden behind CONFIG_SMP anyway.
Signed-off-by: Samuel Holland
---
(
Now that the irq_data_update_affinity helper exists, enforce its use
by returning a a const cpumask from irq_data_get_affinity_mask.
Since the previous commit already updated places that needed to call
irq_data_update_affinity, this commit updates the remaining code that
either did not modify the
A couple of functions directly reference the affinity mask. Route them
through irq_data_get_affinity_mask so they will pick up any refactoring
done there.
Signed-off-by: Samuel Holland
---
(no changes since v1)
include/linux/irq.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletio
The MIPS GIC irqchip driver may be selected in a uniprocessor
configuration, but it unconditionally registers an IPI domain.
Limit the part of the driver dealing with IPIs to only be compiled when
GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.
Reported-by: kernel test robo
The generic IPI code depends on the IRQ affinity mask being allocated
and initialized. This will not be the case if SMP is disabled. Fix up
the remaining driver that selected GENERIC_IRQ_IPI in a non-SMP config.
Reported-by: kernel test robot
Signed-off-by: Samuel Holland
---
(no changes since
This series solves some inconsistency with how IRQ affinity masks are
handled between SMP and non-SMP configurations.
In non-SMP configs, an IRQ's true affinity is always cpumask_of(0), so
irq_{,data_}get_affinity_mask now return that, instead of returning an
uninitialized per-IRQ cpumask. This ch
flight 171437 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171437/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt 8 xen-boot fail REGR. vs. 171277
test-amd64-amd64-xl
On 28/06/2022 15:40, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 9 Jun 2022, at 09:30, Julien Grall wrote:
From: Hongyan Xia
The idea is to split the range into multiple aligned power-of-2 regions
which only needs to call free_heap_pages() once each. We check the least
significa
On Fri, 1 Jul 2022, Jan Beulich wrote:
> On 01.07.2022 00:35, Stefano Stabellini wrote:
> > On Wed, 29 Jun 2022, Daniel P. Smith wrote:
> >> This series makes it so that the idle domain is started privileged under
> >> the
> >> default policy, which the SILO policy inherits, and under the flask
>
On Fri, 1 Jul 2022, Bertrand Marquis wrote:
> > On 30 Jun 2022, at 22:03, Stefano Stabellini wrote:
> >
> > On Thu, 30 Jun 2022, Bertrand Marquis wrote:
> >>> On 29 Jun 2022, at 18:22, Stefano Stabellini
> >>> wrote:
> >>>
> >>> On Wed, 29 Jun 2022, Luca Fancellu wrote:
> + CC: Stefano St
Hi Juergen,
On 01/07/2022 06:13, Juergen Gross wrote:
On 30.06.22 20:36, Julien Grall wrote:
From: Julien Grall
Some tools (e.g. xenstored) always expect EINVAL to be first in
xsd_errors.
To be conservative, mandate that new errors should be added at the end
of the array.
Signed-off-by: J
flight 171444 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171444/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 70586d4e3af67dcc4fa2cd49524b7e5b71e0c7e1
baseline version:
ovmf f966093f5bb88e6fccac8
flight 171435 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171435/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 18 guest-start/debian.repeat fail REGR. vs.
171352
Tests which are fa
On Mon, May 30, 2022 at 05:31:18PM +0200, Jan Beulich wrote:
> On 20.05.2022 15:37, Roger Pau Monne wrote:
> > --- a/xen/arch/x86/include/asm/msr-index.h
> > +++ b/xen/arch/x86/include/asm/msr-index.h
> > @@ -139,6 +139,24 @@
> > #define PASID_PASID_MASK 0x000f
> > #define
flight 171436 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171436/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-arm64-libvirt
flight 171433 qemu-mainline real [real]
flight 171443 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171433/
http://logs.test-lab.xenproject.org/osstest/logs/171443/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
Hi Stefano,
> On 30 Jun 2022, at 22:03, Stefano Stabellini wrote:
>
> On Thu, 30 Jun 2022, Bertrand Marquis wrote:
>>> On 29 Jun 2022, at 18:22, Stefano Stabellini wrote:
>>>
>>> On Wed, 29 Jun 2022, Luca Fancellu wrote:
+ CC: Stefano Stabellini
> On 24 Jun 2022, at 17:04, Antho
Under certain conditions guests can get the CPU stuck in an unbounded
loop without the possibility of an interrupt window to occur on
instruction boundary. This was the case with the scenarios described
in XSA-156.
Make use of the Notify VM Exit mechanism, that will trigger a VM Exit
if no interr
Introduce a small helper to OR VMX_INTR_SHADOW_NMI in
GUEST_INTERRUPTIBILITY_INFO in order to help dealing with the NMI
unblocked by IRET case. Replace the existing usage in handling
EXIT_REASON_EXCEPTION_NMI and also add such handling to EPT violations
and page-modification log-full events.
Repo
Add support for enabling guest Bus Lock Detection on Intel systems.
Such detection works by triggering a vmexit, which ought to be enough
of a pause to prevent a guest from abusing of the Bus Lock.
Add an extra Xen perf counter to track the number of Bus Locks detected.
This is done because Bus Lo
Hello,
Following series implements support for bus lock and notify VM exit.
Patches are not really dependent, but I've developed them together by
virtue of both features being in Intel Instructions Set Extensions PR
Chapter 9.
Thanks, Roger.
Roger Pau Monne (3):
x86/vmx: implement VMExit base
On 01/07/2022 11:34, Jan Beulich wrote:
Signed-off-by: Wei Chen
---
xen/arch/arm/efi/Makefile | 4
1 file changed, 4 insertions(+)
diff --git a/xen/arch/arm/efi/Makefile b/xen/arch/arm/efi/Makefile
index dffe72e589..b06fb96c1f 100644
--- a/xen/arch/arm/efi/Makefile
+++ b/xen/arch/arm
flight 171431 xen-unstable real [real]
flight 171440 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171431/
http://logs.test-lab.xenproject.org/osstest/logs/171440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
On 01.07.2022 12:13, Wei Chen wrote:
> Xen uses "-fshort-wchar" in CFLAGS for EFI common code. Arm32
> is using stub.c of EFI common code for EFI stub functions. But
> "-fshort-wchar" CFLAG will cause a warning when build stub.c
> for Arm32:
> "arm-linux-gnueabihf-ld: warning: arch/arm/efi/built_in
flight 171438 ovmf real [real]
flight 171439 ovmf real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171438/
http://logs.test-lab.xenproject.org/osstest/logs/171439/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-
On 01.07.2022 00:35, Stefano Stabellini wrote:
> On Wed, 29 Jun 2022, Daniel P. Smith wrote:
>> This series makes it so that the idle domain is started privileged under the
>> default policy, which the SILO policy inherits, and under the flask policy.
>> It
>> then introduces a new one-way XSM hoo
Xen uses "-fshort-wchar" in CFLAGS for EFI common code. Arm32
is using stub.c of EFI common code for EFI stub functions. But
"-fshort-wchar" CFLAG will cause a warning when build stub.c
for Arm32:
"arm-linux-gnueabihf-ld: warning: arch/arm/efi/built_in.o uses
2-byte wchar_t yet the output is to use
On 01.07.2022 08:10, Wei Chen wrote:
> Hi Jan,
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年7月1日 13:54
>> To: Wei Chen
>> Cc: nd ; Stefano Stabellini ; Bertrand
>> Marquis ; Volodymyr Babchuk
>> ; Andrew Cooper ;
>> Roger Pau Monné ; Wei Liu ; Jiamei Xie
>> ; xen-devel@list
35 matches
Mail list logo
