RE: [PATCH v3 28/28] xen/domctl: wrap common/domctl.c with CONFIG_MGMT_HYPERCALLS

[Public] > -Original Message- > From: Jason Andryuk > Sent: Wednesday, November 19, 2025 3:30 AM > To: Penny, Zheng ; Jan Beulich > Cc: Huang, Ray ; [email protected]; Andrew > Cooper ; Anthony PERARD > ; Orzel, Michal ; Julien > Grall ; Roger Pau Monné ; Stefano > Stabellini ;

Re: [PATCH] xen: Fix EFI buildid alignment

On Thu, Nov 20, 2025 at 12:43:57AM +, Andrew Cooper wrote: > On 19/11/2025 7:12 pm, Marek Marczykowski-Górecki wrote: > > Old binutils get confused about .buildid overlapping (in VA space) with > > earlier section. That confusion results in weird errors down the road, > > like this one: > > > >

Re: [PATCH] xen: Fix EFI buildid alignment

On 19/11/2025 7:12 pm, Marek Marczykowski-Górecki wrote: > Old binutils get confused about .buildid overlapping (in VA space) with > earlier section. That confusion results in weird errors down the road, > like this one: > > objcopy: xen.efi: Data Directory size (1c) exceeds space left in secti

Re: domU suspend issue - freeze processes failed - Linux 6.16

On 2025-11-13 10:55, Yann Sionneau wrote: On 10/6/25 16:28, Jason Andryuk wrote: On 2025-09-24 10:28, Yann Sionneau wrote: On 9/24/25 15:30, Marek Marczykowski-Górecki wrote: On Wed, Sep 24, 2025 at 01:17:15PM +0300, Grygorii Strashko wrote: On 22.09.25 13:09, Marek Marczykowski-Górecki

[PATCH 1/2] xenbus: Use .freeze/.thaw to handle xenbus devices

The goal is to fix s2idle and S3 for Xen PV devices. A domain resuming from s3 or s2idle disconnects its PV devices during resume. The backends are not expecting this and do not reconnect. b3e96c0c7562 ("xen: use freeze/restore/thaw PM events for suspend/ resume/chkpt") changed xen_suspend()/do_

[PATCH 2/2] xenbus: Rename helpers to freeze/thaw/restore

Rename the xenbus helpers called from the .freeze, .thaw, and .restore pm ops to have matching names. Signed-off-by: Jason Andryuk --- We could continue renaming and change struct xenbus_driver .suspend/.resume to .freeze/.restore. Thereis only the single callback, and it would be more churn, so

[XEN][PATCH] x86: make Viridian support optional

