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

On 12.06.2025 23:32, Stefano Stabellini wrote: > On Thu, 12 Jun 2025, Andrew Cooper wrote: >> +Support in Xen >> +-- >> + >> +There are multiple ways to achieve this security goal, with differing >> +tradeoffs for the eventual system. >> + >> +On one end of the spectrum is the Unified K

RE: [PATCH v4 17/20] xen/sysctl: make CONFIG_COVERAGE depend on CONFIG_SYSCTL

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

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

On 12.06.2025 18:56, Jason Andryuk wrote: > On 2025-06-12 03:52, Jan Beulich wrote: >> On 11.06.2025 06:20, Jason Andryuk wrote: >>> On 2025-06-11 09:17, Jan Beulich wrote: On 11.06.2025 00:57, Jason Andryuk wrote: > --- a/xen/xsm/silo.c > +++ b/xen/xsm/silo.c > @@ -20,6 +20,12 @@

Re: [PATCH v5 16/18] tools: drop "has_num" condition check for cppc mode

On 27.05.2025 10:48, Penny Zheng wrote: > In `xenpm get-cpufreq-para `, ->freq_num and ->cpu_num checking are > tied together via variable "has_num", while ->freq_num only has non-zero value > when cpufreq driver in legacy P-states mode. > > So we drop the "has_num" condition check, and mirror the

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

On 12/06/2025 15:22, Jan Beulich wrote: > On 12.06.2025 15:15, Tu Dinh wrote: >> On 12/06/2025 02:03, Andrew Cooper wrote: >>> +Secure Boot Advanced Targeting >>> +^^ >>> + >>> +SBAT is a recovation scheme for Secure Boot enabled components, using a >>> +generation based

Re: [PATCH v5 17/18] tools: optimize cpufreq average freq print

On 27.05.2025 10:48, Penny Zheng wrote: > Unlike Cx/Px states, for which we need an extra loop to summerize residency ( > sum_cx[]/sum_px[]), we could call get_avgfreq_by_cpuid() right before > printing. > Also, with introduction of CPPC mode, average frequency print shall > not depend on the exis

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

