search for: irq_worker

? 2023/3/23 13:30, Xie Yongji ??: > Since virtio-vdpa bus driver already support interrupt > affinity spreading mechanism, let's implement the > set_vq_affinity callback to bring it to vduse device. > After we get the virtqueue's affinity, we can spread > IRQs between CPUs in the affinity mask, in a round-robin > manner, to run the irq callback. > > Signed-off-by:

.../events: Check that IRQ value passed in is valid. xen/time: Add default value of -1 for IRQ and check for that. xen/spinlock: Check against default value of -1 for IRQ line. xen/spinlock: Disable IRQ spinlock (PV) allocation on PVHVM xen/smp/pvhvm: Don''t initialize IRQ_WORKER as we are using the native one. xen/smp: Unifiy some of the PVs and PVHVM offline CPU path

* Yi Wang <wang.yi59 at zte.com.cn> wrote: > We may get -Wmissing-prototypes warnings when building > kernel with W=1, it's better to fix them as global function > signature can be changed and caller who use the old unchanged > prototypes will be hosed. > > This patch fixes most of -Wmissing-prototypes warnings which > are in the root directory of arch/x86/kernel,

kmap_types.h is a misnomer because the old atomic MAP based array does not exist anymore and the whole indirection of architectures including kmap_types.h is inconinstent and does not allow to provide guard page debugging for this misfeature. Add a common header file which defines the mapping stack size for all architectures. Will be used when converting architectures over to a generic

The xen_play_dead is an undead function. When the vCPU is told to offline it ends up calling xen_play_dead wherin it calls the VCPUOP_down hypercall which offlines the vCPU. However, when the vCPU is onlined back, it resumes execution right after VCPUOP_down hypercall. That was OK (albeit the API for play_dead assumes that the CPU stays dead and never returns) but with commit 4b0c0f294 (tick:

The header is not longer used and on alpha, ia64, openrisc, parisc and um it was completely unused anyway as these architectures have no highmem support. Signed-off-by: Thomas Gleixner <tglx at linutronix.de> --- V3: New patch --- arch/alpha/include/asm/kmap_types.h | 15 --------------- arch/ia64/include/asm/kmap_types.h | 13 ------------- arch/openrisc/mm/init.c |

From: Jiang Liu <jiang.liu at huawei.com> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call

From: Jiang Liu <jiang.liu at huawei.com> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call

From: Jiang Liu <jiang.liu at huawei.com> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic similar to smp_call_function_single()" has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call

While working on a drm driver that doesn't need the i2c algobit stuff I noticed that DRM selects this code even though only 8 drivers actually use it. While also only some drivers use i2c, keep the select for I2C for the next cleanup patch. Still prepare this already by also selecting I2C for the individual drivers. Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> ---

I'll look. On May 16, 2014 8:01 AM, "Jan-Simon Möller" <dl9pf at gmx.de> wrote: > The unrecognized junk is (path shortened, so don't worry): > > .Ldebug_range: > .file 1 "/src/linux/include/linux" "export.h" > .file 2 "/src/linux/init" "main.c" > .file 3

Hi ! I reproduced it on the file init/main.c The invocation, log and main.i / main.s is attached. -- Dipl.-Ing. Jan-Simon Möller jansimon.moeller at gmx.de Am Freitag, 16. Mai 2014, 14:25:47 schrieb Renato Golin: > On 16 May 2014 14:01, Jan-Simon Möller <dl9pf at gmx.de> wrote: > > A bisection points to > > > > git-svn-id:

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

On the vast majority of modern systems, no processes will use the userspsace IO syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Since these syscalls only exist to support rare legacy userspace programs, X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant

On the vast majority of modern systems, no processes will use the userspsace I/O syscalls, iopl and ioperm. Add a new config option, CONFIG_X86_IOPORT, to support configuring them out of the kernel entirely. Most current systems do not run programs using these syscalls, so X86_IOPORT does not depend on EXPERT, though it does still default to y. In addition to saving a significant amount of

I/O from userspace is used to implement usermode virtio driver(s). This has been done independently by Intel, Brocade/Vyatta, and 6Wind. Sorry, it has to stay. On Mon, Oct 21, 2013 at 7:35 PM, Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, >

I/O from userspace is used to implement usermode virtio driver(s). This has been done independently by Intel, Brocade/Vyatta, and 6Wind. Sorry, it has to stay. On Mon, Oct 21, 2013 at 7:35 PM, Josh Triplett <josh at joshtriplett.org> wrote: > On the vast majority of modern systems, no processes will use the > userspsace I/O syscalls, iopl and ioperm. Add a new config option, >

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett

The 32-bit and 64-bit versions of copy_thread have functionally identical handling for copying the I/O bitmap, modulo differences in error handling. Clean up the error paths in both by moving the copy of the I/O bitmap to the end, to eliminate the need to free it if subsequent copy steps fail; move the resulting identical code to a static inline in a common header. Signed-off-by: Josh Triplett