Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

On 06/10/17 14:45, Alex Bennée wrote: Julien Thierry writes: On 06/10/17 12:39, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return into KVM_RUN. To handle mmio related updates we wait until they have been

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

On 06/10/17 14:45, Alex Bennée wrote: Julien Thierry writes: On 06/10/17 12:39, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return into KVM_RUN. To handle mmio related updates we wait until they have been committed and then schedule

Re: [PATCH] net/mlx4_core: Convert timers to use timer_setup()

On Thu, Oct 5, 2017 at 2:38 AM, Leon Romanovsky wrote: > On Wed, Oct 04, 2017 at 05:51:54PM -0700, Kees Cook wrote: >> In preparation for unconditionally passing the struct timer_list pointer to >> all timer callbacks, switch to using the new timer_setup() and from_timer() >> to

Re: [PATCH] net/mlx4_core: Convert timers to use timer_setup()

On Thu, Oct 5, 2017 at 2:38 AM, Leon Romanovsky wrote: > On Wed, Oct 04, 2017 at 05:51:54PM -0700, Kees Cook wrote: >> In preparation for unconditionally passing the struct timer_list pointer to >> all timer callbacks, switch to using the new timer_setup() and from_timer() >> to pass the timer

Re: [PATCH v3] irqchip/gicv3: Add support for Range Selector (RS) feature

On Thu, Oct 5, 2017 at 6:59 PM, Shanker Donthineni wrote: > +#define MPIDR_TO_SGI_CLUSTER_ID(mpidr) (mpidr & ~0xFUL) This should be "((mpidr) & 0xFUL)", just to be safe.

Re: [PATCH v3] irqchip/gicv3: Add support for Range Selector (RS) feature

On Thu, Oct 5, 2017 at 6:59 PM, Shanker Donthineni wrote: > +#define MPIDR_TO_SGI_CLUSTER_ID(mpidr) (mpidr & ~0xFUL) This should be "((mpidr) & 0xFUL)", just to be safe.

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

On 06/10/17 15:00, Marc Zyngier wrote: On 06/10/17 14:47, Alex Bennée wrote: Marc Zyngier writes: On 06/10/17 13:37, Marc Zyngier wrote: On 06/10/17 12:39, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

On 06/10/17 15:00, Marc Zyngier wrote: On 06/10/17 14:47, Alex Bennée wrote: Marc Zyngier writes: On 06/10/17 13:37, Marc Zyngier wrote: On 06/10/17 12:39, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return into KVM_RUN. To handle

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

On Fri, Oct 06, 2017 at 12:34:02PM +0100, Tvrtko Ursulin wrote: > > On 06/10/2017 10:06, Daniel Vetter wrote: > > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > > seems to have uncovered a few more rules about what is allowed and > > isn't. > > > > This one here seems to

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

On Fri, Oct 06, 2017 at 12:34:02PM +0100, Tvrtko Ursulin wrote: > > On 06/10/2017 10:06, Daniel Vetter wrote: > > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > > seems to have uncovered a few more rules about what is allowed and > > isn't. > > > > This one here seems to

Re: [PATCH v7] KVM: LAPIC: Apply change to TDCR right away to the timer

On 06/10/2017 16:01, Wanpeng Li wrote: > + if (!apic->lapic_timer.period) > + return; > + > + now = ktime_get(); > + remaining = ktime_sub(apic->lapic_timer.target_expiration, now); > + if (ktime_to_ns(remaining) < 0) > + remaining = 0; > + delta =

Re: [PATCH v7] KVM: LAPIC: Apply change to TDCR right away to the timer

On 06/10/2017 16:01, Wanpeng Li wrote: > + if (!apic->lapic_timer.period) > + return; > + > + now = ktime_get(); > + remaining = ktime_sub(apic->lapic_timer.target_expiration, now); > + if (ktime_to_ns(remaining) < 0) > + remaining = 0; > + delta =

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:03:49PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-10-06 10:06:37) > > stop_machine is not really a locking primitive we should use, except > > when the hw folks tell us the hw is broken and that's the only way to > > work around it. > > > > This patch

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:03:49PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-10-06 10:06:37) > > stop_machine is not really a locking primitive we should use, except > > when the hw folks tell us the hw is broken and that's the only way to > > work around it. > > > > This patch

