flight 173390 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173390/
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
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 that
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 30,
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 2
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 at
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
db0340c8e2628314226c6
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 at
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 Ma
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,
> > > EFI_BOOT_SERVIC
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, EFI_LOADER_
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 ESRT
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 L
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 1
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 cert
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 EFI_BOOT_SERV
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 u
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 i
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 it.
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
$dyn
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, co
> 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:
>> https://github.com/edwinto
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 6
> 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() fol
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 i
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 p
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 interr
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 de
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
>> efi_ar
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 x8
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() foll
> 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 suit
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 & ACPI_SRAT_MEM_HOT_PLUG
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
> resu
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
> highe
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)" : "");
>
> - node_me
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 nee
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 cont
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 blocki
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 succee
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
> > statist
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
test-amd64-amd64-
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]
http://logs.test-lab.xenproject.org/oss
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 insertions(+)
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), o
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 fo
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 host-build-pre
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 nee
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 EfiACPIRecla
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: c4e5cc
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 not
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 ("x8
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 xen
64 matches
Mail list logo
