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

Kees, > 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen

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

Kees, > 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering

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

Kees, > 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen

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

Kees, > 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering

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

Kees, > 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen

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

Kees, > 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. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering

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

Kees, > 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. This removes > several redundant setup calls in favor of just changing the timer > function

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

Kees, > 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. This removes > several redundant setup calls in favor of just changing the timer > function

[PATCH v2 2/2] KVM: VMX: Fix VPID capability detection

From: Wanpeng Li In my setup, EPT is not exposed to L1, the VPID capability is exposed and can be observed by vmxcap tool in L1: INVVPID supportedyes Individual-address INVVPID yes Single-context INVVPID yes

[PATCH v2 2/2] KVM: VMX: Fix VPID capability detection

From: Wanpeng Li In my setup, EPT is not exposed to L1, the VPID capability is exposed and can be observed by vmxcap tool in L1: INVVPID supportedyes Individual-address INVVPID yes Single-context INVVPID yes All-context INVVPID

[PATCH v2 1/2] KVM: VMX: Don't advertise EPT switching if EPT itself is not exposed

From: Wanpeng Li I can use vmxcap tool to observe "EPTP Switching yes" even if EPT is not exposed to L1. EPT switching is advertised unconditionally since it is emulated, however, it can be treated as an extended feature for EPT and it should not be advertised if

[PATCH v2 1/2] KVM: VMX: Don't advertise EPT switching if EPT itself is not exposed

From: Wanpeng Li I can use vmxcap tool to observe "EPTP Switching yes" even if EPT is not exposed to L1. EPT switching is advertised unconditionally since it is emulated, however, it can be treated as an extended feature for EPT and it should not be advertised if EPT itself is not exposed.

[tip:x86/timers 7/8] tsc.c:undefined reference to `tsc_async_resets'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/timers head: 97d21003df3e7504c899b1701546f18ff475966f commit: 6c66350d0a482892793b888b07c1177fc6d4b344 [7/8] x86/tsc: Provide a means to disable TSC ART config: i386-randconfig-x0-10170810 (attached as .config) compiler:

[tip:x86/timers 7/8] tsc.c:undefined reference to `tsc_async_resets'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/timers head: 97d21003df3e7504c899b1701546f18ff475966f commit: 6c66350d0a482892793b888b07c1177fc6d4b344 [7/8] x86/tsc: Provide a means to disable TSC ART config: i386-randconfig-x0-10170810 (attached as .config) compiler:

Re: [PATCH v8 14/15] platform/x86: wmi: create userspace interface for drivers