Re: [PATCH v5 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 22:03+0800, Wanpeng Li: > 2017-10-06 21:03 GMT+08:00 Radim Krčmář : > > 2017-10-06 07:14+0800, Wanpeng Li: > >> 2017-10-06 2:14 GMT+08:00 Radim Krčmář : > >> > 2017-10-05 07:35-0700, Wanpeng Li: > >> >> From: Wanpeng Li >

Re: [PATCH v2] block/aoe: Convert timers to use timer_setup()

On 10/05/2017 05:13 PM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Applied to for-4.15/timer -- Jens Axboe

Re: [PATCH v5 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 22:03+0800, Wanpeng Li: > 2017-10-06 21:03 GMT+08:00 Radim Krčmář : > > 2017-10-06 07:14+0800, Wanpeng Li: > >> 2017-10-06 2:14 GMT+08:00 Radim Krčmář : > >> > 2017-10-05 07:35-0700, Wanpeng Li: > >> >> From: Wanpeng Li > >> >> + remaining = > >> >>

Re: [PATCH v2] block/aoe: Convert timers to use timer_setup()

On 10/05/2017 05:13 PM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. Applied to for-4.15/timer -- Jens Axboe

Re: [PATCH 4.4 22/50] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()

On Fri, Oct 06, 2017 at 11:20:11AM +0200, Greg Kroah-Hartman wrote: >On Fri, Oct 06, 2017 at 02:09:14AM -0700, Joe Perches wrote: >> On Fri, 2017-10-06 at 10:53 +0200, Greg Kroah-Hartman wrote: >> > 4.4-stable review patch. If anyone has any objections, please let me know. >> >> I hope this patch

Re: [PATCH 4.4 22/50] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()

On Fri, Oct 06, 2017 at 11:20:11AM +0200, Greg Kroah-Hartman wrote: >On Fri, Oct 06, 2017 at 02:09:14AM -0700, Joe Perches wrote: >> On Fri, 2017-10-06 at 10:53 +0200, Greg Kroah-Hartman wrote: >> > 4.4-stable review patch. If anyone has any objections, please let me know. >> >> I hope this patch

Re: [PATCH 2/2] sysctl: remove /proc/sys/vm/nr_pdflush_threads

On 10/06/2017 07:49 AM, Rakesh Pandit wrote: > Hi Jens, > > On Tue, Oct 03, 2017 at 09:16:21AM -0600, Jens Axboe wrote: >> This tunable has been obsolete since 2.6.32, and writes to the >> file have been failing and complaining in dmesg since then: >> >> nr_pdflush_threads exported in /proc is

Re: [PATCH 2/2] sysctl: remove /proc/sys/vm/nr_pdflush_threads

On 10/06/2017 07:49 AM, Rakesh Pandit wrote: > Hi Jens, > > On Tue, Oct 03, 2017 at 09:16:21AM -0600, Jens Axboe wrote: >> This tunable has been obsolete since 2.6.32, and writes to the >> file have been failing and complaining in dmesg since then: >> >> nr_pdflush_threads exported in /proc is

Re: [PATCH v6 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 21:59+0800, Wanpeng Li: > 2017-10-06 21:14 GMT+08:00 Radim Krčmář : > > 2017-10-05 18:54-0700, Wanpeng Li: > >> From: Wanpeng Li > >> > >> The description in the Intel SDM of how the divide configuration > >> register is used: "The APIC timer

Re: [PATCH v6 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 21:59+0800, Wanpeng Li: > 2017-10-06 21:14 GMT+08:00 Radim Krčmář : > > 2017-10-05 18:54-0700, Wanpeng Li: > >> From: Wanpeng Li > >> > >> The description in the Intel SDM of how the divide configuration > >> register is used: "The APIC timer frequency will be the processor's bus > >>

Re: [PATCH 1/4] rcu: introduce noref debug

On Fri, 6 Oct 2017 14:57:46 +0200 Paolo Abeni wrote: > We currently lack a debugging infrastructure to ensure that > long-lived noref dst are properly handled - namely dropped > or converted to a refcounted version before escaping the current > RCU section. > > This

Re: [PATCH 1/4] rcu: introduce noref debug

On Fri, 6 Oct 2017 14:57:46 +0200 Paolo Abeni wrote: > We currently lack a debugging infrastructure to ensure that > long-lived noref dst are properly handled - namely dropped > or converted to a refcounted version before escaping the current > RCU section. > > This changeset implements such

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:12:41PM +0200, Thomas Gleixner wrote: > On Fri, 6 Oct 2017, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-10-06 10:06:37) > > > stop_machine is not really a locking primitive we should use, except > > > when the hw folks tell us the hw is broken and that's the only

Re: [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:12:41PM +0200, Thomas Gleixner wrote: > On Fri, 6 Oct 2017, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-10-06 10:06:37) > > > stop_machine is not really a locking primitive we should use, except > > > when the hw folks tell us the hw is broken and that's the only

Re: [PATCH] scsi: isci: Convert timers to use timer_setup()

On 10/05/2017 02:48 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Intel SCU Linux support

Re: [PATCH] scsi: isci: Convert timers to use timer_setup()

On 10/05/2017 02:48 AM, Kees Cook wrote: > In preparation for unconditionally passing the struct timer_list pointer to > all timer callbacks, switch to using the new timer_setup() and from_timer() > to pass the timer pointer explicitly. > > Cc: Intel SCU Linux support > Cc: Artur Paszkiewicz >

Re: [PATCH 4.9 000/104] 4.9.54-stable review

On 10/06/2017 01:50 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.54 release. There are 104 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.9 000/104] 4.9.54-stable review

On 10/06/2017 01:50 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.9.54 release. There are 104 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/50] 4.4.91-stable review

On 10/06/2017 01:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.91 release. There are 50 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 4.4 00/50] 4.4.91-stable review

