Re: [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk()

On Tue, 20 Mar 2018, Dou Liyang wrote: > ACPI driver should make sure all the processor IDs in their ACPI Namespace > are unique for CPU hotplug. the driver performs a depth-first walk of the > namespace tree and calls the acpi_processor_ids_walk(). > > But, the acpi_processor_ids_walk() will

Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

On Wed, 21 Mar 2018, Peter Zijlstra wrote: > On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote: > > How about: > > > > possible_cpus= [s390,x86_64] Set the number of possible CPUs which > > are determined by the ACPI tables MADT or mptables by > > default.

Re: 92a0f81d89 ("x86/cpu_entry_area: Move it out of the fixmap"): BUG: kernel hang in boot stage

On Sun, 24 Dec 2017, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git WIP.x86/pti > > commit 92a0f81d89571e3e8759366e050ee05cc545ef99 > Aut

Re: [PATCH v5 11/11] intel_sgx: driver documentation

On Fri, 17 Nov 2017, Darren Hart wrote: @intel: I removed intel-sgx-kernel-...@lists.01.org from CC because I can do without the silly moderation spam of that list. Please disable that nonsense. > On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote: > Is SGX considered architectural

Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Fri, 17 Nov 2017, Quan Xu wrote: > On 2017-11-16 17:53, Thomas Gleixner wrote: > > That's just plain wrong. We don't want to see any of this PARAVIRT crap in > > anything outside the architecture/hypervisor interfacing code which really > > needs it. > > > > T

Re: [PATCH] Documentation/process: add Co-Developed-by: tag for patches with multiple authors

"Co-Developed-by:" tag which can be used to show other authors of > the patch. > > Note, these other authors must also provide a Signed-off-by: tag as it > is their work that is being submitted here. > > Reported-by: Thomas Gleixner <t...@linutronix.de> > Si

Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Thu, 16 Nov 2017, Quan Xu wrote: > On 2017-11-16 06:03, Thomas Gleixner wrote: > --- a/drivers/cpuidle/cpuidle.c > +++ b/drivers/cpuidle/cpuidle.c > @@ -210,6 +210,13 @@ int cpuidle_enter_state(struct cpuidle_device *dev, > struct cpuidle_driver *drv, >     targ

Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Thu, 16 Nov 2017, Quan Xu wrote: > On 2017-11-16 16:45, Peter Zijlstra wrote: > > I really have considered this factor, and try my best not to interfere with > scheduler/idle code. > > if irq_timings code is ready, I can use it directly. I think irq_timings > is not an easy task, I'd like to

Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Thu, 16 Nov 2017, Peter Zijlstra wrote: > On Wed, Nov 15, 2017 at 11:03:08PM +0100, Thomas Gleixner wrote: > > If I understand the problem correctly then he wants to avoid the heavy > > lifting in tick_nohz_idle_enter() in the first place, but there is already > >

RE: [PATCH V1 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Mon, 13 Nov 2017, Dey, Megha wrote: > >-Original Message- > >From: Peter Zijlstra [mailto:pet...@infradead.org] > >Sent: Monday, November 13, 2017 1:00 AM > >To: Megha Dey > >Cc: x...@kernel.org; linux-ker...@vger.kernel.org; linux- Please fix your mail

Re: [PATCH] docs: highres: fix broken urls

On Tue, 26 Sep 2017, Jonathan Corbet wrote: > On Tue, 29 Aug 2017 10:42:24 +0800 > stephen lu wrote: > > > Some urls is invalid. I find alternative urls. > > > > Signed-off-by: stephen lu > > --- > > Documentation/timers/highres.txt | 4 ++-- > > 1 file

Re: [PATCH 2/2 v10] printk: Add monotonic, boottime, and realtime timestamps

gt; +} And no, this function is just horrible, both in name and implementation. This can be done without that unprotected and racy access to the realtime offset. Patch below. Thanks, tglx 8<--- Subject: timekeeping: Provide NMI safe access to clock realtime From: Thomas Glei

Re: [PATCH 2/2 v9] printk: Add monotonic, boottime, and realtime timestamps

On Fri, 25 Aug 2017, Prarit Bhargava wrote: > + > + if (printk_time_source == PRINTK_TIME_UNDEFINED) > + printk_time_source = _printk_time; > +#ifndef CONFIG_PRINTK_TIME_DEBUG > + else if ((printk_time_source != _printk_time) && > + (_printk_time !=

Re: [PATCH v4 0/3] simulated interrupts

On Mon, 14 Aug 2017, Bartosz Golaszewski wrote: > Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated > interrupts that can be 'fired' from process context when needed and > requested just like normal interrupts. This is useful for testing and > development purposes. > >

Re: [PATCH v5] printk: Add monotonic, boottime, and realtime timestamps

On Thu, 10 Aug 2017, Prarit Bhargava wrote: > diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c > index cedafa008de5..1ddf04201047 100644 > --- a/kernel/time/timekeeping.c > +++ b/kernel/time/timekeeping.c > @@ -25,6 +25,7 @@ > #include > #include > #include > +#include

Re: [PATCH v3 1/3] irq/irq_sim: add a simple interrupt simulator framework

On Mon, 14 Aug 2017, Bartosz Golaszewski wrote: > 2017-08-14 15:06 GMT+02:00 Thomas Gleixner <t...@linutronix.de>: > > On Mon, 14 Aug 2017, Bartosz Golaszewski wrote: > > > >> Implement a simple, irq_work-based framework for simulating > >> interru

Re: [PATCH v3 1/3] irq/irq_sim: add a simple interrupt simulator framework

On Mon, 14 Aug 2017, Bartosz Golaszewski wrote: > Implement a simple, irq_work-based framework for simulating > interrupts. Currently the API exposes routines for initializing and > deinitializing the simulator object, enqueueing the interrupts and > retrieving the allocated interrupt numbers

Re: [PATCH v2] printk: Add boottime and real timestamps

On Tue, 1 Aug 2017, Prarit Bhargava wrote: > On 08/01/2017 01:00 PM, John Stultz wrote: > > Its been asked already, but I've not yet seen an answer. > > Sorry for missing this. > > > Is there a reason your not also adding PRINTK_TIME_BOOT here (which to > > me would be more generally useful then

Re: [PATCH 2/2] printk: Add boottime and real timestamps

On Fri, 28 Jul 2017, Prarit Bhargava wrote: > On 07/25/2017 09:00 AM, Peter Zijlstra wrote: > Thanks for the above change. I can see that makes the code simpler. > > > Although I must strongly discourage using REALTIME, DST will make > > untangling your logs an absolute nightmare. I would simply

Re: [PATCH 0/3] simulated interrupts

On Wed, 19 Jul 2017, Andy Shevchenko wrote: > On Wed, Jul 19, 2017 at 5:19 PM, Marc Zyngier <marc.zyng...@arm.com> wrote: > > On 19/07/17 14:58, Thomas Gleixner wrote: > >> On Wed, 19 Jul 2017, Bartosz Golaszewski wrote: > > > echo 1 >/proc/irq/9/trigger &

Re: [PATCH 0/3] simulated interrupts

On Wed, 19 Jul 2017, Bartosz Golaszewski wrote: > Some frameworks (e.g. iio, gpiolib) use irq_work to implement simulated > interrupts that can be 'fired' from process context when needed and > requested just like normal interrupts. This is useful for testing and > development purposes. > >

Re: [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)

ies is a pre-cursor to another AMD processor feature called > Secure Encrypted Virtualization (SEV). The support for SEV will build upon > the SME support and will be submitted later. Details on SEV can be found > in the links below. Well done series. Thanks to all people involved, espec

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On Tue, 4 Jul 2017, Radim Krčmář wrote: > I think there is a nicer solution to avoid the expensive timer rewrite: > Linux uses one-shot APIC timers and getting the timer interrupt is about > as expensive as programming the timer, so the guest can keep the timer > armed, but not re-arm it after the

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On Mon, 3 Jul 2017, Yang Zhang wrote: > The background is that we(Alibaba Cloud) do get more and more complaints from > our customers in both KVM and Xen compare to bare-mental.After investigations, > the root cause is known to us: big cost in message passing workload(David show > it in KVM forum

Re: [PATCH 2/2] x86/idle: use dynamic halt poll

On Thu, 22 Jun 2017, root wrote: > @@ -962,6 +962,7 @@ __visible void __irq_entry > smp_apic_timer_interrupt(struct pt_regs *regs) >* interrupt lock, which is the WrongThing (tm) to do. >*/ > entering_ack_irq(); > + check_poll(); No way, that we sprinkle this function

Re: [PATCH 1/2] x86/idle: add halt poll for halt idle

On Thu, 22 Jun 2017, root wrote: > --- a/arch/x86/kernel/process.c > +++ b/arch/x86/kernel/process.c > @@ -39,6 +39,10 @@ > #include > #include > > +#ifdef CONFIG_HYPERVISOR_GUEST > +unsigned long poll_threshold_ns; > +#endif > + > /* > * per-CPU TSS segments. Threads are completely

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Wed, 21 Jun 2017, Tom Lendacky wrote: > On 6/21/2017 2:16 AM, Thomas Gleixner wrote: > > Why is this an unconditional function? Isn't the mask simply 0 when the MEM > > ENCRYPT support is disabled? > > I made it unconditional because of the call from head_64.S. I can'

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Fri, 16 Jun 2017, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/mem_encrypt.h > b/arch/x86/include/asm/mem_encrypt.h > index a105796..988b336 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -15,16 +15,24 @@ > > #ifndef __ASSEMBLY__

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit

Re: [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

On Tue, 20 Jun 2017, Bartosz Golaszewski wrote: > 2017-06-20 12:41 GMT+02:00 Marc Zyngier : > > There was a kbuild report from June 1st with worrying warnings on x86_64 > > (though I couldn't see how that was related to these patches). What's > > the status of that? > > > >

Re: [PATCH 3/9] genericirq.tmpl: convert it to ReST

== > > + > > +:Copyright: |copy| 2005-2010: Thomas Gleixner > > +:Copyright: |copy| 2005-2006: Ingo Molnar > > It seems maybe they should have been CC'd on this one? Adding them now > (and leaving the full patch for their amusement). > > > Brainless c

Re: [PATCH] irqdesc: add memory managed version of irq_alloc_descs()

On Tue, 7 Feb 2017, Bartosz Golaszewski wrote: > + > +int __devm_irq_alloc_descs(struct device *dev, int irq, unsigned int from, > +unsigned int cnt, int node, struct module *owner, > +const struct cpumask *affinity) This lacks the kernel doc

Re: [PATCH v2] time: Remove CONFIG_TIMER_STATS

his patch entirely > > > removes CONFIG_TIMER_STATS. > > > > > > Suggested-by: Thomas Gleixner <t...@linutronix.de> > > > Signed-off-by: Kees Cook <keesc...@chromium.org> > > > Acked-by: John Stultz <john.stu...@linaro.org> > > >

Re: [PATCH] time: Remove CONFIG_TIMER_STATS

SEQ_printf(m, ", %s/%d", tmp, timer->start_pid); > > > > /proc/timer_list: > > > > #11: <>, hrtimer_wakeup, S:01, do_nanosleep, cron/2570 > > > > Given that the tracer can give the same information, this patch entirely > &g

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

On Tue, 8 Nov 2016, Andy Lutomirski wrote: > On Tue, Nov 8, 2016 at 5:16 AM, Peter Zijlstra wrote: > > On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote: > >> There is a caveat, however. Certain applications running in virtual-8086 > >> mode, such as DOSEMU[1] and

Re: [RESEND PATCH 3/3] x86/vmware: Add paravirt sched clock

On Thu, 27 Oct 2016, Alexey Makhalov wrote: > Set pv_time_ops.sched_clock to vmware_sched_clock(). Please do not describe WHAT the patch does, describe why. Describe the problem you are solving. I can see from the patch > + pv_time_ops.sched_clock = vmware_sched_clock; that you

Re: [PATCH 2/3] x86/vmware: Add basic paravirt ops support

On Wed, 26 Oct 2016, Tim Mann wrote: > I believe our trademark guidelines say we aren't supposed to use VMware as a > noun to mean a product, only to mean the company. So we can say "running on > VMware ESXi" or "running in a VMware virtual machine", but "running on VMware" > is wrong. There is

Re: [PATCH 3/3] x86/vmware: Add paravirt sched clock

On Tue, 25 Oct 2016, Alexey Makhalov wrote: > no-vmw-sched-clock kernel parameter is added to switch back to the > native_sched_clock() implementation. You are not switching back. The parameter is used to disable the paravirt sched clock. > #ifdef CONFIG_PARAVIRT > +static struct cyc2ns_data

Re: [PATCH v2 -tip] locking/rtmutex: Reduce top-waiter blocking on a lock

On Mon, 24 Oct 2016, Davidlohr Bueso wrote: > Any comments? can this make it for v4.10? We need to fry the futex/rtmutex fish first -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH v3 07/13] futex: Throughput-optimized (TP) futexes

On Fri, 30 Sep 2016, Waiman Long wrote: > + WRITE_ONCE(state->owner, current); > + preempt_disable(); > + for (;;) { > + ret = futex_trylock(uaddr, vpid, , true); Did you actually read what I said? You CANNOT access userspace in a preempt disabled region without disabling

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Thu, 22 Sep 2016, Waiman Long wrote: > On 09/22/2016 04:38 PM, Thomas Gleixner wrote: > > > wait-wake futex PI futexTO futex > > > --- > > > max time3.49s

Re: [RFC PATCH 3/4] futex: Throughput-optimized (TO) futexes

On Thu, 22 Sep 2016, Waiman Long wrote: > On 09/22/2016 09:32 AM, Thomas Gleixner wrote: > > > + WARN_ON(!pi_state->owner); > > > + if (pi_state->owner) > > > + wake_up_process(pi_state->owner); > >

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Thu, 22 Sep 2016, Davidlohr Bueso wrote: > On Thu, 22 Sep 2016, Waiman Long wrote: > > > BTW, my initial attempt for the new futex was to use the same workflow as > > the PI futexes, but use mutex which has optimistic spinning instead of > > rt_mutex. > > Btw, Thomas, do you still have any

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Thu, 22 Sep 2016, Waiman Long wrote: > BTW, my initial attempt for the new futex was to use the same workflow as the > PI futexes, but use mutex which has optimistic spinning instead of rt_mutex. > That version can double the throughput compared with PI futexes but still far > short of what can

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Thu, 22 Sep 2016, Waiman Long wrote: > On 09/22/2016 09:34 AM, Thomas Gleixner wrote: > > On Thu, 22 Sep 2016, Peter Zijlstra wrote: > > > > > > I'd leave out the TO part entirely (or only mention it in changelogs). > > > > > > That is, I'd ca

Re: [RFC PATCH 4/4] futex, doc: TO futexes document

On Thu, 22 Sep 2016, Waiman Long wrote: > On 09/22/2016 06:40 AM, Thomas Gleixner wrote: > > On Tue, 6 Sep 2016, Waiman Long wrote: > > > This patch adds a new document file on how to use the TO futexes. > > Documentation is nice, but the proper place for documenting this

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Thu, 22 Sep 2016, Peter Zijlstra wrote: > On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote: > > On 09/21/2016 02:59 AM, Mike Galbraith wrote: > > >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote: > > >>This patch introduces a new futex implementation called > >

Re: [RFC PATCH 3/4] futex: Throughput-optimized (TO) futexes

On Tue, 6 Sep 2016, Waiman Long wrote: > +enum futex_type { > + TYPE_PI = 0, > + TYPE_TO, > +}; Please introduce the futex_type magic and the related changes to the pi code in a seperate patch so it can be verified independently. It's sad that one has to explain that to you over and over

Re: [RFC PATCH 4/4] futex, doc: TO futexes document

On Tue, 6 Sep 2016, Waiman Long wrote: > This patch adds a new document file on how to use the TO futexes. Documentation is nice, but the proper place for documenting this is the futex(2) man page. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in

Re: [RFC PATCH v2 04/20] x86: Secure Memory Encryption (SME) support

On Mon, 22 Aug 2016, Tom Lendacky wrote: > Provide support for Secure Memory Encryption (SME). This initial support > defines the memory encryption mask as a variable for quick access and an > accessor for retrieving the number of physical addressing bits lost if > SME is enabled. What is the

RE: [PATCH v4 09/29] staging: unisys: visorinput: remove unnecessary locking

On Thu, 9 Jun 2016, Sell, Timothy C wrote: > > From: Thomas Gleixner [mailto:t...@linutronix.de] > > > > I think I asked this before, but I might have missed the answer. > > > > Why is this a rw_sempahore? It's never taken with down_read and looking > > at

Re: [PATCH v2 13/27] staging: unisys: visorbus: Make visordriver_callback_lock a mutex

On Tue, 31 May 2016, David Kershner wrote: > From: Bryan Thompson > > visordriver_callback_lock is just a binary semaphore that logically > makes more sense as a mutex. > > Signed-off-by: Bryan Thompson > Signed-off-by: David Kershner

Re: [PATCH v2 20/27] staging: unisys: visorbus: make visorchannel function descriptions more kerneldoc-like

On Tue, 31 May 2016, David Kershner wrote: > From: David Binder <david.bin...@unisys.com> > > Per audit feedback from Thomas Gleixner, function descriptions in > visorchannel.c now utilize a more kerneldoc-like formatting. The affected > comments do not implement other k

Re: new driver for drivers/virt/?

On Wed, 18 May 2016, Sell, Timothy C wrote: > We have a bus driver currently in drivers/staging/unisys/visorbus/ that > we are trying to get out of staging and into the kernel proper. Since > "visorbus" is a driver to host a virtual bus presented to a Linux guest > in a hypervisor environment

RE: [PATCH 1/7] debugobjects: make fixup functions return bool instead of int

On Fri, 22 Apr 2016, Du, Changbin wrote: > > On Fri, 22 Apr 2016, changbin...@intel.com wrote: > > > A bad thing is that debug_object_fixup use the return value for > > > arithmetic operation. It confused me that what is the reall return > > > > What's bad about that? The fact that it's used for

Re: [PATCH 2/7] debugobjects: correct the usage of fixup call results

On Fri, 22 Apr 2016, changbin...@intel.com wrote: > From: "Du, Changbin" > > If debug_object_fixup() return non-zero when problem has been > fixed. But the code got it backwards, it taks 0 as fixup > successfully. So fix it. Wrong. > @@ -415,7 +415,7 @@ int