Hi Mario, [auto build test WARNING on platform-drivers-x86/for-next] [also build test WARNING on next-20171016] [cannot apply to v4.14-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mario

Re: [PATCH v8 14/15] platform/x86: wmi: create userspace interface for drivers

Hi Mario, [auto build test WARNING on platform-drivers-x86/for-next] [also build test WARNING on next-20171016] [cannot apply to v4.14-rc5] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mario

Re: [PATCH 02/25] thermal/drivers/hisi: Remove the multiple sensors support

On Tue, Oct 10, 2017 at 08:02:27PM +0200, Daniel Lezcano wrote: > By essence, the tsensor does not really support multiple sensor at the same > time. It allows to set a sensor and use it to get the temperature, another > sensor could be switched but with a delay of 3-5ms. It is difficult to read >

Re: [PATCH 02/25] thermal/drivers/hisi: Remove the multiple sensors support

On Tue, Oct 10, 2017 at 08:02:27PM +0200, Daniel Lezcano wrote: > By essence, the tsensor does not really support multiple sensor at the same > time. It allows to set a sensor and use it to get the temperature, another > sensor could be switched but with a delay of 3-5ms. It is difficult to read >

Re: [PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

Hi Mario, [auto build test ERROR on platform-drivers-x86/for-next] [also build test ERROR on v4.14-rc5 next-20171016] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce

Re: [PATCH v8 09/15] platform/x86: dell-smbios: Introduce dispatcher for SMM calls

Hi Mario, [auto build test ERROR on platform-drivers-x86/for-next] [also build test ERROR on v4.14-rc5 next-20171016] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mario-Limonciello/Introduce

Re: [PATCH] powerpc/watchdog: Convert timers to use timer_setup()

Kees Cook writes: > 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: Benjamin Herrenschmidt >

Re: [PATCH] powerpc/watchdog: Convert timers to use timer_setup()

Kees Cook writes: > 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: Benjamin Herrenschmidt > Cc: Paul Mackerras > Cc: Michael Ellerman >

Re: [linux-sunxi] Re: [PATCH 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address

On Tue, Oct 17, 2017 at 4:15 AM, Maxime Ripard wrote: > On Mon, Oct 16, 2017 at 04:20:32PM +0800, Chen-Yu Tsai wrote: >> > On Sat, Oct 14, 2017 at 12:02:50PM +0800, Chen-Yu Tsai wrote: >> >> The display backend, as well as other peripherals that have a DRAM >> >>

Re: [linux-sunxi] Re: [PATCH 5/7] drm/sun4i: backend: Offset layer buffer address by DRAM starting address

On Tue, Oct 17, 2017 at 4:15 AM, Maxime Ripard wrote: > On Mon, Oct 16, 2017 at 04:20:32PM +0800, Chen-Yu Tsai wrote: >> > On Sat, Oct 14, 2017 at 12:02:50PM +0800, Chen-Yu Tsai wrote: >> >> The display backend, as well as other peripherals that have a DRAM >> >> clock gate and access DRAM

Re: [PATCH] scsi: qedi: Delete redundant variables

Christos, > Remove redundant variables in quedi_fw.c that are set but not used. Applied to 4.15/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: qedi: Delete redundant variables

Christos, > Remove redundant variables in quedi_fw.c that are set but not used. Applied to 4.15/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 2/4] rtc: mediatek: add driver for RTC on MT7622 SoC

On Mon, 2017-10-16 at 16:17 +0800, Sean Wang wrote: > Hi Alexandre, > > Thanks for your valuable suggestions on the driver. > > I added comments inline and will have following-ups in the next version > > Sean > > On Thu, 2017-10-12 at 23:20 +0200, Alexandre Belloni wrote: > > Hi, > > >

Re: [PATCH 2/4] rtc: mediatek: add driver for RTC on MT7622 SoC

On Mon, 2017-10-16 at 16:17 +0800, Sean Wang wrote: > Hi Alexandre, > > Thanks for your valuable suggestions on the driver. > > I added comments inline and will have following-ups in the next version > > Sean > > On Thu, 2017-10-12 at 23:20 +0200, Alexandre Belloni wrote: > > Hi, > > >

Re: [PATCH] csi: hpsa: Fix configured_logical_drive_count·check

Christos, > Check whether configured_logical_drive_count is less than > 255. Previous check was always evaluating to true as this variable is > defined as u8. Applied to 4.14/scsi-fixes. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] csi: hpsa: Fix configured_logical_drive_count·check

Christos, > Check whether configured_logical_drive_count is less than > 255. Previous check was always evaluating to true as this variable is > defined as u8. Applied to 4.14/scsi-fixes. Thank you! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH 1/2] KVM: VMX: Don't advertise EPT switching if EPT itself is not exposed

2017-10-17 1:16 GMT+08:00 Jim Mattson : > Does it still make sense to advertise "Enable VM Functions" in the > secondary processor-based VM-execution controls if we don't actually > support any VM Functions? Will do in v2. Thanks for your review. Regards, Wanpeng Li > > On

Re: [PATCH 1/2] KVM: VMX: Don't advertise EPT switching if EPT itself is not exposed

2017-10-17 1:16 GMT+08:00 Jim Mattson : > Does it still make sense to advertise "Enable VM Functions" in the > secondary processor-based VM-execution controls if we don't actually > support any VM Functions? Will do in v2. Thanks for your review. Regards, Wanpeng Li > > On Sat, Oct 14, 2017 at

[PATCH 2/2] mm/mmu_notifier: avoid call to invalidate_range() in range_end()

