On Wed, Sep 12 2018 at 16:28 -0600, Matthias Kaehlcke wrote:
On Fri, Jul 27, 2018 at 03:34:48PM +0530, Raju P L S S S N wrote:
From: Lina Iyer
The Power Domain Controller can be programmed to wakeup the RSC and
setup the resources back in the active state, before the processor is
woken up by
On Wed, Sep 12 2018 at 16:28 -0600, Matthias Kaehlcke wrote:
On Fri, Jul 27, 2018 at 03:34:48PM +0530, Raju P L S S S N wrote:
From: Lina Iyer
The Power Domain Controller can be programmed to wakeup the RSC and
setup the resources back in the active state, before the processor is
woken up by
On 9/12/2018 1:30 PM, Guenter Roeck wrote:
On Wed, Sep 12, 2018 at 01:10:45PM -0700, Jae Hyun Yoo wrote:
On 9/12/2018 12:58 PM, Guenter Roeck wrote:
On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
On 9/11/2018 6:34 PM, Guenter Roeck wrote:
On Tue, Sep 11, 2018 at 04:58:44PM
On 9/12/2018 1:30 PM, Guenter Roeck wrote:
On Wed, Sep 12, 2018 at 01:10:45PM -0700, Jae Hyun Yoo wrote:
On 9/12/2018 12:58 PM, Guenter Roeck wrote:
On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
On 9/11/2018 6:34 PM, Guenter Roeck wrote:
On Tue, Sep 11, 2018 at 04:58:44PM
On Fri, Jul 27, 2018 at 03:34:48PM +0530, Raju P L S S S N wrote:
> From: Lina Iyer
>
> The Power Domain Controller can be programmed to wakeup the RSC and
> setup the resources back in the active state, before the processor is
> woken up by a timer interrupt. The wakeup value from the timer
On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> +linux-api, I guess
>
> On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
>>
>> Restrict the ability to inspect kernel stacks of arbitrary tasks to root
>> in order to prevent a local attacker from exploiting racy stack unwinding
>> to leak
On Fri, Jul 27, 2018 at 03:34:48PM +0530, Raju P L S S S N wrote:
> From: Lina Iyer
>
> The Power Domain Controller can be programmed to wakeup the RSC and
> setup the resources back in the active state, before the processor is
> woken up by a timer interrupt. The wakeup value from the timer
On Wed, Sep 12, 2018 at 8:29 AM, Jann Horn wrote:
> +linux-api, I guess
>
> On Tue, Sep 11, 2018 at 8:39 PM Jann Horn wrote:
>>
>> Restrict the ability to inspect kernel stacks of arbitrary tasks to root
>> in order to prevent a local attacker from exploiting racy stack unwinding
>> to leak
On Fri, Jul 27, 2018 at 03:34:47PM +0530, Raju P L S S S N wrote:
> From: "Raju P.L.S.S.S.N"
>
> For RSCs that have sleep & wake TCS but no dedicated active TCS, wake
> TCS can be re-purposed to send active requests. Once the active requests
> are sent and response is received, the active mode
On Fri, Jul 27, 2018 at 03:34:47PM +0530, Raju P L S S S N wrote:
> From: "Raju P.L.S.S.S.N"
>
> For RSCs that have sleep & wake TCS but no dedicated active TCS, wake
> TCS can be re-purposed to send active requests. Once the active requests
> are sent and response is received, the active mode
Hi!
> On 09/11/2018 03:05 PM, Pavel Machek wrote:
> > On Tue 2018-09-11 12:08:20, Dan Murphy wrote:
> >> Remove support for the LM3697 LED device
> >> from the ti-lmu. The LM3697 will be supported
> >> via a stand alone LED driver.
> >>
> >> Signed-off-by: Dan Murphy
> >
> > I'd really like to
Hi!
> On 09/11/2018 03:05 PM, Pavel Machek wrote:
> > On Tue 2018-09-11 12:08:20, Dan Murphy wrote:
> >> Remove support for the LM3697 LED device
> >> from the ti-lmu. The LM3697 will be supported
> >> via a stand alone LED driver.
> >>
> >> Signed-off-by: Dan Murphy
> >
> > I'd really like to
On Wed, 12 Sep 2018, Tim Chen wrote:
> I'm working on a patch for choosing the Spectre v2 app to app
> mitigation option.
>
> Something like the following:
>
> enum spectre_v2_app2app_mitigation {
> SPECTRE_V2_APP2APP_NONE,
> SPECTRE_V2_APP2APP_LITE,
>
On Wed, 12 Sep 2018, Tim Chen wrote:
> I'm working on a patch for choosing the Spectre v2 app to app
> mitigation option.
>
> Something like the following:
>
> enum spectre_v2_app2app_mitigation {
> SPECTRE_V2_APP2APP_NONE,
> SPECTRE_V2_APP2APP_LITE,
>
syzbot has found a reproducer for the following crash on:
HEAD commit:7c1b097f27bf Add linux-next specific files for 20180912
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=117a33be40
kernel config: https://syzkaller.appspot.com/x/.config?x
syzbot has found a reproducer for the following crash on:
HEAD commit:7c1b097f27bf Add linux-next specific files for 20180912
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=117a33be40
kernel config: https://syzkaller.appspot.com/x/.config?x
On Mon, Jul 30, 2018 at 04:21:44PM -0500, Alexandru Gagniuc wrote:
> When a PCI device is gone, we don't want to send IO to it if we can
> avoid it. We expose functionality via the irq_chip structure. As
> users of that structure may not know about the underlying PCI device,
> it's our
On Mon, Jul 30, 2018 at 04:21:44PM -0500, Alexandru Gagniuc wrote:
> When a PCI device is gone, we don't want to send IO to it if we can
> avoid it. We expose functionality via the irq_chip structure. As
> users of that structure may not know about the underlying PCI device,
> it's our
Commit-ID: 49e73246cbe6fe0df9cae2db87f31cdc3a0b2b61
Gitweb: https://git.kernel.org/tip/49e73246cbe6fe0df9cae2db87f31cdc3a0b2b61
Author: Zubin Mithra
AuthorDate: Wed, 12 Sep 2018 09:45:10 -0700
Committer: Ingo Molnar
CommitDate: Wed, 12 Sep 2018 21:16:16 +0200
perf/x86/intel/pt:
Commit-ID: 49e73246cbe6fe0df9cae2db87f31cdc3a0b2b61
Gitweb: https://git.kernel.org/tip/49e73246cbe6fe0df9cae2db87f31cdc3a0b2b61
Author: Zubin Mithra
AuthorDate: Wed, 12 Sep 2018 09:45:10 -0700
Committer: Ingo Molnar
CommitDate: Wed, 12 Sep 2018 21:16:16 +0200
perf/x86/intel/pt:
On 09/12/2018 10:16 AM, Tom Lendacky wrote:
>
>
> On 09/11/2018 04:16 PM, Thomas Gleixner wrote:
>> On Tue, 11 Sep 2018, Tim Chen wrote:
>>> On 09/10/2018 04:46 AM, Jiri Kosina wrote:
Nah, IBPB is actuall there, sorry. So I'll add reporting of STIBP + fixup
the missing reporting of
On 09/12/2018 10:16 AM, Tom Lendacky wrote:
>
>
> On 09/11/2018 04:16 PM, Thomas Gleixner wrote:
>> On Tue, 11 Sep 2018, Tim Chen wrote:
>>> On 09/10/2018 04:46 AM, Jiri Kosina wrote:
Nah, IBPB is actuall there, sorry. So I'll add reporting of STIBP + fixup
the missing reporting of
On Wed, Sep 12, 2018 at 10:29:07AM -0700, Jagdish Tirumala wrote:
> Fix the following checkpatch error:
>
> ERROR: pointer location foo * bar should be foo *bar
> FILE: drivers/watchdog/diag288_wdt.c:202
>
> Signed-off-by: Jagdish Tirumala
Reviewed-by: Guenter Roeck
> ---
>
On Wed, Sep 12, 2018 at 10:29:07AM -0700, Jagdish Tirumala wrote:
> Fix the following checkpatch error:
>
> ERROR: pointer location foo * bar should be foo *bar
> FILE: drivers/watchdog/diag288_wdt.c:202
>
> Signed-off-by: Jagdish Tirumala
Reviewed-by: Guenter Roeck
> ---
>
On Wed, Sep 12, 2018 at 07:24:48AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 11, 2018 at 09:58:48PM -0700, Guenter Roeck wrote:
> > On 09/11/2018 09:58 AM, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > Trivial fix to spelling mistake in comment
> > >
> > > Signed-off-by: Colin
On Wed, Sep 12, 2018 at 07:24:48AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 11, 2018 at 09:58:48PM -0700, Guenter Roeck wrote:
> > On 09/11/2018 09:58 AM, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > Trivial fix to spelling mistake in comment
> > >
> > > Signed-off-by: Colin
* Richard Henderson wrote:
> On 09/12/2018 07:44 AM, Matthew Wilcox wrote:
> > rth wrote a patch back in 2016 that uses gcc's address space machinery
> > to improve code generation for percpu accesses. Ingo asked for some
> > minor changes to be made, but Richard didn't respond. While
* Richard Henderson wrote:
> On 09/12/2018 07:44 AM, Matthew Wilcox wrote:
> > rth wrote a patch back in 2016 that uses gcc's address space machinery
> > to improve code generation for percpu accesses. Ingo asked for some
> > minor changes to be made, but Richard didn't respond. While
Ville Syrjälä - 12.09.18, 19:10:
> On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote:
> > Cc´d Intel Gfx mailing list, in case somebody there knows something:
> >
> > Cc´d Thorsten for regression tracking… forgot initially. Can also
> > open bug report at a later time but so far
Ville Syrjälä - 12.09.18, 19:10:
> On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote:
> > Cc´d Intel Gfx mailing list, in case somebody there knows something:
> >
> > Cc´d Thorsten for regression tracking… forgot initially. Can also
> > open bug report at a later time but so far
On 09/12/2018 01:42 PM, prakash.sangappa wrote:
On 05/09/2018 04:31 PM, Dave Hansen wrote:
On 05/07/2018 06:16 PM, prakash.sangappa wrote:
It will be /proc//numa_vamaps. Yes, the behavior will be
different with respect to seeking. Output will still be text and
the format will be same.
I
On 09/12/2018 01:42 PM, prakash.sangappa wrote:
On 05/09/2018 04:31 PM, Dave Hansen wrote:
On 05/07/2018 06:16 PM, prakash.sangappa wrote:
It will be /proc//numa_vamaps. Yes, the behavior will be
different with respect to seeking. Output will still be text and
the format will be same.
I
Stale mentions of irq_task are left in the kerneldoc after its removal.
Remove them.
There is still one indirect mention left but commit 3c8bb90efb6e ("rtc: Fix
hrtimer deadlock") can probably be reverted now.
Reported-by: Linus Torvalds
Signed-off-by: Alexandre Belloni
---
Stale mentions of irq_task are left in the kerneldoc after its removal.
Remove them.
There is still one indirect mention left but commit 3c8bb90efb6e ("rtc: Fix
hrtimer deadlock") can probably be reverted now.
Reported-by: Linus Torvalds
Signed-off-by: Alexandre Belloni
---
On 05/09/2018 04:31 PM, Dave Hansen wrote:
On 05/07/2018 06:16 PM, prakash.sangappa wrote:
It will be /proc//numa_vamaps. Yes, the behavior will be
different with respect to seeking. Output will still be text and
the format will be same.
I want to get feedback on this approach.
I think it
On 05/09/2018 04:31 PM, Dave Hansen wrote:
On 05/07/2018 06:16 PM, prakash.sangappa wrote:
It will be /proc//numa_vamaps. Yes, the behavior will be
different with respect to seeking. Output will still be text and
the format will be same.
I want to get feedback on this approach.
I think it
On Wed, Sep 12, 2018 at 5:27 AM, Oleg Nesterov wrote:
> On 09/11, Kees Cook wrote:
>>
>> Oh, I like this patch! This is much cleaner.
>
> it's pity. cause this means I will have to actually test this change and
> (worse) write the changelog ;)
Hehe. I know this pain well! :)
>> > @@ -410,11
Hi!
> >>> No, we are not back to full circle.
> >>>
> >>> Or at least we should not be.
> >>>
> >>> Yes, hw_pattern can have some limitation pattern does not, but if you
> >>> take values from hw_pattern file and put them into pattern file, you
> >>> should get the same pattern (with more power
On Wed, Sep 12, 2018 at 5:27 AM, Oleg Nesterov wrote:
> On 09/11, Kees Cook wrote:
>>
>> Oh, I like this patch! This is much cleaner.
>
> it's pity. cause this means I will have to actually test this change and
> (worse) write the changelog ;)
Hehe. I know this pain well! :)
>> > @@ -410,11
Hi!
> >>> No, we are not back to full circle.
> >>>
> >>> Or at least we should not be.
> >>>
> >>> Yes, hw_pattern can have some limitation pattern does not, but if you
> >>> take values from hw_pattern file and put them into pattern file, you
> >>> should get the same pattern (with more power
On Wed, 12 Sep 2018, Michal Hocko wrote:
> > Saying that we really want THP isn't an all-or-nothing decision. We
> > certainly want to try hard to fault hugepages locally especially at task
> > startup when remapping our .text segment to thp, and MADV_HUGEPAGE works
> > very well for that.
On Wed, 12 Sep 2018, Michal Hocko wrote:
> > Saying that we really want THP isn't an all-or-nothing decision. We
> > certainly want to try hard to fault hugepages locally especially at task
> > startup when remapping our .text segment to thp, and MADV_HUGEPAGE works
> > very well for that.
On Wed, Sep 12, 2018 at 01:10:45PM -0700, Jae Hyun Yoo wrote:
> On 9/12/2018 12:58 PM, Guenter Roeck wrote:
> >On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
> >>On 9/11/2018 6:34 PM, Guenter Roeck wrote:
> >>>On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
> On
On Wed, Sep 12, 2018 at 01:10:45PM -0700, Jae Hyun Yoo wrote:
> On 9/12/2018 12:58 PM, Guenter Roeck wrote:
> >On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
> >>On 9/11/2018 6:34 PM, Guenter Roeck wrote:
> >>>On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
> On
+Joe P
On Wed, Sep 12, 2018 at 10:17 AM Mauro Carvalho Chehab
wrote:
>
> Em Tue, 28 Aug 2018 10:44:33 -0500
> Rob Herring escreveu:
>
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Steve
+Joe P
On Wed, Sep 12, 2018 at 10:17 AM Mauro Carvalho Chehab
wrote:
>
> Em Tue, 28 Aug 2018 10:44:33 -0500
> Rob Herring escreveu:
>
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > Cc: Steve
This patch provides process address range to numa node information
thru /proc//numa_vamaps file. For address ranges not having
any pages mapped, a '-' is printed instead of the numa node id.
Following is the sample of the file format
0040-0041 N1
0041-0047f000 N0
0047f000-0048 N2
This patch provides process address range to numa node information
thru /proc//numa_vamaps file. For address ranges not having
any pages mapped, a '-' is printed instead of the numa node id.
Following is the sample of the file format
0040-0041 N1
0041-0047f000 N0
0047f000-0048 N2
Add support to check if numa node id matches when gathering pte stats,
to be used by later patches.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 44 +---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git
Introduce supporting data structures and file operations. Later
patch will provide changes for generating file content.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/base.c | 2 ++
fs/proc/internal.h | 1 +
fs/proc/task_mmu.c | 42
Permission to access /proc//numa_vamaps file should be governed by
PTRACE_READ_REALCREADS check to restrict getting specific VA range to numa
node mapping information.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/base.c | 4 +++-
fs/proc/task_mmu.c | 2 +-
2 files
Add documentation for /proc//numa_vamaps in
Documentation/filesystems/proc.txt
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
Documentation/filesystems/proc.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/filesystems/proc.txt
Add support to check if numa node id matches when gathering pte stats,
to be used by later patches.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 44 +---
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git
Introduce supporting data structures and file operations. Later
patch will provide changes for generating file content.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/base.c | 2 ++
fs/proc/internal.h | 1 +
fs/proc/task_mmu.c | 42
Permission to access /proc//numa_vamaps file should be governed by
PTRACE_READ_REALCREADS check to restrict getting specific VA range to numa
node mapping information.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/base.c | 4 +++-
fs/proc/task_mmu.c | 2 +-
2 files
Add documentation for /proc//numa_vamaps in
Documentation/filesystems/proc.txt
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
Documentation/filesystems/proc.txt | 21 +
1 file changed, 21 insertions(+)
diff --git a/Documentation/filesystems/proc.txt
For analysis purpose it is useful to have numa node information
corresponding mapped virtual address ranges of a process. Currently,
the file /proc//numa_maps provides list of numa nodes from where pages
are allocated per VMA of a process. This is not useful if an user needs to
determine which
Allow lseeking to a process virtual address(VA), starting from where
the address range to numa node information can be read. The lseek offset
will be the process virtual address.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 23 ++-
1
For analysis purpose it is useful to have numa node information
corresponding mapped virtual address ranges of a process. Currently,
the file /proc//numa_maps provides list of numa nodes from where pages
are allocated per VMA of a process. This is not useful if an user needs to
determine which
Allow lseeking to a process virtual address(VA), starting from where
the address range to numa node information can be read. The lseek offset
will be the process virtual address.
Signed-off-by: Prakash Sangappa
Reviewed-by: Steve Sistare
---
fs/proc/task_mmu.c | 23 ++-
1
Ensure the non managed version of the un/registration functions is not used
anymore. No driver is using it anymore and they should not be necessary.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/class.c | 12 +---
include/linux/rtc.h | 5 -
2 files changed, 5 insertions(+), 12
Ensure the non managed version of the un/registration functions is not used
anymore. No driver is using it anymore and they should not be necessary.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/class.c | 12 +---
include/linux/rtc.h | 5 -
2 files changed, 5 insertions(+), 12
On 09/12/2018 09:18 PM, Pavel Machek wrote:
> Hi!
>
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
[..]
> +What:/sys/class/leds//hw_pattern
> +Date:September 2018
On 09/12/2018 09:18 PM, Pavel Machek wrote:
> Hi!
>
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
[..]
> +What:/sys/class/leds//hw_pattern
> +Date:September 2018
On 9/12/2018 12:58 PM, Guenter Roeck wrote:
On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
On 9/11/2018 6:34 PM, Guenter Roeck wrote:
On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
On 9/11/2018 4:33 PM, Guenter Roeck wrote:
Looking into the patch, clearing the
On 9/12/2018 12:58 PM, Guenter Roeck wrote:
On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
On 9/11/2018 6:34 PM, Guenter Roeck wrote:
On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
On 9/11/2018 4:33 PM, Guenter Roeck wrote:
Looking into the patch, clearing the
On Tue, 11 Sep 2018 at 12:34, Kirill A. Shutemov
wrote:
>
> A transparent huge page is represented by a single entry on an LRU list.
> Therefore, we can only make unevictable an entire compound page, not
> individual subpages.
>
> If a user tries to mlock() part of a huge page, we want the rest
On Tue, 11 Sep 2018 at 12:34, Kirill A. Shutemov
wrote:
>
> A transparent huge page is represented by a single entry on an LRU list.
> Therefore, we can only make unevictable an entire compound page, not
> individual subpages.
>
> If a user tries to mlock() part of a huge page, we want the rest
On 12/09/2018 17:08:53+0200, Arnd Bergmann wrote:
> We no longer need the rtc compat handling to be in common code, now that
> all drivers are either moved to the rtc-class framework, or (rarely)
> exist in drivers/char for architectures without compat mode (m68k,
> alpha and ia64, respectively).
On 12/09/2018 17:08:53+0200, Arnd Bergmann wrote:
> We no longer need the rtc compat handling to be in common code, now that
> all drivers are either moved to the rtc-class framework, or (rarely)
> exist in drivers/char for architectures without compat mode (m68k,
> alpha and ia64, respectively).
On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
> On 9/11/2018 6:34 PM, Guenter Roeck wrote:
> >On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
> >>On 9/11/2018 4:33 PM, Guenter Roeck wrote:
> >>>Looking into the patch, clearing the interrupt status at the end of an
>
On Wed, Sep 12, 2018 at 09:54:51AM -0700, Jae Hyun Yoo wrote:
> On 9/11/2018 6:34 PM, Guenter Roeck wrote:
> >On Tue, Sep 11, 2018 at 04:58:44PM -0700, Jae Hyun Yoo wrote:
> >>On 9/11/2018 4:33 PM, Guenter Roeck wrote:
> >>>Looking into the patch, clearing the interrupt status at the end of an
>
Commit-ID: cf40361ede6cf9dc09349e4c049dc0d166ca2d8b
Gitweb: https://git.kernel.org/tip/cf40361ede6cf9dc09349e4c049dc0d166ca2d8b
Author: Guenter Roeck
AuthorDate: Tue, 11 Sep 2018 11:18:12 -0700
Committer: Thomas Gleixner
CommitDate: Wed, 12 Sep 2018 21:53:34 +0200
x86/efi: Load fixmap
Commit-ID: cf40361ede6cf9dc09349e4c049dc0d166ca2d8b
Gitweb: https://git.kernel.org/tip/cf40361ede6cf9dc09349e4c049dc0d166ca2d8b
Author: Guenter Roeck
AuthorDate: Tue, 11 Sep 2018 11:18:12 -0700
Committer: Thomas Gleixner
CommitDate: Wed, 12 Sep 2018 21:53:34 +0200
x86/efi: Load fixmap
A perf event has many attributes that are maintained in a separate
structure that should be provided when a new perf_event is created.
In preparation for the transition to perf_events the required attribute
structures are created for all the events that may be used in the
measurements. Most
A perf event has many attributes that are maintained in a separate
structure that should be provided when a new perf_event is created.
In preparation for the transition to perf_events the required attribute
structures are created for all the events that may be used in the
measurements. Most
From: Tony Krowiak
Notes:
=
Patches 1-2 (by David) are posted with this series because they are not
currently available in our master branch, upon which this series is based,
and because this series is dependent upon them.
This patch series works with the v8 QEMU patches.
Abstract:
From: David Hildenbrand
VCPU requests and VCPU blocking right now don't take care of the vSIE
(as it was not necessary until now). But we want to have synchronous VCPU
requests that will also be handled before running the vSIE again.
So let's simulate a SIE entry of the VCPU when calling the
From: Tony Krowiak
Notes:
=
Patches 1-2 (by David) are posted with this series because they are not
currently available in our master branch, upon which this series is based,
and because this series is dependent upon them.
This patch series works with the v8 QEMU patches.
Abstract:
From: David Hildenbrand
VCPU requests and VCPU blocking right now don't take care of the vSIE
(as it was not necessary until now). But we want to have synchronous VCPU
requests that will also be handled before running the vSIE again.
So let's simulate a SIE entry of the VCPU when calling the
This reverts commit 12eeeb4f4733bbc4481d01df35933fc15beb8b19.
The patch claims it fixes accessing memory with null pointer on
skl_interrupt() and snd_hdac_bus_update_rirb() path, but in fact it
has no effect.
There are two problems: 1) skl_init_chip() is called twice, before
and after dma buffer
This reverts commit 12eeeb4f4733bbc4481d01df35933fc15beb8b19.
The patch claims it fixes accessing memory with null pointer on
skl_interrupt() and snd_hdac_bus_update_rirb() path, but in fact it
has no effect.
There are two problems: 1) skl_init_chip() is called twice, before
and after dma buffer
From: Pierre Morel
When the guest schedules a SIE with a FORMAT-0 CRYCB,
we are able to schedule it in the host with a FORMAT-2
CRYCB if the host uses FORMAT-2
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c |4 +++-
1 files changed, 3 insertions(+), 1
From: Pierre Morel
When the guest schedules a SIE with a CRYCB FORMAT-1 CRYCB,
we are able to schedule it in the host with a FORMAT-2 CRYCB
if the host uses FORMAT-2.
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c | 33 -
1
Internally, skl_init_chip() calls snd_hdac_bus_init_chip() which
1) sets bus->chip_init to prevent multiple entrances before device
is stopped; 2) enables interrupt.
We shouldn't use it for the purpose of resetting device only because
1) when we really want to initialize device, we won't be able
From: Pierre Morel
When the guest schedules a SIE with a CRYCB FORMAT-1 CRYCB,
we are able to schedule it in the host with a FORMAT-2 CRYCB
if the host uses FORMAT-2.
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c | 33 -
1
Internally, skl_init_chip() calls snd_hdac_bus_init_chip() which
1) sets bus->chip_init to prevent multiple entrances before device
is stopped; 2) enables interrupt.
We shouldn't use it for the purpose of resetting device only because
1) when we really want to initialize device, we won't be able
From: Pierre Morel
When the guest schedules a SIE with a FORMAT-0 CRYCB,
we are able to schedule it in the host with a FORMAT-2
CRYCB if the host uses FORMAT-2
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c |4 +++-
1 files changed, 3 insertions(+), 1
From: Tony Krowiak
Introduces two new VM crypto device attributes (KVM_S390_VM_CRYPTO)
to enable or disable AP instruction interpretation from userspace
via the KVM_SET_DEVICE_ATTR ioctl:
* The KVM_S390_VM_CRYPTO_ENABLE_APIE attribute enables hardware
interpretation of AP instructions
From: Tony Krowiak
This patch provides documentation describing the AP architecture and
design concepts behind the virtualization of AP devices. It also
includes an example of how to configure AP devices for exclusive
use of KVM guests.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
From: Tony Krowiak
Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.
CPU model feature:
The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP instructions are available on the guest. This
feature will be enabled by the kernel only if
From: Tony Krowiak
Introduces two new VM crypto device attributes (KVM_S390_VM_CRYPTO)
to enable or disable AP instruction interpretation from userspace
via the KVM_SET_DEVICE_ATTR ioctl:
* The KVM_S390_VM_CRYPTO_ENABLE_APIE attribute enables hardware
interpretation of AP instructions
From: Tony Krowiak
This patch provides documentation describing the AP architecture and
design concepts behind the virtualization of AP devices. It also
includes an example of how to configure AP devices for exclusive
use of KVM guests.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
From: Tony Krowiak
Introduces a new CPU model feature and two CPU model
facilities to support AP virtualization for KVM guests.
CPU model feature:
The KVM_S390_VM_CPU_FEAT_AP feature indicates that
AP instructions are available on the guest. This
feature will be enabled by the kernel only if
From: Pierre Morel
When the guest schedules a SIE with a FORMAT-0 CRYCB,
we are able to schedule it in the host with a FORMAT-1
CRYCB if the host uses FORMAT-1 or FORMAT-0.
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c | 14 ++
1 files
In snd_hdac_bus_init_chip(), we enable interrupt before
snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has
been acquired and irq handler uses the dma buffer, kernel may crash
when interrupt comes in.
Fix the problem by postponing enabling irq after dma buffer
initialization. And warn
From: Pierre Morel
When the host and the guest both use a FORMAT-0 CRYCB,
we copy the guest's FORMAT-0 APCB to a shadow CRYCB
for use by vSIE.
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c | 20 +---
1 files changed, 17 insertions(+), 3
From: Pierre Morel
When the guest schedules a SIE with a FORMAT-0 CRYCB,
we are able to schedule it in the host with a FORMAT-1
CRYCB if the host uses FORMAT-1 or FORMAT-0.
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c | 14 ++
1 files
In snd_hdac_bus_init_chip(), we enable interrupt before
snd_hdac_bus_init_cmd_io() initializing dma buffers. If irq has
been acquired and irq handler uses the dma buffer, kernel may crash
when interrupt comes in.
Fix the problem by postponing enabling irq after dma buffer
initialization. And warn
From: Pierre Morel
When the host and the guest both use a FORMAT-0 CRYCB,
we copy the guest's FORMAT-0 APCB to a shadow CRYCB
for use by vSIE.
Signed-off-by: Pierre Morel
Signed-off-by: Tony Krowiak
---
arch/s390/kvm/vsie.c | 20 +---
1 files changed, 17 insertions(+), 3
301 - 400 of 1468 matches
Mail list logo
