David!
On Sun, Nov 03 2024 at 16:05, David Wang wrote:
$Subject: [PATCH] kernel/irq/proc: performance: ...
That's not a valid subsystem prefix.
> seq_printf is costy, when stress reading /proc/interrupts, profiling indicates
> seq_printf takes about ~47% of show_interrupts samples:
Also please
David!
On Sun, Nov 03 2024 at 16:05, David Wang wrote:
$Subject: [PATCH] kernel/irq/proc: performance: ...
That's not a valid subsystem prefix.
> seq_printf is costy, when stress reading /proc/interrupts, profiling indicates
> seq_printf takes about ~47% of show_interrupts samples:
Also please
On Wed, Nov 06 2024 at 22:19, David Laight wrote:
> From: Thomas Gleixner
>> Still the macro should be documented.
>
> I was wondering if it really had any purpose at all.
> It just obfuscates code, doesn't even make it smaller.
What is obfuscated here?
secs_to_jiffies(
On Fri, Nov 01 2024 at 11:03, mapicccy wrote:
>> 2024年10月31日 18:35，Thomas Gleixner 写道：
>>> + get_nodes_in_cpumask(node_to_cpumask, premask, &nodemsk);
>>> +
>>> + for_each_node_mask(n, nodemsk) {
>>> + cpumask_and(&managed_irq
On Fri, Nov 01 2024 at 23:19, Jarkko Sakkinen wrote:
> On Fri Nov 1, 2024 at 11:13 PM EET, Jarkko Sakkinen wrote:
>> I think we can sort them out independently as long as we find a
>> conclusion how to address locality change.
>
> And to be fair: there was no reaction from anyone. It is mostly x86
On Fri, Nov 01 2024 at 23:19, Jarkko Sakkinen wrote:
> On Fri Nov 1, 2024 at 11:13 PM EET, Jarkko Sakkinen wrote:
>> I think we can sort them out independently as long as we find a
>> conclusion how to address locality change.
>
> And to be fair: there was no reaction from anyone. It is mostly x86
On Fri, Nov 01 2024 at 12:28, Jarkko Sakkinen wrote:
> On Fri Sep 13, 2024 at 11:04 PM EEST, Ross Philipson wrote:
>> A quick note on terminology. The larger open source project itself is called
>> TrenchBoot, which is hosted on Github (links below). The kernel feature
>> enabling
>> the use of Dy
On Fri, Nov 01 2024 at 12:28, Jarkko Sakkinen wrote:
> On Fri Sep 13, 2024 at 11:04 PM EEST, Ross Philipson wrote:
>> A quick note on terminology. The larger open source project itself is called
>> TrenchBoot, which is hosted on Github (links below). The kernel feature
>> enabling
>> the use of Dy
On Fri, Nov 01 2024 at 11:18, Yicong Yang wrote:
> On 2024/10/31 21:33, Thomas Gleixner wrote:
>> cpu_smt_control is not guaranteed to have CPU_SMT_ENABLED state, so this
>> argument is bogus.
>>
> sorry for didn't explain all the cases here.
>
> For
On Fri, Nov 01 2024 at 00:37, Jarkko Sakkinen wrote:
> On Thu Oct 31, 2024 at 9:25 PM EET, Thomas Gleixner wrote:
>> So this looks pretty reasonable to me by now and I'm inclined to take it
>> through the tip x86 tree, but that needs reviewed/acked-by's from the
>>
On Fri, Nov 01 2024 at 00:37, Jarkko Sakkinen wrote:
> On Thu Oct 31, 2024 at 9:25 PM EET, Thomas Gleixner wrote:
>> So this looks pretty reasonable to me by now and I'm inclined to take it
>> through the tip x86 tree, but that needs reviewed/acked-by's from the
>>
On Fri, Sep 13 2024 at 13:04, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner. The first area of
> focus has been on the Trusted Computing Group's Dynamic Launch for
> establis
On Fri, Sep 13 2024 at 13:04, Ross Philipson wrote:
> The larger focus of the TrenchBoot project (https://github.com/TrenchBoot) is
> to
> enhance the boot security and integrity in a unified manner. The first area of
> focus has been on the Trusted Computing Group's Dynamic Launch for
> establis
On Tue, Oct 15 2024 at 20:51, Philipp Stanner wrote:
> +/**
> + * pci_intx - enables/disables PCI INTx for device dev, unmanaged version
mismatch vs. actual function name.
> + * @pdev: the PCI device to operate on
> + * @enable: boolean: whether to enable or disable PCI INTx
> + *
> + * Enables/d
On Thu, Oct 31 2024 at 20:17, Yicong Yang wrote:
> On 2024/10/30 22:55, Thomas Gleixner wrote:
>>> +static inline bool topology_is_primary_thread(unsigned int cpu)
>>> +{
>>> + /*
>>> +* On SMT hotplug the primary thread of the SMT won't be
On Thu, Oct 31 2024 at 10:56, Frederic Weisbecker wrote:
> On Thu, Oct 31, 2024 at 02:10:14PM +0530, Naresh Kamboju wrote:
>> <4>[ 0.220657] WARNING: CPU: 1 PID: 0 at kernel/time/clockevents.c:455
>> clockevents_register_device (kernel/time/clockevents.c:455
>
> It's possible that I messed up somet
On Thu, Oct 31 2024 at 15:46, guan...@linux.alibaba.com wrote:
> #ifdef CONFIG_SMP
>
> +static unsigned int __read_mostly managed_irqs_per_node;
> +static struct cpumask managed_irqs_cpumsk[MAX_NUMNODES]
> __cacheline_aligned_in_smp = {
> + [0 ... MAX_NUMNODES-1] = {CPU_BITS_ALL}
> +};
>
On Thu, Oct 31 2024 at 14:10, Naresh Kamboju wrote:
> The QEMU-ARM64 boot has failed with the Linux next-20241031 tag.
> The boot log shows warnings at clockevents_register_device and followed
> by rcu_preempt detected stalls.
>
> However, the system did not proceed far enough to reach the login pr
On Wed, Oct 30 2024 at 20:54, Yicong Yang wrote:
>
> +#ifndef topology_is_primary_thread
> +#define topology_is_primary_thread topology_is_primary_thread
Please do not glue defines and functions together w/o a newline in between.
> +static inline bool topology_is_primary_thread(unsigned int cpu
On Tue, Oct 29 2024 at 17:22, Geert Uytterhoeven wrote:
> On Tue, Oct 29, 2024 at 5:08 PM Thomas Gleixner wrote:
>> On Mon, Oct 28 2024 at 19:11, Easwar Hariharan wrote:
>> > diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
>> > index 1220f0fbe5bf..e52
On Mon, Oct 28 2024 at 19:11, Easwar Hariharan wrote:
> diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
> index 1220f0fbe5bf..e5256bb5f851 100644
> --- a/include/linux/jiffies.h
> +++ b/include/linux/jiffies.h
> @@ -526,6 +526,8 @@ static __always_inline unsigned long
> msecs_to_jif
On Mon, Oct 28 2024 at 09:05, Sean Christopherson wrote:
> On Mon, Oct 28, 2024, Nam Cao wrote:
>> This is the first part of a 5-part series (split for convenience). All 5
>> parts are:
>>
>> Part 1:
>> https://lore.kernel.org/lkml/cover.1729864615.git.nam...@linutronix.de
>> Part 2:
>> https://
On Mon, Oct 28 2024 at 19:05, Thomas Gleixner wrote:
> On Fri, Oct 25 2024 at 18:06, Jinjie Ruan wrote:
>
>> As the front patch 6 ~ 13 did, the arm64_preempt_schedule_irq() is
>
> Once this series is applied nobody knows what 'front patch 6 ~ 13' did.
>
>> sa
On Fri, Oct 25 2024 at 18:06, Jinjie Ruan wrote:
$Subject: Can you please make this simply:
entry: Add arch_pre/post_report_syscall_entry/exit()
> Add some syscall arch functions to support arm64 to use generic syscall
> code, which do not affect existing architectures that use generic entry
On Fri, Oct 25 2024 at 18:06, Jinjie Ruan wrote:
> As the front patch 6 ~ 13 did, the arm64_preempt_schedule_irq() is
Once this series is applied nobody knows what 'front patch 6 ~ 13' did.
> same with the irq preempt schedule code of generic entry besides those
> architecture-related logic call
On Mon, Sep 30 2024 at 15:23, Mathieu Desnoyers wrote:
> diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> index a3d8ac00793e..0430890cbb42 100644
> --- a/kernel/trace/trace_syscalls.c
> +++ b/kernel/trace/trace_syscalls.c
> @@ -303,6 +303,7 @@ static void ftrace_syscall_
On Sat, Oct 12 2024 at 11:56, Luming Yu wrote:
> To have lowlevel paca.h include high level entry-common.h cause
> include file dependency mess. Split irqentry-state.h to have
> the irqentry_state.h can be included in low level paca.h
What's the rationale for this?
> Signed-off-by: Luming Yu
>
Signed-off-by: Shuah Khan
Reviewed-by: Thomas Gleixner
Thank you!
On Wed, Sep 11 2024 at 10:54, Thomas Gleixner wrote:
> On Wed, Sep 11 2024 at 15:44, Leizhen wrote:
>> 2. Member tot_cnt of struct global_pool can be deleted. We can get it
>>simply and quickly through (slot_idx * ODEBUG_BATCH_SIZE). Avoid
>>redundant maintenanc
On Wed, Oct 02 2024 at 14:49, Jeff Layton wrote:
> ---
> fs/inode.c | 5 +++--
Grmbl. I explicitely asked to split this into timekeeping and fs
patches, no?
That allows me to pick the timekeeping patches up myself and give
Christian a stable tag to pull them from. That le
On Wed, Sep 11 2024 at 10:30, Vincent Donnefort wrote:
> For tracing purpose, the boot clock is interesting as it doesn't stop on
> suspend. Export it as part of the time snapshot. This will later allow
> the hypervisor to add boot clock timestamps to its events.
>
> Cc: John
On Mon, Sep 16 2024 at 22:20, Christophe JAILLET wrote:
> Le 11/09/2024 à 07:13, Anna-Maria Behnsen a écrit :
>
> not directly related to your serie, but some time ago I sent a patch to
> micro-optimize Optimize usleep_range(). (See [1])
>
> The idea is that the 2 parameters of usleep_range() are
On Tue, Oct 01 2024 at 06:58, Jeff Layton wrote:
V8 ? I remember that I reviewed v* already :)
Also the sentence after the susbsystem prefix starts with an uppercase
letter.
> Multigrain timestamps allow the kernel to use fine-grained timestamps
> when an inode's attributes is being actively obs
u selection, at most 256
>> vCPUs are supported for interrupt routing.
> This patch is OK for me now, but seems it depends on the first two,
> and the first two will get upstream via loongarch-kvm tree. So is that
> possible to also apply this one to loongarch-kvm with your Acked-by?
Go ahead.
Reviewed-by: Thomas Gleixner
On Mon, Sep 16 2024 at 15:20, Costa Shulyupin wrote:
> Interrupts disturb real-time tasks on affined cpus.
> To ensure CPU isolation for real-time tasks, interrupt handling must
> be adjusted accordingly.
> Non-managed interrupts can be configured from userspace,
> while managed interrupts require
On Mon, Sep 16 2024 at 15:20, Costa Shulyupin wrote:
> +/*
> + * housekeeping_update - change housekeeping.cpumasks[type] and propagate the
> + * change.
> + */
> +static int housekeeping_update(enum hk_type type, const struct cpumask
> *update)
> +{
> + struct {
> + struct cpumask
On Tue, Oct 01 2024 at 05:45, Jeff Layton wrote:
> On Mon, 2024-09-30 at 23:35 +0200, Thomas Gleixner wrote:
>> > I certainly wouldn't rule out a workqueue job calling that function,
>> > but this is something we do while dirtying an inode, and that's not
>>
On Mon, Sep 30 2024 at 16:53, Jeff Layton wrote:
> On Mon, 2024-09-30 at 22:19 +0200, Thomas Gleixner wrote:
>> On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
>> > If however, two threads have racing syscalls that overlap in time, then
>> > there
On Mon, Sep 30 2024 at 15:37, Jeff Layton wrote:
> On Mon, 2024-09-30 at 21:16 +0200, Thomas Gleixner wrote:
> I have the following section in the multigrain-ts.rst file that gets
> added in patch 7 of this series. I'll also plan to add some extra
> wording about how backward rea
On Mon, Sep 30 2024 at 15:27, Jeff Layton wrote:
> On Mon, 2024-09-30 at 21:13 +0200, Thomas Gleixner wrote:
>> So if that's the intended behaviour then the changelog is misleading at
>> best.
>
> That is the intended behavior and I'll plan to fix the changelog
On Thu, Sep 19 2024 at 18:50, Jeff Layton wrote:
> The fix for this is to establish a floor value for the coarse-grained
> clock. When stamping a file with a fine-grained timestamp, we update
> the floor value with the current monotonic time (using cmpxchg). Then
> later, when a coarse-grained time
On Mon, Sep 16 2024 at 06:57, Jeff Layton wrote:
> On Mon, 2024-09-16 at 12:32 +0200, Thomas Gleixner wrote:
>> > 'Something has changed' is a truly understandable technical
>> > explanation.
>>
>> old = mg_floor
&
On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
> For multigrain timestamps, we must keep track of the latest timestamp
> that has ever been handed out, and never hand out a coarse time below
> that value.
How is that correct when the clock is off by an hour and then set back
to the correct valu
es. Include include/vdso/time64.h instead. This change
> will also make the defines consistent.
Acked-by: Thomas Gleixner
Cc+ i915 people
On Tue, Sep 17 2024 at 08:37, Will Deacon wrote:
> On Mon, Sep 16, 2024 at 10:52:18AM -0700, Christoph Lameter (Ampere) wrote:
>> On Fri, 13 Sep 2024, kernel test robot wrote:
>>
>> > >> drivers/gpu/drm/i915/gt/intel_tlb.h:21:47: error: macro
>> > >> "seqprop_sequence" requires 2
On Mon, Sep 16 2024 at 12:12, Thomas Gleixner wrote:
> On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
>> +do {
>> +seq = read_seqcount_begin(&tk_core.seq);
>> +
>> +ts->tv_sec = tk->xtime_sec;
>> +mono
On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
> fs/inode.c | 76
> --
> include/linux/timekeeping.h| 1 +
> kernel/time/timekeeping.c | 3 +-
> kernel/time/timekeeping_debug.c| 12 ++
> kernel/time/timekeepi
On Sat, Sep 14 2024 at 13:07, Jeff Layton wrote:
> For multigrain timestamps, we must keep track of the latest timestamp
What is a multgrain timestamp? Can you please describe the concept
behind it? I'm not going to chase random documentation or whatever
because change logs have to self contained.
On Wed, Sep 11 2024 at 15:44, Leizhen wrote:
> On 2024/9/10 19:44, Thomas Gleixner wrote:
>> That minimizes the pool lock contention and the cache foot print. The
>> global to free pool must have an extra twist to accomodate non-batch
>> sized drops and to handle the all slo
On Tue, Sep 10 2024 at 12:00, Leizhen wrote:
> On 2024/9/10 2:41, Thomas Gleixner wrote:
>> All related functions have this problem and all of this code is very
>> strict about boundaries. Instead of accurately doing the refill, purge
>> etc. we should look into proper batch
On Wed, Sep 04 2024 at 21:41, Zhen Lei wrote:
> Currently, there are multiple instances where several nodes are extracted
> from one list and added to another list. One by one extraction, and then
> one by one splicing, not only low efficiency, readability is also poor.
> The work can be done well
On Fri, Aug 30 2024 at 22:21, Ma Ke wrote:
> Zero and negative number is not a valid IRQ for in-kernel code and the
> irq_of_parse_and_map() function returns zero on error. So this check for
> valid IRQs should only accept values > 0.
The subsystem prefix is wrong. This changes drivers/i2c/busses
On Fri, Sep 06 2024 at 10:19, zhangji...@cmss.chinamobile.com wrote:
> @@ -362,6 +363,7 @@ int main(int argc, char *argv[])
> {
> char *test_name;
> int c, ret;
> + bool is_static = false;
what means is_static? It's not connected to test_name in any way and
please use reverse fir
On Tue, Sep 03 2024 at 12:24, Kees Cook wrote:
> On Tue, Sep 03, 2024 at 03:22:17PM -0400, Paul Moore wrote:
>> > > might_alloc include/linux/sched/mm.h:337 [inline]
>> > > slab_pre_alloc_hook mm/slub.c:3987 [inline]
>> > > slab_alloc_node mm/slub.c:4065 [inline]
>> > > kmem_cache_alloc_noprof+
On Mon, Aug 26 2024 at 01:29, syzbot wrote:
Cc:+ seccomp and audit folks
> syzbot found the following issue on:
>
> HEAD commit:6a7917c89f21 Add linux-next specific files for 20240822
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15c8680b98
> ker
On Thu, Aug 29 2024 at 16:25, Gianfranco Trad wrote:
Please add a proper subsystem prefix to the subject.
On Thu, Aug 29 2024 at 20:29, Huacai Chen wrote:
> On Thu, Aug 29, 2024 at 9:46 AM maobibo wrote:
>> > I think qemu hasn't release with v-eiointc? So we still have a chance
>> > to modify qemu and this driver to simplify registers:
>> It is already merged in qemu mainline, code is frozen and qemu
On Mon, Aug 26 2024 at 12:45, Christophe Leroy wrote:
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
>> On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe
On Mon, Aug 26 2024 at 12:45, Christophe Leroy wrote:
> Le 26/08/2024 à 10:58, Jason A. Donenfeld a écrit :
>> On Mon, Aug 26, 2024 at 10:37:49AM +0200, Christophe Leroy wrote:
>>>
>>>
>>> Le 26/08/2024 à 10:07, Jason A. Donenfeld a écrit :
On Thu, Aug 22, 2024 at 09:13:10AM +0200, Christophe
On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>> But tglx pointed out in that thread that this actually isn't necessary:
>>
>> | All of this is pointless because if a 32-bit application runs on a
>> | 64-bit kernel it has to use the 64-
On Mon, Aug 26 2024 at 10:01, Christophe Leroy wrote:
> Le 26/08/2024 à 09:50, Jason A. Donenfeld a écrit :
>> But tglx pointed out in that thread that this actually isn't necessary:
>>
>> | All of this is pointless because if a 32-bit application runs on a
>> | 64-bit kernel it has to use the 64-
hree drivers overriding it depend on that. They should
> probably also be marked broken, but we can give them a bit of a grace
> period for that.
One week :)
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
On Sat, Aug 24 2024 at 18:06, Wentao Zhang wrote:
The subject line is really not useful. What's 'odd' code?
> Disable instrumentation in the same areas that were disabled for
> kernel/gcov/
> Signed-off-by: Wentao Zhang
> Signed-off-by: Chuck Wolber
This Signed-off-by chain is broken. See Doc
On Sat, Aug 24 2024 at 18:06, Wentao Zhang wrote:
The subject line is really not useful. What's 'odd' code?
> Disable instrumentation in the same areas that were disabled for
> kernel/gcov/
> Signed-off-by: Wentao Zhang
> Signed-off-by: Chuck Wolber
This Signed-off-by chain is broken. See Doc
On Sat, Aug 24 2024 at 18:06, Wentao Zhang wrote:
> Makefile | 3 +
> arch/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> arch/x86/kernel/vmlinux.lds.S | 2 +
> include/asm-generic/vmlinux.lds.h | 38 +
> kernel/Makefile
On Sat, Aug 24 2024 at 18:06, Wentao Zhang wrote:
> Makefile | 3 +
> arch/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> arch/x86/kernel/vmlinux.lds.S | 2 +
> include/asm-generic/vmlinux.lds.h | 38 +
> kernel/Makefile
hree drivers overriding it depend on that. They should
> probably also be marked broken, but we can give them a bit of a grace
> period for that.
One week :)
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
hree drivers overriding it depend on that. They should
> probably also be marked broken, but we can give them a bit of a grace
> period for that.
One week :)
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
On Thu, Aug 22 2024 at 11:13, John Stultz wrote:
> On Mon, Aug 5, 2024 at 10:33 AM 'Vincent Donnefort' via kernel-team
> wrote:
>> diff --git a/include/linux/timekeeping.h b/include/linux/timekeeping.h
>> index fc12a9ba2c88..0fc6a61d64bd 100644
>> --- a/include/linux/timekeeping.h
>> +++ b/include
On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> On 5/31/24 09:54, Eric W. Biederman wrote:
>> Eric Biggers writes:
>>> That paragraph is also phrased as a hypothetical, "Even if we'd prefer to
>>> use
>>> SHA-256-only". That implies that you do not, in fact, prefer SHA-256 only.
>>> Is
On Thu, Aug 15 2024 at 13:38, Daniel P. Smith wrote:
> On 5/31/24 09:54, Eric W. Biederman wrote:
>> Eric Biggers writes:
>>> That paragraph is also phrased as a hypothetical, "Even if we'd prefer to
>>> use
>>> SHA-256-only". That implies that you do not, in fact, prefer SHA-256 only.
>>> Is
On Wed, Aug 14 2024 at 11:29, Daniel Thompson wrote:
> On Wed, Aug 14, 2024 at 10:51:41AM +0200, Florian Rommel wrote:
> That's enough to eventuallyremove the int3 instructions but it relies
> on entering the debug trap handler and there's no limit on how long
> could take before that happens. For
Daniel!
On Tue, Aug 13 2024 at 12:31, Daniel Thompson wrote:
> On Mon, Aug 12, 2024 at 11:04:13PM +0200, Thomas Gleixner wrote:
>> Btw, kgdb_skipexception() is a gross nisnomer because it rewinds the
>> instruction pointer to the exception address and does not skip anything,
&
Florian!
On Mon, Aug 12 2024 at 19:43, Florian Rommel wrote:
> On x86, occasionally, the removal of a breakpoint (i.e., removal of
> the int3 instruction) fails because the text_mutex is taken by another
> CPU (mainly due to the static_key mechanism, I think).
Either you know it or not. Speculati
Florian!
On Mon, Aug 12 2024 at 19:43, Florian Rommel wrote:
> On x86, after booting, the kernel text is read-only. Then, KGDB has to
> use the text_poke mechanism to install software breakpoints. KGDB
> uses a special (x86-specific) breakpoint type for these kinds of
> breakpoints (BP_POKE_BREA
On Mon, Aug 05 2024 at 15:35, Bibo Mao wrote:
> Interrupts can be routed to maximal four virtual CPUs with one external
> hardware interrupt. Add the extioi virt extension support so that
> Interrupts can be routed to 256 vcpus on hypervisor mode.
interrupts 256 vCPUs in hypervisor mode.
>
On Thu, Aug 08 2024 at 10:54, Peter Xu wrote:
> On Thu, Aug 08, 2024 at 12:22:38AM +0200, Thomas Gleixner wrote:
>> On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
>> > An entry should be reported as PUD leaf even if it's PROT_NONE, in which
>> > case PRESENT bit is
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> These new helpers will be needed for pud entry updates soon. Introduce
> these helpers by referencing the pmd ones. Namely:
>
> - pudp_invalidate()
> - pud_modify()
Zero content about what these helpers do and why they are needed. That's
not how it
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> Subject: mm/x86: arch_check_zapped_pud()
Is not a proper subject line. It clearly lacks a verb.
Subject: mm/x86: Implement arch_check_zapped_pud()
> Introduce arch_check_zapped_pud() to sanity check shadow stack on PUD zaps.
> It has the same l
On Wed, Aug 07 2024 at 15:48, Peter Xu wrote:
> An entry should be reported as PUD leaf even if it's PROT_NONE, in which
> case PRESENT bit isn't there. I hit bad pud without this when testing dax
> 1G on zapping a PROT_NONE PUD.
That does not qualify as a change log. What you hit is irrelevant un
> Signed-off-by: Michael Ellerman
Reviewed-by: Thomas Gleixner
On Tue, Aug 06 2024 at 15:12, Yunhong Jiang wrote:
> +static void __init hv_reserve_real_mode(void)
> +{
> + phys_addr_t mem;
> + size_t size = real_mode_size_needed();
> +
> + /*
> + * We only need the memory to be <4GB since the 64-bit trampoline goes
> + * down to 32-bit mo
On Tue, Aug 06 2024 at 15:12, Yunhong Jiang wrote:
> The ACPI wakeup mailbox is accessed by the OS and the firmware, both are
> in the guest's context, instead of the hypervisor/VMM context. Mark the
> address private explicitly.
This lacks information why the realmode area must be reserved and
in
On Tue, Aug 06 2024 at 15:12, Yunhong Jiang wrote:
>
> -static int __init acpi_mp_setup_reset(u64 reset_vector)
> +static int __init __maybe_unused acpi_mp_setup_reset(u64 reset_vector)
> {
> struct x86_mapping_info info = {
> .alloc_pgt_page = alloc_pgt_page,
> @@ -226,7 +22
On Fri, Aug 02 2024 at 16:25, Nikolay Borisov wrote:
> On 2.08.24 г. 11:50 ч., Alexey Dobriyan wrote:
>> If this memcmp() is not inlined then PVH early boot code can call
>> into KASAN-instrumented memcmp() which results in unbootable VMs:
>>
>> pvh_start_xen
>> xen_prepare_pvh
>> x
On Fri, Aug 02 2024 at 12:04, David Woodhouse wrote:
> On Fri, 2024-08-02 at 12:49 +0200, Thomas Gleixner wrote:
>> So fine, we can go with the patch from Li, but the changelog needs a
>> rewrite and the code want's a big fat comment.
>
> Nah, it wants to be MODE, COUNT,
On Fri, Aug 02 2024 at 11:53, Alexey Dobriyan wrote:
> If this memset() is not inlined than PVH early boot code can call
> into KASAN-instrumented memset() which results in unbootable VMs.
>
> Ubuntu's 22.04.4 LTS gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04)
> doesn't inline this memset but in
On Fri, Aug 02 2024 at 11:50, Alexey Dobriyan wrote:
Please amend functions with '()' in the subject line and the change log
consistently.
> diff --git a/arch/x86/include/asm/cpuid.h b/arch/x86/include/asm/cpuid.h
> index 6b122a31da06..3eca7824430e 100644
> --- a/arch/x86/include/asm/cpuid.h
> ++
On Fri, Aug 02 2024 at 09:07, David Woodhouse wrote:
> On Thu, 2024-08-01 at 20:57 +0200, Thomas Gleixner wrote:
>> It's not counting right out of reset. But once it started counting it's
>> tedious to stop :)
>
> My reading of the data sheet definitely suggests tha
On Thu, Aug 01 2024 at 21:49, David Woodhouse wrote:
> On Thu, 2024-08-01 at 22:00 +0200, Thomas Gleixner wrote:
>> > I justify my cowardice on the basis that it doesn't *matter* if a
>> > hardware implementation is still toggling the IRQ pin; in that case
>&
On Thu, Aug 01 2024 at 16:22, David Woodhouse wrote:
> On Thu, 2024-08-01 at 10:00 +0100, David Woodhouse wrote:
> bool __init pit_timer_init(void)
> {
> - if (!use_pit())
> + if (!use_pit()) {
> + if (!hypervisor_is_type(X86_HYPER_NATIVE)) {
> + /*
> +
On Thu, Aug 01 2024 at 20:21, David Woodhouse wrote:
> On Thu, 2024-08-01 at 21:06 +0200, Thomas Gleixner wrote:
>> Yes. So the sequence should stop KVM from trying to inject
>> interrupts. Maybe someone fixes it to actually stop fiddling with the
>> counter too :)
>
>
On Thu, Aug 01 2024 at 18:49, David Woodhouse wrote:
> On Thu, 2024-08-01 at 16:21 +0200, Thomas Gleixner wrote:
>> The stop sequence is wrong:
>>
>> When there is a count in progress, writing a new LSB before the
>> counter has counted down to 0 and roll
On Thu, Aug 01 2024 at 19:25, David Woodhouse wrote:
> On Thu, 2024-08-01 at 18:49 +0100, David Woodhouse wrote:
>> > The stop sequence is wrong:
>> >
>> > When there is a count in progress, writing a new LSB before the
>> > counter has counted down to 0 and rolled over to h, WILL stop
On Thu, Aug 01 2024 at 16:14, Michael Kelley wrote:
> From: Thomas Gleixner Sent: Thursday, August 1, 2024
> 7:21 AM
> FWIW, in Hyper-V guests with the Hyper-V quirk removed, tglx's new
> sequence does *not* stop the PIT. But this sequence does:
>
> outb_p(0x30, PIT_MODE);
On Tue, Feb 07 2023 at 09:14, lirongq...@baidu.com wrote:
> @@ -117,11 +110,6 @@ static int pit_shutdown(struct clock_event_device *evt)
>
> outb_p(0x30, PIT_MODE);
>
> - if (i8253_clear_counter_on_shutdown) {
> - outb_p(0, PIT_CH0);
> - outb_p(0, PIT_CH0);
> -
On Wed, Jul 31 2024 at 22:42, Thomas Gleixner wrote:
> Aside of that the proposed parser does not even work anymore on 6.11
> because we switched ARM[64] over to per device domains during the merge
> window.
>
> So if we want a selftest for the correctness of the hardware interrupt
On Wed, Jul 31 2024 at 14:24, Bjorn Helgaas wrote:
> On Wed, May 29, 2024 at 06:27:27PM -0700, Joseph Jang wrote:
>> Validate there are no duplicate ITS-MSI hwirqs from the
>> /sys/kernel/irq/*/hwirq.
>>
>> One example log show 2 duplicated MSI entries in the /proc/interrupts.
>>
>> 150: 0 ... IT
On Wed, Jul 31 2024 at 23:30, wangy...@uniontech.com wrote:
> When SGX is not supported by the BIOS, the kernel log still output
> the error 'SGX disabled by BIOS', which can be confusing since
> there might not be an SGX-related option in the BIOS settings.
>
> As a kernel, it's difficult to disti
Assuming this goes through the PPC tree:
Reviewed-by: Thomas Gleixner
Michael: If I should route it through my tree, let me know.
Thanks,
tglx
1 - 100 of 1850 matches
Mail list logo