From: Jérôme Glisse This is an optimization patch that only affect mmu_notifier users which rely on the invalidate_range() callback. This patch avoids calling that callback twice in a row from inside __mmu_notifier_invalidate_range_end Existing pattern (before this patch):

[PATCH 2/2] mm/mmu_notifier: avoid call to invalidate_range() in range_end()

From: Jérôme Glisse This is an optimization patch that only affect mmu_notifier users which rely on the invalidate_range() callback. This patch avoids calling that callback twice in a row from inside __mmu_notifier_invalidate_range_end Existing pattern (before this patch):

[PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

From: Jérôme Glisse This patch only affects users of mmu_notifier->invalidate_range callback which are device drivers related to ATS/PASID, CAPI, IOMMUv2, SVM ... and it is an optimization for those users. Everyone else is unaffected by it. When clearing a pte/pmd we are

[PATCH 1/2] mm/mmu_notifier: avoid double notification when it is useless v2

From: Jérôme Glisse This patch only affects users of mmu_notifier->invalidate_range callback which are device drivers related to ATS/PASID, CAPI, IOMMUv2, SVM ... and it is an optimization for those users. Everyone else is unaffected by it. When clearing a pte/pmd we are given a choice to

[PATCH 0/2] Optimize mmu_notifier->invalidate_range callback

From: Jérôme Glisse (Andrew you already have v1 in your queue of patch 1, patch 2 is new, i think you can drop it patch 1 v1 for v2, v2 is bit more conservative and i fixed typos) All this only affect user of invalidate_range callback (at this time CAPI

[PATCH 0/2] Optimize mmu_notifier->invalidate_range callback

From: Jérôme Glisse (Andrew you already have v1 in your queue of patch 1, patch 2 is new, i think you can drop it patch 1 v1 for v2, v2 is bit more conservative and i fixed typos) All this only affect user of invalidate_range callback (at this time CAPI

Re: [lkp-robot] [fs] 91f9943e1c: aim7.jobs-per-min -26.6% regression

On 10/16, Christoph Hellwig wrote: >The only change for the non-nowait case is that we now do a trylock before >locking i_rwsem. In the past that was the more optimal pattern. Can you >test the patch below if that's not the case anymore? We have a few more >instances like that which might also

Re: [lkp-robot] [fs] 91f9943e1c: aim7.jobs-per-min -26.6% regression

On 10/16, Christoph Hellwig wrote: >The only change for the non-nowait case is that we now do a trylock before >locking i_rwsem. In the past that was the more optimal pattern. Can you >test the patch below if that's not the case anymore? We have a few more >instances like that which might also

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

On 10/16/2017 05:01 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. > > Cc: Kent Overstreet > Cc:

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

On 10/16/2017 05:01 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. > > Cc: Kent Overstreet > Cc: Shaohua Li > Cc: Alasdair

Re: [bug report & help] arm64: ltp testcase "migrate_pages01" failed

Hi all, I'm not sure if this is the problem on arm64 numa. What do you think ? By the way, this testcase can be successful in any case on x86. Thanks. Xiaojun. On 2017/10/16 19:42, Tan Xiaojun wrote: > Hi all, > > I test ltp in Hisilicon D05 board and get a failed result about the testcase >

Re: [bug report & help] arm64: ltp testcase "migrate_pages01" failed

Hi all, I'm not sure if this is the problem on arm64 numa. What do you think ? By the way, this testcase can be successful in any case on x86. Thanks. Xiaojun. On 2017/10/16 19:42, Tan Xiaojun wrote: > Hi all, > > I test ltp in Hisilicon D05 board and get a failed result about the testcase >

Re: [PATCH] powerpc/watchdog: Convert timers to use timer_setup()

On Mon, 16 Oct 2017 16:47:10 -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 pointer explicitly. > > Cc: Benjamin

Re: [PATCH] powerpc/watchdog: Convert timers to use timer_setup()

On Mon, 16 Oct 2017 16:47:10 -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 pointer explicitly. > > Cc: Benjamin Herrenschmidt > Cc: Paul

Re: [PATCH] scsi: aic7xxx: make a couple of functions static

Colin, > Functions ahc_devlimited_syncrate and ahc_linux_initialize_scsi_bus > are declared static in their prototypes but are missing in their > definitions, so add the missing static. Applied to 4.15/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: aic7xxx: make a couple of functions static

Colin, > Functions ahc_devlimited_syncrate and ahc_linux_initialize_scsi_bus > are declared static in their prototypes but are missing in their > definitions, so add the missing static. Applied to 4.15/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: nsp32: fix logic bug in error handling

Masanori, >> gcc-8 points out a logic error that has existed since the start >> of the git history: >> >> drivers/scsi/nsp32.c: In function 'nsp32_selection_autoscsi': >> drivers/scsi/nsp32.c:607:27: error: bitwise comparison always evaluates to >> false [-Werror=tautological-compare] >>

Re: [PATCH] scsi: nsp32: fix logic bug in error handling

Masanori, >> gcc-8 points out a logic error that has existed since the start >> of the git history: >> >> drivers/scsi/nsp32.c: In function 'nsp32_selection_autoscsi': >> drivers/scsi/nsp32.c:607:27: error: bitwise comparison always evaluates to >> false [-Werror=tautological-compare] >>

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

On Mon, Oct 16, 2017 at 7:12 PM, Shaohua Li wrote: > On Mon, Oct 16, 2017 at 05:01:48PM -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

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

On Mon, Oct 16, 2017 at 7:12 PM, Shaohua Li wrote: > On Mon, Oct 16, 2017 at 05:01:48PM -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: BUG_ON() in irq_work_run_list

Chandan Rajendra writes: > Executing fstests' generic/036 test in a loop on next-20171013 kernel causes > BUG_ON()'s condition to evaluate to true, Did it used to work? ie. the bug just started happening? If so is there a next tag which *doesn't* have the bug. > run

Re: BUG_ON() in irq_work_run_list

Chandan Rajendra writes: > Executing fstests' generic/036 test in a loop on next-20171013 kernel causes > BUG_ON()'s condition to evaluate to true, Did it used to work? ie. the bug just started happening? If so is there a next tag which *doesn't* have the bug. > run fstests generic/036 at

Re: [PATCH 2/2] KVM: VMX: Fix VPID capability detection

Hi Jim, 2017-10-17 3:53 GMT+08:00 Jim Mattson : > According to the SDM, > > The IA32_VMX_EPT_VPID_CAP MSR exists only on processors that support > the 1-setting of the “activate secondary > controls” VM-execution control (only if bit 63 of the > IA32_VMX_PROCBASED_CTLS MSR is

Re: [PATCH 2/2] KVM: VMX: Fix VPID capability detection

Hi Jim, 2017-10-17 3:53 GMT+08:00 Jim Mattson : > According to the SDM, > > The IA32_VMX_EPT_VPID_CAP MSR exists only on processors that support > the 1-setting of the “activate secondary > controls” VM-execution control (only if bit 63 of the > IA32_VMX_PROCBASED_CTLS MSR is 1) and that support >

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

On Mon, Oct 16, 2017 at 05:01:48PM -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 pointer explicitly. If you send the md.c part along, I'll

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

On Mon, Oct 16, 2017 at 05:01:48PM -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 pointer explicitly. If you send the md.c part along, I'll

Re: A issue about ptrace/SINGLESTEP on arm64

On 2017/10/16 23:30, Will Deacon wrote: Can you jump the PC once the child appears to be "stuck"? IIRC, GDB has special heuristics to step through LDXR/STXR critical sections. The function can be returned, But the number of instructions looks too much We use objdump to count the assembly

Re: A issue about ptrace/SINGLESTEP on arm64

On 2017/10/16 23:30, Will Deacon wrote: Can you jump the PC once the child appears to be "stuck"? IIRC, GDB has special heuristics to step through LDXR/STXR critical sections. The function can be returned, But the number of instructions looks too much We use objdump to count the assembly

Re: [PATCH v2 00/12] of: overlay: clean up device tree overlay code

On 10/16/17 18:17, frowand.l...@gmail.com wrote: > From: Frank Rowand > > I have found the device tree overlay code to be difficult to read and > maintain. This patch series attempts to improve that situation. > > The cleanup includes some changes visible to users of

Re: [PATCH v2 00/12] of: overlay: clean up device tree overlay code

On 10/16/17 18:17, frowand.l...@gmail.com wrote: > From: Frank Rowand > > I have found the device tree overlay code to be difficult to read and > maintain. This patch series attempts to improve that situation. > > The cleanup includes some changes visible to users of overlays. The > only in

Re: [PATCH v2 09/12] of: overlay: avoid race condition between applying multiple overlays

On 10/16/17 18:17, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The process of applying an overlay consists of: > - unflatten an overlay FDT (flattened device tree) into an > EDT (expanded device tree) > - fixup the phandle values in the overlay EDT to

Re: [PATCH v2 09/12] of: overlay: avoid race condition between applying multiple overlays

On 10/16/17 18:17, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The process of applying an overlay consists of: > - unflatten an overlay FDT (flattened device tree) into an > EDT (expanded device tree) > - fixup the phandle values in the overlay EDT to fit in a > range

Re: [PATCH v3] net: ftgmac100: Request clock and set speed

On Fri, 2017-10-13 at 12:16 +0800, Joel Stanley wrote: > According to the ASPEED datasheet, gigabit speeds require a clock of > 100MHz or higher. Other speeds require 25MHz or higher. This patch > configures a 100MHz clock if the system has a direct-attached > PHY, or 25MHz if the system is

Re: [PATCH v3] net: ftgmac100: Request clock and set speed

On Fri, 2017-10-13 at 12:16 +0800, Joel Stanley wrote: > According to the ASPEED datasheet, gigabit speeds require a clock of > 100MHz or higher. Other speeds require 25MHz or higher. This patch > configures a 100MHz clock if the system has a direct-attached > PHY, or 25MHz if the system is

[PATCH 2/9] perf/x86/intel/pt: change pt_cap_get() to a public function

From: Chao Peng Change pt_cap_get() to a public function so that KVM can access it. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/events/intel/pt.c | 3 ++- arch/x86/events/intel/pt.h

[PATCH 2/9] perf/x86/intel/pt: change pt_cap_get() to a public function

From: Chao Peng Change pt_cap_get() to a public function so that KVM can access it. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/events/intel/pt.c | 3 ++- arch/x86/events/intel/pt.h | 18 -- arch/x86/include/asm/intel_pt.h | 20

[PATCH 9/9] KVM: x86: Disable intercept for Intel processor trace MSRs

From: Chao Peng Trap for Intel processor trace is none sense. Pass through to guest directly. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/kvm/vmx.c | 14 ++ 1 file changed, 14

[PATCH 9/9] KVM: x86: Disable intercept for Intel processor trace MSRs

From: Chao Peng Trap for Intel processor trace is none sense. Pass through to guest directly. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/kvm/vmx.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index

[PATCH 8/9] KVM: x86: Implement Intel processor trace context switch

From: Chao Peng Load/Store Intel processor trace register in context switch. MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS, other MSRs are loaded/stored manaully. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang

[PATCH 7/9] KVM: x86: add Intel processor trace context for each vcpu

From: Chao Peng Add a date structure to save Intel processor trace context. It mainly include all the MSR of Intel processor trace. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang ---

[PATCH 8/9] KVM: x86: Implement Intel processor trace context switch

From: Chao Peng Load/Store Intel processor trace register in context switch. MSR IA32_RTIT_CTL is loaded/stored automatically from VMCS, other MSRs are loaded/stored manaully. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/kvm/vmx.c | 100

[PATCH 7/9] KVM: x86: add Intel processor trace context for each vcpu

From: Chao Peng Add a date structure to save Intel processor trace context. It mainly include all the MSR of Intel processor trace. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/include/asm/msr-index.h | 1 + arch/x86/include/asm/vmx.h | 2 ++ arch/x86/kvm/vmx.c

[PATCH 6/9] KVM: x86: add Intel processor trace cpuid emulataion

From: Chao Peng Expose Intel processor trace cpuid to guest. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/cpuid.c| 23

[PATCH 1/9] perf/x86/intel/pt: Move Intel-PT MSR bit definitions to a public header

From: Chao Peng Intel processor trace virtualization enabling in guest need to use these MSR bits, so move then to public header msr-index.h. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang ---

[PATCH 6/9] KVM: x86: add Intel processor trace cpuid emulataion

From: Chao Peng Expose Intel processor trace cpuid to guest. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/include/asm/kvm_host.h | 1 + arch/x86/kvm/cpuid.c| 23 +-- arch/x86/kvm/svm.c | 6 ++ arch/x86/kvm/vmx.c

[PATCH 1/9] perf/x86/intel/pt: Move Intel-PT MSR bit definitions to a public header

From: Chao Peng Intel processor trace virtualization enabling in guest need to use these MSR bits, so move then to public header msr-index.h. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/events/intel/pt.h | 37 -

[PATCH 5/9] KVM: x86: implement intel processor trace virtualization callbacks

From: Chao Peng Implement Intel processor trace virtualization callbacks to suppress host event in guest only mode. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/kvm/vmx.c | 21

[PATCH 4/9] perf/x86/intel/pt: add Intel processor trace virtualization call backs

From: Chao Peng Add Intel processor trace virtualization call backs to suppress host event in guest only mode. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/events/intel/pt.c | 21

[PATCH 5/9] KVM: x86: implement intel processor trace virtualization callbacks

From: Chao Peng Implement Intel processor trace virtualization callbacks to suppress host event in guest only mode. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/kvm/vmx.c | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/x86/kvm/vmx.c

[PATCH 4/9] perf/x86/intel/pt: add Intel processor trace virtualization call backs

From: Chao Peng Add Intel processor trace virtualization call backs to suppress host event in guest only mode. Signed-off-by: Chao Peng Signed-off-by: Luwei Kang --- arch/x86/events/intel/pt.c | 21 + arch/x86/include/asm/intel_pt.h | 9 + 2 files changed,

[PATCH 3/9] KVM: x86: add Intel processor trace virtualization mode

From: Chao Peng PT virtualization can be work in one of 4 possible modes: a. system-wide: trace both host/guest and output to host buffer; b. host-only: only trace host and output to host buffer; c. guest-only: only trace guest and output to guest buffer; d.

[PATCH 3/9] KVM: x86: add Intel processor trace virtualization mode

From: Chao Peng PT virtualization can be work in one of 4 possible modes: a. system-wide: trace both host/guest and output to host buffer; b. host-only: only trace host and output to host buffer; c. guest-only: only trace guest and output to guest buffer; d. host-guest: trace host/guest

[PATCH 0/9] Intel Processor Trace virtulization enabling

From: Chao Peng Hi All, Here is a patch-series which adding Processor Trace enabling in KVM guest. You can get It's software developer manuals from:

[PATCH 0/9] Intel Processor Trace virtulization enabling

From: Chao Peng Hi All, Here is a patch-series which adding Processor Trace enabling in KVM guest. You can get It's software developer manuals from: https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf In Chapter 5 INTEL

Re: [RESEND PATCH v2 1/5] arm64: dts: rockchip: Enable edp disaplay on kevin

On 2017年10月16日 18:06, Jeffy Chen wrote: Add edp panel and enable related nodes on kevin. Signed-off-by: Jeffy Chen --- Looks good. Reviewed-by: Mark Yao Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29

Re: [RESEND PATCH v2 1/5] arm64: dts: rockchip: Enable edp disaplay on kevin

On 2017年10月16日 18:06, Jeffy Chen wrote: Add edp panel and enable related nodes on kevin. Signed-off-by: Jeffy Chen --- Looks good. Reviewed-by: Mark Yao Changes in v2: None arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 29 +++

Re: [PATCH v3 3/4] drm/rockchip: Add support for Rockchip Soc RGB output interface

On 2017年10月09日 16:06, Sandy Huang wrote: Some Rockchip CRTCs, like rv1108, can directly output parallel and serial RGB data to panel or conversion chip, so we add this driver to probe encoder and connector. Signed-off-by: Sandy Huang --- Changes in v3: update for

Re: [PATCH v3 3/4] drm/rockchip: Add support for Rockchip Soc RGB output interface

On 2017年10月09日 16:06, Sandy Huang wrote: Some Rockchip CRTCs, like rv1108, can directly output parallel and serial RGB data to panel or conversion chip, so we add this driver to probe encoder and connector. Signed-off-by: Sandy Huang --- Changes in v3: update for rgb-mode move to panel

Re: [Part1 PATCH v6 16/17] X86/KVM: Decrypt shared per-cpu variables when SEV is active

On 10/16/17 5:24 PM, Borislav Petkov wrote: ... >> >> +static inline void __set_percpu_decrypted(void *ptr, unsigned long size) >> +{ >> +early_set_memory_decrypted(slow_virt_to_phys(ptr), size); >> +} > Ok, so this looks like useless conversion: > > you pass in a virtual address, it gets

Re: [Part1 PATCH v6 16/17] X86/KVM: Decrypt shared per-cpu variables when SEV is active

On 10/16/17 5:24 PM, Borislav Petkov wrote: ... >> >> +static inline void __set_percpu_decrypted(void *ptr, unsigned long size) >> +{ >> +early_set_memory_decrypted(slow_virt_to_phys(ptr), size); >> +} > Ok, so this looks like useless conversion: > > you pass in a virtual address, it gets

Re: RFC(v2): Audit Kernel Container IDs

On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote: > On 2017-10-12 16:33, Casey Schaufler wrote: > > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: > > > Containers are a userspace concept. The kernel knows nothing of them. > > > > > > The Linux audit system needs a way to be

Re: RFC(v2): Audit Kernel Container IDs

On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs wrote: > On 2017-10-12 16:33, Casey Schaufler wrote: > > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote: > > > Containers are a userspace concept. The kernel knows nothing of them. > > > > > > The Linux audit system needs a way to be

Re: [PATCH 0/9] Enable dw-mmc multi-card support

On 2017/10/7 3:21, Liming Sun wrote: This series of commits enables the multi-card support for the dw-mmc controller. It includes two parts as below. The first part (patches 1-7) reverts the series of recent commits that removed the multi-card support with comments saying there was no such use

Re: [PATCH 0/9] Enable dw-mmc multi-card support

On 2017/10/7 3:21, Liming Sun wrote: This series of commits enables the multi-card support for the dw-mmc controller. It includes two parts as below. The first part (patches 1-7) reverts the series of recent commits that removed the multi-card support with comments saying there was no such use

Re: [PATCH V7 4/6] blk-mq: introduce .get_budget and .put_budget in blk_mq_ops

On Mon, Oct 16, 2017 at 01:30:09PM +0200, Hannes Reinecke wrote: > On 10/13/2017 07:29 PM, Ming Lei wrote: > > On Fri, Oct 13, 2017 at 05:08:52PM +, Bart Van Assche wrote: > >> On Sat, 2017-10-14 at 00:45 +0800, Ming Lei wrote: > >>> On Fri, Oct 13, 2017 at 04:31:04PM +, Bart Van Assche

Re: [PATCH V7 4/6] blk-mq: introduce .get_budget and .put_budget in blk_mq_ops

On Mon, Oct 16, 2017 at 01:30:09PM +0200, Hannes Reinecke wrote: > On 10/13/2017 07:29 PM, Ming Lei wrote: > > On Fri, Oct 13, 2017 at 05:08:52PM +, Bart Van Assche wrote: > >> On Sat, 2017-10-14 at 00:45 +0800, Ming Lei wrote: > >>> On Fri, Oct 13, 2017 at 04:31:04PM +, Bart Van Assche

[PATCH v4] mm, sysctl: make NUMA stats configurable

This is the second step which introduces a tunable interface that allow numa stats configurable for optimizing zone_statistics(), as suggested by Dave Hansen and Ying Huang. = When page allocation performance becomes a

[PATCH v4] mm, sysctl: make NUMA stats configurable

This is the second step which introduces a tunable interface that allow numa stats configurable for optimizing zone_statistics(), as suggested by Dave Hansen and Ying Huang. = When page allocation performance becomes a

<    1   2   3   4   5   6   7   8   9   10   >