On 2024-08-06 03:03, Stefano Stabellini wrote:
On Sat, 3 Aug 2024, Nicola Vetrini wrote:
On 2024-08-02 00:06, Stefano Stabellini wrote:
> The ECLAIR jobs part of the Gitlab CI pipeline fail reliably when the
> pipeline is started from a merge request. This is the error:
>
> Unexpected event pull
On 05.08.2024 23:09, Stewart Hildebrand wrote:
> In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
> structure") a lock moved from allocate_and_map_msi_pirq() to the caller
> and changed from pcidevs_lock() to read_lock(&d->pci_lock). However, one
> call path wasn't updated to
flight 187166 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187166/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 472be4d139b26c50949cf30eeb47640810e5ef2c
baseline version:
ovmf 1b37b3659b5098f764dee
flight 187165 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187165/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1b37b3659b5098f764dee5b893e4eb174949f40a
baseline version:
ovmf 51ada84cd57c5ef6c75a7
On Sat, 3 Aug 2024, Nicola Vetrini wrote:
> On 2024-08-02 00:06, Stefano Stabellini wrote:
> > The ECLAIR jobs part of the Gitlab CI pipeline fail reliably when the
> > pipeline is started from a merge request. This is the error:
> >
> > Unexpected event pull_request
> >
> > The error is a conseq
flight 187153 xen-4.19-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187153/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail REGR. vs. 187044
Tests which ar
flight 187162 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187162/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 51ada84cd57c5ef6c75a72aeb002226cf9180b21
baseline version:
ovmf 5d43165ff8596c2fa07b7
Hi Ayan,
On 05/08/2024 11:44, Ayan Kumar Halder wrote:
On 02/08/2024 14:27, Julien Grall wrote:
Hi,
Hi Julien,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
From: Penny Zheng
VMAP is widely used in ALTERNATIVE feature, CPUERRATA feature, etc to
remap a range of memory with new memory att
flight 187160 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187160/
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 Mon, 5 Aug 2024, Federico Serafini wrote:
> Tag more of the accepted guidelines as clean to avoid regressions.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
> ---
> automation/eclair_analysis/ECLAIR/tagging.ecl | 4
> 1 file changed, 4 insertions(+)
>
> diff --
On Mon, 5 Aug 2024, Federico Serafini wrote:
> To improve readability, sort guidelines with -V.
>
> No functional change.
Acked-by: Stefano Stabellini
> ---
> .../eclair_analysis/ECLAIR/monitored.ecl | 92 +--
> 1 file changed, 46 insertions(+), 46 deletions(-)
>
> diff -
In commit 4f78438b45e2 ("vpci: use per-domain PCI lock to protect vpci
structure") a lock moved from allocate_and_map_msi_pirq() to the caller
and changed from pcidevs_lock() to read_lock(&d->pci_lock). However, one
call path wasn't updated to reflect the change, leading to a failed
assertion obser
On Mon, 5 Aug 2024, Jan Beulich wrote:
> ... to please Misra C:2012 Rule 9.3 (Arrays shall not be partially
> initialized).
>
> Fixes: d81dd3130351 ("x86/shutdown: change default reboot method preference")
> Signed-off-by: Jan Beulich
Reviewed-by: Stefano Stabellini
> ---
> Cc-ing REST since
flight 187150 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187150/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 186827
test-arm64-arm64-xl
Hi,
On 05/08/2024 12:33, Oleksii Kurochko wrote:
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Remove stubs for process_shm_node() and early_print_info_shmem()
from $xen/arch/arm/include/asm/static-shmem.
On 05.08.2024 18:02, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-08-05 at 17:45 +0200, Jan Beulich wrote:
>> On 05.08.2024 17:13, oleksii.kuroc...@gmail.com wrote:
>>> On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> + }
> +
> + BUG_ON(pte_is_valid(*pte));
> +
On 05.08.2024 17:36, Matthew Barnes wrote:
> When hardware breakpoints are configured on misaligned IO ports, the
> hardware will mask the addresses based on the breakpoint width during
> comparison.
>
> For PV guests, misaligned IO breakpoints do not behave the same way, and
> therefore yield dif
On Mon, 2024-08-05 at 17:45 +0200, Jan Beulich wrote:
> On 05.08.2024 17:13, oleksii.kuroc...@gmail.com wrote:
> > On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> > > > + }
> > > > +
> > > > + BUG_ON(pte_is_valid(*pte));
> > > > +
> > > > + tmp = paddr_to_pte(LINK_TO_LOAD((unsigned
flight 187157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf 6 xen-buildfail REGR. vs. 187127
Tests which
On 05.08.2024 17:34, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-08-05 at 17:13 +0200, oleksii.kuroc...@gmail.com wrote:
>> On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
+ }
+
+ BUG_ON(pte_is_valid(*pte));
+
+ tmp = paddr_to_pte(LINK_TO_LOAD((unsigned
On 05.08.2024 17:13, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
>>> + }
>>> +
>>> + BUG_ON(pte_is_valid(*pte));
>>> +
>>> + tmp = paddr_to_pte(LINK_TO_LOAD((unsigned long)&xen_fixmap),
>>> PTE_TABLE);
>>
>> I'm a little puzzled by the use of L
On 02.08.2024 15:54, Oleksii Kurochko wrote:
> Enable GENERIC_BUG_FRAME to support BUG(), WARN(), ASSERT,
> and run_in_exception_handler().
>
> The 0x opcode is used for BUG_INSTR, which, when macros from
> are used, triggers an exception with the
> ILLEGAL_INSTRUCTION cause.
> This opcode is
When hardware breakpoints are configured on misaligned IO ports, the
hardware will mask the addresses based on the breakpoint width during
comparison.
For PV guests, misaligned IO breakpoints do not behave the same way, and
therefore yield different results.
This patch tweaks the emulation of IO
On Mon, 2024-08-05 at 17:13 +0200, oleksii.kuroc...@gmail.com wrote:
> On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> > > + }
> > > +
> > > + BUG_ON(pte_is_valid(*pte));
> > > +
> > > + tmp = paddr_to_pte(LINK_TO_LOAD((unsigned long)&xen_fixmap),
> > > PTE_TABLE);
> >
> > I'm a l
On Mon, 2024-07-29 at 15:35 +0200, Jan Beulich wrote:
> > + }
> > +
> > + BUG_ON(pte_is_valid(*pte));
> > +
> > + tmp = paddr_to_pte(LINK_TO_LOAD((unsigned long)&xen_fixmap),
> > PTE_TABLE);
>
> I'm a little puzzled by the use of LINK_TO_LOAD() (and LOAD_TO_LINK()
> a
> little further up)
Hi Stewart,
> On 2 Aug 2024, at 7:26 PM, Stewart Hildebrand
> wrote:
>
> Non-PCI platform devices may use the ITS. Dom0 Linux drivers for such
> devices are failing to register IRQs due to a missing #msi-cells
> property. Add the missing #msi-cells property.
>
> Signed-off-by: Stewart Hildebra
-LONG_MIN cannot be represented in a long and hence is UB, for being one
larger than LONG_MAX.
The caller passing an unsigned long and the 1st param also being (array
of) unsigned long, change the 2nd param accordingly while adding the
sole necessary cast. This was the original form of the functio
On 05.08.24 16:11, John E. Krokes wrote:
In "xl help", the output includes this line:
vsnd-list List virtual display devices for a domain
This should obviously say "sound devices" instead of "display devices".
Signed-off-by: John E. Krokes
Reviewed-by: Juergen Gross
Juergen
In "xl help", the output includes this line:
vsnd-list List virtual display devices for a domain
This should obviously say "sound devices" instead of "display devices".
Signed-off-by: John E. Krokes
---
tools/xl/xl_cmdtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
On Mon, 5 Aug 2024, Jan Beulich wrote:
On 04.08.2024 15:18, John E. Krokes wrote:
Here's a simple and obvious mistake:
~> xl help | grep vsnd
vsnd-attach Create a new virtual sound device
vsnd-list List virtual display devices for a domain
vsnd-detach Destroy a
For widening and narrowing moves, operand (vector) size is calculated
from a table. This calculation, for the AVX512 cases, lives ahead of
validation of EVEX.L'L (which cannot be 3 without raising #UD). Account
for the later checking by adjusting the constants in the expression such
that even EVEX.
LAR, LSL, VERR, and VERW emulation involve calling protmode_load_seg()
with x86_seg_none. The fuzzer's read_segment() hook function has an
assertion which triggers in this case. Calling the hook function,
however, makes little sense for those insns, as there's no data to
retrieve. Instead zero-fill
On 05/08/2024 14:45, Ayan Kumar Halder wrote:
>
> On 05/08/2024 10:46, Michal Orzel wrote:
>> Hi Ayan,
> Hi Michal,
>>
>> On 02/08/2024 11:46, Ayan Kumar Halder wrote:
>>> The FUSA folder is expected to contain requirements and other documents
>>> to enable safety certification of Xen hyperviso
flight 187154 xen-unstable-smoke real [real]
flight 187155 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187154/
http://logs.test-lab.xenproject.org/osstest/logs/187155/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
flight 187149 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187149/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187140
test-amd64-amd64-xl-qemut-win7-amd64
On 05/08/2024 10:46, Michal Orzel wrote:
Hi Ayan,
Hi Michal,
On 02/08/2024 11:46, Ayan Kumar Halder wrote:
The FUSA folder is expected to contain requirements and other documents
to enable safety certification of Xen hypervisor.
Added a README to explain how the requirements are categorized
On 05.08.2024 13:33, Oleksii Kurochko wrote:
> From: Shawn Anastasio
>
> Arm's setup.c contains a collection of functions for parsing memory map
> and other boot information from a device tree. Since these routines are
> generally useful on any architecture that supports device tree booting,
> mo
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Remove stubs for process_shm_node() and early_print_info_shmem()
from $xen/arch/arm/include/asm/static-shmem.h.
These stubs are removed to avoid introducing them
The current patch series introduces the common device tree functions
between several architectures: Arm, PPC, RISC-V.
Originally these patches were a part of Shawn's patch series [1].
At that moment it was v4 version of this patches.
After RISC-V started to need this changes these patches have be
On 02/08/2024 14:33, Julien Grall wrote:
Hi,
Hi Julien,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
Moved init_domheap_mappings(), map_domain_page_global(),
unmap_domain_page_global(), map_domain_page(), unmap_domain_page(),
domain_page_map_to_mfn() to MMU specific folder.
On the top lev
31.07.24 15:29, Jan Beulich:
@@ -326,14 +328,14 @@ static inline void __core2_vpmu_load(struct vcpu *v)
if ( vpmu_is_set(vcpu_vpmu(v), VPMU_CPU_HAS_DS) )
wrmsrl(MSR_IA32_DS_AREA, core2_vpmu_cxt->ds_area);
-if ( !is_hvm_vcpu(v) )
+if ( !is_vmx_vcpu(v) )
{
01.08.24 14:39, Jan Beulich:
On 30.07.2024 12:41, Sergiy Kibrik wrote:
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -123,11 +123,25 @@ config HVM
If unsure, say Y.
config AMD_SVM
- def_bool HVM
+ bool "AMD-V" if EXPERT
+ depends on HVM
+ defaul
31.07.24 15:39, Jan Beulich:
[..]
---
changes in v5:
- introduce ARCH_IOREQ_COMPLETION option & put arch_vcpu_ioreq_completion()
under it
- description changed
I'm worried by this naming inconsistency: We also have
arch_ioreq_complete_mmio(),
and who know what else we'll gain. I think the
On 02.08.2024 13:12, Roger Pau Monne wrote:
> @@ -1907,16 +1890,26 @@ void asmlinkage __init noreturn __start_xen(unsigned
> long mbi_p)
> if ( cpu_has_smep && opt_smep != SMEP_HVM_ONLY )
> setup_force_cpu_cap(X86_FEATURE_XEN_SMEP);
> if ( boot_cpu_has(X86_FEATURE_XEN_SMEP) )
>
On 02/08/2024 14:27, Julien Grall wrote:
Hi,
Hi Julien,
On 02/08/2024 13:14, Ayan Kumar Halder wrote:
From: Penny Zheng
VMAP is widely used in ALTERNATIVE feature, CPUERRATA feature, etc to
remap a range of memory with new memory attributes. Since this is
highly dependent on virtual addre
... to please Misra C:2012 Rule 9.3 (Arrays shall not be partially
initialized).
Fixes: d81dd3130351 ("x86/shutdown: change default reboot method preference")
Signed-off-by: Jan Beulich
---
Cc-ing REST since the two other x86 maintainers are away, yet the CI will
want fixing.
--- a/xen/arch/x86/
On 05/08/2024 11:04, oleksii.kuroc...@gmail.com wrote:
Hi Julien,
Hi Oleksii,
On Mon, 2024-08-05 at 10:31 +0100, Julien Grall wrote:
Hi Oleksii,
On 24/07/2024 16:31, Oleksii Kurochko wrote:
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
devic
On 05/08/2024 10:44, oleksii.kuroc...@gmail.com wrote:
[...]
--- /dev/null
+++ b/xen/common/device-tree/bootinfo.c
@@ -0,0 +1,459 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+/*
+ * Derived from $xen/arch/arm/setup.c.
I would suggest to mention the version of Xen this is derived fr
Hi Julien,
On Mon, 2024-08-05 at 10:31 +0100, Julien Grall wrote:
> Hi Oleksii,
>
> On 24/07/2024 16:31, Oleksii Kurochko wrote:
> > From: Shawn Anastasio
> >
> > Move Arm's bootfdt.c to xen/common so that it can be used by other
> > device tree architectures like PPC and RISCV.
> >
> > Sugges
On 02.08.2024 12:56, Roger Pau Monne wrote:
> @@ -492,6 +494,15 @@ static const struct dmi_system_id __initconstrel
> reboot_dmi_table[] = {
> DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge R740")),
> },
> +{/* Handle problem
Hi Ayan,
On 02/08/2024 11:46, Ayan Kumar Halder wrote:
> The FUSA folder is expected to contain requirements and other documents
> to enable safety certification of Xen hypervisor.
> Added a README to explain how the requirements are categorized, written
> and their supported status.
>
> Added ma
Hi Julien,
On Mon, 2024-08-05 at 10:08 +0100, Julien Grall wrote:
> Hi,
>
> On 24/07/2024 16:31, Oleksii Kurochko wrote:
> > Changes in V5:
> > - add xen/include/xen/bootfdt.h to MAINTAINERS file.
> > - drop message "Early device tree parsing and".
> > - After rebase on top of the current s
Tag more of the accepted guidelines as clean to avoid regressions.
Signed-off-by: Federico Serafini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 4
1 file changed, 4 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
b/automation/eclair_analysis/ECLAIR/tagging
To improve readability, sort guidelines with -V.
No functional change.
---
.../eclair_analysis/ECLAIR/monitored.ecl | 92 +--
1 file changed, 46 insertions(+), 46 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/monitored.ecl
b/automation/eclair_analysis/ECLAIR/m
Sort -v monitored guidelines and tag more guidelines as clean.
Federico Serafini (2):
automation/eclair: sort monitored guidelines with -V
automation/eclair: tag more guidelines as clean
.../eclair_analysis/ECLAIR/monitored.ecl | 92 +--
automation/eclair_analysis/ECLAIR
flight 187152 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187152/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5d43165ff8596c2fa07b7d4de3c482d64338ca99
baseline version:
ovmf 68b4c4b481f3129132cd9
Hi Oleksii,
On 24/07/2024 16:31, Oleksii Kurochko wrote:
From: Shawn Anastasio
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
On Matrix you a
On Mon, 2024-08-05 at 08:20 +0200, Jan Beulich wrote:
> On 02.08.2024 15:54, Oleksii Kurochko wrote:
> > Use array_access_nospec() to prevent guest speculation.
> >
> > Avoid double access of trap_causes[cause].
> >
> > Suggested-by: Jan Beulich
> > Signed-off-by: Oleksii Kurochko
>
> Reviewed
Hi,
On 24/07/2024 16:31, Oleksii Kurochko wrote:
Changes in V5:
- add xen/include/xen/bootfdt.h to MAINTAINERS file.
- drop message "Early device tree parsing and".
- After rebase on top of the current staging the following changes were done:
- init bootinfo variable in with
BOOTINFO
flight 187148 xen-4.19-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187148/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stop fail REGR. vs. 187044
Tests which ar
On 05.08.2024 09:52, Juergen Gross wrote:
> On 05.08.24 08:01, Jan Beulich wrote:
>> On 04.08.2024 15:17, A Kundu wrote:
>>> On 8/2/24 13:25, Jan Beulich wrote:
>>> > On 02.08.2024 09:28, A Kundu wrote:
>>> >> On 8/2/24 09:06, Baoquan He wrote:
>>> >>> On 07/31/24 at 06:34pm, A Kundu wrote:
>
On 30.07.24 06:02, A Kundu wrote:
I am experiencing issues using kexec to load Xen 4.19-rc4 and
4.20-dev on a debian host.
The current documentation at
https://xenbits.xenproject.org/docs/4.19-testing/misc/kexec_and_kdump.txt
appears to be missing crucial details on properly using kexec
with the
flight 187151 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187151/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 68b4c4b481f3129132cd90c45d241990445f4a3a
baseline version:
ovmf 5ff99e0dabefea14b04e1
On 05.08.24 08:01, Jan Beulich wrote:
On 04.08.2024 15:17, A Kundu wrote:
On 8/2/24 13:25, Jan Beulich wrote:
> On 02.08.2024 09:28, A Kundu wrote:
>> On 8/2/24 09:06, Baoquan He wrote:
>>> On 07/31/24 at 06:34pm, A Kundu wrote:
I am experiencing issues using kexec to load Xen 4.17(
64 matches
Mail list logo
