Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART emulators

On 11.06.2025 21:07, Stefano Stabellini wrote: > On Wed, 11 Jun 2025, Jan Beulich wrote: >> On 11.06.2025 02:07, dm...@proton.me wrote: >>> On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: On 06.06.2025 22:11, dm...@proton.me wrote: > From: Denis Mukhin > > If virtual

RE: [PATCH v4 04/20] xen: introduce CONFIG_SYSCTL

[Public] Hi > -Original Message- > From: Jan Beulich > Sent: Tuesday, June 10, 2025 9:05 PM > To: Penny, Zheng > Cc: Huang, Ray ; Stabellini, Stefano > ; Andrew Cooper ; > Anthony PERARD ; Orzel, Michal > ; Julien Grall ; Roger Pau Monné > ; Stefano Stabellini ; Sergiy > Kibrik > ; xen

RE: [PATCH v4 03/20] xen/x86: remove "depends on !PV_SHIM_EXCLUSIVE"

[Public] Hi, > -Original Message- > From: Jan Beulich > Sent: Tuesday, June 10, 2025 9:01 PM > To: Penny, Zheng > Cc: Huang, Ray ; Andrew Cooper > ; Roger Pau Monné ; > Anthony PERARD ; Orzel, Michal > ; Julien Grall ; Stefano Stabellini > ; xen-devel@lists.xenproject.org > Subject: Re:

[PATCH] docs: UEFI Secure Boot security policy

Written to be solution and deployment neutral in order to focus on the technology itself. This policy is intended to work as well for UKI as for the "classic server setup" approach. Signed-off-by: Andrew Cooper --- CC: Anthony PERARD CC: Michal Orzel CC: Jan Beulich CC: Julien Grall CC: Roge

Re: [PATCH] docs: UEFI Secure Boot security policy

On 6/11/25 19:58, Andrew Cooper wrote: > Written to be solution and deployment neutral in order to focus on the > technology itself. This policy is intended to work as well for UKI as for the > "classic server setup" approach. > > Signed-off-by: Andrew Cooper > --- > CC: Anthony PERARD > CC: Mi

Re: [PATCH v3 05/22] x86/boot/slaunch-early: early TXT checks and boot data retrieval

On Tue, Jun 03, 2025 at 10:03:31AM -0700, ross.philip...@oracle.com wrote: > > From: Krystian Hebel > > > > The tests validate that important parts of memory are protected against > > DMA attacks, including Xen and MBI. Modules can be tested later, when it > > is possible to report issues to a us

Re: [PATCH v3 04/22] x86/boot/slaunch-early: implement early initialization