On 10/06/2017 01:52 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.4.91 release. There are 50 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH v5 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 21:03 GMT+08:00 Radim Krčmář : > 2017-10-06 07:14+0800, Wanpeng Li: >> 2017-10-06 2:14 GMT+08:00 Radim Krčmář : >> > 2017-10-05 07:35-0700, Wanpeng Li: >> >> From: Wanpeng Li >> >> + remaining =

Re: [PATCH v5 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 21:03 GMT+08:00 Radim Krčmář : > 2017-10-06 07:14+0800, Wanpeng Li: >> 2017-10-06 2:14 GMT+08:00 Radim Krčmář : >> > 2017-10-05 07:35-0700, Wanpeng Li: >> >> From: Wanpeng Li >> >> + remaining = ktime_sub(apic->lapic_timer.target_expiration, >> >> now); >> >> +

Re: [PATCH 3.18 00/35] 3.18.74-stable review

On 10/06/2017 02:24 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.74 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH 3.18 00/35] 3.18.74-stable review

On 10/06/2017 02:24 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.74 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be

Re: [PATCH] kmemleak: clear stale pointers from task stacks

On Fri, Oct 06, 2017 at 02:38:21PM +0300, Konstantin Khlebnikov wrote: > Kmemleak considers any pointers as task stacks as references. ^^ on > This patch clears newly allocated and reused vmap stacks. > > Signed-off-by:

Re: [PATCH] kmemleak: clear stale pointers from task stacks

On Fri, Oct 06, 2017 at 02:38:21PM +0300, Konstantin Khlebnikov wrote: > Kmemleak considers any pointers as task stacks as references. ^^ on > This patch clears newly allocated and reused vmap stacks. > > Signed-off-by:

[PATCH v7] KVM: LAPIC: Apply change to TDCR right away to the timer

From: Wanpeng Li The description in the Intel SDM of how the divide configuration register is used: "The APIC timer frequency will be the processor's bus clock or core crystal clock frequency divided by the value specified in the divide configuration register."

[PATCH v7] KVM: LAPIC: Apply change to TDCR right away to the timer

From: Wanpeng Li The description in the Intel SDM of how the divide configuration register is used: "The APIC timer frequency will be the processor's bus clock or core crystal clock frequency divided by the value specified in the divide configuration register." Observation of baremetal shown

Re: [PATCH v4 19/27] x86: assembly, make some functions local

