On 21.01.2025 23:56, Jason Andryuk wrote:
> On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
>> --- a/xen/drivers/char/console.c
>> +++ b/xen/drivers/char/console.c
>
>> @@ -579,6 +571,9 @@ static void __serial_rx(char c)
>> if ( pv_shim && pv_console )
>> consoled_guest_tx(c)
On 04.01.2025 02:58, Denis Mukhin via B4 Relay wrote:
> --- a/xen/include/xen/ctype.h
> +++ b/xen/include/xen/ctype.h
> @@ -4,6 +4,8 @@
> /*
> * NOTE! This ctype does not handle EOF like the standard C
> * library is required to.
> + *
> + * See Rule 21.13 in docs/misra/rules.rst.
> */
As p
On 21.01.2025 18:07, Andrew Cooper wrote:
> On 21/01/2025 5:04 pm, Jan Beulich wrote:
>> On 21.01.2025 17:56, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/intel.c
>>> +++ b/xen/arch/x86/cpu/intel.c
>>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86
>>> *c)
>>> pr
On 2025/1/21 18:29, Jan Beulich wrote:
> On 21.01.2025 10:29, Roger Pau Monné wrote:
>> On Tue, Jan 21, 2025 at 09:10:26AM +, Chen, Jiqian wrote:
>>> On 2025/1/21 16:46, Roger Pau Monné wrote:
On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> +ctrl = pci_conf_read32(pd
On Wed, Jan 22, 2025, Frederic Weisbecker wrote:
> Le Tue, Jan 14, 2025 at 06:51:35PM +0100, Valentin Schneider a écrit :
> > ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
> > modify the actual CT state part context_tracking.state. This means that
> > upon receiving an IR
Le Tue, Jan 14, 2025 at 06:51:35PM +0100, Valentin Schneider a écrit :
> ct_nmi_{enter, exit}() only touches the RCU watching counter and doesn't
> modify the actual CT state part context_tracking.state. This means that
> upon receiving an IRQ when idle, the CT_STATE_IDLE->CT_STATE_KERNEL
> transit
On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
From: Denis Mukhin
Xen console driver has vpl011-related logic which shall belong vpl011 emulator
code (Arm port). Move vpl011-related code from arch-independent console driver
to Arm's vpl011.c.
Signed-off-by: Denis Mukhin
diff --git a
On 2025-01-03 20:58, Denis Mukhin via B4 Relay wrote:
From: Denis Mukhin
There are several console drivers which have same checks w.r.t. printable
characters. The check is moved to new is_console_printable() function and
re-used in the UART emulation / guest logging code.
Also, MISRA rule 21.1
On Tue, Jan 21, 2025 at 11:35:42AM +0100, Jan Beulich wrote:
> On 21.01.2025 09:52, Roger Pau Monné wrote:
> > On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> >> On 21.01.2025 00:27, Stefano Stabellini wrote:
> >>> On Mon, 20 Jan 2025, Jan Beulich wrote:
> On 18.01.2025 00:41, A
On 21/01/2025 5:04 pm, Jan Beulich wrote:
> On 21.01.2025 17:56, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/intel.c
>> +++ b/xen/arch/x86/cpu/intel.c
>> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
>> printk("%u MHz\n", (factor * max_ratio + 50) / 100);
>>
On 21.01.2025 17:56, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu/intel.c
> +++ b/xen/arch/x86/cpu/intel.c
> @@ -535,39 +535,49 @@ static void intel_log_freq(const struct cpuinfo_x86 *c)
> printk("%u MHz\n", (factor * max_ratio + 50) / 100);
> }
>
> +static void init_intel_perf(struct cpui
> >
> > As noted before, we defer flushing for vmalloc. We have a lazy-threshold
> > which can be exposed(if you need it) over sysfs for tuning. So, we can add
> > it.
> >
>
> In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a
> single userspace application that will never en
On 1/21/25 3:25 PM, Andrew Cooper wrote:
Logic using performance counters needs to look at
MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
When virtualised under ESX, Xen dies with a #GP fault trying to read
MSR_CORE_PERF_GLOBAL_CTRL.
Factor this logic out into a separate
Logic using performance counters needs to look at
MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
When virtualised under ESX, Xen dies with a #GP fault trying to read
MSR_CORE_PERF_GLOBAL_CTRL.
Factor this logic out into a separate function (it's already too squashed to
the RH
Along the lines of 0e3642514719 ("x86: drop REX64_PREFIX"), move to well
formed FXSAVEQ / FXRSTORQ here as well.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/x86_emulate/blk.c
+++ b/xen/arch/x86/x86_emulate/blk.c
@@ -259,16 +259,7 @@ int x86_emul_blk(
if ( s->op_bytes < sizeof(*fxsr) )
On 21/01/2025 4:44 pm, Jan Beulich wrote:
> Along the lines of 0e3642514719 ("x86: drop REX64_PREFIX"), move to well
> formed FXSAVEQ / FXRSTORQ here as well.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Introduce a new pv interface to manage the underlying IOMMU and manage contexts
and devices. This interface allows creation of new contexts from Dom0 and
addition of IOMMU mappings using guest PoV.
This interface doesn't allow creation of mapping to other domains.
Signed-off-by Teddy Astie
---
C
Based on docs/designs/iommu-contexts.md, implement the redesigned IOMMU
subsystem.
Signed-off-by Teddy Astie
---
Changed in V2:
* cleanup some unneeded includes
* s/dettach/detach/
* don't dump IOMMU context of non-iommu domains (fix crash with DomUs)
Changed in v4:
* add "no-dma" support
* us
Current IOMMU subsystem has some limitations that make PV-IOMMU practically
impossible.
One of them is the assumtion that each domain is bound to a single "IOMMU
domain", which
also causes complications with quarantine implementation.
Moreover, current IOMMU subsystem is not entirely well-define
Some operating systems want to use IOMMU to implement various features (e.g
VFIO) or DMA protection.
This patch introduce a proposal for IOMMU paravirtualization for Dom0.
Signed-off-by Teddy Astie
---
Changed in V2:
* nit s/dettach/detach/
Changed in v4:
* updated for iommu_context locking chan
Port the driver with guidances specified in iommu-contexts.md.
Add a arena-based allocator for allocating a fixed chunk of memory and
split it into 4k pages for use by the IOMMU contexts. This chunk size
is configurable with X86_ARENA_ORDER and dom0-iommu=arena-order=N.
Signed-off-by Teddy Astie
This work has been presented at Xen Summit 2024 during the
IOMMU paravirtualization and Xen IOMMU subsystem rework
design session.
Operating systems may want to have access to a IOMMU in order to do DMA
protection or implement certain features (e.g VFIO on Linux).
VFIO support is mandatory for
On Tue, Jan 21, 2025 at 02:25:10PM +, Andrew Cooper wrote:
> Logic using performance counters needs to look at
> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>
> When virtualised under ESX, Xen dies with a #GP fault trying to read
> MSR_CORE_PERF_GLOBAL_CTRL.
>
> Factor
On 21/01/2025 3:58 pm, Jan Beulich wrote:
> On 21.01.2025 16:23, Andrew Cooper wrote:
>> On 21/01/2025 3:03 pm, Jan Beulich wrote:
>>> On 21.01.2025 15:25, Andrew Cooper wrote:
+ !(val & MSR_IA32_MISC_ENABLE_PERF_AVAIL) )
+return;
+
+eax = cpuid_eax(10);
On 21.01.2025 16:23, Andrew Cooper wrote:
> On 21/01/2025 3:03 pm, Jan Beulich wrote:
>> On 21.01.2025 15:25, Andrew Cooper wrote:
>>> Logic using performance counters needs to look at
>>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>>
>>> When virtualised under ESX, Xen di
On 21/01/2025 3:03 pm, Jan Beulich wrote:
> On 21.01.2025 15:25, Andrew Cooper wrote:
>> Logic using performance counters needs to look at
>> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>>
>> When virtualised under ESX, Xen dies with a #GP fault trying to read
>> MSR_CORE_PE
On 21.01.2025 15:25, Andrew Cooper wrote:
> Logic using performance counters needs to look at
> MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
>
> When virtualised under ESX, Xen dies with a #GP fault trying to read
> MSR_CORE_PERF_GLOBAL_CTRL.
>
> Factor this logic out into
Logic using performance counters needs to look at
MSR_MISC_ENABLE.PERF_AVAILABLE before touching any other resources.
When virtualised under ESX, Xen dies with a #GP fault trying to read
MSR_CORE_PERF_GLOBAL_CTRL.
Factor this logic out into a separate function (it's already too squashed to
the RH
Le Tue, Jan 14, 2025 at 06:51:17PM +0100, Valentin Schneider a écrit :
> We now have an RCU_EXPERT config for testing small-sized RCU dynticks
> counter: CONFIG_RCU_DYNTICKS_TORTURE.
>
> Modify scenario TREE04 to exercise to use this config in order to test a
> ridiculously small counter (2 bits)
Le Tue, Jan 14, 2025 at 06:51:16PM +0100, Valentin Schneider a écrit :
> A later commit will reduce the size of the RCU watching counter to free up
> some bits for another purpose. Paul suggested adding a config option to
> test the extreme case where the counter is reduced to its minimum usable
>
On Fri, Jan 10, 2025 at 03:16:08PM +0100, Joel Granados wrote:
Hi Joel,
> Add the const qualifier to all the ctl_tables in the tree except for
> watchdog_hardlockup_sysctl, memory_allocation_profiling_sysctls,
> loadpin_sysctl_table and the ones calling register_net_sysctl (./net,
> drivers/inifi
On 21.01.2025 13:37, Oleksii Kurochko wrote:
> On 1/20/25 4:13 PM, Jan Beulich wrote:
>> On 15.01.2025 17:36, Oleksii Kurochko wrote:
>>> +#if defined(CONFIG_RISCV_32)
>>> +if ( isa[2] != '3' && isa[3] != '2' )
>>> +return -EINVAL;
>>> +#elif defined(CONFIG_RISCV_64)
>>> +if ( isa[2
On Tue, Jan 21, 2025 at 12:20:17PM +0100, Jan Beulich wrote:
> On 21.01.2025 12:09, Roger Pau Monné wrote:
> > On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
> >> On 18.04.2024 13:57, Teddy Astie wrote:
> >>> All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> >>> in
On 1/20/25 4:13 PM, Jan Beulich wrote:
On 15.01.2025 17:36, Oleksii Kurochko wrote:
--- /dev/null
+++ b/xen/arch/riscv/cpufeature.c
@@ -0,0 +1,506 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Taken for Linux kernel v6.12-rc3 and modified by
+ * Oleksii Kurochko:
+ *
+ * - Drop uncond
On 21.01.2025 12:09, Roger Pau Monné wrote:
> On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
>> On 18.04.2024 13:57, Teddy Astie wrote:
>>> All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
>>> initialisation time, and remove the effectively-dead logic for the
>>> no
On Wed, Apr 24, 2024 at 04:27:10PM +0200, Jan Beulich wrote:
> On 18.04.2024 13:57, Teddy Astie wrote:
> > All hardware with VT-d/AMD-Vi has CMPXCHG16B support. Check this at
> > initialisation time, and remove the effectively-dead logic for the
> > non-cx16 case.
>
> As before: What about Xen its
On Thu, Nov 7, 2024 at 3:15 PM Roger Pau Monne wrote:
>
> create-diff-object has a special handling for some specific sections, like
> .altinstructions or .livepatch.hooks.*. The contents of those sections are in
> the form of array elements, where each element can be processed independently
> of
On Thu, Nov 7, 2024 at 3:15 PM Roger Pau Monne wrote:
>
> Not all toolchains generate symbols for the .livepatch.hooks.* sections,
> neither those symbols are required by the livepatch loading logic in Xen to
> find and process the hooks. Hooks in livepatch payloads are found and
> processed base
On 21.01.2025 09:52, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
>> On 21.01.2025 00:27, Stefano Stabellini wrote:
>>> On Mon, 20 Jan 2025, Jan Beulich wrote:
On 18.01.2025 00:41, Andrew Cooper wrote:
> On 17/01/2025 10:43 pm, Stefano Stabellini wr
On 21/01/2025 9:57 am, Roger Pau Monne wrote:
> If using a 32bit Interrupt Remapping Entry or a 128bit one and the CPU
> supports 128bit cmpxchg don't disable the entry by setting RemapEn = 0
> ahead of updating it. As a consequence of not toggling RemapEn ahead of
> the update the Interrupt Remap
On Thu, Nov 7, 2024 at 3:15 PM Roger Pau Monne wrote:
>
> The size of the alt_instr structure in Xen is 14 instead of 12 bytes, adjust
> it.
>
> Signed-off-by: Roger Pau Monné
> ---
> create-diff-object.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/create-diff-object
On Thu, Nov 7, 2024 at 3:15 PM Roger Pau Monne wrote:
>
> XenServer uses quite long Xen version names, and encode such in the livepatch
> filename, and it's currently running out of space in the file name.
>
> Bump max filename size to 127, so it also matches the patch name length in the
> hypervi
On 21.01.2025 10:29, Roger Pau Monné wrote:
> On Tue, Jan 21, 2025 at 09:10:26AM +, Chen, Jiqian wrote:
>> On 2025/1/21 16:46, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
+ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
From: Stefano Stabellini
Extend coverage of CONFIG_VM_EVENT option and make the build of VM events
and monitoring support optional.
This is to reduce code size on Arm when this option isn't enabled.
CC: Jan Beulich
CC: Tamas K Lengyel
Reviewed-by: Ayan Kumar Halder
Signed-off-by: Stefano Stab
On 02.01.2025 09:45, Tu Dinh wrote:
> Add new set_lbr_depth HVM function and emulate ops to support LBR
> XSAVES/XRSTORS emulation.
What about any of the other state components, like BNDCSR?
> Add the appropriate instruction hooks to 0fc7.c. Translate LBR registers
> using cs.base within a large
Following the renaming of Xen build option.
Signed-off-by: Sergiy Kibrik
---
automation/eclair_analysis/xen_arm_config | 2 +-
automation/eclair_analysis/xen_x86_config | 2 +-
automation/gitlab-ci/build.yaml | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/automa
Replace more general CONFIG_HVM option with CONFIG_VM_EVENT which is more
relevant and specific to monitoring. This is only to clarify at build level
to which subsystem this file belongs.
No functional change here, as VM_EVENT depends on HVM.
Signed-off-by: Sergiy Kibrik
---
xen/arch/x86/Makefi
Use more generic CONFIG_VM_EVENT name throughout Xen code instead of
CONFIG_MEM_ACCESS. This reflects the fact that vm_event is a higher level
feature, with mem_access & monitor depending on it.
Suggested-by: Jan Beulich
Suggested-by: Tamas K Lengyel
Signed-off-by: Sergiy Kibrik
---
option rena
This series aims to provide a possibility to build Xen without mem_access and
related features. It is already largely covered by corresponding
CONFIG_MEM_ACCESS option, yet there're still some parts remaining.
Hopefully this would help to reduce dead code a bit.
As coverage of MEM_ACCESS config op
On Thu, Jan 16, 2025 at 5:52 PM Roger Pau Monne wrote:
>
> Hello,
>
> Fixes picked from kpatch to deal with .cold and .hot sub-functions
> sections generated by gcc.
>
> Thanks, Roger.
>
> Artem Savkov (7):
> create-diff-object: ignore .cold.* suffixes in is_bundleable()
> create-diff-object:
On 21/01/2025 9:57 am, Roger Pau Monne wrote:
> diff --git a/xen/drivers/passthrough/amd/iommu_intr.c
> b/xen/drivers/passthrough/amd/iommu_intr.c
> index 7fc796dec25b..efa9ddc62458 100644
> --- a/xen/drivers/passthrough/amd/iommu_intr.c
> +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> @@ -223,1
If using a 32bit Interrupt Remapping Entry or a 128bit one and the CPU
supports 128bit cmpxchg don't disable the entry by setting RemapEn = 0
ahead of updating it. As a consequence of not toggling RemapEn ahead of
the update the Interrupt Remapping Table needs to be flushed after the
entry update.
On Tue, Jan 21, 2025 at 09:10:26AM +, Chen, Jiqian wrote:
> On 2025/1/21 16:46, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> >> +ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
> >> +nbars = MASK_EXTR(ctrl, PCI_REBAR_CTR
On 2025/1/21 16:46, Roger Pau Monné wrote:
> On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
>> +ctrl = pci_conf_read32(pdev->sbdf, rebar_offset + PCI_REBAR_CTRL(0));
>> +nbars = MASK_EXTR(ctrl, PCI_REBAR_CTRL_NBAR_MASK);
>> +for ( unsigned int i = 0; i < nbars; i++ )
>> +
On Tue, Jan 21, 2025 at 09:13:38AM +0100, Jan Beulich wrote:
> On 21.01.2025 00:27, Stefano Stabellini wrote:
> > On Mon, 20 Jan 2025, Jan Beulich wrote:
> >> On 18.01.2025 00:41, Andrew Cooper wrote:
> >>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
> On Fri, 17 Jan 2025, Jan Beulich wr
On Tue, Jan 14, 2025 at 11:26:36AM +0800, Jiqian Chen wrote:
> Some devices, like discrete GPU of amd, support resizable bar
> capability, but vpci of Xen doesn't support this feature, so
> they fail to resize bars and then cause probing failure.
>
> According to PCIe spec, each bar that supports
On 21.01.2025 00:27, Stefano Stabellini wrote:
> On Mon, 20 Jan 2025, Jan Beulich wrote:
>> On 18.01.2025 00:41, Andrew Cooper wrote:
>>> On 17/01/2025 10:43 pm, Stefano Stabellini wrote:
On Fri, 17 Jan 2025, Jan Beulich wrote:
> On 17.01.2025 13:24, Alejandro Vallejo wrote:
>> On Fri
On 21.01.2025 07:14, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, January 9, 2025 6:55 PM
>>
>> On 03.12.2024 09:11, Penny Zheng wrote:
>>> +{
>>> +/* Read Processor Max Speed(mhz) from DMI table as anchor point */
>>> +mul = dmi_max
58 matches
Mail list logo