On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philip...@oracle.com wrote: > > +void asmlinkage slaunch_early_init(uint32_t load_base_addr, > > + uint32_t tgt_base_addr, > > + uint32_t tgt_end_addr, > > +

Re: [REGRESSION] Linux 6.15.1 xen/dom0 domain_crash_sync called from entry.S

On 6/10/25 12:22 AM, Jürgen Groß wrote: > On 10.06.25 00:43, Chuck Zmudzinski wrote: >> Hi, >> >> I am seeing the following regression between Linux 6.14.8 and 6.15.1. >> >> Kernel version 6.14.8 boots fine but version 6.15.1 crashes and >> reboots on Xen. I don't know if 6.14.9 or 6.14.10 is aff

Re: [PATCH v1 2/5] vpci: rework error path in vpci_process_pending()

On 6/5/25 05:53, Roger Pau Monné wrote: > On Sat, May 31, 2025 at 08:54:00AM -0400, Stewart Hildebrand wrote: >> This will make further refactoring simpler. > > I think you want to add: > > No functional change intended. > > To the commit message. Yep, will do. > >> Signed-off-by: Stewart Hil

Re: [PATCH v5 05/18] xen/cpufreq: refactor cmdline "cpufreq=xxx"

Hi Penny, On 2025-05-27 04:48, Penny Zheng wrote: A helper function handle_cpufreq_cmdline() is introduced to tidy different handling pathes. We also add a new helper cpufreq_opts_contain() to ignore and warn user redundant setting, like "cpufreq=hwp;hwp;xen" Signed-off-by: Penny Zheng @@ -

Re: [PATCH v1 5/5] vpci: allow 32-bit BAR writes with memory decoding enabled

On 6/5/25 06:41, Jan Beulich wrote: > On 31.05.2025 14:54, Stewart Hildebrand wrote: >> Currently, Xen vPCI refuses BAR writes if the BAR is mapped in p2m. If >> firmware initializes a 32-bit BAR to a bad address, Linux may try to >> write a new address to the BAR without disabling memory decoding.

Re: [PATCH v1 3/5] vpci: introduce map_bars()

On 6/5/25 06:16, Roger Pau Monné wrote: > On Sat, May 31, 2025 at 08:54:01AM -0400, Stewart Hildebrand wrote: >> Move some logic to a new function to enable code reuse. > > Like with the previous changes, it's helpful if you explicitly note > that no functional change is intended in the commit mes

Re: [PATCH v3 3/6] arm/mpu: Move domain-page.c to arm32 specific dir

Hi Ayan, > On 11 Jun 2025, at 15:35, Ayan Kumar Halder wrote: > > Create xen/arch/arm/mpu/arm32 to hold arm32 specific bits. > > Signed-off-by: Ayan Kumar Halder > --- > Changes from :- > > v1..v2 - New patch in v3. > > xen/arch/arm/mpu/Makefile | 2 +- > xen/arch/arm/mpu/arm

Re: [PATCH v1 1/5] vpci: const-ify some pdev instances

On 6/5/25 05:47, Roger Pau Monné wrote: > On Sat, May 31, 2025 at 08:53:59AM -0400, Stewart Hildebrand wrote: >> Since 622bdd962822 ("vpci/header: handle p2m range sets per BAR"), a >> non-const pdev is no longer needed for error handling in >> vpci_process_pending(). Const-ify pdev in vpci_process

Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on offsets between regions

On 11/06/2025 6:16 pm, Roger Pau Monne wrote: > With the appearance of Intel Sierra Forest and Granite Rapids it's not s/not/now ? The problem here is that it's very possible to get such a system. It might be worth nothing that SRF and GNR are socket compatible, in Birch Stream platforms, which

Re: [PATCH 1/8] x86/pdx: simplify calculation of domain struct allocation boundary

On 11/06/2025 6:16 pm, Roger Pau Monne wrote: > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > index 7536b6c8717e..2f438ce367cf 100644 > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -461,30 +461,6 @@ void domain_cpu_policy_changed(struct domain *d) > } > } >

[PATCH 8/8] pdx: introduce a command line option for offset compression

Allow controlling whether to attempt PDX compression, and which algorithm to use to calculate the coefficients. Document the option and also add a CHANGELOG entry for the newly added feature. Note the work has been originally done to cope with the new Intel Sapphire/Granite Rapids, however the co

[PATCH 6/8] pdx: introduce a new compression algorithm based on offsets between regions

With the appearance of Intel Sierra Forest and Granite Rapids it's not possible to get a production x86 host wit the following memory map: SRAT: Node 0 PXM 0 [, 7fff] SRAT: Node 0 PXM 0 [0001, 00407fff] SRAT: Node 1 PXM 1 [061e8000, 065e7

[PATCH v5 2/2] tools/arm: exclude iomem from domU extended regions