On 6 October 2017 at 13:53, Jiri Slaby wrote: > Hi, > > On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote: >> On 4 October 2017 at 08:22, Jiri Slaby wrote: >>> On 10/02/2017, 02:48 PM, Ard Biesheuvel wrote: On 2 October 2017 at 10:12, Jiri Slaby

Re: [PATCH v4 19/27] x86: assembly, make some functions local

On 6 October 2017 at 13:53, Jiri Slaby wrote: > Hi, > > On 10/04/2017, 09:33 AM, Ard Biesheuvel wrote: >> On 4 October 2017 at 08:22, Jiri Slaby wrote: >>> On 10/02/2017, 02:48 PM, Ard Biesheuvel wrote: On 2 October 2017 at 10:12, Jiri Slaby wrote: > There is a couple of assembly

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

On 06/10/17 14:47, Alex Bennée wrote: > > Marc Zyngier writes: > >> On 06/10/17 13:37, Marc Zyngier wrote: >>> On 06/10/17 12:39, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return into KVM_RUN. To handle

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

On 06/10/17 14:47, Alex Bennée wrote: > > Marc Zyngier writes: > >> On 06/10/17 13:37, Marc Zyngier wrote: >>> On 06/10/17 12:39, Alex Bennée wrote: The system state of KVM when using userspace emulation is not complete until we return into KVM_RUN. To handle mmio related updates we