On 12.06.2025 15:15, Tu Dinh wrote: > On 12/06/2025 02:03, Andrew Cooper wrote: >> +Secure Boot Advanced Targeting >> +^^ >> + >> +SBAT is a recovation scheme for Secure Boot enabled components, using a >> +generation based scheme. See `Shim SBAT.md >> +

Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option

On 6/11/25 01:23, Jan Beulich wrote: > On 10.06.2025 19:46, Stewart Hildebrand wrote: >> --- a/xen/arch/arm/Kconfig >> +++ b/xen/arch/arm/Kconfig >> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION >> >> source "arch/arm/firmware/Kconfig" >> >> +config PCI_PASSTHROUGH >> +bool "PCI passthroug

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

On Thu, Jun 12, 2025 at 10:27:03AM +0200, Jan Beulich wrote: > On 11.06.2025 19:16, Roger Pau Monne wrote: > > 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 [

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

On 6/11/25 1:53 PM, Orzel, Michal wrote: 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 al

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

On 12.06.2025 01:58, Andrew Cooper wrote: > Obviously RFC at this point. It's worth saying that XenServer is intending to > use Shim and get a signature from Microsoft, retaining all exiting features > such as Livepatching and Kexec crash reporting. > > This trails off into more TODOs towards the

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

On Thu, Jun 12, 2025 at 11:03:21AM +0200, Jan Beulich wrote: > On 11.06.2025 19:16, Roger Pau Monne wrote: > > @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void) > > * On systems with CONFIG_BIGMEM there's no packing, and so there's no > > * such restriction. > > */ >

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

On 12.06.2025 12:48, Roger Pau Monné wrote: > On Thu, Jun 12, 2025 at 11:11:14AM +0200, Jan Beulich wrote: >> On 11.06.2025 19:16, Roger Pau Monne wrote: >>> This is the code already present and used by x86 in setup_max_pdx(), which >>> takes into account the current PDX compression, plus the limit

Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver

On 02/06/2025 10:17, Bertrand Marquis wrote: > Hi Stefano and Oleksii, > >> On 23 May 2025, at 22:06, Stefano Stabellini wrote: >> >> One question for Bertrand below >> >> >> On Mon, 19 May 2025, Oleksii Moisieiev wrote: >>> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware

Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu

Hi Stefano, I'm very sorry for a long silence. Please see my answers below: On 22/05/2025 03:25, Stefano Stabellini wrote: > On Mon, 19 May 2025, Oleksii Moisieiev wrote: >> From: Grygorii Strashko >> >> Add chained handling of assigned DT devices to support access-controller >> functionality thr

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

On 12.06.2025 12:46, Roger Pau Monné wrote: > On Thu, Jun 12, 2025 at 11:03:21AM +0200, Jan Beulich wrote: >> On 11.06.2025 19:16, Roger Pau Monne wrote: >>> @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void) >>> * On systems with CONFIG_BIGMEM there's no packing, and so there's n

Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver

Hi Stefano, I'm very sorry for a long silence. Please see my answers below: On 23/05/2025 23:06, Stefano Stabellini wrote: > One question for Bertrand below > > > On Mon, 19 May 2025, Oleksii Moisieiev wrote: >> This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A >> (TF-A)

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

On 12.06.2025 12:51, Roger Pau Monné wrote: > On Thu, Jun 12, 2025 at 10:36:36AM +0200, Jan Beulich wrote: >> On 11.06.2025 19:16, Roger Pau Monne wrote: >>> @@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn) >>> return pdx_to_pfn(pdx - 1) + 1; >>> } >>> >>> +#ifndef CONFIG

Re: [RFC PATCH v4 8/8] docs: arm: proposal to add separate SCMI node for Xen agent

On 23/05/2025 23:19, Stefano Stabellini wrote: > On Mon, 19 May 2025, Oleksii Moisieiev wrote: >> From: Grygorii Strashko >> >> Proposal description to add separate SCMI DT node for Xen management agent >> under "chosen" or xen-config node, like Hyperlaunch "xen,config". > I think it is OK to plac

Re: [RFC PATCH v4 6/8] xen/arm: scmi: introduce SCI SCMI SMC multi-agent driver

On 02.06.25 10:17, Bertrand Marquis wrote: Hi Stefano and Oleksii, On 23 May 2025, at 22:06, Stefano Stabellini wrote: One question for Bertrand below On Mon, 19 May 2025, Oleksii Moisieiev wrote: This patch introduces SCI driver to support for ARM EL3 Trusted Firmware-A (TF-A) which pr

Re: [RFC] Proposed x86 shadow paging changes

On 12.06.2025 13:45, Teddy Astie wrote: > In Xen x86, there is the shadow paging that could be used in some cases > (notably with HVM), and is used when HAP is not available. It may also > be used in very specific cases for PV guests. > > With the vast majority of hardware supporting HAP (throug

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

On Thu, Jun 12, 2025 at 06:13:48PM +0200, Anthony PERARD wrote: > On Thu, Jun 12, 2025 at 04:56:17PM +0200, Roger Pau Monné wrote: > > On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote: > > > On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote: > > > > diff --git a/docs/man

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

On 6/11/25 3:14 PM, Sergii Dmytruk wrote: 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: [PATCH v3 04/22] x86/boot/slaunch-early: implement early initialization

On Thu, Jun 12, 2025 at 09:30:55AM -0700, ross.philip...@oracle.com wrote: > On 6/11/25 3:14 PM, Sergii Dmytruk wrote: > > 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, > > > > +

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

On Thu, Jun 12, 2025 at 10:02:33AM +0200, Jan Beulich wrote: > On 12.06.2025 00:14, Sergii Dmytruk wrote: > > On Tue, Jun 03, 2025 at 09:17:29AM -0700, ross.philip...@oracle.com wrote: > >>> +static inline void *txt_init(void) > >>> +{ > >>> +void *txt_heap; > >>> + > >>> +/* Clear the TXT

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

On 2025-06-12 03:36, Jan Beulich wrote: On 11.06.2025 05:13, Jason Andryuk wrote: 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.

[PATCH 0/6] mm: Consolidate lazy MMU mode context

Hi All, Consolidate arch_enter|leave|flush_lazy_mmu_mode() context and protect with a lock not only user, but also kernel mappings before entering the lazy MMU mode. For not fully preemptible (Real-Time) kernels that simplifies semantics - while the mode is active the code should assume it is exe

[PATCH 2/6] mm: Lock kernel page tables before entering lazy MMU mode

As a follow-up to commit 691ee97e1a9d ("mm: fix lazy mmu docs and usage") take a step forward and protect with a lock not only user, but also kernel mappings before entering the lazy MMU mode. With that the semantics of arch_enter|leave_lazy_mmu_mode() callbacks is consolidated, which allows furthe

[PATCH 1/6] mm: Cleanup apply_to_pte_range() routine

Reverse 'create' vs 'mm == &init_mm' conditions and move page table mask modification out of the atomic context. This is a prerequisite for locking kernel page tables. Reviewed-by: Nicholas Piggin Signed-off-by: Alexander Gordeev --- mm/memory.c | 28 +--- 1 file changed

[PATCH 5/6] powerpc/64s: Do not disable preemption in lazy MMU mode

Commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu mode") is not necessary anymore, since the lazy MMU mode is entered with a spinlock held and powerpc does not support Real-Time. Thus, upon entering the lazy mode the preemption is already disabled. Signed-off-by: Alexander Gor

[PATCH 6/6] powerpc/64s: Do not re-activate batched TLB flush

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 never called, so remove it. Signed-off-by: Alexander Gordeev --- arch/powerpc/include/asm/thread_info.h | 2 -- arch

[PATCH 3/6] mm/debug: Detect wrong arch_enter_lazy_mmu_mode() contexts

Make default arch_enter|leave|flush_lazy_mmu_mode() callbacks complain on enabled preemption to detect wrong contexts. That could help to prevent the complicated lazy MMU mode semantics misuse, such like one that was solved with commit b9ef323ea168 ("powerpc/64s: Disable preemption in hash lazy mmu

[PATCH 4/6] sparc/mm: Do not disable preemption in lazy MMU mode

Commit a1d416bf9faf ("sparc/mm: disable preemption in lazy mmu mode") is not necessary anymore, since the lazy MMU mode is entered with a spinlock held and sparc does not support Real-Time. Thus, upon entering the lazy mode the preemption is already disabled. Signed-off-by: Alexander Gordeev ---

Re: [PATCH] x86: Fix build warnings about export.h

On Thu, Jun 12, 2025 at 05:32:28PM +0800, Zhenghan Cheng wrote: > After commit a934a57a42f64a4 ("scripts/misc-check: > check missing #include when W=1") > and commit 7d95680d64ac8e836c ("scripts/misc-check: > check unnecessary #include when W=1"), > we get some build warnings with W=1,such as: >

Re: [RFC] Proposed x86 shadow paging changes

On 12/06/2025 18:48, Teddy Astie wrote: > Le 12/06/2025 à 14:12, Jan Beulich a écrit : >> On 12.06.2025 13:45, Teddy Astie wrote: >>> In Xen x86, there is the shadow paging that could be used in some cases >>> (notably with HVM), and is used when HAP is not available. It may also >>> be used in ver

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

On 2025-06-12 03:52, Jan Beulich wrote: On 11.06.2025 06:20, Jason Andryuk wrote: 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_doma

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

On Thu, Jun 12, 2025 at 04:56:17PM +0200, Roger Pau Monné wrote: > On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote: > > 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..dd

Re: [RFC] Proposed x86 shadow paging changes

Le 12/06/2025 à 14:12, Jan Beulich a écrit : > On 12.06.2025 13:45, Teddy Astie wrote: >> In Xen x86, there is the shadow paging that could be used in some cases >> (notably with HVM), and is used when HAP is not available. It may also >> be used in very specific cases for PV guests. >> >> With the

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

On 2025-06-12 12:56, Jason Andryuk wrote: On 2025-06-12 03:52, Jan Beulich wrote: On 11.06.2025 06:20, Jason Andryuk wrote: 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 d

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

On Thu, Jun 12, 2025 at 11:22:39AM -0400, Demi Marie Obenour wrote: > On 6/12/25 06:06, Jan Beulich wrote: > > On 12.06.2025 01:58, Andrew Cooper wrote: > >> 2) Pre-boot DMA Protection. Microsoft consider this a platform feature > >> requiring OEM enablement, and do not consider its absence to be

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

On Thu, 12 Jun 2025, 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:

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

On Wed, Jun 11, 2025 at 11:20:29AM +0200, Jan Beulich wrote: > 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-

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

On 11.06.2025 19:16, Roger Pau Monne wrote: > 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 inp

Re: [PATCH] x86: Fix build warnings about export.h

On Thu, Jun 12, 2025 at 1:19 PM Juergen Gross wrote: > > On 12.06.25 11:32, Zhenghan Cheng wrote: > > After commit a934a57a42f64a4 ("scripts/misc-check: > > check missing #include when W=1") > > and commit 7d95680d64ac8e836c ("scripts/misc-check: > > check unnecessary #include when W=1"), > > we

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

The definitions of device_tree_get_reg() and device_tree_get_u32() are already in common code, so move their prototypes there as well. Signed-off-by: Oleksii Kurochko Reviewed-by: Michal Orzel --- Changes in v2: - Update the commit message. - Add Reviewed-by: Michal Orzel . --- xen/arch/arm/i

Re: [PATCH v5 06/18] xen/x86: introduce "cpufreq=amd-cppc" xen cmdline

On 27.05.2025 10:48, Penny Zheng wrote: > Users need to set "cpufreq=amd-cppc" in xen cmdline to enable > amd-cppc driver, which selects ACPI Collaborative Performance > and Power Control (CPPC) on supported AMD hardware to provide a > finer grained frequency control mechanism. > `verbose` option c

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

On Thu, Jun 12, 2025 at 10:32:17AM +0200, Jan Beulich wrote: > On 11.06.2025 19:16, Roger Pau Monne wrote: > > --- a/xen/arch/arm/setup.c > > +++ b/xen/arch/arm/setup.c > > @@ -255,6 +255,10 @@ void __init init_pdx(void) > > { > > const struct membanks *mem = bootinfo_get_mem(); > > padd

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

On Thu, Jun 12, 2025 at 10:36:36AM +0200, Jan Beulich wrote: > On 11.06.2025 19:16, Roger Pau Monne wrote: > > @@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn) > > return pdx_to_pfn(pdx - 1) + 1; > > } > > > > +#ifndef CONFIG_PDX_NONE > > + > > +#ifdef CONFIG_X86 > > +# i

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

On Thu, Jun 12, 2025 at 11:11:14AM +0200, Jan Beulich wrote: > On 11.06.2025 19:16, Roger Pau Monne wrote: > > 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 retur

[PATCH v6 0/4] Add support for R-Car Gen4 PCI host controller

This series adds support for R-Car Gen4 PCI host controller. To fully support the controller, the following changes were made: - Generic mechanism to support PCI child buses is added. - Private data for PCI host bridge and means to access it are added. The series was tested as a part of the pci-p

[PATCH v6 4/4] xen/arm: add support for R-Car Gen4 PCI host controller

From: Oleksandr Andrushchenko Add support for Renesas R-Car Gen4 PCI host controller, specifically targeting the S4 and V4H SoCs. The implementation includes configuration read/write operations for both root and child buses. For accessing the child bus, iATU is used for address translation. The

[PATCH v6 2/4] xen/arm: make pci_host_common_probe return the bridge

From: Oleksandr Andrushchenko Some of the PCI host bridges require additional processing during the probe phase. For that they need to access struct bridge of the probed host, so return pointer to the new bridge from pci_host_common_probe. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: M

[PATCH v6 3/4] xen/arm: add support for PCI child bus

From: Oleksandr Andrushchenko PCI host bridges often have different ways to access the root and child bus configuration spaces. One of the examples is Designware's host bridge and its multiple clones [1]. Linux kernel implements this by instantiating a child bus when device drivers provide not o

[PATCH v6 1/4] xen/arm: allow PCI host bridge to have private data

From: Oleksandr Andrushchenko Some of the PCI host bridges require private data. Add priv field to struct pci_host_bridge, so such bridges may populate it with their private data. Signed-off-by: Oleksandr Andrushchenko Signed-off-by: Mykyta Poturai Reviewed-by: Stefano Stabellini --- v5->v6:

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

Le 12/06/2025 à 12:08, Jan Beulich a écrit : > On 12.06.2025 01:58, Andrew Cooper wrote: >> + >> +Lockdown Mode >> +^ >> + >> +A mode which causes the enforcement of the properties necessary to conform >> to >> +the Secure Boot specification. Lockdown Mode is forced active when Secure

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

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.efi.elf can be used for debugging. Signed-off-by: Frediano Ziglio --- Changes since v1: - avoid leaving target if some command fails --- d

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

On 27.05.2025 10:48, Penny Zheng wrote: > --- a/xen/drivers/cpufreq/cpufreq.c > +++ b/xen/drivers/cpufreq/cpufreq.c > @@ -69,8 +69,55 @@ enum cpufreq_xen_opt __initdata cpufreq_xen_opts[2] = { > CPUFREQ_xen, > CPUFREQ_none }; > unsigned int

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

On 12/06/2025 10:35, Luca Fancellu wrote: Hi Ayan, Hi Luca, On 11 Jun 2025, at 15:35, Ayan Kumar Halder wrote: 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

Re: [PATCH] x86: Fix build warnings about export.h

On 12.06.25 11:32, Zhenghan Cheng wrote: After commit a934a57a42f64a4 ("scripts/misc-check: check missing #include when W=1") and commit 7d95680d64ac8e836c ("scripts/misc-check: check unnecessary #include when W=1"), we get some build warnings with W=1,such as: arch/x86/coco/sev/core.c: warnin

[RFC] Proposed x86 shadow paging changes

Hello, In Xen x86, there is the shadow paging that could be used in some cases (notably with HVM), and is used when HAP is not available. It may also be used in very specific cases for PV guests. With the vast majority of hardware supporting HAP (through EPT or NPT), it's rarely used in practi

Re: [PATCH v5 07/18] xen/cpufreq: disable px statistic info in amd-cppc mode

On 27.05.2025 10:48, Penny Zheng wrote: > We want to bypass construction of px statistic info, while not bypassing > cpufreq_statistic_lock initialization for a good reason, in > cpufreq_statistic_init() for amd-cppc mode, as P-states is not necessary > there. > > Signed-off-by: Penny Zheng > Ac

Re: [PATCH v5 08/18] xen/cpu: Expand core frequency calculation for AMD Family 1Ah CPUs

On 27.05.2025 10:48, Penny Zheng wrote: > --- a/xen/arch/x86/cpu/amd.c > +++ b/xen/arch/x86/cpu/amd.c > @@ -583,12 +583,40 @@ static void amd_get_topology(struct cpuinfo_x86 *c) >: c->cpu_core_id); > } > > +static unsigned int attr_cons

Re: [RFC PATCH v4 5/8] xen/domctl: extend XEN_DOMCTL_assign_device to handle not only iommu

On 12.06.25 14:42, Oleksii Moisieiev wrote: Hi Stefano, I'm very sorry for a long silence. Please see my answers below: On 22/05/2025 03:25, Stefano Stabellini wrote: On Mon, 19 May 2025, Oleksii Moisieiev wrote: From: Grygorii Strashko Add chained handling of assigned DT devices to suppo

Re: [PATCH v5 09/18] xen/amd: introduce amd_process_freq() to get processor frequency

On 27.05.2025 10:48, Penny Zheng wrote: > When _CPC table could not provide processor frequency range > values for Xen governor, we need to read processor max frequency > as anchor point. > So we extract amd cpu core frequency calculation logic from amd_log_freq(), > and wrap it as a new helper amd

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

On 12/06/2025 02:03, 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:

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

On 12.06.2025 06:09, Penny, Zheng wrote: >> -Original Message- >> From: Jan Beulich >> Sent: Tuesday, June 10, 2025 9:01 PM >> >> On 28.05.2025 11:16, Penny Zheng wrote: >>> Remove all "depends on !PV_SHIM_EXCLUSIVE" (also the functionally >>> equivalent "if !...") in Kconfig file, since n

RE: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP

[Public] Hi, > -Original Message- > From: Jan Beulich > Sent: Tuesday, June 10, 2025 9:41 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:

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

On 11.06.2025 19:16, Roger Pau Monne wrote: > --- a/xen/arch/arm/setup.c > +++ b/xen/arch/arm/setup.c > @@ -255,6 +255,10 @@ void __init init_pdx(void) > { > const struct membanks *mem = bootinfo_get_mem(); > paddr_t bank_start, bank_size, bank_end; > +unsigned int bank; > + > +f

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

On 11.06.2025 19:16, Roger Pau Monne wrote: > 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, 00407ff

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

On 11.06.2025 19:16, Roger Pau Monne wrote: > 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 d

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

On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote: > 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/x

Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option

On 12.06.2025 15:39, Stewart Hildebrand wrote: > On 6/11/25 01:23, Jan Beulich wrote: >> On 10.06.2025 19:46, Stewart Hildebrand wrote: >>> --- a/xen/arch/arm/Kconfig >>> +++ b/xen/arch/arm/Kconfig >>> @@ -258,6 +258,16 @@ config PARTIAL_EMULATION >>> >>> source "arch/arm/firmware/Kconfig" >>>

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

On 12/06/2025 16:57, Roger Pau Monné wrote: > On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote: >> 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 >>> ---

Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option

On 6/12/25 10:58, Jan Beulich wrote: > On 12.06.2025 15:39, Stewart Hildebrand wrote: >> On 6/11/25 01:23, Jan Beulich wrote: >>> On 10.06.2025 19:46, Stewart Hildebrand wrote: --- a/xen/arch/arm/Kconfig +++ b/xen/arch/arm/Kconfig @@ -258,6 +258,16 @@ config PARTIAL_EMULATION

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

On 6/12/25 06:06, Jan Beulich wrote: > On 12.06.2025 01:58, Andrew Cooper wrote: >> 2) Pre-boot DMA Protection. Microsoft consider this a platform feature >> requiring OEM enablement, and do not consider its absence to be a Secure Boot >> vulnerability. But, it is less clear what the policy ought

Re: [PATCH v7] xen/arm: pci: introduce PCI_PASSTHROUGH Kconfig option

On 12.06.2025 17:18, Stewart Hildebrand wrote: > On 6/12/25 10:58, Jan Beulich wrote: >> On 12.06.2025 15:39, Stewart Hildebrand wrote: >>> On 6/11/25 01:23, Jan Beulich wrote: On 10.06.2025 19:46, Stewart Hildebrand wrote: > --- a/xen/arch/arm/Kconfig > +++ b/xen/arch/arm/Kconfig

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

On Thu, Jun 12, 2025 at 03:12:03PM +, Tu Dinh wrote: > On 12/06/2025 16:57, Roger Pau Monné wrote: > > On Wed, Jun 11, 2025 at 07:26:06PM +0200, Anthony PERARD wrote: > >> On Tue, Jun 10, 2025 at 06:29:30PM +0200, Roger Pau Monne wrote: > >>> @@ -271,6 +279,44 @@ void pci_setup(void) > >>>

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

On Wed, Jun 11, 2025 at 06:58:31PM +0100, Andrew Cooper wrote: > 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 +4

Re: [PATCH v4 02/25] drm/dumb-buffers: Provide helper to set pitch and size

Hi, On 11/03/2025 17:47, Thomas Zimmermann wrote: > Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer > scanline pitch and allocation size. Implementations of struct > drm_driver.dumb_create can call the new helper for their size > computations. > > There is currently quite a bit o

Re: [PATCH v4 03/25] drm/gem-dma: Compute dumb-buffer sizes with drm_mode_size_dumb()

Hi, On 11/03/2025 17:47, Thomas Zimmermann wrote: > Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and > buffer size. Align the pitch to a multiple of 8. > > Push the current calculation into the only direct caller imx. Imx's > hardware requires the framebuffer width to be aligne

Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree

On 12.06.2025 10:20, Alejandro Vallejo wrote: > On Wed Jun 11, 2025 at 7:35 AM CEST, Jan Beulich wrote: >> On 10.06.2025 19:39, Jason Andryuk wrote: >>> >>> >>> On 2025-06-10 02:56, Jan Beulich wrote: On 09.06.2025 19:07, Jason Andryuk wrote: > On 2025-04-29 08:36, Alejandro Vallejo wrote:

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

On 11.06.2025 19:16, Roger Pau Monne wrote: > @@ -80,6 +81,39 @@ unsigned long get_max_pfn(unsigned long top_pfn) > return pdx_to_pfn(pdx - 1) + 1; > } > > +#ifndef CONFIG_PDX_NONE > + > +#ifdef CONFIG_X86 > +# include > +# define MAX_PFN_RANGES E820MAX > +#elif defined(CONFIG_HAS_DEVICE_T

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

[Public] > -Original Message- > From: Jan Beulich > Sent: Thursday, June 12, 2025 3:02 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: [PA

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

On 11.06.2025 19:16, Roger Pau Monne wrote: > @@ -498,14 +474,15 @@ struct domain *alloc_domain_struct(void) > * On systems with CONFIG_BIGMEM there's no packing, and so there's no > * such restriction. > */ > -#if defined(CONFIG_BIGMEM) || !defined(CONFIG_PDX_COMPRESSION) > -

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

On 11/06/2025 19:51, 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. > > Take the opportunity to update the c

Re: [PATCH v6 06/12] x86/hyperlaunch: obtain cmdline from device tree

On Wed Jun 11, 2025 at 7:35 AM CEST, Jan Beulich wrote: > On 10.06.2025 19:39, Jason Andryuk wrote: >> >> >> On 2025-06-10 02:56, Jan Beulich wrote: >>> On 09.06.2025 19:07, Jason Andryuk wrote: On 2025-04-29 08:36, Alejandro Vallejo wrote: > From: "Daniel P. Smith" > > Add supp

Re: [PATCH v4 01/25] drm/dumb-buffers: Sanitize output on errors

Hi, On 11/03/2025 17:47, Thomas Zimmermann wrote: > The ioctls MODE_CREATE_DUMB and MODE_MAP_DUMB return results into a > memory buffer supplied by user space. On errors, it is possible that > intermediate values are being returned. The exact semantics depends > on the DRM driver's implementation

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

On 12.06.2025 06:35, Penny, Zheng wrote: >> -Original Message- >> From: Jan Beulich >> Sent: Tuesday, June 10, 2025 9:05 PM >> >> On 28.05.2025 11:16, Penny Zheng wrote: >>> From: Stefano Stabellini >>> >>> We introduce a new Kconfig CONFIG_SYSCTL, which shall only be disabled >>> on some

Re: [PATCH v4 11/20] xen/pmstat: introduce CONFIG_PM_OP

On 12.06.2025 09:00, Penny, Zheng wrote: > [Public] > > Hi, > >> -Original Message- >> From: Jan Beulich >> Sent: Tuesday, June 10, 2025 9:41 PM >> To: Penny, Zheng >> Cc: Huang, Ray ; Andrew Cooper >> ; Roger Pau Monné ; >> Anthony PERARD ; Orzel, Michal >> ; Julien Grall ; Stefano Sta

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

On Wed, Jun 11, 2025 at 08:33:55PM +0100, Andrew Cooper wrote: > 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 no

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

On 11.06.2025 22:22, Stewart Hildebrand wrote: > 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

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

On 12.06.2025 10:52, Penny, Zheng wrote: >> -Original Message- >> From: Jan Beulich >> Sent: Thursday, June 12, 2025 3:02 PM >> >> On 12.06.2025 06:09, Penny, Zheng wrote: -Original Message- From: Jan Beulich Sent: Tuesday, June 10, 2025 9:01 PM On 28.05.2

[PATCH v6 4/8] vpci: Hide extended capability when it fails to initialize

When vpci fails to initialize a extended capability of device, it just returns an error and vPCI gets disabled for the whole device. So, add function to hide extended capability when initialization fails. And remove the failed extended capability handler from vpci extended capability list. Signed

[PATCH v6 7/8] vpci/msi: Free MSI resources when init_msi() fails

When init_msi() fails, current logic return fail and free MSI-related resources in vpci_deassign_device(). But the previous new changes will hide MSI capability and return success, it can't reach vpci_deassign_device() to remove resources if hiding success, so those resources must be removed in cle

[PATCH v6 8/8] vpci/msix: Free MSIX resources when init_msix() fails

When init_msix() fails, current logic return fail and free MSIX-related resources in vpci_deassign_device(). But the previous new changes will hide MSIX capability and return success, it can't reach vpci_deassign_device() to remove resources if hiding success, so those resources must be removed in

[PATCH v6 3/8] vpci: Hide legacy capability when it fails to initialize

When vpci fails to initialize a legacy capability of device, it just returns an error and vPCI gets disabled for the whole device. That most likely renders the device unusable, plus possibly causing issues to Xen itself if guest attempts to program the native MSI or MSI-X capabilities if present.

[PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT

Refactor REGISTER_VPCI_INIT to contain more capability specific information, this will benefit further follow-on changes to hide capability when initialization fails. What's more, change the definition of init_header() since it is not a capability and it is needed for all devices' PCI config space

[PATCH v6 6/8] vpci/rebar: Free Rebar resources when init_rebar() fails

When init_rebar() fails, current logic return fail and free Rebar-related resources in vpci_deassign_device(). But the previous new changes will hide Rebar capability and return success, it can't reach vpci_deassign_device() to remove resources if hiding success, so those resources must be removed

[PATCH v6 00/8] Support hiding capability when its initialization fails

Hi, This series is to emulate extended capability list for dom0, including patch #1. hide legacy and extended capability when its initialization fails, including patch #2, #3, #4. remove all related registers and other resources when initializing capability fails, including patch #5, #6, #7, #8.

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

On 11.06.2025 05:13, Jason Andryuk wrote: > 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 is

  1   2   >