On Thu, Nov 01, 2018 at 10:28:28AM +, Charles Keepax wrote:
> 1.2) Read all the registers from the device on boot
> + Uses less memory
> - Potentially very slow boot time
> 1.3) Only read values as you touch registers
> + Uses less memory
> +
On Thu, Nov 01, 2018 at 10:28:28AM +, Charles Keepax wrote:
> 1.2) Read all the registers from the device on boot
> + Uses less memory
> - Potentially very slow boot time
> 1.3) Only read values as you touch registers
> + Uses less memory
> +
On 10/22/2018 10:59 AM, Steve Sistare wrote:
> When a CPU has no more CFS tasks to run, and idle_balance() fails to
> find a task, then attempt to steal a task from an overloaded CPU in the
> same LLC. Maintain and use a bitmap of overloaded CPUs to efficiently
> identify candidates. To minimize
On 10/22/2018 10:59 AM, Steve Sistare wrote:
> When a CPU has no more CFS tasks to run, and idle_balance() fails to
> find a task, then attempt to steal a task from an overloaded CPU in the
> same LLC. Maintain and use a bitmap of overloaded CPUs to efficiently
> identify candidates. To minimize
Laurence,
On Tue, 30 Oct 2018, Laurence Oberman wrote:
This looks much better.
But please send your patches first to yourself. Your subject ended up with
'[PATCH] [PATCH V7]' instead of just '[PATCH V7]'
> Both graphics and serial consoles are exposed to hard lockups
> when handling a large
Laurence,
On Tue, 30 Oct 2018, Laurence Oberman wrote:
This looks much better.
But please send your patches first to yourself. Your subject ended up with
'[PATCH] [PATCH V7]' instead of just '[PATCH V7]'
> Both graphics and serial consoles are exposed to hard lockups
> when handling a large
On 10/13/2018 2:18 AM, Rob Herring wrote:
On Mon, Oct 08, 2018 at 06:55:37PM +0530, Veerabhadrarao Badiganti wrote:
On the SDHC-MSM controllers which makes use of sdcdc10 variant DLLs,
the DLL configuration needs to be restored whenever controller clocks
are gated. This new compatible string
On 10/13/2018 2:18 AM, Rob Herring wrote:
On Mon, Oct 08, 2018 at 06:55:37PM +0530, Veerabhadrarao Badiganti wrote:
On the SDHC-MSM controllers which makes use of sdcdc10 variant DLLs,
the DLL configuration needs to be restored whenever controller clocks
are gated. This new compatible string
Hi Arnaldo,
On Nov 1 2018 4:29, Arnaldo Carvalho de Melo wrote:
Wouldn't a symlink be simpler?
That would be equivalent to using it directly, see my response to
Takashi for a few of the reasons this is done this way.
I have a plan to add changes to 'include/uapi/sound/asound.h' in a
Hi Arnaldo,
On Nov 1 2018 4:29, Arnaldo Carvalho de Melo wrote:
Wouldn't a symlink be simpler?
That would be equivalent to using it directly, see my response to
Takashi for a few of the reasons this is done this way.
I have a plan to add changes to 'include/uapi/sound/asound.h' in a
From: Sent: 31 October 2018 13:28
...
> * I actually have a local variant of the patch that would have you
> open "/proc/$PID/kill/$SIGNO" instead, since different signal numbers
> have different permission checks.
I think you'd need the open() to specify some specific unusual
open modes.
From: Sent: 31 October 2018 13:28
...
> * I actually have a local variant of the patch that would have you
> open "/proc/$PID/kill/$SIGNO" instead, since different signal numbers
> have different permission checks.
I think you'd need the open() to specify some specific unusual
open modes.
SD line mask for MI2S starts from BIT 0 instead of BIT 1.
Fix all bit mask for MI2S SD lines.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/qdsp6/q6afe.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6afe.c
SD line mask for MI2S starts from BIT 0 instead of BIT 1.
Fix all bit mask for MI2S SD lines.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/qdsp6/q6afe.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/sound/soc/qcom/qdsp6/q6afe.c
I am Mr Marc Joseph Hebert a I work in the Finance Risk control/Accounts Broker
Unit of a prestigious bank in London. Under varying state laws in United
Kingdom, financial institutions and other companies are required to turn over
any funds considered "abandoned," including uncashed
I am Mr Marc Joseph Hebert a I work in the Finance Risk control/Accounts Broker
Unit of a prestigious bank in London. Under varying state laws in United
Kingdom, financial institutions and other companies are required to turn over
any funds considered "abandoned," including uncashed
Commit-ID: 3424243e39e8ec138486926949e3668e7553125d
Gitweb: https://git.kernel.org/tip/3424243e39e8ec138486926949e3668e7553125d
Author: Dan Carpenter
AuthorDate: Sat, 13 Oct 2018 13:22:46 +0300
Committer: Thomas Gleixner
CommitDate: Thu, 1 Nov 2018 12:38:48 +0100
Commit-ID: 3424243e39e8ec138486926949e3668e7553125d
Gitweb: https://git.kernel.org/tip/3424243e39e8ec138486926949e3668e7553125d
Author: Dan Carpenter
AuthorDate: Sat, 13 Oct 2018 13:22:46 +0300
Committer: Thomas Gleixner
CommitDate: Thu, 1 Nov 2018 12:38:48 +0100
From: Nathan Chancellor
> Sent: 01 November 2018 00:04
...
> > A slightly lesser evil variant is to add a few PIN_CONFIG_CUSTOM_1
> > PIN_CONFIG_CUSTOM_2 etc at the end of the enum and just
> > #define MY_CONFIG PIN_CONFIG_CUSTOM_1
> > in all drivers that use these.
> >
>
> Some drivers actually
From: Nathan Chancellor
> Sent: 01 November 2018 00:04
...
> > A slightly lesser evil variant is to add a few PIN_CONFIG_CUSTOM_1
> > PIN_CONFIG_CUSTOM_2 etc at the end of the enum and just
> > #define MY_CONFIG PIN_CONFIG_CUSTOM_1
> > in all drivers that use these.
> >
>
> Some drivers actually
On 10/31/2018 07:03 PM, Sasha Levin wrote:
> From: Prarit Bhargava
>
> [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
>
> cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
> (0xC0010064 + state number) set to zero. As a result fid and did are zero
> and
On 10/31/2018 07:03 PM, Sasha Levin wrote:
> From: Prarit Bhargava
>
> [ Upstream commit f69ffc5d3db8f1f03fd6d1df5930f9a1fbd787b6 ]
>
> cpupower crashes on VMWare guests. The guests have the AMD PStateDef MSR
> (0xC0010064 + state number) set to zero. As a result fid and did are zero
> and
On 01/11/18 10:28, Charles Keepax wrote:
On Mon, Oct 29, 2018 at 11:04:39AM +, Lee Jones wrote:
On Fri, 26 Oct 2018, Mark Brown wrote:
On Fri, Oct 26, 2018 at 09:00:51AM +0100, Lee Jones wrote:
On Thu, 25 Oct 2018, Richard Fitzgerald wrote:
I have re-ordered some of the quotes here for
Agreed. slit_valid() on the ACPI parsing is currently enforcing that before
acpi_numa_slit_init() which would call into numa_set_distance(). Hence arch
NUMA code numa_set_distance() never had the opportunity to do the sanity
checks as ACPI slit_valid() has completely invalidated the table.
On 01/11/18 10:28, Charles Keepax wrote:
On Mon, Oct 29, 2018 at 11:04:39AM +, Lee Jones wrote:
On Fri, 26 Oct 2018, Mark Brown wrote:
On Fri, Oct 26, 2018 at 09:00:51AM +0100, Lee Jones wrote:
On Thu, 25 Oct 2018, Richard Fitzgerald wrote:
I have re-ordered some of the quotes here for
Agreed. slit_valid() on the ACPI parsing is currently enforcing that before
acpi_numa_slit_init() which would call into numa_set_distance(). Hence arch
NUMA code numa_set_distance() never had the opportunity to do the sanity
checks as ACPI slit_valid() has completely invalidated the table.
Hi Matias,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 73569e11032fc5a9b314b6351632cfca7793afd5 lightnvm: remove dependencies
on BLK_DEV_NVME and PCI
date: 3
Hi Matias,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 5b7449810ae6d652629c550d3974c8453836d229
commit: 73569e11032fc5a9b314b6351632cfca7793afd5 lightnvm: remove dependencies
on BLK_DEV_NVME and PCI
date: 3
On Thu, Nov 01, 2018 at 07:20:49PM +0800, Wang Yufen wrote:
> From: Yufen Wang
>
> In case panic() and panic() called at the same time on different CPUS.
> For example:
> CPU 0:
> panic()
> __crash_kexec
>machine_crash_shutdown
> crash_smp_send_stop
>machine_kexec
On Thu, Nov 01, 2018 at 07:20:49PM +0800, Wang Yufen wrote:
> From: Yufen Wang
>
> In case panic() and panic() called at the same time on different CPUS.
> For example:
> CPU 0:
> panic()
> __crash_kexec
>machine_crash_shutdown
> crash_smp_send_stop
>machine_kexec
From: Daniel Colascione
> Sent: 31 October 2018 19:33
...
> You can't do it today with kill. The idea that keeping a open file
> descriptor to a /proc/pid or a file within it prevents PID reuse is
> widespread, but incorrect.
Is there a real good reason why that shouldn't be the case?
ie Holding
From: Daniel Colascione
> Sent: 31 October 2018 19:33
...
> You can't do it today with kill. The idea that keeping a open file
> descriptor to a /proc/pid or a file within it prevents PID reuse is
> widespread, but incorrect.
Is there a real good reason why that shouldn't be the case?
ie Holding
On Thu, Nov 1, 2018 at 10:47 AM, Aleksa Sarai wrote:
> On 2018-11-01, Daniel Colascione wrote:
>> On Thu, Nov 1, 2018 at 7:00 AM, Aleksa Sarai wrote:
>> > On 2018-10-29, Daniel Colascione wrote:
>> >> This patch adds a new file under /proc/pid, /proc/pid/exithand.
>> >> Attempting to read from
On Thu, Nov 01, 2018 at 06:35:23AM +0100, Boris Brezillon wrote:
> Hello Greg, Linus,
>
> Greg, I didn't get your feedback on v10 of the i3c patchset [1] where I
> was asking if you'd agree to have this framework merged in 4.20 (I know
> you were busy with the 4.19 release and after that the
On Thu, Nov 1, 2018 at 10:47 AM, Aleksa Sarai wrote:
> On 2018-11-01, Daniel Colascione wrote:
>> On Thu, Nov 1, 2018 at 7:00 AM, Aleksa Sarai wrote:
>> > On 2018-10-29, Daniel Colascione wrote:
>> >> This patch adds a new file under /proc/pid, /proc/pid/exithand.
>> >> Attempting to read from
On Thu, Nov 01, 2018 at 06:35:23AM +0100, Boris Brezillon wrote:
> Hello Greg, Linus,
>
> Greg, I didn't get your feedback on v10 of the i3c patchset [1] where I
> was asking if you'd agree to have this framework merged in 4.20 (I know
> you were busy with the 4.19 release and after that the
On Fri, Oct 12, 2018 at 02:29:37PM -0500, Jeremy Linton wrote:
> The BAD_MADT_GICC_ENTRY check is a little too strict because
> it rejects MADT entries that don't match the currently known
> lengths. We should remove this restriction to avoid problems
> if the table length changes. Future code
On Fri, Oct 12, 2018 at 02:29:37PM -0500, Jeremy Linton wrote:
> The BAD_MADT_GICC_ENTRY check is a little too strict because
> it rejects MADT entries that don't match the currently known
> lengths. We should remove this restriction to avoid problems
> if the table length changes. Future code
On Thu, Nov 01, 2018 at 06:16:22PM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking/core
> head: 30bc7baa9de81efc0584b9290ce8040a1130f156
> commit: 85f8507192fbfb4ad2ac01de879cb50045f4247f [5/6] locking/atomics: Check
> generated
On Thu, Nov 01, 2018 at 06:16:22PM +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking/core
> head: 30bc7baa9de81efc0584b9290ce8040a1130f156
> commit: 85f8507192fbfb4ad2ac01de879cb50045f4247f [5/6] locking/atomics: Check
> generated
[ Nit: Please wrap your lines when replying -- I've done it for you here ]
On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
> On 10/29/2018 08:14 PM, John Garry wrote:
> > I think we should either factor out the sanity check
> >> into a core helper or make the core code
[ Nit: Please wrap your lines when replying -- I've done it for you here ]
On Tue, Oct 30, 2018 at 08:16:21AM +0530, Anshuman Khandual wrote:
> On 10/29/2018 08:14 PM, John Garry wrote:
> > I think we should either factor out the sanity check
> >> into a core helper or make the core code
We accidentally dropped execute permissions from the atomics scripts,
which leads to the check-atomics.sh script failing at build time:
CALLscripts/atomic/check-atomics.sh
scripts/atomic/check-atomics.sh: line 16:
scripts/atomic/gen-atomic-instrumented.sh: Permission denied
warning:
We accidentally dropped execute permissions from the atomics scripts,
which leads to the check-atomics.sh script failing at build time:
CALLscripts/atomic/check-atomics.sh
scripts/atomic/check-atomics.sh: line 16:
scripts/atomic/gen-atomic-instrumented.sh: Permission denied
warning:
On Wed, Oct 31, 2018 at 09:48:15AM -0700, Joe Perches wrote:
On Wed, 2018-10-31 at 09:41 -0400, YU Bo wrote:
Hi,
On Tue, Oct 30, 2018 at 08:01:50AM -0700, Joe Perches wrote:
> On Tue, 2018-10-30 at 08:01 -0400, Bo YU wrote:
> > Fix warning from checkpatch.pl use pr_* to replace printk
>
> If
On Wed, Oct 31, 2018 at 09:48:15AM -0700, Joe Perches wrote:
On Wed, 2018-10-31 at 09:41 -0400, YU Bo wrote:
Hi,
On Tue, Oct 30, 2018 at 08:01:50AM -0700, Joe Perches wrote:
> On Tue, 2018-10-30 at 08:01 -0400, Bo YU wrote:
> > Fix warning from checkpatch.pl use pr_* to replace printk
>
> If
From: Yufen Wang
In case panic() and panic() called at the same time on different CPUS.
For example:
CPU 0:
panic()
__crash_kexec
machine_crash_shutdown
crash_smp_send_stop
machine_kexec
BUG_ON(num_online_cpus() > 1);
CPU 1:
panic()
local_irq_disable
From: Yufen Wang
In case panic() and panic() called at the same time on different CPUS.
For example:
CPU 0:
panic()
__crash_kexec
machine_crash_shutdown
crash_smp_send_stop
machine_kexec
BUG_ON(num_online_cpus() > 1);
CPU 1:
panic()
local_irq_disable
On 31/10/2018 19:14, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 07:34:50PM +, Valentin Schneider wrote:
>> On a sidenote, I find it a bit odd that the exec_start threshold depends on
>> sysctl_sched_migration_cost, which to me is more about idle_balance() cost
>> than "how long does it
On 31/10/2018 19:14, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 07:34:50PM +, Valentin Schneider wrote:
>> On a sidenote, I find it a bit odd that the exec_start threshold depends on
>> sysctl_sched_migration_cost, which to me is more about idle_balance() cost
>> than "how long does it
Rob Herring writes:
> In most cases, nodes with 'status = "disabled";' are treated as if the
> node is not present though it is a common bug to forget to check that.
> However, cpu nodes are different in that "disabled" simply means offline
> and the OS can bring the CPU core online. Commit
Rob Herring writes:
> In most cases, nodes with 'status = "disabled";' are treated as if the
> node is not present though it is a common bug to forget to check that.
> However, cpu nodes are different in that "disabled" simply means offline
> and the OS can bring the CPU core online. Commit
On Thu, Nov 1, 2018 at 11:49 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:59fc453b21f7 Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15fb244740
> kernel config:
On Thu, Nov 1, 2018 at 11:49 AM, syzbot
wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:59fc453b21f7 Merge branch 'akpm' (patches from Andrew)
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15fb244740
> kernel config:
Rob Herring writes:
> On Wed, Oct 31, 2018 at 7:46 AM Michael Ellerman wrote:
>> Rob Herring writes:
>> > Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
>> > has the side effect of defaulting to iterating using "cpu" node names in
>> > preference to the deprecated (for
Rob Herring writes:
> On Wed, Oct 31, 2018 at 7:46 AM Michael Ellerman wrote:
>> Rob Herring writes:
>> > Use the for_each_of_cpu_node iterator to iterate over cpu nodes. This
>> > has the side effect of defaulting to iterating using "cpu" node names in
>> > preference to the deprecated (for
Hi,
On 31/10/18 16:18, Linus Torvalds wrote:
On Tue, Oct 30, 2018 at 10:34 PM Al Viro wrote:
mount API series from David Howells. Last cycle's objections
had been of the "I'd do it differently" variety and with no such
differently done variants having ever materialized over several
Hi,
On 31/10/18 16:18, Linus Torvalds wrote:
On Tue, Oct 30, 2018 at 10:34 PM Al Viro wrote:
mount API series from David Howells. Last cycle's objections
had been of the "I'd do it differently" variety and with no such
differently done variants having ever materialized over several
Linus,
I2C has a core bugfix & cleanup as well as an ID addition and
MAINTAINERS update for you.
Please pull.
Thanks,
Wolfram
The following changes since commit 9bb9d4fdce9e6b351b7b905f150745a0fc06:
Merge branch 'for-linus-4.20-rc1' of
Linus,
I2C has a core bugfix & cleanup as well as an ID addition and
MAINTAINERS update for you.
Please pull.
Thanks,
Wolfram
The following changes since commit 9bb9d4fdce9e6b351b7b905f150745a0fc06:
Merge branch 'for-linus-4.20-rc1' of
On 2018-11-01, Masami Hiramatsu wrote:
> > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > supports retstack).
> > >
> > > I think its time to come up with an algorithm that makes function graph
On 2018-11-01, Masami Hiramatsu wrote:
> > > > Anyway, until that merge happens, this patch looks good to avoid
> > > > this issue for generic solution (e.g. for the arch which doesn't
> > > > supports retstack).
> > >
> > > I think its time to come up with an algorithm that makes function graph
Am Mittwoch, 31. Oktober 2018, 22:17:29 CET schrieb Linus Walleij:
> On Wed, Oct 31, 2018 at 4:47 PM Michal Simek wrote:
> > No doubt about it that this is good. If this is there from day 1 all will
> > be good. I am just saying that we are all the time
> > saying that we shouldn't break
Am Mittwoch, 31. Oktober 2018, 22:17:29 CET schrieb Linus Walleij:
> On Wed, Oct 31, 2018 at 4:47 PM Michal Simek wrote:
> > No doubt about it that this is good. If this is there from day 1 all will
> > be good. I am just saying that we are all the time
> > saying that we shouldn't break
On 01.11.2018 13:24, Michal Hocko wrote:
On Thu 01-11-18 13:09:16, Konstantin Khlebnikov wrote:
Allocations over KMALLOC_MAX_SIZE could be served only by vmalloc.
I would go on and say that allocations with sizes too large can actually
trigger a warning (once you have posted in the
On 01.11.2018 13:24, Michal Hocko wrote:
On Thu 01-11-18 13:09:16, Konstantin Khlebnikov wrote:
Allocations over KMALLOC_MAX_SIZE could be served only by vmalloc.
I would go on and say that allocations with sizes too large can actually
trigger a warning (once you have posted in the
Hello,
syzbot found the following crash on:
HEAD commit:59fc453b21f7 Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15fb244740
kernel config: https://syzkaller.appspot.com/x/.config?x=ea045471e4c756e8
Hello,
syzbot found the following crash on:
HEAD commit:59fc453b21f7 Merge branch 'akpm' (patches from Andrew)
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15fb244740
kernel config: https://syzkaller.appspot.com/x/.config?x=ea045471e4c756e8
On 2018-11-01, Daniel Colascione wrote:
> On Thu, Nov 1, 2018 at 7:00 AM, Aleksa Sarai wrote:
> > On 2018-10-29, Daniel Colascione wrote:
> >> This patch adds a new file under /proc/pid, /proc/pid/exithand.
> >> Attempting to read from an exithand file will block until the
> >> corresponding
On 2018-11-01, Daniel Colascione wrote:
> On Thu, Nov 1, 2018 at 7:00 AM, Aleksa Sarai wrote:
> > On 2018-10-29, Daniel Colascione wrote:
> >> This patch adds a new file under /proc/pid, /proc/pid/exithand.
> >> Attempting to read from an exithand file will block until the
> >> corresponding
On 01/11/18 11:37, Thomas Gleixner wrote:
> VSMP support is built even if CONFIG_X86_VSMP is not set. This leads to a
> build
> breakage when CONFIG_PCI is disabled as well.
>
> Build VSMP code only when selected.
This patch disables detect_vsmp_box() on systems without CONFIG_X86_VSMP, due to
On 01/11/18 11:37, Thomas Gleixner wrote:
> VSMP support is built even if CONFIG_X86_VSMP is not set. This leads to a
> build
> breakage when CONFIG_PCI is disabled as well.
>
> Build VSMP code only when selected.
This patch disables detect_vsmp_box() on systems without CONFIG_X86_VSMP, due to
This patch adds the pmi callback support for the counters reserved by
components outside the perf core. For example, a hypervisor may register
such a callback to get the guest notified about the receiving of the
pmi.
The host PMI handling requires the active_events to be non-zero, so we
need
Add x86_perf_mask_perf_counters to reserve counters from the host perf
subsystem. The masked counters will not be assigned to any host perf
events. This can be used by the hypervisor to reserve perf counters for
a guest to use.
This function is currently supported on Intel CPUs only, but put in
This patch adds the pmi callback support for the counters reserved by
components outside the perf core. For example, a hypervisor may register
such a callback to get the guest notified about the receiving of the
pmi.
The host PMI handling requires the active_events to be non-zero, so we
need
Add x86_perf_mask_perf_counters to reserve counters from the host perf
subsystem. The masked counters will not be assigned to any host perf
events. This can be used by the hypervisor to reserve perf counters for
a guest to use.
This function is currently supported on Intel CPUs only, but put in
Return the assigned counters to host in the case the guest is torn down
unexpectedly.
Signed-off-by: Wei Wang
Cc: Andi Kleen
Cc: Paolo Bonzini
Cc: Peter Zijlstra
---
arch/x86/kvm/pmu_intel.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/pmu_intel.c
On 31-10-18, Pierre-Louis Bossart wrote:
>
> > Just thought it worth mentioning, this new patch that fixes sound
> > again, seems to have ressurected an old issue with PLL unlock. I'm
> > seeing journal entries after fresh boot ..
> >
> > ```
> > picard kernel: max98090 i2c-193C9890:00: PLL
Current vPMU relies on the host perf software stack to update the guest
change of the perf counter MSRs. The whole process includes releasing the
old perf event and re-creating a new one. This results in around 250ns
overhead to update a perf counter control MSR.
This can be avoided by having
Return the assigned counters to host in the case the guest is torn down
unexpectedly.
Signed-off-by: Wei Wang
Cc: Andi Kleen
Cc: Paolo Bonzini
Cc: Peter Zijlstra
---
arch/x86/kvm/pmu_intel.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/pmu_intel.c
On 31-10-18, Pierre-Louis Bossart wrote:
>
> > Just thought it worth mentioning, this new patch that fixes sound
> > again, seems to have ressurected an old issue with PLL unlock. I'm
> > seeing journal entries after fresh boot ..
> >
> > ```
> > picard kernel: max98090 i2c-193C9890:00: PLL
Current vPMU relies on the host perf software stack to update the guest
change of the perf counter MSRs. The whole process includes releasing the
old perf event and re-creating a new one. This results in around 250ns
overhead to update a perf counter control MSR.
This can be avoided by having
When the vCPU is scheduled in, restore the assigned perf counter states
and register the guest pmi callback. When the vCPU is scheduled out,
save the assigned perf counter states and unregister the guest PMI
callback.
Signed-off-by: Wei Wang
Cc: Andi Kleen
Cc: Paolo Bonzini
Cc: Peter Zijlstra
This patch adds support to intel vPMU to switch msrs on vmx transitions.
Currenly only 1 msr (global ctrl) is switched. The number can be
increased on demand in the future (e.g. pebs enable). The old method from
the host perf subsystem is also removed.
Signed-off-by: Wei Wang
Cc: Paolo Bonzini
When the vCPU is scheduled in, restore the assigned perf counter states
and register the guest pmi callback. When the vCPU is scheduled out,
save the assigned perf counter states and unregister the guest PMI
callback.
Signed-off-by: Wei Wang
Cc: Andi Kleen
Cc: Paolo Bonzini
Cc: Peter Zijlstra
This patch adds support to intel vPMU to switch msrs on vmx transitions.
Currenly only 1 msr (global ctrl) is switched. The number can be
increased on demand in the future (e.g. pebs enable). The old method from
the host perf subsystem is also removed.
Signed-off-by: Wei Wang
Cc: Paolo Bonzini
Those functions are used in the old intel vPMU implementation and are not
needed now.
Signed-off-by: Wei Wang
Cc: Paolo Bonzini
Cc: Andi Kleen
Cc: Peter Zijlstra
---
arch/x86/kvm/pmu_intel.c | 103 ---
1 file changed, 103 deletions(-)
diff --git
This patch adds the handling of guest rdpmc. If the physical counter has
been assigned, directly reads the value from the hardware. Otherwise,
return to the guest the virtual counter value.
Signed-off-by: Wei Wang
Cc: Paolo Bonzini
Cc: Andi Kleen
Cc: Peter Zijlstra
---
arch/x86/kvm/pmu.c
This patch series optimizes the Intel PMU virtualization by reducing the
PMU virtualization overhead and providing guests with accurate PMU
statistics.
The differences of the traditional approach and the optimized apporach
are depicted in the figures here:
Those functions are used in the old intel vPMU implementation and are not
needed now.
Signed-off-by: Wei Wang
Cc: Paolo Bonzini
Cc: Andi Kleen
Cc: Peter Zijlstra
---
arch/x86/kvm/pmu_intel.c | 103 ---
1 file changed, 103 deletions(-)
diff --git
This patch adds the handling of guest rdpmc. If the physical counter has
been assigned, directly reads the value from the hardware. Otherwise,
return to the guest the virtual counter value.
Signed-off-by: Wei Wang
Cc: Paolo Bonzini
Cc: Andi Kleen
Cc: Peter Zijlstra
---
arch/x86/kvm/pmu.c
This patch series optimizes the Intel PMU virtualization by reducing the
PMU virtualization overhead and providing guests with accurate PMU
statistics.
The differences of the traditional approach and the optimized apporach
are depicted in the figures here:
On Thu 01-11-18 18:09:39, 禹舟键 wrote:
> Hi Michal
> The null pointer is possible when calling the dump_header, this bug was
> detected by LKP. Below is the context 3 months ago.
Yeah I remember it was 0day report but I coundn't find it in my email
archive. Do you happen to have a message-id?
On Thu 01-11-18 18:09:39, 禹舟键 wrote:
> Hi Michal
> The null pointer is possible when calling the dump_header, this bug was
> detected by LKP. Below is the context 3 months ago.
Yeah I remember it was 0day report but I coundn't find it in my email
archive. Do you happen to have a message-id?
On Mon, Oct 29, 2018 at 11:04:39AM +, Lee Jones wrote:
> On Fri, 26 Oct 2018, Mark Brown wrote:
> > On Fri, Oct 26, 2018 at 09:00:51AM +0100, Lee Jones wrote:
> > > On Thu, 25 Oct 2018, Richard Fitzgerald wrote:
I have re-ordered some of the quotes here for the benefit
of clarity. I will
On Mon, Oct 29, 2018 at 11:04:39AM +, Lee Jones wrote:
> On Fri, 26 Oct 2018, Mark Brown wrote:
> > On Fri, Oct 26, 2018 at 09:00:51AM +0100, Lee Jones wrote:
> > > On Thu, 25 Oct 2018, Richard Fitzgerald wrote:
I have re-ordered some of the quotes here for the benefit
of clarity. I will
On Thu 01-11-18 18:00:12, Miles Chen wrote:
[...]
> I did a test today, the only code changed is to clamp to read count to
> PAGE_SIZE and it worked well. Maybe we can solve this issue by just
> clamping the read count.
>
> count = count > PAGE_SIZE ? PAGE_SIZE : count;
This i what Matthew was
On Thu 01-11-18 18:00:12, Miles Chen wrote:
[...]
> I did a test today, the only code changed is to clamp to read count to
> PAGE_SIZE and it worked well. Maybe we can solve this issue by just
> clamping the read count.
>
> count = count > PAGE_SIZE ? PAGE_SIZE : count;
This i what Matthew was
On Thu 01-11-18 13:09:16, Konstantin Khlebnikov wrote:
> Allocations over KMALLOC_MAX_SIZE could be served only by vmalloc.
I would go on and say that allocations with sizes too large can actually
trigger a warning (once you have posted in the previous version outside
of the changelog area)
On Thu 01-11-18 13:09:16, Konstantin Khlebnikov wrote:
> Allocations over KMALLOC_MAX_SIZE could be served only by vmalloc.
I would go on and say that allocations with sizes too large can actually
trigger a warning (once you have posted in the previous version outside
of the changelog area)
701 - 800 of 1024 matches
Mail list logo