Re: [PATCH v6 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 21:14 GMT+08:00 Radim Krčmář : > 2017-10-05 18:54-0700, Wanpeng Li: >> From: Wanpeng Li >> >> The description in the Intel SDM of how the divide configuration >> register is used: "The APIC timer frequency will be the processor's bus >> clock

Re: [PATCH v6 3/3] KVM: LAPIC: Apply change to TDCR right away to the timer

2017-10-06 21:14 GMT+08:00 Radim Krčmář : > 2017-10-05 18:54-0700, Wanpeng Li: >> From: Wanpeng Li >> >> The description in the Intel SDM of how the divide configuration >> register is used: "The APIC timer frequency will be the processor's bus >> clock or core crystal clock frequency divided by

Re: [PATCH] mm: deferred_init_memmap improvements

Hi Anshuman, Thank you very much for looking at this. My reply below:: On 10/06/2017 02:48 AM, Anshuman Khandual wrote: On 10/04/2017 08:59 PM, Pavel Tatashin wrote: This patch fixes another existing issue on systems that have holes in zones i.e CONFIG_HOLES_IN_ZONE is defined. In

Re: [PATCH] mm: deferred_init_memmap improvements

Hi Anshuman, Thank you very much for looking at this. My reply below:: On 10/06/2017 02:48 AM, Anshuman Khandual wrote: On 10/04/2017 08:59 PM, Pavel Tatashin wrote: This patch fixes another existing issue on systems that have holes in zones i.e CONFIG_HOLES_IN_ZONE is defined. In

Re: [PATCH 0/6] Shrinking DT memory usage

On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring wrote: > On kernels with a minimal config and a RAM target in the 100s of KB, DT > is quite a hog of runtime memory usage. How much is dependent on how many > nodes and properties in the DT which have a corresponding struct device_node

Re: [PATCH 0/6] Shrinking DT memory usage

On Thu, Oct 5, 2017 at 8:44 PM, Rob Herring wrote: > On kernels with a minimal config and a RAM target in the 100s of KB, DT > is quite a hog of runtime memory usage. How much is dependent on how many > nodes and properties in the DT which have a corresponding struct device_node > and struct

Re: [PATCH] kmemleak: change /sys/kernel/debug/kmemleak permissions from 0444 to 0644

On Fri, Oct 06, 2017 at 02:39:25PM +0300, Konstantin Khlebnikov wrote: > Kmemleak could be tweaked in runtime by writing commands into debugfs file. > Root anyway can use it, but without write-bit this interface isn't obvious. > > Signed-off-by: Konstantin Khlebnikov >

Re: [PATCH] kmemleak: change /sys/kernel/debug/kmemleak permissions from 0444 to 0644

On Fri, Oct 06, 2017 at 02:39:25PM +0300, Konstantin Khlebnikov wrote: > Kmemleak could be tweaked in runtime by writing commands into debugfs file. > Root anyway can use it, but without write-bit this interface isn't obvious. > > Signed-off-by: Konstantin Khlebnikov > --- > mm/kmemleak.c |

Re: [RFC] yamldt v0.5, now a DTS compiler too

On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou wrote: > Hi Rob, > > On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote: >> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou >> wrote: >> > Hi Rob, >> > >> > On Tue, 2017-10-03

Re: [RFC] yamldt v0.5, now a DTS compiler too

On Tue, Oct 3, 2017 at 12:39 PM, Pantelis Antoniou wrote: > Hi Rob, > > On Tue, 2017-10-03 at 12:13 -0500, Rob Herring wrote: >> On Tue, Oct 3, 2017 at 9:13 AM, Pantelis Antoniou >> wrote: >> > Hi Rob, >> > >> > On Tue, 2017-10-03 at 08:18 -0500, Rob Herring wrote: >> >> On Mon, Oct 2, 2017 at

Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On 06/10/17 14:47, Jassi Brar wrote: > On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla wrote: >> >> >> On 06/10/17 12:26, Jassi Brar wrote: >>> On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla

Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On 06/10/17 14:47, Jassi Brar wrote: > On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla wrote: >> >> >> On 06/10/17 12:26, Jassi Brar wrote: >>> On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla wrote: > This patch adds ARM MHU specific

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

MSI(X) interrupts are not shared between devices. So when available those should be preferred over legacy interrupts. Signed-off-by: Manuel Stahl ---  drivers/uio/uio_pci_dmem_genirq.c | 27 ---  drivers/uio/uio_pci_generic.c | 24

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

MSI(X) interrupts are not shared between devices. So when available those should be preferred over legacy interrupts. Signed-off-by: Manuel Stahl ---  drivers/uio/uio_pci_dmem_genirq.c | 27 ---  drivers/uio/uio_pci_generic.c | 24 ++--  2 files

Re: [PATCH 2/2] sysctl: remove /proc/sys/vm/nr_pdflush_threads

Hi Jens, On Tue, Oct 03, 2017 at 09:16:21AM -0600, Jens Axboe wrote: > This tunable has been obsolete since 2.6.32, and writes to the > file have been failing and complaining in dmesg since then: > > nr_pdflush_threads exported in /proc is scheduled for removal > > That was 8 years ago. Remove

Re: [PATCH 2/2] sysctl: remove /proc/sys/vm/nr_pdflush_threads

Hi Jens, On Tue, Oct 03, 2017 at 09:16:21AM -0600, Jens Axboe wrote: > This tunable has been obsolete since 2.6.32, and writes to the > file have been failing and complaining in dmesg since then: > > nr_pdflush_threads exported in /proc is scheduled for removal > > That was 8 years ago. Remove

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

Marc Zyngier writes: > On 06/10/17 13:37, Marc Zyngier wrote: >> On 06/10/17 12:39, Alex Bennée wrote: >>> The system state of KVM when using userspace emulation is not complete >>> until we return into KVM_RUN. To handle mmio related updates we wait >>> until they have

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

Marc Zyngier writes: > On 06/10/17 13:37, Marc Zyngier wrote: >> On 06/10/17 12:39, Alex Bennée wrote: >>> The system state of KVM when using userspace emulation is not complete >>> until we return into KVM_RUN. To handle mmio related updates we wait >>> until they have been committed and then

Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla wrote: > > > On 06/10/17 12:26, Jassi Brar wrote: >> On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: >>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla wrote: This patch adds ARM MHU

Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On Fri, Oct 6, 2017 at 7:02 PM, Sudeep Holla wrote: > > > On 06/10/17 12:26, Jassi Brar wrote: >> On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: >>> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla wrote: This patch adds ARM MHU specific mailbox interface for SCMI. Cc: Arnd

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

On Fri, Oct 06, 2017 at 01:33:32PM +, Stahl, Manuel wrote: > > Signed-off-by: Manuel Stahl > --- >  drivers/uio/uio_pci_dmem_genirq.c | 27 --- >  drivers/uio/uio_pci_generic.c | 24 ++-- >  2 files changed, 38

Re: [PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

On Fri, Oct 06, 2017 at 01:33:32PM +, Stahl, Manuel wrote: > > Signed-off-by: Manuel Stahl > --- >  drivers/uio/uio_pci_dmem_genirq.c | 27 --- >  drivers/uio/uio_pci_generic.c | 24 ++-- >  2 files changed, 38 insertions(+), 13 deletions(-) I

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

Julien Thierry writes: > On 06/10/17 12:39, Alex Bennée wrote: >> The system state of KVM when using userspace emulation is not complete >> until we return into KVM_RUN. To handle mmio related updates we wait >> until they have been committed and then schedule our

Re: [PATCH v1 2/2] kvm: arm64: handle single-step of userspace mmio instructions

Julien Thierry writes: > On 06/10/17 12:39, Alex Bennée wrote: >> The system state of KVM when using userspace emulation is not complete >> until we return into KVM_RUN. To handle mmio related updates we wait >> until they have been committed and then schedule our KVM_EXIT_DEBUG. >> >> I've

Re: [PATCH v3 15/22] firmware: arm_scmi: abstract mailbox interface

On 06/10/17 14:34, Jassi Brar wrote: > On Fri, Oct 6, 2017 at 6:57 PM, Sudeep Holla wrote: >> >> >> On 06/10/17 12:34, Jassi Brar wrote: >>> On Wed, Oct 4, 2017 at 5:02 PM, Sudeep Holla wrote: >>> Also, I have added shim only for specific

Re: [PATCH v3 15/22] firmware: arm_scmi: abstract mailbox interface

On 06/10/17 14:34, Jassi Brar wrote: > On Fri, Oct 6, 2017 at 6:57 PM, Sudeep Holla wrote: >> >> >> On 06/10/17 12:34, Jassi Brar wrote: >>> On Wed, Oct 4, 2017 at 5:02 PM, Sudeep Holla wrote: >>> Also, I have added shim only for specific controllers that need them. E.g. ARM MHU as

Re: [PATCH v7 2/2] tracing: Add support for preempt and irq enable/disable events

On Fri, 6 Oct 2017 00:28:21 -0700 Joel Fernandes wrote: > Oh ok. So I traced this down to the original patch that added > time_hardirqs_off to lockdep. I *think* it was added just to keep the > irqsoff tracer working while lockdep is enabled, so that both lockdep > and the

Re: [PATCH v7 2/2] tracing: Add support for preempt and irq enable/disable events

On Fri, 6 Oct 2017 00:28:21 -0700 Joel Fernandes wrote: > Oh ok. So I traced this down to the original patch that added > time_hardirqs_off to lockdep. I *think* it was added just to keep the > irqsoff tracer working while lockdep is enabled, so that both lockdep > and the tracer would work at

Re: [PATCH 0/4] RCU: introduce noref debug

On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote: > The networking subsystem is currently using some kind of long-lived > RCU-protected, references to avoid the overhead of full book-keeping. > > Such references - skb_dst() noref - are stored inside the skbs and can be > moved across

Re: [PATCH 0/4] RCU: introduce noref debug

On Fri, Oct 06, 2017 at 02:57:45PM +0200, Paolo Abeni wrote: > The networking subsystem is currently using some kind of long-lived > RCU-protected, references to avoid the overhead of full book-keeping. > > Such references - skb_dst() noref - are stored inside the skbs and can be > moved across

[PATCH v2 4/5] arm64: locking: Move rwlock implementation over to qrwlocks

Now that the qrwlock can make use of WFE, remove our homebrew rwlock code in favour of the generic queued implementation. Signed-off-by: Will Deacon --- arch/arm64/Kconfig | 17 arch/arm64/include/asm/Kbuild | 1 +

[PATCH v2 4/5] arm64: locking: Move rwlock implementation over to qrwlocks

Now that the qrwlock can make use of WFE, remove our homebrew rwlock code in favour of the generic queued implementation. Signed-off-by: Will Deacon --- arch/arm64/Kconfig | 17 arch/arm64/include/asm/Kbuild | 1 + arch/arm64/include/asm/spinlock.h |

[PATCH v2 3/5] kernel/locking: Use atomic_cond_read_acquire when spinning in qrwlock

The qrwlock slowpaths involve spinning when either a prospective reader is waiting for a concurrent writer to drain, or a prospective writer is waiting for concurrent readers to drain. In both of these situations, atomic_cond_read_acquire can be used to avoid busy-waiting and make use of any

[PATCH v2 3/5] kernel/locking: Use atomic_cond_read_acquire when spinning in qrwlock

The qrwlock slowpaths involve spinning when either a prospective reader is waiting for a concurrent writer to drain, or a prospective writer is waiting for concurrent readers to drain. In both of these situations, atomic_cond_read_acquire can be used to avoid busy-waiting and make use of any

[PATCH v2 2/5] locking/atomic: Add atomic_cond_read_acquire

smp_cond_load_acquire provides a way to spin on a variable with acquire semantics until some conditional expression involing the variable is satisfied. Architectures such as arm64 can potentially enter a low-power state, waking up only when the value of the variable changes, which reduces the

[PATCH v2 2/5] locking/atomic: Add atomic_cond_read_acquire

smp_cond_load_acquire provides a way to spin on a variable with acquire semantics until some conditional expression involing the variable is satisfied. Architectures such as arm64 can potentially enter a low-power state, waking up only when the value of the variable changes, which reduces the

[PATCH v2 1/5] kernel/locking: Use struct qrwlock instead of struct __qrwlock

There's no good reason to keep the internal structure of struct qrwlock hidden from qrwlock.h, particularly as it's actually needed for unlock and ends up being abstracted independently behind the __qrwlock_write_byte function. Stop pretending we can hide this stuff, and move the __qrwlock

[PATCH v2 1/5] kernel/locking: Use struct qrwlock instead of struct __qrwlock

There's no good reason to keep the internal structure of struct qrwlock hidden from qrwlock.h, particularly as it's actually needed for unlock and ends up being abstracted independently behind the __qrwlock_write_byte function. Stop pretending we can hide this stuff, and move the __qrwlock

[PATCH v2 0/5] Switch arm64 over to qrwlock

Hi all, This is version two of the patches I posted yesterday: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/534666.html I'd normally leave it longer before posting again, but Peter had a good suggestion to rework the layout of the lock word, so I wanted to post a version

[PATCH v2 5/5] kernel/locking: Prevent slowpath writers getting held up by fastpath

When a prospective writer takes the qrwlock locking slowpath due to the lock being held, it attempts to cmpxchg the wmode field from 0 to _QW_WAITING so that concurrent lockers also take the slowpath and queue on the spinlock accordingly, allowing the lockers to drain. Unfortunately, this isn't

[PATCH v2 0/5] Switch arm64 over to qrwlock

Hi all, This is version two of the patches I posted yesterday: http://lists.infradead.org/pipermail/linux-arm-kernel/2017-October/534666.html I'd normally leave it longer before posting again, but Peter had a good suggestion to rework the layout of the lock word, so I wanted to post a version

[PATCH v2 5/5] kernel/locking: Prevent slowpath writers getting held up by fastpath

When a prospective writer takes the qrwlock locking slowpath due to the lock being held, it attempts to cmpxchg the wmode field from 0 to _QW_WAITING so that concurrent lockers also take the slowpath and queue on the spinlock accordingly, allowing the lockers to drain. Unfortunately, this isn't

Re: [PATCH v3 15/22] firmware: arm_scmi: abstract mailbox interface

On Fri, Oct 6, 2017 at 6:57 PM, Sudeep Holla wrote: > > > On 06/10/17 12:34, Jassi Brar wrote: >> On Wed, Oct 4, 2017 at 5:02 PM, Sudeep Holla wrote: >> >>> Also, I have added shim only for specific controllers that need them. >>> E.g. ARM MHU as Jassi

Re: [PATCH v3 15/22] firmware: arm_scmi: abstract mailbox interface

On Fri, Oct 6, 2017 at 6:57 PM, Sudeep Holla wrote: > > > On 06/10/17 12:34, Jassi Brar wrote: >> On Wed, Oct 4, 2017 at 5:02 PM, Sudeep Holla wrote: >> >>> Also, I have added shim only for specific controllers that need them. >>> E.g. ARM MHU as Jassi disagreed to add doorbell mechanism to

Re: [ANNOUNCE] v4.11.12-rt13

On Fri, 2017-10-06 at 12:28 +0200, Sebastian Andrzej Siewior wrote: > On 2017-10-06 04:20:31 [+0200], Mike Galbraith wrote: > > On Thu, 2017-10-05 at 17:54 +0200, Sebastian Andrzej Siewior wrote: > > > On 2017-10-04 18:07:59 [+0200], Mike Galbraith wrote: > > > > Seems combo-patch induced some ltp

Re: [ANNOUNCE] v4.11.12-rt13

On Fri, 2017-10-06 at 12:28 +0200, Sebastian Andrzej Siewior wrote: > On 2017-10-06 04:20:31 [+0200], Mike Galbraith wrote: > > On Thu, 2017-10-05 at 17:54 +0200, Sebastian Andrzej Siewior wrote: > > > On 2017-10-04 18:07:59 [+0200], Mike Galbraith wrote: > > > > Seems combo-patch induced some ltp

[PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

Signed-off-by: Manuel Stahl ---  drivers/uio/uio_pci_dmem_genirq.c | 27 ---  drivers/uio/uio_pci_generic.c | 24 ++--  2 files changed, 38 insertions(+), 13 deletions(-) diff --git a/drivers/uio/uio_pci_dmem_genirq.c

[PATCH 2/2] uio: Prefer MSI(X) interrupts in PCI drivers

Signed-off-by: Manuel Stahl ---  drivers/uio/uio_pci_dmem_genirq.c | 27 ---  drivers/uio/uio_pci_generic.c | 24 ++--  2 files changed, 38 insertions(+), 13 deletions(-) diff --git a/drivers/uio/uio_pci_dmem_genirq.c

Re: [PATCH] mwifiex: Use put_unaligned_le32

Himanshu Jha writes: > On Thu, Oct 05, 2017 at 11:02:50AM -0700, Brian Norris wrote: >> On Thu, Oct 05, 2017 at 08:52:33PM +0530, Himanshu Jha wrote: >> > There are various instances where a function used in file say for eg >> > int func_align (void* a) >> > is used

Re: [PATCH] mwifiex: Use put_unaligned_le32

Himanshu Jha writes: > On Thu, Oct 05, 2017 at 11:02:50AM -0700, Brian Norris wrote: >> On Thu, Oct 05, 2017 at 08:52:33PM +0530, Himanshu Jha wrote: >> > There are various instances where a function used in file say for eg >> > int func_align (void* a) >> > is used and it is defined in align.h

[PATCH 1/2 v3] Add new uio device for PCI with dynamic memory allocation

This device combines the uio_pci_generic driver and the uio_dmem_genirq driver since PCI uses a slightly different API for interrupts. A fixed number of DMA capable memory regions can be defined using the module parameter "dmem_sizes". The memory is not allocated until the uio device file is

[PATCH 1/2 v3] Add new uio device for PCI with dynamic memory allocation

This device combines the uio_pci_generic driver and the uio_dmem_genirq driver since PCI uses a slightly different API for interrupts. A fixed number of DMA capable memory regions can be defined using the module parameter "dmem_sizes". The memory is not allocated until the uio device file is

Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On 06/10/17 12:26, Jassi Brar wrote: > On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: >> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla wrote: >>> This patch adds ARM MHU specific mailbox interface for SCMI. >>> >>> Cc: Arnd Bergmann

Re: [PATCH v3 16/22] firmware: arm_scmi: add arm_mhu specific mailbox interface

On 06/10/17 12:26, Jassi Brar wrote: > On Wed, Oct 4, 2017 at 5:06 PM, Arnd Bergmann wrote: >> On Thu, Sep 28, 2017 at 3:11 PM, Sudeep Holla wrote: >>> This patch adds ARM MHU specific mailbox interface for SCMI. >>> >>> Cc: Arnd Bergmann >>> Signed-off-by: Sudeep Holla >> >> This clearly

<    5   6   7   8   9   10   11   12   13   14   >