From: Sergiy Kibrik Add config option VIRIDIAN that covers viridian code within HVM. Calls to viridian functions guarded by is_viridian_domain() and related macros. Having this option may be beneficial by reducing code footprint for systems that are not using Hyper-V. [[email protected]

Re: [XEN][PATCH v4] xen/x86: guest_access: optimize raw_x_guest() for PV and HVM combinations

Hi Jan On 18.11.25 15:45, Jan Beulich wrote: On 18.11.2025 14:08, Grygorii Strashko wrote: On 17.11.25 18:43, Jan Beulich wrote: On 14.11.2025 15:01, Grygorii Strashko wrote: --- a/xen/arch/x86/pv/Makefile +++ b/xen/arch/x86/pv/Makefile @@ -14,6 +14,10 @@ obj-y += ro-page-fault.o obj-$(CON

[XEN][PATCH v4] xen: make VMTRACE support optional

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

[XEN][PATCH v2 4/4] x86: pvh: allow to disable 32-bit interface support

From: Grygorii Strashko For x86 Xen safety certification only PVH Gusts are selected to be allowed which are started by using direct Direct Kernel Boot only. There is also an assumption that x86 Guest's (OS) early boot code (which is running not in 64-bit mode) does not access Xen interfaces (hyp

[XEN][PATCH v2 3/4] x86: hvm: factor out COMPAT code under ifdefs

From: Grygorii Strashko Factor out COMPAT HVM code under ifdefs in preparation for making HVM COMPAT code optional. - hypercall-defs.c updated to always provide compat declaration for: physdev_op, grant_table_op, grant_table_op. This reduces number of COMPAT ifdefs in HVM code and lets compiler

[XEN][PATCH v2 1/4] x86: hvm: dm: factor out compat code under ifdefs

From: Grygorii Strashko Factor out COMPAT HVM DM code under ifdefs in preparation for making HVM COMPAT code optional. Signed-off-by: Grygorii Strashko Reviewed-by: Jason Andryuk --- changes in v2: - no changes xen/arch/x86/hvm/dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/xen/

[XEN][PATCH v2 2/4] x86: hvm: compat: introduce is_hcall_compat() helper

From: Grygorii Strashko Introduce is_hcall_compat() helper and use it instead of direct access to struct vcpu->hcall_compat field in preparation for making HVM COMPAT code optional. The vcpu->hcall_compat field is under CONFIG_COMPAT ifdefs already. Signed-off-by: Grygorii Strashko --- changes

[XEN][PATCH v2 0/4] x86: pvh: allow to disable 32-bit (COMPAT) interface support

From: Grygorii Strashko Hi This series introduces possibility to disable 32-bit (COMPAT) interface support in the following case: - Only PVH domains are used - Guests (OS) are started by using direct Direct Kernel Boot - Guests (OS) are 64-bit and Guest early boot code, which i

Re: [PATCH 1/5] hw/core/loader: Make load_elf_hdr() return bool, simplify caller

Vladimir Sementsov-Ogievskiy writes: > On 19.11.25 16:08, Markus Armbruster wrote: >> Signed-off-by: Markus Armbruster > > Reviewed-by: Vladimir Sementsov-Ogievskiy > >> --- >> include/hw/loader.h | 4 +++- >> hw/arm/boot.c | 6 +- >> hw/core/loader.c| 8 ++-- >> hw/ri

[PATCH] xen: Fix EFI buildid alignment

Old binutils get confused about .buildid overlapping (in VA space) with earlier section. That confusion results in weird errors down the road, like this one: objcopy: xen.efi: Data Directory size (1c) exceeds space left in section (8) While the bug is fixed in later binutils version, force al

Re: [PATCH 2/5] hw/nvram/xlnx-bbram: More idiomatic and simpler error reporting

Vladimir Sementsov-Ogievskiy writes: > On 19.11.25 16:08, Markus Armbruster wrote: >> bbram_bdrv_error() interpolates a "detail" string into a template with >> error_setg_errno(), then reports the result with error_report(). >> Produces error messages with an unwanted '.': >> >> BLK-NAME: BB

Re: [PATCH 3/5] nbd/client-connection: Replace error_propagate() by assignment

On Wed, Nov 19, 2025 at 02:08:53PM +0100, Markus Armbruster wrote: > connect_thread_func() sets a variable to null, then error_propagate()s > an Error * to it. This is a roundabout way to assign the Error * to > it, so replace it by just that. > > Signed-off-by: Markus Armbruster Reviewed-by: P

Re: [PATCH 2/5] hw/nvram/xlnx-bbram: More idiomatic and simpler error reporting

On Wed, Nov 19, 2025 at 02:08:52PM +0100, Markus Armbruster wrote: > bbram_bdrv_error() interpolates a "detail" string into a template with > error_setg_errno(), then reports the result with error_report(). > Produces error messages with an unwanted '.': > > BLK-NAME: BBRAM backstore DETAIL fa

Re: [PATCH 1/5] hw/core/loader: Make load_elf_hdr() return bool, simplify caller

On Wed, Nov 19, 2025 at 02:08:51PM +0100, Markus Armbruster wrote: > Signed-off-by: Markus Armbruster Reviewed-by: Peter Xu -- Peter Xu

Re: [PATCH v8] xen: Strip xen.efi by default

On 19/11/2025 5:08 pm, Marek Marczykowski-Górecki wrote: > On Wed, Nov 19, 2025 at 04:02:30PM +, Andrew Cooper wrote: >> Given it's now only 16.04 broken, how about simply excluding xen.efi >> with these broken toolchains? > That would mean adjusting README to say a newer binutils is required f

Re: [PATCH 4/5] error: error_free(NULL) is safe, drop unnecessary conditionals

On Wed, Nov 19, 2025 at 02:08:54PM +0100, Markus Armbruster wrote: > Signed-off-by: Markus Armbruster Acked-by: Peter Xu -- Peter Xu

Xen Project Releases Version 4.21

Hello everyone, It's with great pleasure that I announce our 4.21 PR release. I want to thank the whole community for their efforts in getting this release published! *Please find the PR article attached here

Re: [for 4.22 v5 17/18] xen/riscv: add support of page lookup by GFN

On 11/17/25 5:00 PM, Jan Beulich wrote: On 17.11.2025 16:52, Oleksii Kurochko wrote: On 11/10/25 5:46 PM, Jan Beulich wrote: On 20.10.2025 17:58, Oleksii Kurochko wrote: +static bool check_outside_boundary(gfn_t gfn, gfn_t boundary, bool is_lower, + unsigned

Re: [PATCH v8] xen: Strip xen.efi by default

On Wed, Nov 19, 2025 at 04:02:30PM +, Andrew Cooper wrote: > Given it's now only 16.04 broken, how about simply excluding xen.efi > with these broken toolchains? That would mean adjusting README to say a newer binutils is required for xen.efi, right? Then ofc we would need to figure out which

Re: [PATCH 4/5] error: error_free(NULL) is safe, drop unnecessary conditionals

On 19.11.25 16:08, Markus Armbruster wrote: Signed-off-by: Markus Armbruster Reviewed-by: Vladimir Sementsov-Ogievskiy -- Best regards, Vladimir

Re: [PATCH 3/5] nbd/client-connection: Replace error_propagate() by assignment

On 19.11.25 16:08, Markus Armbruster wrote: connect_thread_func() sets a variable to null, then error_propagate()s an Error * to it. This is a roundabout way to assign the Error * to it, so replace it by just that. Signed-off-by: Markus Armbruster Reviewed-by: Vladimir Sementsov-Ogievskiy

Re: [PATCH 2/5] hw/nvram/xlnx-bbram: More idiomatic and simpler error reporting

On 19.11.25 16:08, Markus Armbruster wrote: bbram_bdrv_error() interpolates a "detail" string into a template with error_setg_errno(), then reports the result with error_report(). Produces error messages with an unwanted '.': BLK-NAME: BBRAM backstore DETAIL failed.: STERROR Replace both c

Re: [PATCH 1/5] hw/core/loader: Make load_elf_hdr() return bool, simplify caller

On 19.11.25 16:08, Markus Armbruster wrote: Signed-off-by: Markus Armbruster Reviewed-by: Vladimir Sementsov-Ogievskiy --- include/hw/loader.h | 4 +++- hw/arm/boot.c | 6 +- hw/core/loader.c| 8 ++-- hw/riscv/spike.c| 10 +- 4 files changed, 11 insert

Re: [PATCH v8] xen: Strip xen.efi by default

On 19/11/2025 3:06 pm, Marek Marczykowski-Górecki wrote: > On Sat, Nov 15, 2025 at 06:23:08AM +, Frediano Ziglio wrote: >> On Fri, 14 Nov 2025 at 19:18, Andrew Cooper >> wrote: >>> On 14/11/2025 3:40 pm, Oleksii Kurochko wrote: On 11/13/25 4:43 PM, Frediano Ziglio wrote: > From:

Re: [PATCH v8] xen: Strip xen.efi by default

On Sat, Nov 15, 2025 at 06:23:08AM +, Frediano Ziglio wrote: > On Fri, 14 Nov 2025 at 19:18, Andrew Cooper wrote: > > > > On 14/11/2025 3:40 pm, Oleksii Kurochko wrote: > > > > > > > > > On 11/13/25 4:43 PM, Frediano Ziglio wrote: > > >> From: Frediano Ziglio > > >> > > >> For xen.gz file we

Re: [PATCH v2.1 5/5] x86/ioapic: Don't open-code 32-bits rte reads

On 19.11.2025 12:02, Teddy Astie wrote: > There are many places where we use interesting ways of reading 32-bits > components of the RTE. Introduce and use low and high components directly > to the rte structure instead. > > Also take the opportunity to simplify "x & 1 ? 1 : 0". > > Signed-off-by

Re: [PATCH 5/5] error: Consistently name Error * objects err, and not errp

Daniel P. Berrangé writes: > On Wed, Nov 19, 2025 at 01:22:06PM +, Andrew Cooper wrote: >> On 19/11/2025 1:08 pm, Markus Armbruster wrote: >> > diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c >> > index b93ff80c85..3e62ec09d0 100644 >> > --- a/hw/xen/xen-pvh-common.c >> > +++ b

Re: [XEN PATCH] xen/arm/p2m: perform IPA-based TLBI for arm64 when IPA is known

Hi Julien, Thanks for your review. > > The first one is addressed by relaxing VMALLS12E1IS -> VMALLE1IS. > > Each CPU have their own private TLBs, so flush between vCPU of the > > same domains is required to avoid translations from vCPUx to "leak" > > to the vCPUy. > > This doesn't really tell me

Re: [PATCH 5/5] error: Consistently name Error * objects err, and not errp

On Wed, Nov 19, 2025 at 01:22:06PM +, Andrew Cooper wrote: > On 19/11/2025 1:08 pm, Markus Armbruster wrote: > > diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c > > index b93ff80c85..3e62ec09d0 100644 > > --- a/hw/xen/xen-pvh-common.c > > +++ b/hw/xen/xen-pvh-common.c > > @@ -101

Re: [PATCH 5/5] error: Consistently name Error * objects err, and not errp

On 19/11/2025 1:08 pm, Markus Armbruster wrote: > diff --git a/hw/xen/xen-pvh-common.c b/hw/xen/xen-pvh-common.c > index b93ff80c85..3e62ec09d0 100644 > --- a/hw/xen/xen-pvh-common.c > +++ b/hw/xen/xen-pvh-common.c > @@ -101,7 +101,7 @@ static void > xen_create_virtio_mmio_devices(XenPVHMachineSta

[PATCH 5/5] error: Consistently name Error * objects err, and not errp

This touches code in xen_enable_tpm() that is obviously wrong. Since I don't know how to fix it properly, I'm adding a FIXME there. Signed-off-by: Markus Armbruster --- block/crypto.c | 8 hw/acpi/ghes.c | 8 hw/ppc/spapr.c | 16 h

[PATCH 0/5] A bit of cleanup around Error

Note: the last patch adds a drive-by FIXME. I asked for advice on how to fix it: Subject: Incorrect error handling in xen_enable_tpm() To: [email protected] Cc: Stefano Stabellini , Anthony PERARD , Paul Durrant , "Edgar E. Iglesias" , [email protected], Vi

[PATCH 3/5] nbd/client-connection: Replace error_propagate() by assignment

connect_thread_func() sets a variable to null, then error_propagate()s an Error * to it. This is a roundabout way to assign the Error * to it, so replace it by just that. Signed-off-by: Markus Armbruster --- nbd/client-connection.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff -

[PATCH 4/5] error: error_free(NULL) is safe, drop unnecessary conditionals

Signed-off-by: Markus Armbruster --- hw/acpi/pcihp.c | 4 +--- io/channel-websock.c| 4 +--- io/task.c | 4 +--- migration/migration.c | 6 ++ tests/unit/test-smp-parse.c | 5 + 5 files changed, 6 insertions(+), 17 deletions(-) diff --git a/hw/

[PATCH 1/5] hw/core/loader: Make load_elf_hdr() return bool, simplify caller

Signed-off-by: Markus Armbruster --- include/hw/loader.h | 4 +++- hw/arm/boot.c | 6 +- hw/core/loader.c| 8 ++-- hw/riscv/spike.c| 10 +- 4 files changed, 11 insertions(+), 17 deletions(-) diff --git a/include/hw/loader.h b/include/hw/loader.h index d035e72748.

[PATCH 2/5] hw/nvram/xlnx-bbram: More idiomatic and simpler error reporting

bbram_bdrv_error() interpolates a "detail" string into a template with error_setg_errno(), then reports the result with error_report(). Produces error messages with an unwanted '.': BLK-NAME: BBRAM backstore DETAIL failed.: STERROR Replace both calls of bbram_bdrv_error() by straightforward e

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On Wed, Nov 19, 2025 at 10:48 AM Orzel, Michal wrote: > > > > On 18/11/2025 16:37, Mykola Kvach wrote: > > From: Mykola Kvach > > > > Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface, > > allowing guests to request suspend via the PSCI v1.0+ SYSTEM_SUSPEND call > > (both 32

Re: [XEN][PATCH 3/5] x86: hvm: factor out compat code under ifdefs

On 19.11.25 12:48, Grygorii Strashko wrote: Hi Jürgen, On 13.11.25 17:43, Jürgen Groß wrote: On 13.11.25 16:32, Grygorii Strashko wrote: Hi Jürgen, On 13.11.25 16:46, Juergen Gross wrote: On 13.11.25 15:39, Jürgen Groß wrote: On 13.11.25 14:23, Jan Beulich wrote: On 13.11.2025 14:18, Grygo

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On Wed, Nov 19, 2025 at 1:43 PM Orzel, Michal wrote: > > > > On 19/11/2025 12:32, Mykola Kvach wrote: > > On Wed, Nov 19, 2025 at 1:07 PM Orzel, Michal wrote: > >> > >> > >> > >> On 19/11/2025 12:00, Mykola Kvach wrote: > >>> Hi Michal, > >>> > >>> Thanks for your review. > >>> > >>> On Wed, Nov

Re: [XEN][PATCH 3/5] x86: hvm: factor out compat code under ifdefs

Hi Jürgen, On 13.11.25 17:43, Jürgen Groß wrote: On 13.11.25 16:32, Grygorii Strashko wrote: Hi Jürgen, On 13.11.25 16:46, Juergen Gross wrote: On 13.11.25 15:39, Jürgen Groß wrote: On 13.11.25 14:23, Jan Beulich wrote: On 13.11.2025 14:18, Grygorii Strashko wrote: On 13.11.25 14:30, Jan B

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On 19/11/2025 12:32, Mykola Kvach wrote: > On Wed, Nov 19, 2025 at 1:07 PM Orzel, Michal wrote: >> >> >> >> On 19/11/2025 12:00, Mykola Kvach wrote: >>> Hi Michal, >>> >>> Thanks for your review. >>> >>> On Wed, Nov 19, 2025 at 10:48 AM Orzel, Michal wrote: On 18/11/2025 16

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On Wed, Nov 19, 2025 at 1:07 PM Orzel, Michal wrote: > > > > On 19/11/2025 12:00, Mykola Kvach wrote: > > Hi Michal, > > > > Thanks for your review. > > > > On Wed, Nov 19, 2025 at 10:48 AM Orzel, Michal wrote: > >> > >> > >> > >> On 18/11/2025 16:37, Mykola Kvach wrote: > >>> From: Mykola Kvach

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On 19/11/2025 12:00, Mykola Kvach wrote: > Hi Michal, > > Thanks for your review. > > On Wed, Nov 19, 2025 at 10:48 AM Orzel, Michal wrote: >> >> >> >> On 18/11/2025 16:37, Mykola Kvach wrote: >>> From: Mykola Kvach >>> >>> Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interf

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On 2025-11-19 12:00, Mykola Kvach wrote: Hi Michal, Thanks for your review. On Wed, Nov 19, 2025 at 10:48 AM Orzel, Michal wrote: On 18/11/2025 16:37, Mykola Kvach wrote: > From: Mykola Kvach > > Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface, > allowing guests t

[PATCH v2.1 5/5] x86/ioapic: Don't open-code 32-bits rte reads

There are many places where we use interesting ways of reading 32-bits components of the RTE. Introduce and use low and high components directly to the rte structure instead. Also take the opportunity to simplify "x & 1 ? 1 : 0". Signed-off-by: Teddy Astie Acked-by: Jan Beulich --- v2.1: - fix

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

Hi Michal, Thanks for your review. On Wed, Nov 19, 2025 at 10:48 AM Orzel, Michal wrote: > > > > On 18/11/2025 16:37, Mykola Kvach wrote: > > From: Mykola Kvach > > > > Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface, > > allowing guests to request suspend via the PSCI v

[PATCH 4/4] x86/vPMU: don't statically reserve the interrupt vector

Move the setup to vPMU code, doing the allocation of a vector only when one is actually going to be needed. With that the handler function also doesn't need to be split across two places anymore. Add the freed up vector to the dynamically allocatable range. Signed-off-by: Jan Beulich --- In case

[PATCH 3/4] x86/IRQ: direct-APIC-vector setting is now init-only

With all callers of alloc_direct_apic_vector() now being limited to BSP setup, it and its helpers (whose other callers have already been init- only) can become __init. As a result data items can be adjusted, too. Signed-off-by: Jan Beulich --- Question is whether with this the "if (*vector == 0)"

[PATCH 2/4] x86/MCE: restrict allocation of thermal and CMCI vector to BSP

There's no need to do this for every AP; just do it once when setting up the BSP. Then both vector variables can also validly become ro-after-init. While touching intel_init_thermal(), constify its 1st parameter, which in turn requires touching intel_thermal_supported() as well. Signed-off-by: Ja

[PATCH 1/4] x86/guest: move allocation of Xen upcall vector to init code

There's no need to do this every time init_evtchn() is called. Just do it once when setting up CPU0. Drop the assertion as well, as alloc_hipriority_vector() (called by alloc_direct_apic_vector()) uses more restrictive BUG_ON() anyway. Then evtchn_upcall_vector can also validly become ro-after-init

[PATCH 0/4] x86: direct APIC vector adjustments

The setting up of such vectors really is a boot-time-only thing. vPMU also doesn't need any vector when it's no in use anyway (which is the default). 1: guest: move allocation of Xen upcall vector to init code 2: MCE: restrict allocation of thermal and CMCI vector to BSP 3: IRQ: direct-APIC-vector

Re: [PATCH v2 5/5] x86/ioapic: Don't open-code 32-bits rte reads

On 23/10/2025 10:12 am, Teddy Astie wrote: > diff --git a/xen/drivers/passthrough/vtd/intremap.c > b/xen/drivers/passthrough/vtd/intremap.c > index 612e08bcec..a276518c52 100644 > --- a/xen/drivers/passthrough/vtd/intremap.c > +++ b/xen/drivers/passthrough/vtd/intremap.c > @@ -411,11 +411,8 @@ uns

Re: [PATCH 2/2] amd/iommu: Remove dead non-atomic update checking

On 19.11.2025 11:22, Teddy Astie wrote: > Le 13/11/2025 à 12:39, Jan Beulich a écrit : >> On 12.11.2025 16:37, Teddy Astie wrote: >>> 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

Re: [PATCH 2/2] amd/iommu: Remove dead non-atomic update checking

Le 13/11/2025 à 12:39, Jan Beulich a écrit : > On 12.11.2025 16:37, Teddy Astie wrote: >> 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 >>

Re: [PATCH v14 1/4] xen/arm: Implement PSCI SYSTEM_SUSPEND call for guests

On 18/11/2025 16:37, Mykola Kvach wrote: > From: Mykola Kvach > > Add support for the PSCI SYSTEM_SUSPEND function in the vPSCI interface, > allowing guests to request suspend via the PSCI v1.0+ SYSTEM_SUSPEND call > (both 32-bit and 64-bit variants). > > Implementation details: > - Add SYSTE

Re: [PATCH v3 1/3] arm/mpu: Implement setup_mm for MPU systems

On 19/11/2025 08:53, 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

Re: [PATCH 8/8] x86/cpufreq: use host CPU policy in HWP driver

On 18.11.2025 21:04, Andrew Cooper wrote: > On 18/11/2025 3:09 pm, Jan Beulich wrote: >> --- a/xen/arch/x86/acpi/cpufreq/hwp.c >> +++ b/xen/arch/x86/acpi/cpufreq/hwp.c >> @@ -183,29 +178,25 @@ static bool __init hwp_available(void) >> return false; >> } >> >> -eax = cpuid_eax(CP

Re: [PATCH v3 3/3] arm/mpu: Implement ioremap_attr for MPU

On 19/11/2025 08:53, Harry Ramsey wrote: > Implement the function `ioremap_attr` for MPU systems. > > Signed-off-by: Harry Ramsey > Acked-by: Michal Orzel > --- > xen/arch/arm/mpu/mm.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/xen/arch/arm/mpu/mm.c b/