ls/arch/x86/include/asm/xen/prefix.h | 10 +++
> tools/arch/x86/lib/insn.c | 43
> +++
> tools/objtool/sync-check.sh |3 +-
> 9 files changed, 121 insertions(+), 3 deletions(-)
> create mode 100644 arch/x86/inc
On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote:
> I don't know if you've spotted, but the prefix is a ud2a instruction
> followed by 'xen' in ascii.
>
> The KVM version was added in c/s 6c86eedc206dd1f9d37a2796faa8e6f2278215d2
While the Xen one disassebles to valid instructions, th
On Thu, Sep 05, 2019 at 09:53:32AM +0100, Andrew Cooper wrote:
> On 05/09/2019 09:26, Peter Zijlstra wrote:
> > On Thu, Sep 05, 2019 at 08:54:17AM +0100, Andrew Cooper wrote:
> >
> >> I don't know if you've spotted, but the prefix is a ud2a instructi
On Fri, Sep 06, 2019 at 10:45:48AM +0900, Masami Hiramatsu wrote:
> diff --git a/arch/x86/include/asm/xen/interface.h
> b/arch/x86/include/asm/xen/interface.h
> index 62ca03ef5c65..fe33a9798708 100644
> --- a/arch/x86/include/asm/xen/interface.h
> +++ b/arch/x86/include/asm/xen/interface.h
> @@ -
On Fri, Sep 06, 2019 at 05:51:43PM +0900, Masami Hiramatsu wrote:
> On Fri, 6 Sep 2019 17:45:19 +0900
> Masami Hiramatsu wrote:
>
> > >
> > > How about we make this asm/virt_prefix.h or something and include:
> > >
> > > /*
> > > * Virt escape sequences to trigger instruction emulation;
> > >
On Sat, May 25, 2019 at 10:54:50AM +0200, Juergen Gross wrote:
> On 25/05/2019 10:22, Nadav Amit wrote:
> > diff --git a/arch/x86/include/asm/paravirt_types.h
> > b/arch/x86/include/asm/paravirt_types.h
> > index 946f8f1f1efc..3a156e63c57d 100644
> > --- a/arch/x86/include/asm/paravirt_types.h
>
On Mon, May 27, 2019 at 12:21:59PM +0200, Paolo Bonzini wrote:
> On 27/05/19 11:47, Peter Zijlstra wrote:
> > --- a/arch/x86/kernel/kvm.c
> > +++ b/arch/x86/kernel/kvm.c
> > @@ -580,7 +580,7 @@ static void __init kvm_apf_trap_init(voi
> >
> > static DEFINE_PER
On Wed, Jun 12, 2019 at 12:12:28PM +0200, Juergen Gross wrote:
> When running as a Xen guest selecting "nosmt" either via command line
> or implicitly via default settings makes no sense, as the guest has no
> clue about the real system topology it is running on. With Xen it is
> the hypervisor's j
On Thu, Aug 01, 2019 at 07:16:19PM -0700, john.hubb...@gmail.com wrote:
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions"). That commit
> has an extensive description of the problem and the planned steps to
> solve
On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
>
> Could you review this version?
These look good to me; shall I merge them or what was the plan?
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xen
On Thu, Oct 17, 2019 at 12:26:55PM +0900, Masami Hiramatsu wrote:
> Hi Peter,
>
> On Wed, 9 Oct 2019 14:31:06 +0200
> Peter Zijlstra wrote:
>
> > On Tue, Sep 17, 2019 at 03:14:03PM +0900, Masami Hiramatsu wrote:
> > > Hi Peter,
> > >
> > > Co
On Tue, Mar 13, 2018 at 01:59:24PM -0700, Thomas Garnier wrote:
> @@ -1576,7 +1578,9 @@ first_nmi:
> addq$8, (%rsp) /* Fix up RSP */
> pushfq /* RFLAGS */
> pushq $__KERNEL_CS/* CS */
> - pushq $1f /* RIP */
> + pushq %rax
On Tue, Mar 13, 2018 at 01:59:39PM -0700, Thomas Garnier wrote:
> + /*
> + * If PIE is not enabled or no GOT call was found, default to the
> + * original approach to code modification.
> + */
> + if (!IS_ENABLED(CONFIG_X86_PIE)
> + || probe_kernel_read(replaced, (voi
On Mon, Aug 13, 2018 at 09:37:37AM +0200, Juergen Gross wrote:
> Some of the paravirt ops defined in pv_irq_ops are for Xen PV guests
> only. Define them only if CONFIG_PARAVIRT_XXL is set.
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index e652e
On Mon, Aug 13, 2018 at 09:37:38AM +0200, Juergen Gross wrote:
> struct pv_mmu_ops {
> + /* TLB operations */
> + void (*flush_tlb_user)(void);
> + void (*flush_tlb_kernel)(void);
> + void (*flush_tlb_one_user)(unsigned long addr);
> + void (*flush_tlb_others)(const struct cpum
On Fri, Aug 24, 2018 at 03:52:55PM +0200, Juergen Gross wrote:
> Ping?
Looking good; although I messed it up a little bit by adding a new
paravirt function.
Thanks for doing this!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.
On Sat, Jan 06, 2018 at 01:39:48PM -0800, Nick Desaulniers wrote:
> Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
> frowned upon by others.
>
> https://lkml.org/lkml/2013/9/23/500
>
> Here, the VLAIS was used because the size of the bitmap returned from
> xen_mc_entry()
On Fri, Sep 25, 2020 at 11:29:13AM -0400, Qian Cai wrote:
> It looks like the crashes happen in the interrupt remapping code where they
> are
> only able to to generate partial call traces.
> [8.466614][T0] BUG: kernel NULL pointer dereference, address:
>
> [8.47429
On Fri, Oct 09, 2020 at 04:42:25PM +0200, Juergen Gross wrote:
> When running in lazy TLB mode the currently active page tables might
> be the ones of a previous process, e.g. when running a kernel thread.
>
> This can be problematic in case kernel code is being modified via
> text_poke() in a ker
On Mon, Oct 12, 2020 at 12:26:06PM +0200, Jürgen Groß wrote:
> > > @@ -807,6 +807,15 @@ static inline temp_mm_state_t
> > > use_temporary_mm(struct mm_struct *mm)
> > > temp_mm_state_t temp_state;
> > > lockdep_assert_irqs_disabled();
> > > +
> > > + /*
> > > + * Make sure no
On Tue, Apr 07, 2020 at 10:03:06PM -0700, Ankur Arora wrote:
> +/*
> + * preempt_enable_no_resched() so we don't add any preemption points until
> + * after the caller has returned.
> + */
> +#define preempt_enable_runtime_patch() preempt_enable_no_resched()
> +#define preempt_disable_runtime
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> struct text_poke_loc {
> s32 rel_addr; /* addr := _stext + rel_addr */
> - s32 rel32;
> - u8 opcode;
> + union {
> + struct {
> + s32 rel32;
> + u8 opcode;
> +
On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static void __maybe_unused sync_one(void)
> +{
> + /*
> + * We might be executing in NMI context, and so cannot use
> + * IRET as a synchronizing instruction.
> + *
> + * We could use native_write_cr2() but that
On Tue, Apr 07, 2020 at 10:03:11PM -0700, Ankur Arora wrote:
> @@ -1071,10 +1079,13 @@ int notrace poke_int3_handler(struct pt_regs *regs)
> goto out_put;
> }
>
> - len = text_opcode_size(tp->opcode);
> + if (desc->native)
> + BUG();
> +
Subject:
On Tue, Apr 07, 2020 at 10:03:12PM -0700, Ankur Arora wrote:
> +static int __maybe_unused text_poke_late(patch_worker_t worker, void *stage)
> +{
> + int ret;
> +
> + lockdep_assert_held(&text_mutex);
> +
> + if (system_state != SYSTEM_RUNNING)
> + return -EINVAL;
> +
> +
On Tue, Apr 07, 2020 at 10:03:16PM -0700, Ankur Arora wrote:
> @@ -1807,12 +1911,20 @@ static int __maybe_unused
> text_poke_late(patch_worker_t worker, void *stage)
> text_poke_state.state = PATCH_SYNC_DONE; /* Start state */
> text_poke_state.primary_cpu = smp_processor_id();
>
> +
On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
> A KVM host (or another hypervisor) might advertise paravirtualized
> features and optimization hints (ex KVM_HINTS_REALTIME) which might
> become stale over the lifetime of the guest. For instance, the
> host might go from being undersu
On Wed, Apr 08, 2020 at 03:33:52PM +0200, Jürgen Groß wrote:
> On 08.04.20 14:08, Peter Zijlstra wrote:
> > On Tue, Apr 07, 2020 at 10:02:57PM -0700, Ankur Arora wrote:
> > > Mechanism: the patching itself is done using stop_machine(). That is
> > > not ideal -- t
On Thu, Oct 22, 2020 at 11:24:39AM +0200, Jürgen Groß wrote:
> On 09.10.20 16:42, Juergen Gross wrote:
> > When running in lazy TLB mode the currently active page tables might
> > be the ones of a previous process, e.g. when running a kernel thread.
> >
> > This can be problematic in case kernel c
ug exception already do.
>
> Juergen Gross (4):
> x86/xen: use specific Xen pv interrupt entry for MCE
> x86/xen: use specific Xen pv interrupt entry for DF
> x86/pv: switch SWAPGS to ALTERNATIVE
> x86/xen: drop USERGS_SYSRET64 paravirt call
Looks 'sane' :-))
Acked-by: Peter Zijlstra (Intel)
On Fri, Nov 20, 2020 at 12:46:23PM +0100, Juergen Gross wrote:
> +static __always_inline void arch_local_irq_restore(unsigned long flags)
> +{
> + if (!arch_irqs_disabled_flags(flags))
> + arch_local_irq_enable();
> +}
If someone were to write horrible code like:
local_irq
On Fri, Nov 20, 2020 at 12:46:24PM +0100, Juergen Gross wrote:
> The time pvops functions are the only ones left which might be
> used in 32-bit mode and which return a 64-bit value.
>
> Switch them to use the static_call() mechanism instead of pvops, as
> this allows quite some simplification of
On Fri, Nov 20, 2020 at 12:46:26PM +0100, Juergen Gross wrote:
> +#define PVOP_CALL(rettype, op, clbr, call_clbr, extra_clbr, ...) \
> ({ \
> PVOP_CALL_ARGS; \
>
On Fri, Nov 20, 2020 at 12:46:18PM +0100, Juergen Gross wrote:
> 30 files changed, 325 insertions(+), 598 deletions(-)
Much awesome ! I'll try and get that objtool thing sorted.
On Fri, Nov 20, 2020 at 01:53:42PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 20, 2020 at 12:46:18PM +0100, Juergen Gross wrote:
> > 30 files changed, 325 insertions(+), 598 deletions(-)
>
> Much awesome ! I'll try and get that objtool thing sorted.
This seems to work
On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> From: Eduardo Valentin
>
> System instability are seen during resume from hibernation when system
> is under heavy CPU load. This is due to the lack of update of sched
> clock data, and the scheduler would then think that heavy CPU
On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> Hey Peter,
>
> On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> > On Tue, Jan 07, 2020 at 11:45:26PM +, Anchal Agarwal wrote:
> > > From: Eduardo Valentin
> > >
> &g
On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> For your original comment, just wanted to clarify the following:
>
> 1. After hibernation, the machine can be resumed on a different but compatible
> host (these are VM images hibernated)
> 2. This means the clock between host1 and h
On Tue, Feb 09, 2021 at 02:16:49PM -0800, Nadav Amit wrote:
> @@ -816,8 +821,8 @@ STATIC_NOPV void native_flush_tlb_others(const struct
> cpumask *cpumask,
>* doing a speculative memory access.
>*/
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, fl
On Wed, Jul 01, 2020 at 01:06:46PM +0200, Juergen Gross wrote:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporti
On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
> diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> index 4722ba2..2138d69 100644
> --- a/arch/x86/xen/enlighten_pv.c
> +++ b/arch/x86/xen/enlighten_pv.c
> @@ -596,7 +596,7 @@ struct trap_array_entry {
>
> sta
On Fri, Jul 12, 2019 at 09:04:22PM +0800, Zhenzhong Duan wrote:
>
> On 2019/7/12 20:06, Peter Zijlstra wrote:
> > On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
> > > diff --git a/arch/x86/xen/enlighten_pv.c b/arch/x86/xen/enlighten_pv.c
> > >
On Fri, Jul 12, 2019 at 03:09:16PM +0200, Peter Zijlstra wrote:
> On Fri, Jul 12, 2019 at 09:04:22PM +0800, Zhenzhong Duan wrote:
> >
> > On 2019/7/12 20:06, Peter Zijlstra wrote:
> > > On Thu, Jul 11, 2019 at 04:15:21PM +0800, Zhenzhong Duan wrote:
> >
On Mon, Jul 15, 2019 at 01:37:37PM +0200, Juergen Gross wrote:
> The long term plan has been to replace Xen PV guests by PVH. The first
> victim of that plan are now 32-bit PV guests, as those are used only
> rather seldom these days. Xen on x86 requires 64-bit support and with
> Grub2 now supporti
On Thu, Jul 18, 2019 at 05:58:32PM -0700, Nadav Amit wrote:
> @@ -709,8 +716,9 @@ void native_flush_tlb_others(const struct cpumask
> *cpumask,
>* doing a speculative memory access.
>*/
> if (info->freed_tables) {
> - smp_call_function_many(cpumask, flush_tlb_func
On Mon, Jul 22, 2019 at 07:27:09PM +, Nadav Amit wrote:
> > On Jul 22, 2019, at 12:14 PM, Peter Zijlstra wrote:
> > But then we can still do something like the below, which doesn't change
> > things and still gets rid of that dual function crud, simplifying
> >
ive.
Add ANNOTATE_ENDBR to silence future objtool warnings.
Fixes: ed53a0d97192 ("x86/alternative: Use .ibt_endbr_seal to seal indirect
calls")
Signed-off-by: Josh Poimboeuf
Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Andrew Cooper
Link:
https://lkml.kernel.org/r/a87bd48b06d11ec4b98122a429e71e489b4e48c3.1650300597.git.jpoim...@redhat.com
y the ".note.Xen"
section, and is the real entry point of the VM. Control transfer is
through IRET, which *could* set NEED_ENDBR, however Xen currently does
no such thing.
Add ANNOTATE_NOENDBR to silence future objtool warnings.
Fixes: ed53a0d97192 ("x86/alternative: Use .ibt_endb
On Thu, Nov 04, 2021 at 12:45:29AM +0100, Thomas Gleixner wrote:
> On Wed, Oct 27 2021 at 17:29, Josef Johansson wrote:
> > [ cut here ]
> > cfs_rq->avg.load_avg || cfs_rq->avg.util_avg || cfs_rq->avg.runnable_avg
> > installing Xen timer for CPU 4
> > WARNING: CPU: 3 PID: 4
On Tue, Nov 02, 2021 at 07:36:36PM -0400, Boris Ostrovsky wrote:
> Commit 66558b730f25 ("sched: Add cluster scheduler level for x86")
> introduced cpu_l2c_shared_map mask which is expected to be initialized
> by smp_op.smp_prepare_cpus(). That commit only updated
> native_smp_prepare_cpus() version
On Mon, Nov 08, 2021 at 12:20:26PM -0500, Boris Ostrovsky wrote:
>
> On 11/8/21 10:11 AM, Peter Zijlstra wrote:
> > On Tue, Nov 02, 2021 at 07:36:36PM -0400, Boris Ostrovsky wrote:
> > > Commit 66558b730f25 ("sched: Add cluster scheduler level for x86")
> >
On Wed, Nov 10, 2021 at 10:52:09PM +0100, Josef Johansson wrote:
> On 11/3/21 00:36, Boris Ostrovsky wrote:
> > Commit 66558b730f25 ("sched: Add cluster scheduler level for x86")
> > introduced cpu_l2c_shared_map mask which is expected to be initialized
> > by smp_op.smp_prepare_cpus(). That commit
On Thu, Nov 11, 2021 at 08:26:58AM +0100, Paolo Bonzini wrote:
> On 11/11/21 03:07, Sean Christopherson wrote:
> > EXPORT_SYMBOL_GPL(perf_register_guest_info_callbacks);
> > int perf_unregister_guest_info_callbacks(struct perf_guest_info_callbacks
> > *cbs)
> > {
> > - perf_guest_cbs = NU
On Thu, Nov 11, 2021 at 02:07:21AM +, Sean Christopherson wrote:
> Like Xu (1):
> perf/core: Rework guest callbacks to prepare for static_call support
>
> Sean Christopherson (16):
> perf: Protect perf_guest_cbs with RCU
> KVM: x86: Register perf callbacks after calling vendor's
> h
| 7 ---
> arch/x86/mm/ioremap.c | 2 +-
> arch/x86/xen/setup.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 ++--
> include/asm-generic/fixmap.h | 2 +-
> 6 files changed, 6 insertions(+), 13 deletions(-)
Acked-by: Peter Zijlstra (Intel)
tance of the SWAPGS macro.
>
> Cc: # 5.19
> Fixes: c89191ce67ef ("x86/entry: Convert SWAPGS to swapgs and remove the
> definition of SWAPGS")
> Signed-off-by: Juergen Gross
It's a little unfortunate int80 is different from the other compat entry
points, but tha
On Tue, Aug 30, 2022 at 02:48:49PM -0700, Suren Baghdasaryan wrote:
> ===
> Code tagging framework
> ===
> Code tag is a structure identifying a specific location in the source code
> which is generated at compile time and can be embedded in an applic
On Tue, Aug 30, 2022 at 02:48:52PM -0700, Suren Baghdasaryan wrote:
> +static void lazy_percpu_counter_switch_to_pcpu(struct
> raw_lazy_percpu_counter *c)
> +{
> + u64 __percpu *pcpu_v = alloc_percpu_gfp(u64, GFP_ATOMIC|__GFP_NOWARN);
Realize that this is incorrect when used under a raw_spinl
On Wed, Aug 31, 2022 at 11:19:48AM +0100, Mel Gorman wrote:
> It's also unclear *who* would enable this. It looks like it would mostly
> have value during the development stage of an embedded platform to track
> kernel memory usage on a per-application basis in an environment where it
> may be dif
On Wed, Aug 31, 2022 at 11:59:41AM -0400, Kent Overstreet wrote:
> Also, ftrace can drop events. Not really ideal if under system load your
> memory
> accounting numbers start to drift.
You could attach custom handlers to tracepoints. If you were to replace
these unconditional code hooks of your
On Tue, Aug 30, 2022 at 02:49:16PM -0700, Suren Baghdasaryan wrote:
> From: Kent Overstreet
>
> This adds the ability to easily instrument code for measuring latency.
> To use, add the following to calls to your code, at the start and end of
> the event you wish to measure:
>
> code_tag_time_s
On Wed, Aug 31, 2022 at 01:46:29PM -0400, Kent Overstreet wrote:
> Because all the counters are statically allocated, without even a pointer
> deref
> to get to them in the allocation path (one pointer deref to get to them in the
> deallocate path), that makes this _much, much_ cheaper than anyth
On Thu, Sep 01, 2022 at 09:05:36AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 31, 2022 at 11:59:41AM -0400, Kent Overstreet wrote:
>
> > Also, ftrace can drop events. Not really ideal if under system load your
> > memory
> > accounting numbers start to drift.
>
On Thu, Sep 01, 2022 at 10:32:19AM -0400, Kent Overstreet wrote:
> On Thu, Sep 01, 2022 at 08:51:31AM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 30, 2022 at 02:48:52PM -0700, Suren Baghdasaryan wrote:
> > > +static void lazy_percpu_counter_switch_to_pcpu(struct
> > >
t let xen_pv_play_dead() return
> x86/xen: mark xen_pv_play_dead() as __noreturn
>
> arch/x86/xen/smp.h | 2 ++
> arch/x86/xen/smp_pv.c | 17 -
> arch/x86/xen/xen-head.S | 7 +++
> tools/objtool/check.c | 1 +
> 4 files changed, 14 insertions(+), 13 deletions(-)
Acked-by: Peter Zijlstra (Intel)
When resuming there must not be any code between swsusp_arch_suspend()
and restore_processor_state() since the CPU state is ill defined at
this point in time.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/power/hibernate.c | 30 +++---
1 file changed, 27 insertions
cpu() invocation from secondary_startup_64()
renders the whole secondary_startup_64_no_verify() thing moot, so
remove that too.
Cc: jroe...@suse.de
Cc: h...@zytor.com
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter
From: Joan Bruguera
When resuming from suspend we don't have coherent CPU state, trying to
do callthunks here isn't going to work. Specifically GS isn't set yet.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Signed-off-by: Joan Brugu
Since Xen PV doesn't use restore_processor_state(), and we're going to
have to avoid CALL/RET until at least GS is restored, de-paravirt the
easy bits.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-of
Hi all,
Patches to address the various callthunk fails reported by Joan.
The first two patches are new (and I've temporarily dropped the
restore_processor_state sealing).
It is my understanding that AP bringup will always use the 16bit trampoline
path, if this is not the case, please holler.
hunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/kernel/head_64.S | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64
Since we can't do CALL/RET until GS is restored and CR[04] pinning is
of dubious value in this code path, simply write the stored values.
Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
tracking")
Reported-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (I
Ensure no compiler instrumentation sneaks in while restoring the CPU
state. Specifically we can't handle CALL/RET until GS is restored.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/
On Tue, Jan 17, 2023 at 10:31:05AM +0100, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > + /*
> > +* Definitely wrong, but at this point we should have at least enough
> > +* to do CALL/RET (consider SKL callthunks) and this avoids having
> >
On Sun, Jan 15, 2023 at 08:27:50PM -0800, Srivatsa S. Bhat wrote:
> I see that's not an issue right now since there is no other actual
> user for these callbacks. But are we sure that merging the callbacks
> just because the current user (Xen PV) has the same implementation for
> both is a good id
On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
> The boot trampolines from trampoline_64.S have code flow like:
>
> 16bit BIOS SEV-ES 64bit EFI
>
> trampoline_start() sev_es_trampoline_start()
> t
On Wed, Jan 25, 2023 at 12:38:46AM -0800, Suren Baghdasaryan wrote:
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 2d6d790d9bed..6c7c70bf50dd 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -491,7 +491,13 @@ struct vm_area_struct {
>
On Thu, Jan 19, 2023 at 11:35:06AM -0800, H. Peter Anvin wrote:
> On January 18, 2023 1:45:44 AM PST, Peter Zijlstra
> wrote:
> >On Mon, Jan 16, 2023 at 03:25:34PM +0100, Peter Zijlstra wrote:
> >> The boot trampolines from trampoline_64.S have code flow like:
&g
On Tue, Feb 14, 2023 at 12:47:00PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> The following commits are also in the tip tree as different commits
> (but the same patches):
>
> 415dab3c1796 ("drivers/xen/hypervisor: Expose Xen SIF flags to userspace")
> 336f560a8917 ("x86/xen: don't let xen_
On Thu, Jun 09, 2022 at 04:49:21PM -0700, Jacob Pan wrote:
> Hi Peter,
>
> On Wed, 08 Jun 2022 16:27:27 +0200, Peter Zijlstra
> wrote:
>
> > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
> > Xeons") wrecked intel_idle in two ways:
>
On Mon, Jun 13, 2022 at 04:26:01PM +0800, Lai Jiangshan wrote:
> On Wed, Jun 8, 2022 at 10:48 PM Peter Zijlstra wrote:
> >
> > Now that arch_cpu_idle() is expected to return with IRQs disabled,
> > avoid the useless STI/CLI dance.
> >
> > Per the specs this is sup
On Mon, Jun 13, 2022 at 03:39:05PM +0300, Tony Lindgren wrote:
> OMAP4 uses full SoC suspend modes as idle states, as such it needs the
> whole power-domain and clock-domain code from the idle path.
>
> All that code is not suitable to run with RCU disabled, as such push
> RCU-idle deeper still.
>
On Tue, Jun 14, 2022 at 12:19:29PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:23PM +0200, Peter Zijlstra wrote:
> > Hi All! (omg so many)
>
> Hi Peter,
>
> Sorry for the delay; my plate has also been rather full recently. I'm
> beginning
> to p
On Tue, Jun 14, 2022 at 05:13:16PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:38PM +0200, Peter Zijlstra wrote:
> > All callers should still have RCU enabled.
>
> IIUC with that true we should be able to drop the RCU_NONIDLE() from
> drivers/perf/arm_pmu.c, as w
On Mon, Jun 13, 2022 at 07:23:13PM +, Nadav Amit wrote:
> On Jun 13, 2022, at 11:48 AM, Srivatsa S. Bhat wrote:
>
> > ⚠ External Email
> >
> > On 6/8/22 4:27 PM, Peter Zijlstra wrote:
> >> vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wb
On Tue, Jun 14, 2022 at 01:41:13PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:37PM +0200, Peter Zijlstra wrote:
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -622,9 +622,13 @@ struct cpumask *tick_get_broadcast_onesh
&g
On Sat, Apr 15, 2023 at 01:44:13AM +0200, Thomas Gleixner wrote:
> Background
> --
>
> The reason why people are interested in parallel bringup is to shorten
> the (kexec) reboot time of cloud servers to reduce the downtime of the
> VM tenants. There are obviously other interesting use ca
On Tue, Jun 22, 2021 at 05:42:49PM +0800, Zhu Lingshan wrote:
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 8f71dd72ef95..c71af4cfba9b 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -90,6 +90,27 @@ DEFINE_STATIC_CALL_NULL(x86_pmu_pebs_aliases,
>
On Fri, Jul 02, 2021 at 09:00:22AM -0700, Joe Perches wrote:
> On Fri, 2021-07-02 at 13:22 +0200, Peter Zijlstra wrote:
> > On Tue, Jun 22, 2021 at 05:42:49PM +0800, Zhu Lingshan wrote:
> > > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> []
On Thu, Aug 05, 2021 at 10:05:17PM +0800, Tianyu Lan wrote:
> +static int default_set_memory_enc(unsigned long addr, int numpages, bool
> enc)
> +{
> + return 0;
> +}
> +
> +DEFINE_STATIC_CALL(x86_set_memory_enc, default_set_memory_enc);
That's spelled:
DEFINE_STATIC_CALL_RET0(x86_set_memory_
On Thu, Aug 05, 2021 at 10:05:17PM +0800, Tianyu Lan wrote:
> static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
> {
> + return static_call(x86_set_memory_enc)(addr, numpages, enc);
> }
Hurpmh... So with a bit of 'luck' you get code-gen like:
__set_memory_enc_dec:
On Tue, Nov 22, 2022 at 05:23:50PM -0800, Josh Poimboeuf wrote:
> On Tue, Nov 22, 2022 at 09:35:17AM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 21, 2022 at 09:16:05PM -0800, Josh Poimboeuf wrote:
> >
> > > It's complaining about an unreachabl
Hi,
I'm thinking these few patches should do the trick -- but I've only compiled
them and looked at the resulting asm output, I've not actually ran them.
Joan, could you kindly test?
The last (two) patches are optional fixes and should probably not go into
/urgent.
Disallow indirect branches to restore_processor_state().
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/include/asm/suspend_64.h |4
arch/x86/power/cpu.c |2 +-
arch/x86/power/hibernate_asm_64.S |4
include/linux/suspend.h |4
4 files
When resuming there must not be any code between swsusp_arch_suspend()
and restore_processor_state() since the CPU state is ill defined at
this point in time.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/power/hibernate.c | 30 +++---
1 file changed, 27 insertions
From: Joan Bruguera
When resuming from suspend we don't have coherent CPU state, trying to
do callthunks here isn't going to work. Specifically GS isn't set yet.
Signed-off-by: Joan Bruguera
Signed-off-by: Peter Zijlstra (Intel)
Link: https://lkml.kernel.org/r/20230109040531.78
Since we can't do CALL/RET until GS is restored and CR[04] pinning is
of dubious value in this code path, simply write the stored values.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/power/cpu.c
Ensure no compiler instrumentation sneaks in while restoring the CPU
state. Specifically we can't handle CALL/RET until GS is restored.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
--- a/arch/x86/
Since Xen PV doesn't use restore_processor_state(), and we're going to
have to avoid CALL/RET until at least GS is restored, de-paravirt the
easy bits.
Signed-off-by: Peter Zijlstra (Intel)
---
arch/x86/power/cpu.c | 24
1 file changed, 12 insertions(+), 12
On Fri, Jan 13, 2023 at 07:39:38AM +, Joan Bruguera wrote:
> Hi Peter,
>
> I tried your patches on both QEMU and my two (real) computers where
> s2ram with `retbleed=stuff` was failing and they wake up fine now.
Yay \o/
> However, I think some minor reviews are needed:
>
> (1) I got a build
1 - 100 of 199 matches
Mail list logo
