On 12.11.2025 19:54, Andrew Cooper wrote:
> There's a lot of stale information in the current checklists. Merge the
> documents and present the information in chronological order. Provide real
> examples from the tree rather than trying to be too prescriptive.
>
> Signed-off-by: Andrew Cooper
On 12.11.2025 17:22, Alejandro Vallejo wrote:
> Hi,
>
> The series is mostly a refactor between everything needed to load microcode
> and
> the bare minimum to probe the current microcode revision.
>
> The Kconfig option keeps the reading of microcode rev data around, as it's
> very
> relevant
On 12.11.2025 21:25, Grygorii Strashko wrote:
> Could it be merged if no other comments, please?
It's on my list of things to put in. However, since you ask: You do realize that
all your recent postings were while the tree was frozen? That's okay-ish, but
when preparing a release people would pref
On 12.11.2025 18:43, Grygorii Strashko wrote:
> On 12.11.25 15:07, Jan Beulich wrote:
>> On 12.11.2025 12:27, Grygorii Strashko wrote:
>>> On 12.11.25 08:38, Jan Beulich wrote:
On 11.11.2025 18:52, Grygorii Strashko wrote:
> On 10.11.25 09:11, Jan Beulich wrote:
>> On 07.11.2025 19:17,
On 12.11.25 22:13, Elliott Mitchell wrote:
A few times there have been mentions of a need to choose between boot
methods for DomUs. There is a need to decide on ones to recommend and
put effort into supportting. I may not have tried that many nor done
particularly great amounts of experimentati
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, October 30, 2025 8:44 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; [email protected]; Stefano
> Stabellini ; Julien Grall ; Bertrand
> Marquis ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERARD
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Wednesday, November 12, 2025 6:02 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; [email protected]; Stefano
> Stabellini ; Julien Grall ; Bertrand
> Marquis ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERA
Feature memory access is based on vm event subsystem, and it could be disabled
in the future. So a few switch-blocks in do_altp2m_op() need
IS_ENABLED(CONFIG_VM_EVENT) wrapping to pass compilation when ALTP2M=y and
VM_EVENT=n(, hence MEM_ACCESS=n), like HVMOP_altp2m_set_mem_access, etc.
Function p2
This patch serie originates from "Disable domctl-op via CONFIG_MGMT_HYPERCALLS"
[1], and focuses on consolidating vm event subsystem (i.e. VM_EVENT), and its
derived features, like memory paging, etc.
[1] https://www.mail-archive.com/[email protected]/msg200843.html
Penny Zheng (7):
File hvm/vm_event.c and x86/vm_event.c are the extend to vm_event handling
routines, and its compilation shall be guarded by CONFIG_VM_EVENT too.
Although CONFIG_VM_EVENT is right now forcibly enabled on x86 via
MEM_ACCESS_ALWAYS_ON, we could disable it through disabling
CONFIG_MGMT_HYPERCALLS lat
Memory access and ALTP2M are two seperate features, while both depending on
helper xenmem_access_to_p2m_access(). So it betters lives in common p2m.c,
other than mem_access.c which will be compiled out when VM_EVENT=n && ALTP2M=y.
Coding style has been corrected at the same time.
Signed-off-by: Pe
Memory access and ALTP2M are two seperate features, and each could be
controlled via VM_EVENT or ALTP2M. In order to avoid implicit declaration
when ALTP2M=y and VM_EVENT=n on compiling hvm.o/altp2m.o, we move declaration
of the following functions from to :
- p2m_set_suppress_ve
- p2m_set_suppres
Feature monitor_op is based on vm event subsystem, so monitor.o shall be
wrapped under CONFIG_VM_EVENT.
The following functions are only invoked by monitor-op, so they all shall be
wrapped with CONFIG_VM_EVENT (otherwise they will become unreachable and
violate Misra rule 2.1 when VM_EVENT=n):
- hv
struct cpuinfo_x86
.x86=> .family
.x86_vendor => .vendor
.x86_model => .model
.x86_mask => .stepping
No functional change.
---
xen/arch/x86/cpu/intel.c| 32 +
xen/arch/x86/include/asm/intel-family.h | 4
2 files changed, 21 insertio
A few times there have been mentions of a need to choose between boot
methods for DomUs. There is a need to decide on ones to recommend and
put effort into supportting. I may not have tried that many nor done
particularly great amounts of experimentation, but I do have some
experience with multip
Hi
Could it be merged if no other comments, please?
On 24.09.25 13:14, Grygorii Strashko wrote:
From: Grygorii Strashko
Since commit b99227347230 ("x86: Fix AMD_SVM and INTEL_VMX dependency") the
HVM Intel VT-x support can be disabled, but it still keeps VMX
code partially built-in. Particula
From: Grygorii Strashko
The VMTRACE feature is depends on Platform/Arch HW and code support and now
can be used only on x86 HVM with Intel VT-x (INTEL_VMX) enabled.
This makes VMTRACE support optional by introducing HVM Kconfig option:
- CONFIG_VMTRACE to enable/disable the feature.
Signed-off-b
There's a lot of stale information in the current checklists. Merge the
documents and present the information in chronological order. Provide real
examples from the tree rather than trying to be too prescriptive.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beu
On 12.11.25 15:07, Jan Beulich wrote:
On 12.11.2025 12:27, Grygorii Strashko wrote:
On 12.11.25 08:38, Jan Beulich wrote:
On 11.11.2025 18:52, Grygorii Strashko wrote:
On 10.11.25 09:11, Jan Beulich wrote:
On 07.11.2025 19:17, Grygorii Strashko wrote:
--- a/xen/arch/x86/include/asm/gues
On 12.11.25 19:21, Alejandro Vallejo wrote:
On Wed Nov 12, 2025 at 4:56 PM CET, Grygorii Strashko wrote:
On 12.11.25 17:22, Alejandro Vallejo wrote:
They are unnecessary. The only two cases with link-time failures are
fallback else branches that can just as well be adjusted with explicit
I
On Wed Nov 12, 2025 at 4:56 PM CET, Grygorii Strashko wrote:
>
>
> On 12.11.25 17:22, Alejandro Vallejo wrote:
>> They are unnecessary. The only two cases with link-time failures are
>> fallback else branches that can just as well be adjusted with explicit
>> IS_ENABLED(CONFIG_PV). HVM has no equiv
Don't unnecessarily negate 'buffer' and simplify the return statement.
Reviewed-by: Jason Andryuk
Signed-off-by: Thorsten Blum
---
drivers/xen/xenbus/xenbus_xs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
i
On 12.11.25 16:27, Alejandro Vallejo wrote:
On Wed Nov 12, 2025 at 7:40 AM CET, Jan Beulich wrote:
On 11.11.2025 19:25, Grygorii Strashko wrote:
On 06.11.25 15:47, Jan Beulich wrote:
On 06.11.2025 14:42, Grygorii Strashko wrote:
On 06.11.25 13:35, Jan Beulich wrote:
On 31.10.2025 17:17, G
Keeps around the microcode revision reading logic, as that's security
sensitive to detect out-of-date patforms and report them.
Move cpu_sig to base.c, because that's externally visible symbol outside
the microcode subsystem and we need it always accesible.
Signed-off-by: Alejandro Vallejo
---
Some code must be executed even with microcode loading disabled to find
out the current microcode revision. This is important to determine active
erratas and such.
With the intent of stripping microcode loading via Kconfig, move such
essential AMD-specific code to an amd-base.c file.
Not a functi
A later patch compiles out most of the microcode loading code by removing
core.c from the Makefile based on Kconfig. These functions are important
to set up the ucode_op to read the microcode revision and report it on
every CPU.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
xen/
Some code must be executed even with microcode loading disabled to find
out the current microcode revision. This is important to determine active
erratas and such.
With the intent of stripping microcode loading via Kconfig, move such
essential Intel-specific code to an intel-base.c file.
Not a fu
Hi,
The series is mostly a refactor between everything needed to load microcode and
the bare minimum to probe the current microcode revision.
The Kconfig option keeps the reading of microcode rev data around, as it's very
relevant for security and debuggability in order to deduce which erratas ap
Hi Michal,
>>> +void __init setup_mm(void)
>>> +{
>>> +const struct membanks *banks = bootinfo_get_mem();
>>> +paddr_t ram_start = INVALID_PADDR;
>>> +paddr_t ram_end = 0;
>>> +paddr_t ram_size = 0;
>>> +unsigned int i;
>>> +
>>> +init_pdx();
>>> +
>>> +for ( i = 0; i <
On 12.11.2025 16:56, Grygorii Strashko wrote:
> On 12.11.25 17:22, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -571,15 +571,17 @@ int arch_vcpu_create(struct vcpu *v)
>>
>> if ( is_hvm_domain(d) )
>> rc = hvm_vcpu_initialise(v);
>>
On 12/11/2025 3:43 pm, Jan Beulich wrote:
> Much like done later in the function, syscall and hypercall vectors can
> have their bits set without use of LOCKed accesses.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 12/11/2025 3:39 pm, Jan Beulich wrote:
> This option is only relevant for C ones.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Hi,
On 11/11/2025 22:05, Oleksandr Tyshchenko wrote:
Introduce a new Arm-specific DOMU_TRAP_UNMAP parameter that allows
configuring how Xen handles domain accesses to unmapped address ranges.
This parameter corresponds to the "trap-unmapped-accesses" device tree
property.
Signed-off-by: Oleksan
On 12.11.25 17:22, Alejandro Vallejo wrote:
They are unnecessary. The only two cases with link-time failures are
fallback else branches that can just as well be adjusted with explicit
IS_ENABLED(CONFIG_PV). HVM has no equivalent stubs and there's no reason
to keep the asymmetry.
No functional
cpumask_var_t can resolve to a pointer or to an array. While the pointer
typically is allocated once for a CPU and then only read (i.e. wants to be
marked read-mostly), the same isn't necessarily true for the array case.
There things depend on how the variable is actually used. cpu_core_mask
and cp
Le 12/11/2025 à 16:25, Alejandro Vallejo a écrit :
> A couple of branches rely on PV being the "else" branch, making it
> be compiled even when PV support is not itself compiled-in.
>
> Add a explicit conditional on CONFIG_PV in those cases to remove the
> code in !CONFIG_PV builds.
>
> Not a funct
On 12/11/2025 12:40, Orzel, Michal wrote:
On 11/11/2025 11:15, Harry Ramsey wrote:
Implement `setup_mm` for MPU systems. This variant does not require
setting up a direct map.
To reduce code duplication the common initalisation code for both MPU
and MMU Arm64 configurations is refactored int
On 11/10/25 10:37, Frediano Ziglio wrote:
> From: Frediano Ziglio
>
> For xen.gz file we strip all symbols and have an additional
> xen-syms.efi file
Can you add xen/xen-syms.efi to .gitignore please? Or perhaps change the
existing xen/xen-syms.map to xen/xen-syms.* ?
The types are local to the shadow and HAP subsystems respectively, and
HAP has no need for the shadow-specific fields (i.e. it can get away with
smaller allocations). In struct hvm_domain it therefore suffices to have
a union of two (generally opaque) pointers.
Signed-off-by: Jan Beulich
--- a/x
It's really FIRST_IRQ_VECTOR vector which is meant here, i.e. effectively
there is a form of open-coding in use right now.
No change in practice, due to the present aliasing.
Signed-off-by: Jan Beulich
---
While doing the HPET work I had to fiddle with this, even if in the end
no vector below FI
Much like done later in the function, syscall and hypercall vectors can
have their bits set without use of LOCKed accesses.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/irq.c
+++ b/xen/arch/x86/irq.c
@@ -450,12 +450,12 @@ int __init init_irq_data(void)
#ifdef CONFIG_PV
/* Never allocate
This option is only relevant for C ones.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Rules.mk
+++ b/xen/arch/x86/Rules.mk
@@ -7,4 +7,4 @@ else
object_label_flags = '-D__OBJECT_LABEL__=$(subst /,$$,$(subst -,_,$@))'
endif
c_flags += $(object_label_flags) $(CFLAGS_stack_boundary)
-a_flags +=
This NR_CPUS-dimensioned array is likely unused on most installations.
Therefore it is especially wasteful for it to consume more space than
really needed. Use the smallest possible type.
Further the array having all fields set to -1 is actually useless. Nothing
relies on it, and core_parking_remo
When updating a DTE, amd_iommu_setup_domain_device() would check if
the update had been non-atomic (i.e rc > 0) and throw a warning if
such non-atomic update could be dangerous. However since commit
3fc44151d83d, rc can no longer be positive, making this branch
unreachable code.
No functional cha
amd_iommu_set_root_page_table chooses between updating atomically
and non-atomically depending on whether the DTE is active or not.
This choice existed mostly because cx16 wasn't supposed always available
until [1]. Thus we don't need to threat the non-atomic path in a special
way anymore.
By rea
Various simplifications (redundant logic merging and dead code removal)
with no expected impact on effective behavior.
Teddy Astie (2):
amd/iommu: Always atomically update DTE
amd/iommu: Remove dead non-atomic update checking
xen/drivers/passthrough/amd/iommu_map.c | 78 +++--
On 12/11/2025 3:00 pm, Jan Beulich wrote:
> Many *.c files are symlinked while building, so along with generated *.h
> files they ought to be removed. Conversely $(TARGET) doesn't need removing
> twice.
>
> Fixes: cb4fcf70b2f3 ("x86emul: parallelize SIMD test code building")
> Signed-off-by: Jan Be
They are unnecessary. The only two cases with link-time failures are
fallback else branches that can just as well be adjusted with explicit
IS_ENABLED(CONFIG_PV). HVM has no equivalent stubs and there's no reason
to keep the asymmetry.
No functional change.
Signed-off-by: Alejandro Vallejo
---
I
General cleanup, with marginal binary size reduction in the !CONFIG_PV case.
Some PV-only code remains in the build when !CONFIG_PV because it's in fallback
else branches and there's a number of stubs in asm/pv/domain.h that are either
irrelevant or can be made irrelevant through trivial changes t
A couple of branches rely on PV being the "else" branch, making it
be compiled even when PV support is not itself compiled-in.
Add a explicit conditional on CONFIG_PV in those cases to remove the
code in !CONFIG_PV builds.
Not a functional change.
Signed-off-by: Alejandro Vallejo
---
xen/arch/
Many *.c files are symlinked while building, so along with generated *.h
files they ought to be removed. Conversely $(TARGET) doesn't need removing
twice.
Fixes: cb4fcf70b2f3 ("x86emul: parallelize SIMD test code building")
Signed-off-by: Jan Beulich
--- a/tools/tests/x86_emulator/Makefile
+++ b
On 12.11.2025 15:21, Frediano Ziglio wrote:
> On Mon, 10 Nov 2025 at 16:01, Jan Beulich wrote:
>>
>> On 10.11.2025 16:35, Frediano Ziglio wrote:
>>> From: Frediano Ziglio
>>>
>>> For xen.gz file we strip all symbols and have an additional
>>> xen-syms.efi file version with all symbols.
>>> Make x
Introduce a new option to start the BSP vCPU in x2APIC mode instead
of xAPIC mode. Expose this in xl through a new "x2apic_mode" option.
Signed-off-by: Teddy Astie
---
Cc: Andrew Cooper
Cc: Jan Beulich
Cc: Alejandro Vallejo
Cc: Grygorii Strashko
Later on, we could consider with this option t
On Wed Nov 12, 2025 at 7:40 AM CET, Jan Beulich wrote:
> On 11.11.2025 19:25, Grygorii Strashko wrote:
>> On 06.11.25 15:47, Jan Beulich wrote:
>>> On 06.11.2025 14:42, Grygorii Strashko wrote:
On 06.11.25 13:35, Jan Beulich wrote:
> On 31.10.2025 17:17, Grygorii Strashko wrote:
>> ---
On Wed Nov 12, 2025 at 11:58 AM CET, Teddy Astie wrote:
> Le 11/11/2025 à 18:55, Grygorii Strashko a écrit :
>> From: Grygorii Strashko
>>
>> Hi
>>
>> This series introduces possibility to disable 32-bit (COMPAT) interface
>> support
>> in the following cases:
>>- Only PVH domains are u
On Mon, 10 Nov 2025 at 16:01, Jan Beulich wrote:
>
> On 10.11.2025 16:35, Frediano Ziglio wrote:
> > From: Frediano Ziglio
> >
> > For xen.gz file we strip all symbols and have an additional
> > xen-syms.efi file version with all symbols.
> > Make xen.efi more coherent stripping all symbols too.
I don't really mind either way, but I don't see an immediate use for [C]
and [D] - the idea is that the paused section is short and controlled,
not made up of arbitrary calls.
If my thinking above is correct, then I've already demonstrated that this is not
the case. So I'd be inclined to go w
On 12.11.2025 12:27, Grygorii Strashko wrote:
>
>
> On 12.11.25 08:38, Jan Beulich wrote:
>> On 11.11.2025 18:52, Grygorii Strashko wrote:
>>> On 10.11.25 09:11, Jan Beulich wrote:
On 07.11.2025 19:17, Grygorii Strashko wrote:
> --- a/xen/arch/x86/include/asm/guest_access.h
> +++ b/x
On 11/11/2025 11:15, Harry Ramsey wrote:
> Implement `setup_mm` for MPU systems. This variant does not require
> setting up a direct map.
>
> To reduce code duplication the common initalisation code for both MPU
> and MMU Arm64 configurations is refactored into `setup_mm`. Platform-specific
> s
On 20.10.2025 17:58, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -20,6 +20,16 @@
>
> #define P2M_SUPPORTED_LEVEL_MAPPING 2
>
> +/*
> + * P2M PTE context is used only when a PTE's P2M type is p2m_ext_storage.
> + * In this case, the P2M type is stored
On 12.11.25 08:38, Jan Beulich wrote:
On 11.11.2025 18:52, Grygorii Strashko wrote:
On 10.11.25 09:11, Jan Beulich wrote:
On 07.11.2025 19:17, Grygorii Strashko wrote:
--- a/xen/arch/x86/include/asm/guest_access.h
+++ b/xen/arch/x86/include/asm/guest_access.h
@@ -13,26 +13,64 @@
#include
> On 12 Nov 2025, at 09:50, Dmytro Prokopchuk1
> wrote:
>
> Remove the redundant local 'DTB_MAGIC' definition and replace its usage
> with the canonical 'FDT_MAGIC' from 'libfdt'.
>
> Amends: 66edeb2e3972 (arm: copy DTB appended to zImage)
> Signed-off-by: Dmytro Prokopchuk
> ---
You can re
On 12/11/2025 10:35 am, Teddy Astie wrote:
> Le 29/10/2025 à 19:26, Teddy Astie a écrit :
>> Introduce a new flag to force the x2APIC enabled and preventing a
>> guest from switching back LAPIC to xAPIC mode.
>>
>> The semantics of this mode are based IA32_XAPIC_DISABLE_STATUS
>> architectural MSR
Le 11/11/2025 à 21:11, Grygorii Strashko a écrit :
> From: Grygorii Strashko
>
> Functions:
> hvm_shadow_handle_cd()
> hvm_set_uc_mode()
> domain_exit_uc_mode()
> are used only by Intel VMX code, so move them to VMX code.
>
> While here:
> - minor format change in domain_exit_uc_mode()
> - s
Le 11/11/2025 à 18:55, Grygorii Strashko a écrit :
> From: Grygorii Strashko
>
> Hi
>
> This series introduces possibility to disable 32-bit (COMPAT) interface
> support
> in the following cases:
>- Only PVH domains are used
I assume this one is mostly due to hvmloader being today runnin
On 12.11.2025 11:52, Teddy Astie wrote:
> Le 11/11/2025 à 21:11, Grygorii Strashko a écrit :
>> @@ -1451,6 +1452,66 @@ static int cf_check vmx_get_guest_pat(struct vcpu *v,
>> u64 *gpat)
>> return 1;
>> }
>>
>> +/* Exit UC mode only if all VCPUs agree on MTRR/PAT and are not in no_fill.
With CPU hotplug sysctls implemented on Arm it becomes useful to have a
tool for calling them. Introduce a new congifure option "hptool" to
allow building hptool separately from other migration tools, and enable
it by default.
Signed-off-by: Mykyta Poturai
v3->v4:
* no changes
v2->v3:
* no chan
This series implements support for CPU hotplug/unplug on Arm. To achieve this,
several things need to be done:
1. XEN_SYSCTL_CPU_HOTPLUG_* calls implemented.
2. timer and GIC maintenance interrupts switched to static irqactions to remove
the need for freeing them during release_irq.
3. Enabled the
When stopping a core deinit_timer_interrupt is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
Signed-off-by: Mykyta Poturai
Reviewed-by: Mykola Kvach
Reviewe
Implement XEN_SYSCTL_CPU_HOTPLUG_{ONLINE,OFFLINE} calls to allow for
enabling/disabling CPU cores in runtime.
For now this operations only support Arm64. For proper Arm32 support,
there needs to be a mechanism to free per-cpu page tables, allocated in
init_domheap_mappings.
Also, hotplug is not su
Signed-off-by: Mykyta Poturai
v3->v4:
* update configuration section
v2->v3:
* patch introduced
---
docs/misc/cpu-hotplug.txt | 51 +++
1 file changed, 51 insertions(+)
create mode 100644 docs/misc/cpu-hotplug.txt
diff --git a/docs/misc/cpu-hotplug.txt b/do
When stopping a core cpu_gic_callback is called in non-alloc
context, which causes xfree in release_irq to fail an assert.
To fix this, switch to a statically allocated irqaction that does not
need to be freed in release_irq.
Signed-off-by: Mykyta Poturai
Reviewed-by: Mykola Kvach
Reviewed-by:
This will reduce code duplication for the upcoming cpu hotplug support
on Arm64 patch.
SMT-disable enforcement check is moved into a separate
architecture-specific function.
Signed-off-by: Mykyta Poturai
v3->v4:
* patch introduced
---
xen/arch/arm/smp.c | 6 ++
xen/arch/ppc/st
Move IRQs from dying CPU to the online ones.
Guest-bound IRQs are already handled by scheduler in the process of
moving vCPUs to active pCPUs, so we only need to handle IRQs used by Xen
itself.
If IRQ is to be migrated, it's affinity is set to a mask of all online
CPUs. With current GIC implementa
Currently on Arm the desc->affinity mask of an irq is never updated,
which makes it hard to know the actual affinity of an interrupt.
Fix this by updating the field in irq_set_affinity.
Signed-off-by: Mykyta Poturai
v3->v4:
* patch introduced
---
xen/arch/arm/irq.c | 3 +++
1 file changed, 3 i
On 11/11/2025 17:03, Ryan Roberts wrote:
> On 11/11/2025 15:56, Kevin Brodsky wrote:
>> On 11/11/2025 10:24, Ryan Roberts wrote:
>>> [...]
>>>
>> +state->active = true;
>> +arch_enter_lazy_mmu_mode();
>> +}
>> }
>>
>> static inline
Le 29/10/2025 à 19:26, Teddy Astie a écrit :
> Introduce a new flag to force the x2APIC enabled and preventing a
> guest from switching back LAPIC to xAPIC mode.
>
> The semantics of this mode are based IA32_XAPIC_DISABLE_STATUS
> architectural MSR of Intel specification.
>
> Signed-off-by: Teddy A
On 12.11.25 08:50, Jan Beulich wrote:
On 11.11.2025 18:54, Grygorii Strashko wrote:
This series introduces possibility to disable 32-bit (COMPAT) interface support
in the following cases:
The use of plural here ...
should be "case"
- Only PVH domains are used
- Guests (O
On 12.11.2025 09:58, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, October 30, 2025 8:44 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; [email protected]; Stefano
>> Stabellini ; Julien Grall ; Bertrand
>> Marquis ; Orzel, Michal ;
>>
Remove the redundant local 'DTB_MAGIC' definition and replace its usage
with the canonical 'FDT_MAGIC' from 'libfdt'.
Amends: 66edeb2e3972 (arm: copy DTB appended to zImage)
Signed-off-by: Dmytro Prokopchuk
---
Changes in v2:
- "Fixes" tag was replaced with "Amends"
Link to v1:
https://patchew.o
On 11/12/25 10:27, Jan Beulich wrote:
> On 12.11.2025 09:15, Orzel, Michal wrote:
>> On 12/11/2025 08:47, Luca Fancellu wrote:
On 12 Nov 2025, at 07:08, Dmytro Prokopchuk1
wrote:
Remove the redundant local 'DTB_MAGIC' definition and replace its usage
with the canonical
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Thursday, October 30, 2025 8:44 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; [email protected]; Stefano
> Stabellini ; Julien Grall ; Bertrand
> Marquis ; Orzel, Michal ;
> Volodymyr Babchuk ; Andrew Cooper
> ; Anthony PERARD
Hi Dmytro,
> On 31 Oct 2025, at 16:02, Dmytro Prokopchuk1
> wrote:
>
> The current implementation of 'free_init_memory()' fills the freed '__init'
> and '__initdata' memory regions with a faulting instruction before unmapping
> and returning them to the heap. However, after unmapping, any acces
On 12.11.2025 09:15, Orzel, Michal wrote:
> On 12/11/2025 08:47, Luca Fancellu wrote:
>>> On 12 Nov 2025, at 07:08, Dmytro Prokopchuk1
>>> wrote:
>>>
>>> Remove the redundant local 'DTB_MAGIC' definition and replace its usage
>>> with the canonical 'FDT_MAGIC' from 'libfdt'.
>>>
>>> Fixes: 66edeb
On 12/11/2025 08:47, Luca Fancellu wrote:
> Hi Dmytro,
>
>> On 12 Nov 2025, at 07:08, Dmytro Prokopchuk1
>> wrote:
>>
>> Remove the redundant local 'DTB_MAGIC' definition and replace its usage
>> with the canonical 'FDT_MAGIC' from 'libfdt'.
>>
>> Fixes: 66edeb2e3972 (arm: copy DTB appended t
85 matches
Mail list logo
