On 03.09.2025 17:26, Andrew Cooper wrote:
> On 03/09/2025 4:13 pm, Jan Beulich wrote:
>> For in-tree builds relative paths are used, whereas for out-of-tree builds
>> in various situations absolute ones come into play. The extra paths can be
>> long, wasting space and e.g.
https://gitlab.com/xen-project/hardware/xen/-/commit/51190865a4918c443c310c0478247d5f9caa5dad
> )
> Commit Message: x86/suspend: unconditionally raise a timer soft...
> Commit Author: Roger Pau Monné
> Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
>
>
> Pipel
https://gitlab.com/xen-project/hardware/xen/-/commit/dabd719321b652286b9d0b0c23e29c8427eb7da5
> )
> Commit Message: x86/gen-cpuid: Fix debugging for cycle detectio...
> Commit Author: Andrew Cooper ( https://gitlab.com/andyhhp )
> Committed by: Jan Beulich ( https://gitlab.com/jbeulich
x27;s
(and Clang's) ability to "remap" file names. For older gcc fall back to
using the option affecting debug info only.
Signed-off-by: Jan Beulich
---
Of course we may want to consider putting this in the top-level Config.mk,
to also affect other sub-trees (presently mainly/only
On 03.09.2025 16:02, Teddy Astie wrote:
> Le 02/09/2025 à 16:10, Jan Beulich a écrit :
>> On 02.09.2025 15:24, Teddy Astie wrote:
>>> Regarding sgn, maybe we can use `segment` instead ?
>>
>> Why not segment_group or seg_group (seeing how devfn also is an
>&
DT() which reads %dr6.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 28.08.2025 17:04, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct
> cpu_user_regs *regs, bool ist_exit)
>
> void asmlinkage entry_from_pv(struct cpu_user_regs *regs)
> {
> +struct fred_in
On 01.09.2025 20:53, Andrew Cooper wrote:
> On 01/09/2025 4:41 pm, Jan Beulich wrote:
>> On 01.09.2025 17:33, Andrew Cooper wrote:
>>> On 01/09/2025 10:28 am, Jan Beulich wrote:
>>>> On 28.08.2025 17:03, Andrew Cooper wrote:
>>>>> @@ -908,7 +909,29 @@
option. This makes it impossible to e.g. disable INTEL_VMX
> when INTEL is disabled (option is hidden). Fix it while keeping the
> possibility of e.g. enabling INTEL_VMX when INTEL is disabled.
>
> Fixes: e3ed540f2e9f ("x86/hvm: add HVM-specific Kconfig")
> Signed-off-by: Michal Orzel
Acked-by: Jan Beulich
On 02.09.2025 16:06, Manuel Bouyer wrote:
> On Tue, Sep 02, 2025 at 03:55:14PM +0200, Jan Beulich wrote:
>> On 02.09.2025 15:41, Manuel Bouyer wrote:
>>> On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote:
>>>>> What puzzles me is that:
>>>&
On 29.08.2025 21:57, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
>> +static void cf_check ns16x50_free(void *arg)
>> +{
>> +struct vuart_ns16x50 *vdev = arg;
>> +
>> +if ( vdev )
>> +ns16x50_deinit(vdev);
>> +
>> +XVFREE(vdev);
>
> XVFREE should only
On 01.09.2025 17:36, Andrew Cooper wrote:
> On 01/09/2025 10:46 am, Jan Beulich wrote:
>> On 28.08.2025 17:03, Andrew Cooper wrote:
>>> FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2
>>> manually.
>>>
>>> Rename do_page_faul
On 01.09.2025 12:31, Andrew Cooper wrote:
> On 01/09/2025 9:56 am, Jan Beulich wrote:
>> With the processing done linearly (rather than recursively), checking
>> whether any of the features was previously seen is wrong: That would
>> e.g. trigger for this simple set of depende
On 31.08.2025 00:10, Mykola Kvach wrote:
> --- a/xen/arch/ppc/stubs.c
> +++ b/xen/arch/ppc/stubs.c
> @@ -224,6 +224,11 @@ void arch_domain_creation_finished(struct domain *d)
> BUG_ON("unimplemented");
> }
>
> +int arch_domain_resume(struct domain *d)
> +{
> +return 0;
> +}
> +
> int a
On 03.09.2025 09:54, Jan Beulich wrote:
> It's not quite clear whether the two functions involved violate only rule
> 2.1 (dead code, not accepted so far) or even rule 2.2 (unreachable code).
> I'm leaning towards the latter, hence the changes would be an active fix.
>
be executed."
Otoh it's "only" __init code.
As this removes the last user of APIC_XAPIC(), remove the macro as well.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/include/asm/apicdef.h
+++ b/xen/arch/x86/include/asm/apicdef.h
@@ -19,7 +19,6 @@
#define
d long read_gs_shadow(void)
> {
> -if ( read_cr4() & X86_CR4_FSGSBASE )
> +unsigned long cr4 = read_cr4();
> +
> +if ( !(cr4 & X86_CR4_FRED) && (cr4 & X86_CR4_FSGSBASE) )
> return __rdgs_shadow();
... the one here. Was the former (and the subjec
be executed."
Otoh it's "only" __init code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/io_apic.c
+++ b/xen/arch/x86/io_apic.c
@@ -1459,119 +1459,6 @@ void disable_IO_APIC(void)
}
/*
- * function to set the IO-APIC physical IDs based on the
- * values stored in the MPC table
It's not quite clear whether the two functions involved violate only rule
2.1 (dead code, not accepted so far) or even rule 2.2 (unreachable code).
I'm leaning towards the latter, hence the changes would be an active fix.
This is effectively follow-on to "x86/apic: Drop vestigial pieces (Intel
VFM
On 28.08.2025 17:03, Andrew Cooper wrote:
> FRED provides %cr2 in the the stack frame, avoiding the need to read %cr2
> manually.
>
> Rename do_page_fault() to handle_PF(), and update it to take cr2, still named
> addr for consistency.
>
> Introduce a new handle_PF_IDT() which reads %cr2 and cond
On 02.09.2025 16:44, Gerald Elder-Vass wrote:
> The existing Verify functionality of the Shim lock protocol is
> deprecated and will be removed, instead we must use the LoadImage
> interface to perform the verification.
>
> When the loading is successful we won't be using the newly loaded image
>
clobber a FRED MSR_PL0_SSP with an IDT one.
>
> This also simplifies the AP path too. Updating reinit_bsp_stack() is deferred
> until later.
This last sentence looks to be ...
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Rog
On 02.09.2025 16:49, Andrew Cooper wrote:
> Drop unused or stale lines.
>
> * While it's necessary to have .git and .hg in each others ignore files if
>using multiple SCMs (as we did for a while), they should not be in their
>own.
Despite what you say you remove .hg from .gitignore thoug
On 29.08.2025 15:59, Teddy Astie wrote:
> Le 28/08/2025 à 14:35, Jan Beulich a écrit :
>> On 21.08.2025 17:25, Teddy Astie wrote:
>>> FastABI is a alternative ABI designed with performance and coco-enabled
>>> guest in mind. It is register-oriented instead of refering
On 02.09.2025 08:29, Mykola Kvach wrote:
> On Mon, Sep 1, 2025 at 8:02 PM Mykola Kvach wrote:
>>
>> Hi Jan,
>>
>> On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote:
>>>
>>> On 31.08.2025 00:10, Mykola Kvach wrote:
>>>> --- a/xen/arch/p
On 03.09.2025 08:46, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-----
>> From: Jan Beulich
>> Sent: Wednesday, September 3, 2025 2:22 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Anthony PERARD
>> ; Andrew Cooper ;
>> Roger Pau Mo
On 03.09.2025 05:14, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-----
>> From: Jan Beulich
>> Sent: Thursday, August 28, 2025 7:07 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Anthony PERARD
>> ; Andrew Cooper ;
>> Roger Pau Monné
On 02.09.2025 18:15, Andrew Cooper wrote:
> On 25/08/2025 2:54 pm, Jan Beulich wrote:
>> --- a/tools/misc/mktarball
>> +++ b/tools/misc/mktarball
>> @@ -5,14 +5,6 @@
>> # Takes 2 arguments, the path to the dist directory and the version
>> set -ex
&
in such
a situation.
Requested-by: Roger Pau Monné
Signed-off-by: Jan Beulich
--- a/docs/process/sending-patches.pandoc
+++ b/docs/process/sending-patches.pandoc
@@ -42,7 +42,7 @@ should be mentioned.
When referencing other patches (e.g. `similar to patch xy ...`) those
patches should be refe
On 02.09.2025 14:10, Manuel Bouyer wrote:
> On Tue, Sep 02, 2025 at 02:00:35PM +0200, Jan Beulich wrote:
>> On 02.09.2025 12:56, Manuel Bouyer wrote:
>>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote:
>>>> On 02/09/2025 11:17 am, Manuel Bouyer wrote:
ewhat unclear there, though.
> No functional change.
>
> Link: https://lore.kernel.org/r/20240212154639.057209...@linutronix.de
> Signed-off-by: Andrew Cooper
Irrespective of the above:
Acked-by: Jan Beulich
Jan
On 01.09.2025 17:33, Andrew Cooper wrote:
> On 01/09/2025 10:28 am, Jan Beulich wrote:
>> On 28.08.2025 17:03, Andrew Cooper wrote:
>>> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void)
>>> if ( cpu_has_xen_shstk )
>>>
On 01.09.2025 12:52, Sergiy Kibrik wrote:
> --- a/xen/common/Kconfig
> +++ b/xen/common/Kconfig
> @@ -418,6 +418,17 @@ config XSM_FLASK_AVC_STATS
>
> If unsure, say Y.
>
> +config XSM_FLASK_SIDTABLE_ORDER
> + int "Maximum number of security identifiers (base-2 exponent)" if EXPERT
>
On 02.09.2025 14:28, Manuel Bouyer wrote:
> On Tue, Sep 02, 2025 at 02:22:29PM +0200, Juergen Gross wrote:
>> On 02.09.25 12:56, Manuel Bouyer wrote:
>>> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote:
On 02/09/2025 11:17 am, Manuel Bouyer wrote:
> Hello,
> I'm trying to
On 02.09.2025 01:11, dmuk...@xen.org wrote:
> On Fri, Aug 29, 2025 at 12:57:43PM -0700, Stefano Stabellini wrote:
>> On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
>>> --- a/xen/common/emul/vuart/Kconfig
>>> +++ b/xen/common/emul/vuart/Kconfig
>>> @@ -3,4 +3,22 @@ config VUART_FRAMEWORK
>>>
>>> men
On 02.09.2025 11:03, Mykola Kvach wrote:
> ---
> xen/arch/arm/domain.c | 37
> xen/arch/arm/include/asm/domain.h | 6 ++
> xen/arch/arm/include/asm/perfc_defn.h | 1 +
> xen/arch/arm/include/asm/psci.h | 2 +
> xen/arch/arm/include/asm/suspend.h| 18 +
On 02.09.2025 00:10, Mykola Kvach wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -1317,7 +1317,11 @@ int domain_shutdown(struct domain *d, u8 reason)
> d->shutdown_code = reason;
> reason = d->shutdown_code;
>
> +#if defined(CONFIG_SYSTEM_SUSPEND) && defined(CON
On 02.09.2025 15:24, Teddy Astie wrote:
> Le 02/09/2025 à 14:38, Jan Beulich a écrit :
>> On 29.08.2025 11:58, Teddy Astie wrote:
>>> @@ -505,7 +505,22 @@ smbios_type_1_init(void *start, const char
>>> *xen_version,
>>> p->version_str
On 02.09.2025 15:41, Manuel Bouyer wrote:
> On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote:
>>> What puzzles me is that:
>>>
>>> - %cr2 is 0, so probably the first fault wasn't a page fault
>>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop?
>>>
>>> Could it be t
On 02.09.2025 14:54, Manuel Bouyer wrote:
> On Tue, Sep 02, 2025 at 02:45:04PM +0200, Jan Beulich wrote:
>>>> What puzzles me is that:
>>>>
>>>> - %cr2 is 0, so probably the first fault wasn't a page fault
>>>
>>> AFAIK it can't
On 29.08.2025 11:58, Teddy Astie wrote:
> @@ -505,7 +505,22 @@ smbios_type_1_init(void *start, const char *xen_version,
> p->version_str = 3;
> p->serial_number_str = 4;
>
> -memcpy(p->uuid, uuid, 16);
> +/*
> + * Xen toolstack uses big endian UUIDs, however GUIDs (which req
On 02.09.2025 12:56, Manuel Bouyer wrote:
> On Tue, Sep 02, 2025 at 11:44:36AM +0100, Andrew Cooper wrote:
>> On 02/09/2025 11:17 am, Manuel Bouyer wrote:
>>> Hello,
>>> I'm trying to boot a NetBSD PVH dom0 on Xen 4.20.
>>> The same NetBSD kernel works fine with Xen 4.18
>>>
>>> The boot options ar
On 01.09.2025 20:08, Andrew Cooper wrote:
> Ever since it's introduction in commit 192df6f9122d ("x86: allow HVM guests to
> use hypercalls to bring up vCPUs"), %cs.g/limit has been handled differently
> to all other segments.
>
> The hypercall takes full 32bit,
This is an implication from the im
On 02.09.2025 10:42, Mykola Kvach wrote:
> Since the current codebase already uses this approach in multiple places,
> contributors may get mixed signals when similar patterns are sometimes
> accepted and sometimes discouraged. Clearer project-wide guidance, or even
> small clarifications in coding
On 01.09.2025 19:17, Mykola Kvach wrote:
> On Mon, Sep 1, 2025 at 8:02 PM Mykola Kvach wrote:
>> On Mon, Sep 1, 2025 at 5:29 PM Jan Beulich wrote:
>>> On 31.08.2025 00:10, Mykola Kvach wrote:
>>>> --- a/xen/arch/ppc/stubs.c
>>>> +++ b/xen/arch/
On 02.09.2025 00:27, dmuk...@xen.org wrote:
> On Mon, Sep 01, 2025 at 10:14:04AM +0200, Jan Beulich wrote:
>> On 29.08.2025 21:27, Stefano Stabellini wrote:
>>> On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
>>>> --- /dev/null
>>>> +++ b/xen/com
On 29.08.2025 11:58, Teddy Astie wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -11,6 +11,7 @@ The format is based on [Keep a
> Changelog](https://keepachangelog.com/en/1.0.0/)
> - For x86, GCC 5.1 and Binutils 2.25, or Clang/LLVM 11
> - For ARM32 and ARM64, GCC 5.1 and Binutils 2.2
On 29.08.2025 15:32, Teddy Astie wrote:
> Le 28/08/2025 à 14:30, Jan Beulich a écrit :
>> On 21.08.2025 17:25, Teddy Astie wrote:
>>> @@ -686,10 +691,31 @@ static int domain_construct_memmap(libxl__gc *gc,
>>> /* We always own at least one lowmem entry. */
>>
that similar, is it? MBS will be observed set once guest context is
entered, irrespective of any scheduling. So it's entirely benign if we set
it up-front, except of course for a back-to-back set/get.
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
On 01.09.2025 16:31, Andrew Cooper wrote:
> On 01/09/2025 3:26 pm, Jan Beulich wrote:
>> Hmm, okay, it is of course in principle possible that one flavor is screwed
>> while the other isn't.
>>
>> Acked-by: Jan Beulich
>
> Thanks, but I now have both R
On 29.08.2025 16:13, Teddy Astie wrote:
> Le 28/08/2025 à 15:05, Jan Beulich a écrit :
>> On 26.06.2025 16:01, Teddy Astie wrote:
>>> Is it possible to have multiples vCPUs of a same domain simultaneously
>>> scheduled on top of a single pCPU ? If so, it would need a sp
On 01.09.2025 16:21, Andrew Cooper wrote:
> On 27/08/2025 8:52 am, Jan Beulich wrote:
>> On 26.08.2025 19:41, Andrew Cooper wrote:
>>> --- a/xen/common/bitops.c
>>> +++ b/xen/common/bitops.c
>>> @@ -97,14 +97,14 @@ static void __init test_for_each_set_
On 29.08.2025 11:58, Teddy Astie wrote:
> --- a/CHANGELOG.md
> +++ b/CHANGELOG.md
> @@ -34,6 +34,7 @@ The format is based on [Keep a
> Changelog](https://keepachangelog.com/en/1.0.0/)
> - Support in hvmloader for new SMBIOS tables: 7 (Cache Info), 8 (Port
> Connector), 9 (System Slots),
On 01.09.2025 15:27, Andrew Cooper wrote:
> On 01/09/2025 1:57 pm, Jan Beulich wrote:
>> On 28.08.2025 17:04, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const s
On 28.08.2025 17:04, Andrew Cooper wrote:
> Under FRED, entry_from_pv() handles everything, even system calls. This means
> more of our logic is written in C now, rather than assembly.
>
> In order to facilitate this, introduce pv_inject_callback(), which reuses
> struct trap_bounce infrastructur
On 28.08.2025 17:03, Andrew Cooper wrote:
> @@ -20,6 +22,9 @@ unsigned int __ro_after_init ler_msr;
> static bool __initdata opt_ler;
> boolean_param("ler", opt_ler);
>
> +int8_t __ro_after_init opt_fred = 0;
Can't this be __initdata now that we have ...
> @@ -299,6 +304,37 @@ void __init tra
On 28.08.2025 17:04, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2345,6 +2345,113 @@ void asmlinkage entry_from_pv(struct cpu_user_regs
> *regs)
> fatal_trap(regs, false);
> }
>
> +void nocall eretu_error_dom_crash(void);
> +
> +/*
> + * Classify an
On 28.08.2025 17:04, Andrew Cooper wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -2265,9 +2265,83 @@ void asmlinkage check_ist_exit(const struct
> cpu_user_regs *regs, bool ist_exit)
>
> void asmlinkage entry_from_pv(struct cpu_user_regs *regs)
> {
> +struct fred_in
o under FRED needs to be a simple MOV %gs. Simply skip the SWAPGSes.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> v2:
> * New
>
> I think this functions, but it's not ideal. The conditions are asymmetric and
> awkw
On 28.08.2025 17:04, Andrew Cooper wrote:
> It is no longer used.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
exceptions, and undergo normal flags handling there.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 01.09.2025 13:25, Orzel, Michal wrote:
>
>
> On 01/09/2025 13:19, Jan Beulich wrote:
>> On 01.09.2025 12:43, Michal Orzel wrote:
>>> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
>>> INTEL_VMX on INTEL. Such dependency should be done u
;
> Later in exception_with_ints_disabled(), it suffices to load %ecx rather than
> %rcx, and remove a stray semi-colon from the rep movsq.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 28.08.2025 17:04, Andrew Cooper wrote:
> This is really a rearrangement to make adding FRED support easier.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
> ---
> CC: Jan Beulich
> CC: Roger Pau Monné
>
> v2:
> * New
>
> There is a mar
On 01.09.2025 12:43, Michal Orzel wrote:
> Commit e3ed540f2e9f was meant to make AMD_SVM dependent on AMD and
> INTEL_VMX on INTEL. Such dependency should be done using 'depends on'
> and not 'if' next to prompt that deals only with the visibility of the
> given Kconfig option. This makes it imposs
On 01.09.2025 13:03, Andrew Cooper wrote:
> On 01/09/2025 9:33 am, Jan Beulich wrote:
>> On 29.08.2025 18:17, Andrew Cooper wrote:
>>> This is a port of Linux commit 517234446c1a ("x86/apic: Get rid of
>>> get_physical_broadcast()") to Xen. Thomas Gleixner n
On 28.08.2025 17:04, Andrew Cooper wrote:
> With the shadow stack and exception handling adjustements in place, we can now
> activate FRED when appropriate. Note that opt_fred is still disabled by
> default.
>
> Introduce init_fred() to set up all the MSRs relevant for FRED. FRED uses
> MSR_STAR
On 28.08.2025 17:03, Andrew Cooper wrote:
> Under FRED, there's one entrypoint from Ring 3, and one from Ring 0.
>
> FRED gives us a good stack (even for SYSCALL/SYSENTER), and a unified event
> frame on the stack, meaing that all software needs to do is spill the GPRs
> with a line of PUSHes. In
logic, rather than trying to adjust vendor/family logic.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 28.08.2025 17:03, Andrew Cooper wrote:
> FRED doesn't use Supervisor Shadow Stack tokens. Skip setting them up.
>
> Signed-off-by: Andrew Cooper
In principle
Reviewed-by: Jan Beulich
However, ...
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -
On 28.08.2025 17:03, Andrew Cooper wrote:
> FRED and IDT differ by a Supervisor Token on the base of the shstk. This
> means that switch_stack_and_jump() needs to discard one extra word when FRED
> is active.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
However,
we need to avoid is adding a feature again when we've
already seen it.
As a result, seeding "seen[]" with "feat" isn't necessary anymore.
Fixes: fe4408d180f4 ("xen/x86: Generate deep dependencies of features")
Signed-off-by: Jan Beulich
---
Doing AMX-AVX512
On 28.08.2025 17:03, Andrew Cooper wrote:
> @@ -908,7 +909,29 @@ static void __init noreturn reinit_bsp_stack(void)
> if ( cpu_has_xen_shstk )
> {
> wrmsrl(MSR_S_CET, xen_msr_s_cet_value());
> -asm volatile ("setssbsy" ::: "memory");
> +
> +/*
> + * IDT an
re
> names") being rather lazy and marking dependenices on unknown features.
>
> Introduce a helper to pick the known features in a range, and use it for
> ARCH_CAPS.
>
> Additionally, remove trailing whitepsace from the debug print.
>
> Reported-by: Jan Beulich
> Fixes: ce8c930851a5 ("x86/cpu-policy: MSR_ARCH_CAPS feature names")
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
On 29.08.2025 21:27, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, dmuk...@xen.org wrote:
>> --- /dev/null
>> +++ b/xen/common/emul/vuart/vuart.c
>> @@ -0,0 +1,156 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * UART emulator framework.
>> + *
>> + * Copyright 2025 Ford Motor Co
On 01.09.2025 05:21, Penny, Zheng wrote:
> [Public]
>
>> -Original Message-----
>> From: Jan Beulich
>> Sent: Friday, August 29, 2025 2:12 PM
>> To: Penny, Zheng
>> Cc: Huang, Ray ; Andrew Cooper
>> ; Roger Pau Monné ;
>> Anthony PERARD ; Orze
On 30.08.2025 17:23, Sergiy Kibrik wrote:
> 29.08.25 14:44, Jan Beulich:
>> On 29.08.2025 13:33, Sergiy Kibrik wrote:
>>> 25.08.25 15:00, Jan Beulich:
>>>> On 22.08.2025 11:51, Sergiy Kibrik wrote:
>>>>> --- a/xen/common/Kconfig
>>>>> +++
On 29.08.2025 16:24, Roger Pau Monné wrote:
> On Wed, Apr 02, 2025 at 03:57:57PM +0200, Jan Beulich wrote:
>> ... before making changes to the involved logic.
>>
>> Signed-off-by: Jan Beulich
>> ---
>> While Andrew validly suggests cf_check isn't a require
On 29.08.2025 13:04, Mykola Kvach wrote:
> On Fri, Aug 29, 2025 at 10:45 AM Jan Beulich wrote:
>> On 28.08.2025 18:32, Volodymyr Babchuk wrote:
>>> Mykola Kvach writes:
>>>> @@ -880,6 +883,25 @@ void arch_domain_creation_finished(struct domain *d)
>>&g
On 29.08.2025 13:33, Sergiy Kibrik wrote:
> 25.08.25 15:00, Jan Beulich:
>> On 22.08.2025 11:51, Sergiy Kibrik wrote:
>>> --- a/xen/common/Kconfig
>>> +++ b/xen/common/Kconfig
>>
>> I wonder whether we wouldn't better move XSM's controls to a d
On 29.08.2025 10:56, Roger Pau Monné wrote:
> On Fri, Aug 29, 2025 at 10:10:59AM +0200, Jan Beulich wrote:
>> On 29.08.2025 09:51, Roger Pau Monne wrote:
>>> There's no need for PDX compression given the memory map provided by Xen
>>> to guests is contiguous, turn o
On 29.08.2025 09:51, Roger Pau Monne wrote:
> There's no need for PDX compression given the memory map provided by Xen
> to guests is contiguous, turn off the feature by default in the PV shim
> defconfig.
>
> Reported-by: Jan Beulich
> Fixes: c5c45bcbd6a1 ('pdx:
On 28.08.2025 18:40, Oleksii Moisieiev wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -1097,6 +1097,15 @@ affinities to prefer but be not limited to the
> specified node(s).
>
> Pin dom0 vcpus to their respective pcpus
>
> +### scmi-smc-passthr
On 28.08.2025 18:32, Volodymyr Babchuk wrote:
> Mykola Kvach writes:
>> @@ -880,6 +883,25 @@ void arch_domain_creation_finished(struct domain *d)
>> p2m_domain_creation_finished(d);
>> }
>>
>> +int arch_domain_resume(struct domain *d)
>> +{
>> +int rc;
>> +typeof(d->arch.resume_ctx
On 29.08.2025 01:41, Stefano Stabellini wrote:
> On Thu, 28 Aug 2025, Jan Beulich wrote:
>> On 28.08.2025 02:52, Stefano Stabellini wrote:
>>> On Wed, 27 Aug 2025, Jan Beulich wrote:
>>>> On 27.08.2025 02:33, Stefano Stabellini wrote:
>>>>> --- a/xen
On 29.08.2025 06:06, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 08, 2025 at 02:56:58PM +0100, Frediano Ziglio wrote:
>> EFI code path split options from EFI LoadOptions fields in 2
>> pieces, first EFI options, second Xen options.
>> "get_argv" function is called first to get the number of arg
On 28.08.2025 19:16, Jason Andryuk wrote:
> On 2025-08-28 12:11, Jan Beulich wrote:
>> On 28.08.2025 09:28, Jan Beulich wrote:
>>> On 28.08.2025 03:03, Jason Andryuk wrote:
>>>> On 2025-04-02 09:58, Jan Beulich wrote:
>>>>> --- a/xen/to
On 28.08.2025 23:33, Jason Andryuk wrote:
> On 2025-08-28 05:17, Jan Beulich wrote:
>> The present copy_page_sse2() is useful in case the destination page isn't
>> going to get touched again soon, or if we want to limit churn on the
>> caches. Just rename it, to fit the
On 29.08.2025 02:16, Jason Andryuk wrote:
> On 2025-08-28 07:22, Jan Beulich wrote:
>> On 28.08.2025 12:03, Penny Zheng wrote:
>>> +static int cf_check amd_cppc_cpufreq_target(struct cpufreq_policy *policy,
>>> +
On 29.08.2025 05:30, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Thursday, August 28, 2025 7:23 PM
>>
>> On 28.08.2025 12:03, Penny Zheng wrote:
>>> +static int cf_check amd_cppc_cpufr
On 28.08.2025 09:28, Jan Beulich wrote:
> On 28.08.2025 03:03, Jason Andryuk wrote:
>> On 2025-04-02 09:58, Jan Beulich wrote:
>>> --- a/xen/tools/symbols.c
>>> +++ b/xen/tools/symbols.c
>>
>>> @@ -318,24 +334,42 @@ static void write_src(void)
>&
efault in shim mode. OTOH, if
> FRED is active, then PV32 needs disabling like with CET.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
oundary will be loaded into MSR_FRED_RSP_SL0, and must be
> 64-byte aligned.
>
> This does add 16 bytes back into struct cpu_info, undoing the saving we made
> by dropping the vm86 data segment selectors.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
On 26.06.2025 16:01, Teddy Astie wrote:
> From: Vaishali Thakkar (formely vates.tech)
>
> Currently ASID generation and management is done per-PCPU. This
> scheme is incompatible with SEV technologies as SEV VMs need to
> have a fixed ASID associated with all vcpus of the VM throughout
> it's lif
On 28.08.2025 12:02, Penny Zheng wrote:
> @@ -693,6 +699,120 @@ int acpi_set_pdc_bits(unsigned int acpi_id,
> XEN_GUEST_HANDLE(uint32) pdc)
> return ret;
> }
>
> +static void print_CPPC(const struct xen_processor_cppc *cppc_data)
> +{
> +printk("\t_CPC: highest_perf=%u, lowest_perf=%u,
On 21.08.2025 17:25, Teddy Astie wrote:
> Allow specifying in memory map a region which can be hotplugged.
>
> This will be used by a future memory hotplug feature.
Why could this not be done the ACPI way, with the regions properly specified
in SRAT?
Jan
On 21.08.2025 17:25, Teddy Astie wrote:
> do_poll takes sched_poll* as parameter, but that's actually in guest memory
> (so it's more a guest handle).
No, it's not, or else ...
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1437,21 +1437,13 @@ static void vcpu_block_enable_
On 21.08.2025 17:25, Teddy Astie wrote:
> FastABI is a alternative ABI designed with performance and coco-enabled
> guest in mind. It is register-oriented instead of refering to C structures
> in the guest memory (through a virtual memory pointer).
>
> It only focuses on kernel-side hypercalls, it
On 21.08.2025 17:25, Teddy Astie wrote:
> @@ -686,10 +691,31 @@ static int domain_construct_memmap(libxl__gc *gc,
> /* We always own at least one lowmem entry. */
> unsigned int e820_entries = 1;
> struct e820entry *e820 = NULL;
> +uint64_t highmem_start = ((uint64_t)1 << 32);
>
On 21.08.2025 17:25, Teddy Astie wrote:
> Make these functions work with hypervisor-owned pointer rather than
> guest handles, so the function parameters don't have to live in guest memory.
This is odd to read - the function parameters (arguments) didn't live in
guest memory before either.
> No f
1 - 100 of 14787 matches
Mail list logo