When a device is passed through to a xl domU, the iomem ranges may overlap with the extended regions. Remove iomem from extended regions. Signed-off-by: Stewart Hildebrand Reviewed-by: Anthony PERARD --- Not sure if we need a Fixes: tag, but if we do: Fixes: 57f87857dc2d ("libxl/arm: Add handlin

[PATCH 2/8] pdx: introduce function to calculate max PFN based on PDX compression

This is the code already present and used by x86 in setup_max_pdx(), which takes into account the current PDX compression, plus the limitation of the virtual memory layout to return the maximum usable PFN in the system, possibly truncating the input PFN provided by the caller. This helper will be

[PATCH v5 0/2] arm: extended regions fixes

v4->v5: * see individual patches v3->v4: * see individual patches v2->v3: * drop committed patches * add ("xen/arm: exclude xen,reg from direct-map domU extended regions") v1->v2: * rebase * address feedback Stewart Hildebrand (2): xen/arm: exclude xen,reg from direct-map domU extended region

Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo

On 2025-06-11 09:27, Jan Beulich wrote: On 11.06.2025 00:57, Jason Andryuk wrote: Allow the hwdom to access the console, and to access physical information about the system. xenconsoled can read Xen's dmesg. If it's in hwdom, then that permission would be required. Why would xenconsoled run

Re: [PATCH v3 2/2] xen/console: unify printout behavior for UART emulators

On Wed, 11 Jun 2025, Jan Beulich wrote: > On 11.06.2025 02:07, dm...@proton.me wrote: > > On Tue, Jun 10, 2025 at 10:21:40AM +0200, Jan Beulich wrote: > >> On 06.06.2025 22:11, dm...@proton.me wrote: > >>> From: Denis Mukhin > >>> > >>> If virtual UART from domain X prints on the physical console,

[PATCH 4/8] pdx: provide a unified set of unit functions

The current setup (pdx_init_mask() and pdx_region_mask()) and init (pfn_pdx_hole_setup()) PDX compression functions are tailored to the existing PDX compression algorithm. In preparation for introducing a new compression algorithm convert the setup and init functions to more generic interfaces tha

[PATCH 1/8] x86/pdx: simplify calculation of domain struct allocation boundary

When not using CONFIG_BIGMEM there are some restrictions in the address width for allocations of the domain structure, as it's PDX truncated to 32bits it's stashed into page_info structure for domain allocated pages. The current logic to calculate this limit is based on the internals of the PDX co

Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR cache attribute

On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote: > diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in > index c388899306c2..ddbff6fffc16 100644 > --- a/docs/man/xl.cfg.5.pod.in > +++ b/docs/man/xl.cfg.5.pod.in > @@ -2351,6 +2351,14 @@ Windows L

[PATCH v5 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions

Similarly to fba1b0974dd8, when a device is passed through to a direct-map dom0less domU, the xen,reg ranges may overlap with the extended regions. Remove xen,reg from direct-map domU extended regions. Take the opportunity to update the comment ahead of find_memory_holes(). Signed-off-by: Stewart

Re: [PATCH 0/4] XSM changes for split hardware / control domain

On 2025-06-11 09:28, Jan Beulich wrote: On 11.06.2025 00:57, Jason Andryuk wrote: Theses are the broad changes needed for a split hardware / control domain. An earlier posting gave device_model privileges to hardware domain. For this posting, it was split out into a new capability. This way t

Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains

On 2025-06-11 09:17, Jan Beulich wrote: On 11.06.2025 00:57, Jason Andryuk wrote: In a disaggregated environment, dom0 is split into Control, Hardware, and Xenstore domains, along with domUs. The is_control_domain() check is not sufficient to handle all these cases. Add is_priv_domain() to sup

[PATCH 7/8] pdx: introduce translation helpers for offset compression

Implement the helpers to translate from pfns or physical addresses into the offset compressed index space. Add a further check in the PDX testing to ensure conversion resulting from the added functions is bi-directional. Signed-off-by: Roger Pau Monné --- tools/tests/pdx/test-pdx-offset.c | 10

Re: [PATCH v3] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT

On 2025-06-11 06:02, Jan Beulich wrote: This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Reviewed-by: Jason Andryuk

Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model

On 2025-06-11 09:24, Jan Beulich wrote: On 11.06.2025 00:57, Jason Andryuk wrote: To add more flexibility in system configuration add the new DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model. Thie new flag corresponds to allowing XSM_DM_PRIV for the domain. This will enable runnin

[PATCH 5/8] pdx: allow optimizing PDX conversion helpers

There are four performance critical PDX conversion helpers that do the PFN to/from PDX and the physical addresses to/from directmap offsets translations. In the absence of an active PDX compression, those functions would still do the calculations needed, just to return the same input value as no t

[PATCH 3/8] kconfig: turn PDX compression into a choice

Rename the current CONFIG_PDX_COMPRESSION to CONFIG_PDX_MASK_COMPRESSION, and make it part of the PDX compression choice block, in preparation for adding further PDX compression algorithms. No functional change intended as the PDX compression defaults should still be the same for all architectures

[PATCH 0/8] pdx: introduce a new compression algorithm

Hello, This series implements a new PDX compression algorithm to cope with the spare memory maps found on the Intel Sapphire/Granite Rapids. Patches 1 to 5 prepare the existing code to make it easier to introduce a new PDX compression, including generalizing the initialization and setup functions

Re: [PATCH v5 04/18] xen/cpufreq: introduce new sub-hypercall to propagate CPPC data

On 27.05.2025 10:48, Penny Zheng wrote: > @@ -635,6 +641,124 @@ out: > return ret; > } > > +static void print_CPPC(const struct xen_processor_cppc *cppc_data) > +{ > +printk("\t_CPC: highest_perf=%u, lowest_perf=%u, " > + "nominal_perf=%u, lowest_nonlinear_perf=%u, " > +

Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV

On 2025-06-11 09:02, Jan Beulich wrote: On 11.06.2025 00:57, Jason Andryuk wrote: Xen includes disctinct concepts of a control domain (privileged) and a hardware domain, but there is only a single XSM_PRIV check. For dom0 this is not an issue as they are one and the same. With hyperlaunch and

Re: [PATCH v5 02/18] xen/cpufreq: move "init" flag into common structure

On 27.05.2025 10:48, Penny Zheng wrote: > AMD cpufreq cores will be intialized in two modes, legacy P-state mode, > and CPPC mode. So "init" flag shall be extracted from px-specific > "struct xen_processor_perf", and placed in the common > "struct processor_pminfo". Otherwise, later when introducin

Re: [PATCH v5 03/18] xen/cpufreq: extract _PSD info from "struct xen_processor_performance"

On 27.05.2025 10:48, Penny Zheng wrote: > @@ -201,14 +221,14 @@ int cpufreq_add_cpu(unsigned int cpu) > struct cpufreq_dom *cpufreq_dom = NULL; > struct cpufreq_policy new_policy; > struct cpufreq_policy *policy; > -struct processor_performance *perf; > +const struct xen_psd_

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

On 6/11/25 05:35, Jan Beulich wrote: > On 10.06.2025 12:12, Frediano Ziglio wrote: >> 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. > > And the other difference (compressed vs not) sti

Re: [PATCH v5 01/18] xen/pmstat: guard perf.states[] access with XEN_PX_INIT

On 27.05.2025 10:48, Penny Zheng wrote: > Accessing to perf.states[] array shall not be only guarded with user-defined > hypercall input, so we add XEN_PX_INIT check to gain safety. What is "guarded with user-defined hypercall input"? And what safety are we lacking? > --- a/xen/drivers/acpi/pmsta

[PATCH v3 5/6] arm/mpu: Define arm32 system registers

Fix the definition for HPRLAR. Define the base/limit address registers to access the first 32 protection regions. Signed-off-by: Ayan Kumar Halder --- Changes from :- v1 - v1 - New patch introduced in v3 (Extracted from "arm/mpu: Provide access to the MPU region from the C code"). xen/arch/ar

[PATCH v3 6/6] arm/mpu: Enable read/write to protection regions for arm32

Define prepare_selector(), read_protection_region() and write_protection_region() for arm32. Also, define GENERATE_{READ/WRITE}_PR_REG_OTHERS to access MPU regions from 32 to 255. Enable pr_{get/set}_{base/limit}(), region_is_valid() for arm32. Enable pr_of_addr() for arm32. Signed-off-by: Ayan K

[PATCH v3 4/6] arm/mpu: Move the functions to arm64 specific files

prepare_selector(), read_protection_region() and write_protection_region() differ significantly between arm32 and arm64. Thus, move these functions to their specific folders. GENERATE_{WRITE/READ}_PR_REG_CASE are duplicated for arm32 and arm64 so as to improve the code readability. Signed-off-by:

[PATCH v3 3/6] arm/mpu: Move domain-page.c to arm32 specific dir

Create xen/arch/arm/mpu/arm32 to hold arm32 specific bits. Signed-off-by: Ayan Kumar Halder --- Changes from :- v1..v2 - New patch in v3. xen/arch/arm/mpu/Makefile | 2 +- xen/arch/arm/mpu/arm32/Makefile| 1 + xen/arch/arm/mpu/{ => arm32}/domain-page.c | 0 3 files

[PATCH v3 2/6] arm/mpu: Provide and populate MPU C data structures

Modify Arm32 assembly boot code to reset any unused MPU region, initialise 'max_mpu_regions' with the number of supported MPU regions and set/clear the bitmap 'xen_mpumap_mask' used to track the enabled regions. Introduce cache.S to hold arm32 cache related functions. Use the macro definition for

[PATCH v3 1/6] arm/mpu: Introduce MPU memory region map structure

Introduce pr_t typedef which is a structure having the prbar and prlar members, each being structured as the registers of the AArch32 Armv8-R architecture. Also, define MPU_REGION_RES0 to 0 as there are no reserved 0 bits beyond the BASE or LIMIT bitfields in prbar or prlar respectively. In pr_of

[PATCH v3 0/6] Enable R52 support for the first chunk of MPU support

Hi all, This patch serie enables R52 support based on Luca's series. "[PATCH v6 0/6] First chunk for Arm R82 and MPU support". Changes from :- v1 .. v2 - Changes mentioned in individual patches v3 - Split "arm/mpu: Provide access to the MPU region from the C code" into 4 patches. Ayan Kumar Ha

Re: [PATCH v4 2/2] tools/arm: exclude iomem from domU extended regions

On Mon, Jun 09, 2025 at 02:34:33PM -0400, Stewart Hildebrand wrote: > When a device is passed through to a xl domU, the iomem ranges may > overlap with the extended regions. Remove iomem from extended regions. > > Signed-off-by: Stewart Hildebrand Reviewed-by: Anthony PERARD Thanks, -- Antho

Re: [PATCH v4 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions

On 11/06/2025 15:49, Stewart Hildebrand wrote: > On 6/10/25 03:27, Orzel, Michal wrote: >> On 09/06/2025 20:34, Stewart Hildebrand wrote: >>> Similarly to fba1b0974dd8, when a device is passed through to a >>> direct-map dom0less domU, the xen,reg ranges may overlap with the >>> extended regions

Re: [PATCH 07/11] xen/page_alloc: Set node affinity when claiming pages from an exact node

On 14.03.2025 18:24, Alejandro Vallejo wrote: > Set the domain's node affinity to the claimed node if the claim > specified an exact node. Do it immediately before making any changes in > case setting the affinity fails (even though it shouldn't). > > This allows preferentially allocating from the

Re: [PATCH v4 1/2] xen/arm: exclude xen,reg from direct-map domU extended regions

On 6/10/25 03:27, Orzel, Michal wrote: > On 09/06/2025 20:34, Stewart Hildebrand wrote: >> Similarly to fba1b0974dd8, when a device is passed through to a >> direct-map dom0less domU, the xen,reg ranges may overlap with the >> extended regions. Remove xen,reg from direct-map domU extended regions.

Re: [PATCH 04/11] xen: Add node argument to domain_{adjust_tot_pages,set_outstanding_pages}()

On 14.03.2025 18:24, Alejandro Vallejo wrote: > domain_adjust_tot_pages() decreases the outstanding claims of a domain > as pages are allocated, so that'll need to take into account the node in > which an allocation is done. Deallocations just pass NUMA_NO_NODE. > > domain_set_outstanding_pages()

Re: [PATCH 03/11] xen/page_alloc: Add static per-node counts of free pages

On 14.03.2025 18:24, Alejandro Vallejo wrote: > --- a/xen/common/page_alloc.c > +++ b/xen/common/page_alloc.c > @@ -485,6 +485,9 @@ static unsigned long node_need_scrub[MAX_NUMNODES]; > static unsigned long *avail[MAX_NUMNODES]; > static long total_avail_pages; > > +/* Per-node counts of free p

Re: [PATCH 0/4] XSM changes for split hardware / control domain

On 11.06.2025 00:57, Jason Andryuk wrote: > Theses are the broad changes needed for a split hardware / control > domain. > > An earlier posting gave device_model privileges to hardware domain. For > this posting, it was split out into a new capability. This way the > operator can choose where to

Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo

On 11.06.2025 00:57, Jason Andryuk wrote: > Allow the hwdom to access the console, and to access physical > information about the system. > > xenconsoled can read Xen's dmesg. If it's in hwdom, then that > permission would be required. Why would xenconsoled run in the hardware domain? It's purel

Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model

On 11.06.2025 00:57, Jason Andryuk wrote: > To add more flexibility in system configuration add the new > DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model. > > Thie new flag corresponds to allowing XSM_DM_PRIV for the domain. This > will enable running device model emulators (QEMU) f

Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains

On 11.06.2025 00:57, Jason Andryuk wrote: > In a disaggregated environment, dom0 is split into Control, Hardware, > and Xenstore domains, along with domUs. The is_control_domain() check > is not sufficient to handle all these cases. Add is_priv_domain() to > support allowing for the various domai

Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV

On 11.06.2025 00:57, Jason Andryuk wrote: > Xen includes disctinct concepts of a control domain (privileged) and a > hardware domain, but there is only a single XSM_PRIV check. For dom0 > this is not an issue as they are one and the same. > > With hyperlaunch and its build capabilities, a non-pri

Re: [PATCH 5/6] x86/paravirt: Switch MSR access pv_ops functions to instruction interfaces

On 13.05.25 09:44, Xin Li wrote: On 5/12/2025 4:20 AM, Jürgen Groß wrote: On 09.05.25 10:18, Xin Li wrote: On 5/6/2025 2:20 AM, Juergen Gross wrote: I'm trying to evaluate how to add the immediate form MSR instructions on top of this patch set.  And I'm close to get it done. There is somethin

Re: [PATCH] xen: move declarations of device_tree_get_{reg,u32}() to xen/device_tree.h

On 11/06/2025 13:44, Oleksii Kurochko wrote: > There is nothing Arm specific for these functions thereby it makes sense > to move their declarations to common header: xen/device_tree.h. I find it a bit odd that you don't mention that the definitions are already in common and therefore the protot

Re: [PATCH v4] x86/hvmloader: select xenpci MMIO BAR UC or WB MTRR cache attribute

On 10.06.2025 18:29, Roger Pau Monne wrote: > The Xen PCI device (vendor ID 0x5853) exposed to x86 HVM guests doesn't > have the functionality of a traditional PCI device. The exposed MMIO BAR > is used by some guests (including Linux) as a safe place to map foreign > memory, including the grant t

Re: [PATCH] ACPI: adjust decl of acpi_set_pdc_bits()

On 2025-06-11 13:53, Jan Beulich wrote: The commit referenced below changed the type of the first parameter. Misra C:2012 Rule 8.3 requires the declaration to follow suit. Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.c") Signed-off-by: Jan Beulich Reviewed-by: Nicola Vetrin

Re: [PATCH 5/6] vVMX: operand size in decode_vmx_inst()

On 11.06.2025 13:32, Andrew Cooper wrote: > On 11/06/2025 11:44 am, Jan Beulich wrote: >> Address size is entirely irrelevant to operand size determination; For >> VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while >> in 64-bit mode it's (naturally) 64 bits. For all other insn

[PATCH 1/6] vVMX: use reg_read()

Let's avoid such open-coding. There's also no need to use guest_cpu_user_regs(), when the function has a suitable parameter. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -2675,7 +2675,7 @@ int nvmx_n2_vmexit_handler(struct cpu_us

Re: [PATCH v4 01/20] xen/pmstat: consolidate code into pmstat.c

On 28.05.2025 11:16, Penny Zheng wrote: > @@ -518,34 +687,3 @@ int do_pm_op(struct xen_sysctl_pm_op *op) > > return ret; > } > - > -int acpi_set_pdc_bits(uint32_t acpi_id, XEN_GUEST_HANDLE(uint32) pdc) You can't change ... > --- a/xen/drivers/cpufreq/cpufreq.c > +++ b/xen/drivers/cpufreq/

[PATCH] ACPI: adjust decl of acpi_set_pdc_bits()

The commit referenced below changed the type of the first parameter. Misra C:2012 Rule 8.3 requires the declaration to follow suit. Fixes: bf0cd071db2a ("xen/pmstat: consolidate code into pmstat.c") Signed-off-by: Jan Beulich --- a/xen/include/xen/acpi.h +++ b/xen/include/xen/acpi.h @@ -186,7 +1

[PATCH] xen: move declarations of device_tree_get_{reg,u32}() to xen/device_tree.h

There is nothing Arm specific for these functions thereby it makes sense to move their declarations to common header: xen/device_tree.h. Signed-off-by: Oleksii Kurochko --- xen/arch/arm/include/asm/setup.h | 6 -- xen/include/xen/device_tree.h| 6 ++ 2 files changed, 6 insertions(+),

Re: [PATCH 5/6] vVMX: operand size in decode_vmx_inst()

On 11/06/2025 11:44 am, Jan Beulich wrote: > Address size is entirely irrelevant to operand size determination; For > VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while > in 64-bit mode it's (naturally) 64 bits. For all other insns it's 64 > bits (a physical address) or 128 bi

Re: [PATCH 2/6] vVMX: adjust reg_read() for 32-bit guests

On 11.06.2025 13:07, Andrew Cooper wrote: > On 11/06/2025 11:42 am, Jan Beulich wrote: >> Using the full 64-bit register values is wrong in this case; especially >> soon after a mode switch from long mode to 32-bit one upper halves of >> registers may continue to be non-zero. >> >> Fixes: 09fce8016

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

On 11.06.2025 12:49, Frediano Ziglio wrote: > On Wed, Jun 11, 2025 at 10:35 AM Jan Beulich wrote: >> >> On 10.06.2025 12:12, Frediano Ziglio wrote: >>> 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 a

Re: [PATCH 2/6] vVMX: adjust reg_read() for 32-bit guests

On 11/06/2025 11:42 am, Jan Beulich wrote: > Using the full 64-bit register values is wrong in this case; especially > soon after a mode switch from long mode to 32-bit one upper halves of > registers may continue to be non-zero. > > Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF in

[PATCH v3] x86/HVM: restrict use of pinned cache attributes as well as associated flushing

We don't permit use of uncachable memory types elsewhere unless a domain meets certain criteria. Enforce this also during registration of pinned cache attribute ranges. Furthermore restrict cache flushing to just - registration of uncachable ranges, - de-registration of cachable ranges. While the

Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT

On Wed, Jun 11, 2025 at 10:19:34AM +, Chen, Jiqian wrote: > Hi Roger, > > On 2025/6/10 15:08, Jan Beulich wrote: > > On 10.06.2025 05:52, Chen, Jiqian wrote: > >> On 2025/6/9 18:40, Roger Pau Monné wrote: > >>> On Mon, Jun 09, 2025 at 10:18:42AM +, Chen, Jiqian wrote: > On 2025/6/9 17

Re: [PATCH 1/6] vVMX: use reg_read()

On 11/06/2025 11:42 am, Jan Beulich wrote: > Let's avoid such open-coding. There's also no need to use > guest_cpu_user_regs(), when the function has a suitable parameter. > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper

[PATCH 6/6] vVMX: address size in decode_vmx_inst()

While the original use of the address size file in the instruction info provided was wrong, it still wants using: The offset into the designated segment still may need truncating accordingly. Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction") Signed-off-by: Jan Beulich

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

On Wed, Jun 11, 2025 at 10:35 AM Jan Beulich wrote: > > On 10.06.2025 12:12, Frediano Ziglio wrote: > > 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. > > And the other difference (co

[PATCH 2/6] vVMX: adjust reg_read() for 32-bit guests

Using the full 64-bit register values is wrong in this case; especially soon after a mode switch from long mode to 32-bit one upper halves of registers may continue to be non-zero. Fixes: 09fce8016596 ("Nested VMX: Emulation of guest VMXON/OFF instruction") Signed-off-by: Jan Beulich --- Note tha

Re: Xen 4.21 Development Update [May]

Hello Mykola, On 6/11/25 9:03 AM, Mykola Kvach wrote: === ARM === * SMMU handling for PCIe Passthrough on ARM (v11) - Mykyta Poturai - https://lore.kernel.org/xen-devel/cover.1741958647.git.mykyta_potu...@epam.com/ - https://patchew.org/Xen/cover.1748422217.git.mykyta._5fpotu...@epa

[PATCH 4/6] vVMX: prefer hvm_long_mode_active() in decode_vmx_inst()

All affected VMX insns are invalid to use from compatibility mode, and hence the more expensive vmx_guest_x86_mode() doesn't need using here. Signed-off-by: Jan Beulich --- a/xen/arch/x86/hvm/vmx/vvmx.c +++ b/xen/arch/x86/hvm/vmx/vvmx.c @@ -418,7 +418,7 @@ static int decode_vmx_inst(struct cpu_u

[PATCH 5/6] vVMX: operand size in decode_vmx_inst()

Address size is entirely irrelevant to operand size determination; For VMREAD and VMWRITE outside of 64-bit mode operand size is 32 bits, while in 64-bit mode it's (naturally) 64 bits. For all other insns it's 64 bits (a physical address) or 128 bits (INVEPT, INVVPID). To limit the amount of change

[PATCH 3/6] vVMX: adjust reg_write() for 32-bit guests

Using the full 64-bit register values is slightly wrong in this case; 32-bit writes of registers would normally zero-extend the value to 64 bits. The difference may be observable after switching (back) to 64-bit mode (even if as per the spec upper halves of registers are undefined after a mode swit

[PATCH 0/6] vVMX: VMX insn handling

Originally, while dealing with some other patch, I merely noticed the issue addressed by patch 2. That quickly grew then, though. 1: use reg_read() 2: adjust reg_read() for 32-bit guests 3: adjust reg_write() for 32-bit guests 4: prefer hvm_long_mode_active() in decode_vmx_inst() 5: operand size i

Re: [PATCH v4 3/9] xen/riscv: imsic_init() implementation

On 6/10/25 5:17 PM, Jan Beulich wrote: On 05.06.2025 17:58, Oleksii Kurochko wrote: --- /dev/null +++ b/xen/arch/riscv/imsic.c @@ -0,0 +1,358 @@ +/* SPDX-License-Identifier: MIT */ + +/* + * xen/arch/riscv/imsic.c + * + * RISC-V Incoming MSI Controller support + * + * (c) Microchip Technology I

Re: [PATCH v5 04/10] vpci: Refactor REGISTER_VPCI_INIT

Hi Roger, On 2025/6/10 15:08, Jan Beulich wrote: > On 10.06.2025 05:52, Chen, Jiqian wrote: >> On 2025/6/9 18:40, Roger Pau Monné wrote: >>> On Mon, Jun 09, 2025 at 10:18:42AM +, Chen, Jiqian wrote: On 2025/6/9 17:29, Roger Pau Monné wrote: > On Mon, Jun 09, 2025 at 07:50:21AM +,

Re: [PATCH v2] x86/HVM: restrict use of pinned cache attributes as well as associated flushing

On 10.06.2025 17:54, Roger Pau Monné wrote: > On Tue, Jun 10, 2025 at 04:13:40PM +0200, Jan Beulich wrote: >> On 10.06.2025 15:24, Roger Pau Monné wrote: >>> IMO the added complexity here is not worth the performance >>> improvement, not without a clear justification that it's needed. >> >> Well, o

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

On 10.06.2025 12:12, Frediano Ziglio wrote: > --- a/xen/arch/x86/Makefile > +++ b/xen/arch/x86/Makefile > @@ -238,6 +238,7 @@ endif > > $@.map > ifeq ($(CONFIG_DEBUG_INFO),y) > $(if $(filter --strip-debug,$(EFI_LDFLAGS)),:$(space))$(OBJCOPY) -O > elf64-x86-64 $@ $@.elf > +

[PATCH v3] x86: FLUSH_CACHE -> FLUSH_CACHE_EVICT

This is to make the difference to FLUSH_CACHE_WRITEBACK more explicit. Requested-by: Andrew Cooper Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné --- Note that this (of course) collides with "x86/HVM: restrict use of pinned cache attributes as well as associated flushing". --- v3: Re-base

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

On 10.06.2025 12:12, Frediano Ziglio wrote: > 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. And the other difference (compressed vs not) still remains. > xen.efi.elf can be used for deb

Re: [PATCH] xen/domain: fix late hwdom feature

On 11.06.2025 01:42, dm...@proton.me wrote: > From: Denis Mukhin > > Fix get_initial_domain_id() which how returns hardware_domid and breaks late > hwdom feature [1]. > > [1] > https://lore.kernel.org/xen-devel/a4c860d7-1fa0-43f4-8ae1-af59b7c65...@xen.org/ > Reported-by: Julien Grall > Fixe

Re: [PATCH v2 3/3] Disallow most command-line options when lockdown mode is enabled

On Tue, Jun 10, 2025 at 4:56 PM Jan Beulich wrote: > >It's still being left entirely unclear what the criteria are by which an >option can / cannot be marked "safe". The purpose of lockdown mode is to protect Xen from unauthorized code execution in Secure Boot mode. Xen especially needs protectio

Re: [PATCH v4][PART 2 01/10] xen/x86: Move freeze/thaw_domains to common code

On 11.06.2025 07:55, Mykola Kvach wrote: > On Mon, Jun 2, 2025 at 12:20 PM Jan Beulich wrote: >> >> On 02.06.2025 11:04, Mykola Kvach wrote: >>> From: Mirela Simonovic >>> >>> The freeze_domains and thaw_domains functions are currently defined >>> in x86-specific suspend code. These functions are

Re: [PATCH v4 1/9] xen/riscv: dt_processor_hartid() implementation

On 11.06.2025 10:26, Oleksii Kurochko wrote: > > On 6/10/25 4:08 PM, Jan Beulich wrote: >> On 05.06.2025 17:58, Oleksii Kurochko wrote: >>> @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void) >>> cpumask_set_cpu(0, &cpu_possible_map); >>> cpumask_set_cpu(0, &cpu_online_map); >>>

Re: [PATCH v4 1/9] xen/riscv: dt_processor_hartid() implementation

On 6/10/25 4:08 PM, Jan Beulich wrote: On 05.06.2025 17:58, Oleksii Kurochko wrote: @@ -14,3 +17,77 @@ void __init smp_prepare_boot_cpu(void) cpumask_set_cpu(0, &cpu_possible_map); cpumask_set_cpu(0, &cpu_online_map); } + +/** + * dt_get_hartid - Get the hartid from a CPU device n

Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model

Acked-by: Christian Lindig > On 10 Jun 2025, at 23:57, Jason Andryuk wrote: > > To add more flexibility in system configuration add the new > DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model. > > Thie new flag corresponds to allowing XSM_DM_PRIV for the domain. This > will enable

Re: Xen 4.21 Development Update [May]

Hi Oleksii, On Mon, Jun 2, 2025 at 7:37 PM Oleksii Kurochko wrote: > > Hello everyone, > > This email only tracks big items for xen.git tree. Please reply for > items you > would like to see in 4.21 so that people have an idea what is going on and > prioritise accordingly. > > You're welcome to p