flight 173388 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173388/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
build-i386-pvops
On Fri, Sep 30, 2022 at 08:27:09PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour wrote:
> > On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
> > > I know very little about Xen, but based on the context you provided in
> > > this thread, I'd say
flight 173386 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173386/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
build-i386-pvops
On Fri, Sep 30, 2022 at 10:59:49PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 22:21, Demi Marie Obenour
> wrote:
> >
> > On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
> > > wrote:
> > > >
> > > > On Fri, Sep
On Fri, Sep 30, 2022 at 11:24:37PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 22:59, Ard Biesheuvel wrote:
> >
> > On Fri, 30 Sept 2022 at 22:21, Demi Marie Obenour
> > wrote:
> > >
> > > On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> > > > On Fri, 30 Sept 2022 at
flight 173385 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173385/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 broken
build-i386-prev
On Fri, 30 Sept 2022 at 22:59, Ard Biesheuvel wrote:
>
> On Fri, 30 Sept 2022 at 22:21, Demi Marie Obenour
> wrote:
> >
> > On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
> > > wrote:
> > > >
> > > > On Fri, Sep 30, 2022
As discussed on xen-devel, using EfiRuntimeServicesData for more than is
absolutely necessary is a bad idea.
---
xen/common/efi/boot.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index
On Fri, 30 Sept 2022 at 22:21, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
> > wrote:
> > >
> > > On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel wrote:
> > > > On Fri, 30 Sept 2022
On Fri, Sep 30, 2022 at 09:11:19PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
> wrote:
> >
> > On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > > wrote:
> > > >
> > > > fwupd requires
On Fri, 30 Sept 2022 at 20:21, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > wrote:
> > >
> > > fwupd requires access to the EFI System Resource Table (ESRT) to
> > > discover which firmware
On Fri, Sep 30, 2022 at 08:42:41PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 20:17, Demi Marie Obenour
> wrote:
> >
> > On Fri, Sep 30, 2022 at 06:25:53PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > > wrote:
> > > >
> > > > Memory of type
On Fri, Sep 30, 2022 at 08:27:09PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour
> wrote:
> >
> > On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
> > > On Fri, 30 Sept 2022 at 08:44, Jan Beulich wrote:
> > > >
> > > > On 30.09.2022 01:02, Demi
On Fri, 30 Sept 2022 at 20:17, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 06:25:53PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> > wrote:
> > >
> > > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > >
On Fri, 30 Sept 2022 at 19:12, Demi Marie Obenour
wrote:
>
> On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
> > On Fri, 30 Sept 2022 at 08:44, Jan Beulich wrote:
> > >
> > > On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > > > Memory of type EFI_CONVENTIONAL_MEMORY,
On Fri, Sep 30, 2022 at 06:36:11PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> wrote:
> >
> > fwupd requires access to the EFI System Resource Table (ESRT) to
> > discover which firmware can be updated by the OS. Currently, Linux does
> > not expose the
On Fri, Sep 30, 2022 at 06:25:53PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
> wrote:
> >
> > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> > Xen before
flight 173387 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173387/
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
On 30/09/2022 16:41, Marek Marczykowski-Górecki wrote:
On Fri, Sep 30, 2022 at 11:25:12AM +, Andrew Cooper wrote:
On 15/09/2022 11:04, Jan Beulich wrote:
[1] specifies a long list of instructions which are intended to exhibit
timing behavior independent of the data they operate on. On
On Fri, Sep 30, 2022 at 06:30:57PM +0200, Ard Biesheuvel wrote:
> On Fri, 30 Sept 2022 at 08:44, Jan Beulich wrote:
> >
> > On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > > EFI_BOOT_SERVICES_CODE, and
On Fri, Sep 30, 2022 at 08:44:21AM +0200, Jan Beulich wrote:
> On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> > Xen before Linux gets to start
On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
wrote:
>
> fwupd requires access to the EFI System Resource Table (ESRT) to
> discover which firmware can be updated by the OS. Currently, Linux does
> not expose the ESRT when running as a Xen dom0. Therefore, it is not
> possible to use fwupd
On Fri, 30 Sept 2022 at 08:44, Jan Beulich wrote:
>
> On 30.09.2022 01:02, Demi Marie Obenour wrote:
> > Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> > EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> > Xen before Linux gets to start using
On Fri, 30 Sept 2022 at 01:02, Demi Marie Obenour
wrote:
>
> Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> Xen before Linux gets to start using it. Therefore, Linux under Xen
> must not use EFI
From: Andrei Cherechesu
Normally, the Imagebuilder would precompute the sizes of the loaded
binaries and addresses where they are loaded before generating the
script, and the sizes and addresses that needed to be provided to
Xen via /chosen would be hardcoded in the boot script.
Added an option
From: Andrei Cherechesu
This sent patch adds support for dynamically computing the addresses
and sizes for loaded binaries via the boot script generated by
Imagebuilder.
Compared to the v3 version of the patch, this includes Stefano's
suggestions of not adding as many "if" statements on the
On Fri, Sep 30, 2022 at 11:25:12AM +, Andrew Cooper wrote:
> On 15/09/2022 11:04, Jan Beulich wrote:
> > [1] specifies a long list of instructions which are intended to exhibit
> > timing behavior independent of the data they operate on. On certain
> > hardware this independence is optional,
> On 30 Sep 2022, at 15:59, Christian Lindig
> wrote:
>
>
>
>> On 27 Sep 2022, at 17:13, Edwin Torok wrote:
>>
>>
>> See below for a patch for that. I've included this patch in the correct
>> place (before the patch that breaks it) in the git repository at:
>>
flight 173383 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173383/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsmbroken
build-arm64-pvops
> On 27 Sep 2022, at 17:13, Edwin Torok wrote:
>
>
> See below for a patch for that. I've included this patch in the correct place
> (before the patch that breaks it) in the git repository at:
> https://github.com/edwintorok/xen/compare/private/edvint/public0
>
Acked-by: Christian Lindig
On Fri, Sep 30, 2022 at 09:50:40AM +0200, Jan Beulich wrote:
> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
> higher priority than the type of the range. To avoid accessing memory at
> runtime which was re-used for other purposes, make
> efi_arch_process_memory_map()
The EFI memory map contains two memory types (EfiMemoryMappedIO and
EfiMemoryMappedIOPortSpace) used to describe IO memory areas of
devices used by EFI.
The current parsing of the EFI memory map was translating
EfiMemoryMappedIO and EfiMemoryMappedIOPortSpace to E820_RESERVED on
x86. This is an
Hi Andrew,
> On 30 Sep 2022, at 14:53, Andrew Cooper wrote:
>
> On 30/09/2022 08:50, Jan Beulich wrote:
>> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>> higher priority than the type of the range. To avoid accessing memory at
>> runtime which was re-used for other
On Fri, Sep 30, 2022 at 03:11:07PM +0200, Juergen Gross wrote:
> Yes, this can be done. It would practically have to be the first one just
> after CPUHP_BRINGUP_CPU.
Right.
> The question is whether we really want to call the MTRR/PAT initialization
> on hotplugged cpus only after enabling
On 30.09.22 13:55, Borislav Petkov wrote:
On Thu, Sep 29, 2022 at 10:26:59AM +0200, Juergen Gross wrote:
So right now I'm inclined to be better on the safe side by not adding any
cpu hotplug hook, but to use just the same "delayed AP init" flag as today,
just renaming it. This would leave the
On 30.09.2022 14:53, Andrew Cooper wrote:
> On 30/09/2022 08:50, Jan Beulich wrote:
>> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>> higher priority than the type of the range. To avoid accessing memory at
>> runtime which was re-used for other purposes, make
>>
On 30/09/2022 08:50, Jan Beulich wrote:
> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
> higher priority than the type of the range. To avoid accessing memory at
> runtime which was re-used for other purposes, make
> efi_arch_process_memory_map() follow suit. While on
Hi Jan,
> On 30 Sep 2022, at 09:50, Jan Beulich wrote:
>
> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
> higher priority than the type of the range. To avoid accessing memory at
> runtime which was re-used for other purposes, make
> efi_arch_process_memory_map()
> On 30 Sep 2022, at 08:50, Jan Beulich wrote:
>
> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
> higher priority than the type of the range. To avoid accessing memory at
> runtime which was re-used for other purposes, make
> efi_arch_process_memory_map() follow
On 30.09.2022 13:54, Andrew Cooper wrote:
> On 27/09/2022 17:20, Jan Beulich wrote:
>> --- a/xen/arch/x86/srat.c
>> +++ b/xen/arch/x86/srat.c
>> @@ -413,14 +414,37 @@ acpi_numa_memory_affinity_init(const str
>> node, pxm, start, end - 1,
>> ma->flags &
On Thu, Sep 29, 2022 at 10:26:59AM +0200, Juergen Gross wrote:
> So right now I'm inclined to be better on the safe side by not adding any
> cpu hotplug hook, but to use just the same "delayed AP init" flag as today,
> just renaming it. This would leave the delayed MTRR/PAT init in place for
>
Hi Jan,
We will review and test the arm part (even though it is modifying some unused
code at the moment) but I wanted to answer you on some questions you have ..
> On 30 Sep 2022, at 09:50, Jan Beulich wrote:
>
> efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
>
On 27/09/2022 17:20, Jan Beulich wrote:
> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -413,14 +414,37 @@ acpi_numa_memory_affinity_init(const str
> node, pxm, start, end - 1,
> ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE ? " (hotplug)" : "");
>
> -
On Tue, Sep 27, 2022 at 06:20:35PM +0200, Jan Beulich wrote:
> SRAT may describe individual nodes using multiple ranges. When they're
> adjacent (with or without a gap in between), only the start of the first
> such range actually needs accounting for. Furthermore the very first
> range doesn't
On 15/09/2022 11:04, Jan Beulich wrote:
> [1] specifies a long list of instructions which are intended to exhibit
> timing behavior independent of the data they operate on. On certain
> hardware this independence is optional, controlled by a bit in a new
> MSR. Provide a command line option to
On Thu, Sep 29, 2022 at 05:25:29PM +0100, Andrew Cooper wrote:
> On 29/09/2022 17:22, osstest service owner wrote:
> > flight 173362 xen-unstable-smoke real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/173362/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are
flight 173379 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173379/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail pass in
173361
Tests which did not
On Thu, Sep 29, 2022 at 05:55:50PM +0200, Jan Beulich wrote:
> On 24.08.2022 15:27, Matias Ezequiel Vara Larsen wrote:
> > The purpose of this RFC is to get feedback about a new acquire resource that
> > exposes vcpu statistics for a given domain. The current mechanism to get
> > those
> >
flight 173384 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173384/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-debianhvm-amd64 20 guest-start/debianhvm.repeat fail
like 173342
On 30.09.2022 12:22, Anthony PERARD wrote:
> On Fri, Sep 30, 2022 at 08:31:20AM +0200, Jan Beulich wrote:
>> On 29.09.2022 18:25, Andrew Cooper wrote:
>>> On 29/09/2022 17:22, osstest service owner wrote:
flight 173362 xen-unstable-smoke real [real]
On 30.09.2022 12:03, Roger Pau Monné wrote:
> On Fri, Sep 30, 2022 at 10:36:20AM +0200, Jan Beulich wrote:
>> On 30.09.2022 10:25, Roger Pau Monné wrote:
>>> On Tue, Sep 27, 2022 at 06:20:35PM +0200, Jan Beulich wrote:
@@ -413,14 +414,37 @@ acpi_numa_memory_affinity_init(const str
Hi Rahul,
> On 23 Sep 2022, at 13:02, Rahul Singh wrote:
>
> Static event channel support is tech preview, which shall be documented
> in SUPPORT.md
>
> Signed-off-by: Rahul Singh
Reviewed-by: Bertrand Marquis
Cheers
Bertrand
> ---
> SUPPORT.md | 7 +++
> 1 file changed, 7
Hi,
> On 23 Sep 2022, at 13:02, Rahul Singh wrote:
>
> When ACPI is enabled and the system booted with ACPI, BUG() is observed
> after merging the static event channel series. As there is not DT when
> booted with ACPI there will be no chosen node because of that
> "BUG_ON(chosen == NULL)" will
On Fri, Sep 30, 2022 at 08:31:20AM +0200, Jan Beulich wrote:
> On 29.09.2022 18:25, Andrew Cooper wrote:
> > On 29/09/2022 17:22, osstest service owner wrote:
> >> flight 173362 xen-unstable-smoke real [real]
> >> http://logs.test-lab.xenproject.org/osstest/logs/173362/
> >>
> >> Regressions :-(
>
On Fri, Sep 30, 2022 at 10:36:20AM +0200, Jan Beulich wrote:
> On 30.09.2022 10:25, Roger Pau Monné wrote:
> > On Tue, Sep 27, 2022 at 06:20:35PM +0200, Jan Beulich wrote:
> >> SRAT may describe individual nodes using multiple ranges. When they're
> >> adjacent (with or without a gap in between),
On 30.09.2022 10:25, Roger Pau Monné wrote:
> On Tue, Sep 27, 2022 at 06:20:35PM +0200, Jan Beulich wrote:
>> SRAT may describe individual nodes using multiple ranges. When they're
>> adjacent (with or without a gap in between), only the start of the first
>> such range actually needs accounting
flight 173381 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173381/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-armhf 5
On Tue, Sep 27, 2022 at 06:20:35PM +0200, Jan Beulich wrote:
> SRAT may describe individual nodes using multiple ranges. When they're
> adjacent (with or without a gap in between), only the start of the first
> such range actually needs accounting for. Furthermore the very first
> range doesn't
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
higher priority than the type of the range. To avoid accessing memory at
runtime which was re-used for other purposes, make
efi_arch_process_memory_map() follow suit. While on x86 in theory the
same would apply to
Hi Jan,
> On 30 Sep 2022, at 08:27, Jan Beulich wrote:
>
> While an oversight in 9982fe275ba4 ("arm/vgic: drop const attribute
> from gic_iomem_deny_access()"), the issue really became apparent only
> when iomem_deny_access() was switched to have a non-const first
> parameter.
>
> Fixes:
flight 173378 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173378/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 173364
Tests which did
On 30/09/2022 08:27, Jan Beulich wrote:
>
>
> While an oversight in 9982fe275ba4 ("arm/vgic: drop const attribute
> from gic_iomem_deny_access()"), the issue really became apparent only
> when iomem_deny_access() was switched to have a non-const first
> parameter.
>
> Fixes: c4e5cc2ccc5b
flight 173382 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173382/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf broken
build-arm64-xsm 6
On 30.09.2022 01:02, Demi Marie Obenour wrote:
> Memory of type EFI_CONVENTIONAL_MEMORY, EFI_LOADER_CODE, EFI_LOADER_DATA,
> EFI_BOOT_SERVICES_CODE, and EFI_BOOT_SERVICES_DATA may be clobbered by
> Xen before Linux gets to start using it. Therefore, Linux under Xen
> must not use EFI tables from
On 29.09.2022 18:25, Andrew Cooper wrote:
> On 29/09/2022 17:22, osstest service owner wrote:
>> flight 173362 xen-unstable-smoke real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/173362/
>>
>> Regressions :-(
>>
>> Tests which did not succeed and are blocking,
>> including tests
While an oversight in 9982fe275ba4 ("arm/vgic: drop const attribute
from gic_iomem_deny_access()"), the issue really became apparent only
when iomem_deny_access() was switched to have a non-const first
parameter.
Fixes: c4e5cc2ccc5b ("x86/ept: limit calls to memory_type_changed()")
Reported-by:
On 30.09.2022 03:40, Wei Chen wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 2022年9月29日 20:21
>>
>> On 29.09.2022 10:21, Wei Chen wrote:
>>> On 2022/9/27 23:48, Jan Beulich wrote:
On 20.09.2022 11:12, Wei Chen wrote:
> --- a/xen/drivers/acpi/Kconfig
> +++
67 matches
Mail list logo
