On 06.11.2025 17:37, Frediano Ziglio wrote:
> On Thu, 6 Nov 2025 at 10:32, Jan Beulich wrote:
>> On 05.11.2025 16:38, Frediano Ziglio wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -147,12 +147,7 @@ config DEBUG_INFO
>>> Say Y here if you want to build Xen with debug
On 06.11.2025 17:32, Frediano Ziglio wrote:
> On Thu, 6 Nov 2025 at 10:27, Jan Beulich wrote:
>>
>> On 06.11.2025 10:58, Frediano Ziglio wrote:
>>> On Thu, 6 Nov 2025 at 03:52, Demi Marie Obenour
>>> wrote:
Does objdump on the signed file return correct section names?
>>>
>>> From objdump -
On 06.11.2025 23:26, Grygorii Strashko wrote:
> From: Grygorii Strashko
>
> Xen uses below pattern for raw_x_guest() functions:
>
> define raw_copy_to_guest(dst, src, len)\
> (is_hvm_vcpu(current) ? \
> copy_to_user_hvm((dst), (src), (len)) :\
> copy
On 2025-11-06 12:40, Grygorii Strashko wrote:
On 06.11.25 19:27, Teddy Astie wrote:
Le 06/11/2025 à 18:00, Jason Andryuk a écrit :
On 2025-11-06 11:33, Grygorii Strashko wrote:
Hi Teddy, Jan,
On 06.11.25 17:57, Teddy Astie wrote:
Le 31/10/2025 à 22:25, Grygorii Strashko a écrit :
Can try.
On 2025-11-06 17:26, Grygorii Strashko wrote:
From: Grygorii Strashko
Xen uses below pattern for raw_x_guest() functions:
define raw_copy_to_guest(dst, src, len)\
(is_hvm_vcpu(current) ? \
copy_to_user_hvm((dst), (src), (len)) :\
copy_to_gues
From: Grygorii Strashko
Xen uses below pattern for raw_x_guest() functions:
define raw_copy_to_guest(dst, src, len)\
(is_hvm_vcpu(current) ? \
copy_to_user_hvm((dst), (src), (len)) :\
copy_to_guest_pv(dst, src, len))
This pattern works depending on
On 06.11.25 19:27, Teddy Astie wrote:
Le 06/11/2025 à 18:00, Jason Andryuk a écrit :
On 2025-11-06 11:33, Grygorii Strashko wrote:
Hi Teddy, Jan,
On 06.11.25 17:57, Teddy Astie wrote:
Le 31/10/2025 à 22:25, Grygorii Strashko a écrit :
Can try.
Yes, I was thinking something like Teddy su
Le 06/11/2025 à 18:00, Jason Andryuk a écrit :
> On 2025-11-06 11:33, Grygorii Strashko wrote:
>> Hi Teddy, Jan,
>>
>> On 06.11.25 17:57, Teddy Astie wrote:
>>> Le 31/10/2025 à 22:25, Grygorii Strashko a écrit :
>> Can try.
>
> Yes, I was thinking something like Teddy suggested:
>
> #define raw_cop
Ritesh Harjani (IBM) writes:
> For e.g...
>
> arch_enter_lazy_mmu_mode()
> hpte_need_flush()
> get_cpu_var() // this takes care of preempt_disable()
> adds vpns to per-cpu batch[i]
> put_cpu_var() //
> arch_leave_lazy_mmu_mode()
>
Sor
Alexander Gordeev writes:
> On Wed, Nov 05, 2025 at 02:19:03PM +0530, Ritesh Harjani wrote:
>> > + * in_lazy_mmu_mode() can be used to check whether the lazy MMU mode is
>> > + * currently enabled.
>> > */
>> > #ifdef CONFIG_ARCH_HAS_LAZY_MMU_MODE
>> > static inline void lazy_mmu_mode_enable(
On 2025-11-06 11:33, Grygorii Strashko wrote:
Hi Teddy, Jan,
On 06.11.25 17:57, Teddy Astie wrote:
Le 31/10/2025 à 22:25, Grygorii Strashko a écrit :
From: Grygorii Strashko
Xen uses below pattern for raw_x_guest() functions:
define raw_copy_to_guest(dst, src, len) \
(is_hvm_vc
On Thu, 6 Nov 2025 at 10:32, Jan Beulich wrote:
>
> On 05.11.2025 16:38, Frediano Ziglio wrote:
> > From: Frediano Ziglio
> >
> > For xen.gz file we strip all symbols and have an additional
> > xen-syms file version with all symbols.
> > Make xen.efi more coherent stripping all symbols too.
> > x
Hi Teddy, Jan,
On 06.11.25 17:57, Teddy Astie wrote:
Le 31/10/2025 à 22:25, Grygorii Strashko a écrit :
From: Grygorii Strashko
Xen uses below pattern for raw_x_guest() functions:
define raw_copy_to_guest(dst, src, len)\
(is_hvm_vcpu(current) ? \
copy
On Thu, 6 Nov 2025 at 10:27, Jan Beulich wrote:
>
> On 06.11.2025 10:58, Frediano Ziglio wrote:
> > On Thu, 6 Nov 2025 at 03:52, Demi Marie Obenour
> > wrote:
> >> Does objdump on the signed file return correct section names?
> >
> > From objdump -x
> >
> > Sections:
> > Idx Name Size
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WOR
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WO
Hi,
=== Current situation: problems ===
Let's consider a nohz_full system with isolated CPUs: wq_unbound_cpumask is
set to the housekeeping CPUs, for !WQ_UNBOUND the local CPU is selected.
This leads to different scenarios if a work item is scheduled on an
isolated CPU where "delay" value is 0 o
Le 31/10/2025 à 22:25, Grygorii Strashko a écrit :
> From: Grygorii Strashko
>
> Xen uses below pattern for raw_x_guest() functions:
>
> define raw_copy_to_guest(dst, src, len)\
> (is_hvm_vcpu(current) ? \
> copy_to_user_hvm((dst), (src), (len)) :\
>
Hi
On 30.10.25 14:47, Jan Beulich wrote:
On 30.10.2025 13:28, Grygorii Strashko wrote:
On 30.10.25 13:08, Jan Beulich wrote:
On 30.10.2025 00:54, Grygorii Strashko wrote:
From: Grygorii Strashko
Functions:
hvm_shadow_handle_cd()
hvm_set_uc_mode()
domain_exit_uc_mode()
are used only
On Thu, Nov 06, 2025 at 10:51:43AM +, Kevin Brodsky wrote:
> On 05/11/2025 16:12, Alexander Gordeev wrote:
> > On Wed, Nov 05, 2025 at 02:19:03PM +0530, Ritesh Harjani wrote:
> >>> + * in_lazy_mmu_mode() can be used to check whether the lazy MMU mode is
> >>> + * currently enabled.
> >>> */
>
On 20.10.2025 17:57, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/p2m.c
> +++ b/xen/arch/riscv/p2m.c
> @@ -3,6 +3,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -103,6 +104,70 @@ void __init pre_gstage_init(void)
> vmid_init();
> }
>
>
On 06.11.2025 14:50, Grygorii Strashko wrote:
> On 06.11.25 14:00, Jan Beulich wrote:
>> On 31.10.2025 22:20, Grygorii Strashko wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -155,4 +155,19 @@ config DEBUG_INFO
>>> "make install-xen" for installing xen.efi, stripping ne
On 20.10.2025 17:57, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/vmid.c
> @@ -0,0 +1,193 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
Hi Jan,
On 06.11.25 14:00, Jan Beulich wrote:
On 31.10.2025 22:20, Grygorii Strashko wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -155,4 +155,19 @@ config DEBUG_INFO
"make install-xen" for installing xen.efi, stripping needs to be
done outside the Xen build envi
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:
>>> --- a/xen/arch/x86/hvm/Makefile
>>> +++ b/xen/arch/x86/hvm/Makefile
>>> @@ -1,6 +1,6 @@
>>> obj-$(CONFIG_AMD_SVM) += svm/
>>> obj-$(CONFIG_INTEL_VMX) += vmx
On 20.10.2025 17:57, Oleksii Kurochko wrote:
> Changes in V5:
> - Add static and __initconst for local variable modes[] in
>gstage_mode_detect().
> - Change type for gstage_mode from 'unsigned long' to 'unsigned char'.
> - Update the comment inisde defintion if modes[] variable in
>gstag
On 06.11.25 13:35, Jan Beulich wrote:
On 31.10.2025 17:17, Grygorii Strashko wrote:
--- a/xen/arch/x86/hvm/Makefile
+++ b/xen/arch/x86/hvm/Makefile
@@ -1,6 +1,6 @@
obj-$(CONFIG_AMD_SVM) += svm/
obj-$(CONFIG_INTEL_VMX) += vmx/
-obj-y += viridian/
+obj-$(CONFIG_VIRIDIAN) += viridian/
With
On 24.09.2025 09:59, Mykyta Poturai wrote:
> @@ -133,6 +134,12 @@ void arch_iommu_domain_destroy(struct domain *d)
> {
> }
>
> +static int iommu_add_hwdom_pci_device(u8 devfn, struct pci_dev *pdev)
> +{
> +const struct domain_iommu *hd = dom_iommu(hardware_domain);
> +return iommu_call(
On 24.09.2025 09:59, Mykyta Poturai wrote:
> From: Stewart Hildebrand
>
> A PCI device must have valid BARs in order to assign it to a domain. On
> ARM, firmware is unlikely to have initialized the BARs, so we must do
> this in Xen. During setup_hwdom_pci_devices(), check if each BAR is
> valid.
On 06/11/2025 13:19, Jan Beulich wrote:
> On 06.11.2025 13:13, Tu Dinh wrote:
>> On 06/11/2025 13:10, Jan Beulich wrote:
>>> On 05.11.2025 01:03, Tu Dinh wrote:
The LAML field should follow the TCG PFP specification:
The TCG ACPI specification uses the field name "Log Area Minimum
>>
On 06.11.2025 13:13, Tu Dinh wrote:
> On 06/11/2025 13:10, Jan Beulich wrote:
>> On 05.11.2025 01:03, Tu Dinh wrote:
>>> The LAML field should follow the TCG PFP specification:
>>>
>>> The TCG ACPI specification uses the field name "Log Area Minimum
>>> Length", but the field value is the actual lo
On 24.09.2025 09:59, Mykyta Poturai wrote:
> From: Stefano Stabellini
>
> has_vpci_bridge is a macro to check if the domain is a domU or is dom0
> with vPCI (pci-scan=yes) enabled.
Hmm. Why would DomU-s, now and forever, not have (virtual) bridges? Wasn't them
gaining (virtual) bridges actually
On 06/11/2025 13:10, Jan Beulich wrote:
> On 05.11.2025 01:03, Tu Dinh wrote:
>> The LAML field should follow the TCG PFP specification:
>>
>> The TCG ACPI specification uses the field name "Log Area Minimum
>> Length", but the field value is the actual log area length reserved by
>> Platform Firmw
On 05.11.2025 01:03, Tu Dinh wrote:
> The LAML field should follow the TCG PFP specification:
>
> The TCG ACPI specification uses the field name "Log Area Minimum
> Length", but the field value is the actual log area length reserved by
> Platform Firmware, not a lower bound.
And this is said wher
On 31.10.2025 22:20, Grygorii Strashko wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -155,4 +155,19 @@ config DEBUG_INFO
> "make install-xen" for installing xen.efi, stripping needs to be
> done outside the Xen build environment).
>
> +config HAS_VMTRACE
> +b
On 31.10.2025 17:17, Grygorii Strashko wrote:
> --- a/xen/arch/x86/hvm/Makefile
> +++ b/xen/arch/x86/hvm/Makefile
> @@ -1,6 +1,6 @@
> obj-$(CONFIG_AMD_SVM) += svm/
> obj-$(CONFIG_INTEL_VMX) += vmx/
> -obj-y += viridian/
> +obj-$(CONFIG_VIRIDIAN) += viridian/
With this, what is the point of the a
On 05/11/2025 16:12, Alexander Gordeev wrote:
> On Wed, Nov 05, 2025 at 02:19:03PM +0530, Ritesh Harjani wrote:
>>> + * in_lazy_mmu_mode() can be used to check whether the lazy MMU mode is
>>> + * currently enabled.
>>> */
>>> #ifdef CONFIG_ARCH_HAS_LAZY_MMU_MODE
>>> static inline void lazy_mmu
On 11/6/25 05:28, Jan Beulich wrote:
> On 06.11.2025 10:58, Frediano Ziglio wrote:
>> On Thu, 6 Nov 2025 at 03:52, Demi Marie Obenour
>> wrote:
>>> Does objdump on the signed file return correct section names?
>>
>> From objdump -x
>>
>> Sections:
>> Idx Name Size VMA
On 01.11.2025 12:56, Oleksii Moisieiev wrote:
> --- /dev/null
> +++ b/xen/lib/arm/Makefile
> @@ -0,0 +1 @@
> +obj-y += io.o
Yet one more thing: For a library, I think every function wants to live in its
own source file, such that under no conditions any unused code would be linked
in.
Jan
On 05/11/2025 04:40, Ritesh Harjani (IBM) wrote:
> Kevin Brodsky writes:
>
>> Architectures currently opt in for implementing lazy_mmu helpers by
>> defining __HAVE_ARCH_ENTER_LAZY_MMU_MODE.
>>
>> In preparation for introducing a generic lazy_mmu layer that will
>> require storage in task_struct,
On 05.11.2025 16:38, Frediano Ziglio wrote:
> From: Frediano Ziglio
>
> For xen.gz file we strip all symbols and have an additional
> xen-syms file version with all symbols.
> Make xen.efi more coherent stripping all symbols too.
> xen-syms.efi can be used for debugging.
>
> Signed-off-by: Fredi
On 05/11/2025 09:49, Ritesh Harjani (IBM) wrote:
> Ritesh Harjani (IBM) writes:
>
>> Kevin Brodsky writes:
>>
>>> Upcoming changes to the lazy_mmu API will cause
>>> arch_flush_lazy_mmu_mode() to be called when leaving a nested
>>> lazy_mmu section.
>>>
>>> Move the relevant logic from arch_leave
On 05/11/2025 02:46, Ritesh Harjani (IBM) wrote:
> Kevin Brodsky writes:
>
>> From: Alexander Gordeev
>>
>> Since commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash
>> lazy mmu mode") a task can not be preempted while in lazy MMU mode.
>> Therefore, the batch re-activation code is neve
On 06.11.2025 10:58, Frediano Ziglio wrote:
> On Thu, 6 Nov 2025 at 03:52, Demi Marie Obenour wrote:
>> Does objdump on the signed file return correct section names?
>
> From objdump -x
>
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .text
On 01.11.2025 12:56, Oleksii Moisieiev wrote:
> --- /dev/null
> +++ b/xen/include/xen/lib/io.h
> @@ -0,0 +1,83 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Generic I/O memory copy function prototypes.
> + *
> + * These functions provide low-level implementation for copying data bet
On 01.11.2025 12:56, Oleksii Moisieiev wrote:
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -29,6 +29,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
Does this build at all on non-Arm?
> @@ -827,7 +828,32 @@ long do_domctl(XEN_GUEST_HANDLE_PAR
On Thu, 6 Nov 2025 at 03:52, Demi Marie Obenour wrote:
>
> On 11/5/25 21:00, Frediano Ziglio wrote:
> > On Wed, 5 Nov 2025 at 20:31, Demi Marie Obenour
> > wrote:
> >>
> >> On 11/5/25 10:38, Frediano Ziglio wrote:
> >>> From: Frediano Ziglio
> >>>
> >>> For xen.gz file we strip all symbols and
On 31.10.2025 22:20, Grygorii Strashko wrote:
> @@ -34,6 +35,43 @@
> copy_from_user_hvm((dst), (src), (len)) : \
> __copy_from_guest_pv(dst, src, len))
>
> +#elif defined(CONFIG_HVM)
> +#define raw_copy_to_guest(dst, src, len)\
> + copy_to_user_hvm((dst), (src), (len))
O
On 31.10.2025 22:20, Grygorii Strashko wrote:
> --- a/xen/arch/x86/include/asm/guest_access.h
> +++ b/xen/arch/x86/include/asm/guest_access.h
> @@ -13,6 +13,7 @@
> #include
>
> /* Raw access functions: no type checking. */
> +#if defined(CONFIG_PV) && defined(CONFIG_HVM)
> #define raw_copy_to
On 03.11.2025 12:26, Andrew Cooper wrote:
> On 03/11/2025 10:11 am, Dmytro Prokopchuk1 wrote:
>> diff --git a/xen/common/spinlock.c b/xen/common/spinlock.c
>> index 0389293b09..d9dc9998e6 100644
>> --- a/xen/common/spinlock.c
>> +++ b/xen/common/spinlock.c
>> @@ -367,7 +367,8 @@ static void always_
On 31.10.2025 14:24, Dmytro Prokopchuk1 wrote:
> These files 'docs/misc/kconfig{,-language}.txt' were deleted, but
> references are still present in Xen. Remove them to clean-up.
>
> Fixes: 044503f61c95 ("docs: Delete kconfig docs to fix licensing violation")
> Fixes: f80fe2b34f08 ("xen: Update Kc
On 31.10.2025 14:15, Roger Pau Monné wrote:
> Not putting rdseed in the max policy completely blocks the upgrade
> path, even when a toolstack is possibly making the right informed
> decisions.
Why would that be? To evacuate guests, one would force-enable RDSEED on
an affected host. After updating
On 03.11.2025 15:10, Andrew Cooper wrote:
> On 28/10/2025 3:32 pm, Jan Beulich wrote:
>> Both patches also want 'x86/CPU: extend is_forced_cpu_cap()'s "reach"' in
>> place.
>>
>> 1: disable RDSEED on Fam17 model 47 stepping 0
>> 2: disable RDSEED on most of Zen5
>
> We have two existing cases for
On 31.10.2025 14:15, Roger Pau Monné wrote:
> On Fri, Oct 31, 2025 at 01:34:55PM +0100, Jan Beulich wrote:
>> On 31.10.2025 13:14, Roger Pau Monné wrote:
>>> On Fri, Oct 31, 2025 at 12:47:51PM +0100, Jan Beulich wrote:
On 31.10.2025 11:54, Roger Pau Monné wrote:
> On Fri, Oct 31, 2025 at 1
On 31.10.2025 15:33, Teddy Astie wrote:
> Le 30/10/2025 à 08:56, Jan Beulich a écrit :
>> On 29.10.2025 19:26, Teddy Astie wrote:
>>> --- a/xen/arch/x86/hvm/vlapic.c
>>> +++ b/xen/arch/x86/hvm/vlapic.c
>>> @@ -1116,6 +1116,20 @@ int guest_wrmsr_apic_base(struct vcpu *v, uint64_t
>>> val)
>>>
On 03.11.2025 15:30, Teddy Astie wrote:
> Le 30/10/2025 à 14:54, Jan Beulich a écrit :
>> On 29.10.2025 16:59, Teddy Astie wrote:
>> I'd also like to note that unlike the two THERM_STATUS,
>> MSR_TEMPERATURE_TARGET
>> (as per the absence if an IA32 infix in the SDM) isn't an architectural MSR,
>>
56 matches
Mail list logo
