Re: [PATCH] iio staging: tsl2x7x: clean up limit checks

On Tue, Sep 05, 2017 at 05:02:55PM -0400, Brian Masney wrote: > On Tue, Sep 05, 2017 at 05:58:54PM +0300, Dan Carpenter wrote: > > On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote: > > > On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote: > > > > On Mon, 21 Aug 2017

Re: [PATCH] iio staging: tsl2x7x: clean up limit checks

On Tue, Sep 05, 2017 at 05:02:55PM -0400, Brian Masney wrote: > On Tue, Sep 05, 2017 at 05:58:54PM +0300, Dan Carpenter wrote: > > On Sun, Sep 03, 2017 at 10:12:46PM -0400, Brian Masney wrote: > > > On Sun, Sep 03, 2017 at 12:35:05PM +0100, Jonathan Cameron wrote: > > > > On Mon, 21 Aug 2017

Re: [PATCH v2 25/40] tracing: Add support for dynamic tracepoints

- On Sep 5, 2017, at 5:57 PM, Tom Zanussi tom.zanu...@linux.intel.com wrote: > The tracepoint infrastructure assumes statically-defined tracepoints > and uses static_keys for tracepoint enablement. In order to define > tracepoints on the fly, we need to have a dynamic counterpart. > > Add a

Re: [PATCH v2 25/40] tracing: Add support for dynamic tracepoints

- On Sep 5, 2017, at 5:57 PM, Tom Zanussi tom.zanu...@linux.intel.com wrote: > The tracepoint infrastructure assumes statically-defined tracepoints > and uses static_keys for tracepoint enablement. In order to define > tracepoints on the fly, we need to have a dynamic counterpart. > > Add a

Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

On Tue, Sep 5, 2017 at 6:13 PM, Łukasz Majewski wrote: > { > clock-frequency = <40>; > pinctrl-names = "default"; > pinctrl-0 = <_i2c1>; > status = "okay"; > > codec: tfa9879@6C { > #sound-dai-cells = <0>; >

Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

On Tue, Sep 5, 2017 at 6:13 PM, Łukasz Majewski wrote: > { > clock-frequency = <40>; > pinctrl-names = "default"; > pinctrl-0 = <_i2c1>; > status = "okay"; > > codec: tfa9879@6C { > #sound-dai-cells = <0>; > compatible

Re: linux-next: manual merge of the pci tree with the net tree

Hi Sinan, On Tue, 5 Sep 2017 18:54:38 -0400 Sinan Kaya wrote: > > On 9/4/2017 12:54 AM, Stephen Rothwell wrote: > > Just a reminder that this conflict still exists. > > I suppose this was a message for Bjorn, right? Correct. It was just a reminder that he may have to

Re: linux-next: manual merge of the pci tree with the net tree

Hi Sinan, On Tue, 5 Sep 2017 18:54:38 -0400 Sinan Kaya wrote: > > On 9/4/2017 12:54 AM, Stephen Rothwell wrote: > > Just a reminder that this conflict still exists. > > I suppose this was a message for Bjorn, right? Correct. It was just a reminder that he may have to tell Linus about the

Re: [GIT PULL] x86/mm changes for v4.14: PCID support, 5-level paging support, Secure Memory Encryption support

On Tue, Sep 5, 2017 at 3:33 PM, Linus Torvalds wrote: > > And one of those 18 is commit 10af6235e0d3 ("x86/mm: Implement PCID > based optimization: try to preserve old TLB entries using PCID"), > which I guess is where the problem might actually start showing up if

Re: [GIT PULL] x86/mm changes for v4.14: PCID support, 5-level paging support, Secure Memory Encryption support

On Tue, Sep 5, 2017 at 3:33 PM, Linus Torvalds wrote: > > And one of those 18 is commit 10af6235e0d3 ("x86/mm: Implement PCID > based optimization: try to preserve old TLB entries using PCID"), > which I guess is where the problem might actually start showing up if > it is pcid. Yup, that's what

Re: [PATCH 1/2] pidmap(2)

On 09/05/17 15:53, Andrew Morton wrote: > On Tue, 5 Sep 2017 22:05:00 +0300 Alexey Dobriyan wrote: > >> Implement system call for bulk retrieveing of pids in binary form. >> >> Using /proc is slower than necessary: 3 syscalls + another 3 for each thread >> + >> converting

Re: [PATCH 1/2] pidmap(2)

On 09/05/17 15:53, Andrew Morton wrote: > On Tue, 5 Sep 2017 22:05:00 +0300 Alexey Dobriyan wrote: > >> Implement system call for bulk retrieveing of pids in binary form. >> >> Using /proc is slower than necessary: 3 syscalls + another 3 for each thread >> + >> converting with atoi(). >> >>

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

On Sun, 3 Sep 2017, Thomas Gleixner wrote: > On Fri, 1 Sep 2017, Chen Yu wrote: > > > This is the major logic to spread the vectors on different CPUs. > > The main idea is to choose the 'idlest' CPU which has assigned > > the least number of vectors as the candidate/hint for the vector > >

Re: [PATCH 4/4][RFC v2] x86/apic: Spread the vectors by choosing the idlest CPU

On Sun, 3 Sep 2017, Thomas Gleixner wrote: > On Fri, 1 Sep 2017, Chen Yu wrote: > > > This is the major logic to spread the vectors on different CPUs. > > The main idea is to choose the 'idlest' CPU which has assigned > > the least number of vectors as the candidate/hint for the vector > >

[PATCH v2 0/2] Dual MMU support for TI DRA7xx DSPs

Hi Joerg, The following is v2 of the patch series that enhances the OMAP IOMMU driver to support the mirror-programming of the two MMUs present within the DSP subsystems on TI DRA7xx/AM57xx family of SoCs. The main changes are to address the review comments on the registration of the MMU devices

[PATCH v2 0/2] Dual MMU support for TI DRA7xx DSPs

Hi Joerg, The following is v2 of the patch series that enhances the OMAP IOMMU driver to support the mirror-programming of the two MMUs present within the DSP subsystems on TI DRA7xx/AM57xx family of SoCs. The main changes are to address the review comments on the registration of the MMU devices

[PATCH v2 2/2] iommu/omap: Add support to program multiple iommus

A client user instantiates and attaches to an iommu_domain to program the OMAP IOMMU associated with the domain. The iommus programmed by a client user are bound with the iommu_domain through the user's device archdata. The OMAP IOMMU driver currently supports only one IOMMU per IOMMU domain per

[PATCH v2 2/2] iommu/omap: Add support to program multiple iommus

A client user instantiates and attaches to an iommu_domain to program the OMAP IOMMU associated with the domain. The iommus programmed by a client user are bound with the iommu_domain through the user's device archdata. The OMAP IOMMU driver currently supports only one IOMMU per IOMMU domain per

[PATCH v2 1/2] iommu/omap: Change the attach detection logic

The OMAP IOMMU driver allows only a single device (eg: a rproc device) to be attached per domain. The current attach detection logic relies on a check for an attached iommu for the respective client device. Change this logic to use the client device pointer instead in preparation for supporting

[PATCH v2 1/2] iommu/omap: Change the attach detection logic

The OMAP IOMMU driver allows only a single device (eg: a rproc device) to be attached per domain. The current attach detection logic relies on a check for an attached iommu for the respective client device. Change this logic to use the client device pointer instead in preparation for supporting

Re: linux-next: manual merge of the pci tree with the net tree

On 9/4/2017 12:54 AM, Stephen Rothwell wrote: > Just a reminder that this conflict still exists. I suppose this was a message for Bjorn, right? I looked at the change and it looked good to me. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.

Re: linux-next: manual merge of the pci tree with the net tree

On 9/4/2017 12:54 AM, Stephen Rothwell wrote: > Just a reminder that this conflict still exists. I suppose this was a message for Bjorn, right? I looked at the change and it looked good to me. -- Sinan Kaya Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.

Re: [PATCH 1/2] pidmap(2)

On Tue, 5 Sep 2017 22:05:00 +0300 Alexey Dobriyan wrote: > Implement system call for bulk retrieveing of pids in binary form. > > Using /proc is slower than necessary: 3 syscalls + another 3 for each thread + > converting with atoi(). > > /proc may be not mounted

Re: [PATCH 1/2] pidmap(2)

On Tue, 5 Sep 2017 22:05:00 +0300 Alexey Dobriyan wrote: > Implement system call for bulk retrieveing of pids in binary form. > > Using /proc is slower than necessary: 3 syscalls + another 3 for each thread + > converting with atoi(). > > /proc may be not mounted especially in containers.

Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

On Tue, Sep 05, 2017 at 11:13:40PM +0200, Łukasz Majewski wrote: > They key point here is the asoc_simple_card_parse_clk() function > from simple-card-utils.c > > Please look how the clock is assigned; It first checks for cpu > clock, then for "system-clock-frequency" DTS node and _finally_ >

Re: [PATCH] sound: soc: fsl: Do not set DAI sysclk when it is equal to system freq

On Tue, Sep 05, 2017 at 11:13:40PM +0200, Łukasz Majewski wrote: > They key point here is the asoc_simple_card_parse_clk() function > from simple-card-utils.c > > Please look how the clock is assigned; It first checks for cpu > clock, then for "system-clock-frequency" DTS node and _finally_ >

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 09/05, Andreas Dilger wrote: > On Sep 5, 2017, at 3:06 PM, Jaegeuk Kim wrote: > > > > This patch fixes bavail and bfree finally. > > > > longf_bfree;/* free blocks in fs */ > > longf_bavail; /* free blocks avail to non-superuser */ > > > > So, bfree

Re: [PATCH] f2fs: fix wrong bfree and bavail

On 09/05, Andreas Dilger wrote: > On Sep 5, 2017, at 3:06 PM, Jaegeuk Kim wrote: > > > > This patch fixes bavail and bfree finally. > > > > longf_bfree;/* free blocks in fs */ > > longf_bavail; /* free blocks avail to non-superuser */ > > > > So, bfree represents all the reserved

[PATCH 0/9] add ext4 per-inode DAX flag

The original intent of this series was to add a per-inode DAX flag to ext4 so that it would be consistent with XFS. In my travels I found and fixed several related issues in both ext4 and XFS. I'm not fully happy with the ways that ext4 DAX interacts with conflicting features (journaling, inline

[PATCH 0/9] add ext4 per-inode DAX flag

The original intent of this series was to add a per-inode DAX flag to ext4 so that it would be consistent with XFS. In my travels I found and fixed several related issues in both ext4 and XFS. I'm not fully happy with the ways that ext4 DAX interacts with conflicting features (journaling, inline

[PATCH 6/9] ext4: safely transition S_DAX on journaling changes

The IOCTL path which switches the journaling mode for an inode is currently unsafe because it doesn't properly do a writeback and invalidation on the inode. In XFS, for example, safe transitions of S_DAX are handled by xfs_ioctl_setattr_dax_invalidate() which locks out page faults and I/O, does a

[PATCH 6/9] ext4: safely transition S_DAX on journaling changes

The IOCTL path which switches the journaling mode for an inode is currently unsafe because it doesn't properly do a writeback and invalidation on the inode. In XFS, for example, safe transitions of S_DAX are handled by xfs_ioctl_setattr_dax_invalidate() which locks out page faults and I/O, does a

[PATCH 7/9] ext4: prevent data corruption with inline data + DAX

If an inode has inline data it is currently prevented from using DAX by a check in ext4_should_use_dax(). When the inode grows inline data via ext4_create_inline_data() or removes its inline data via ext4_destroy_inline_data_nolock(), the value of S_DAX can change. Currently these changes are

[PATCH 7/9] ext4: prevent data corruption with inline data + DAX

If an inode has inline data it is currently prevented from using DAX by a check in ext4_should_use_dax(). When the inode grows inline data via ext4_create_inline_data() or removes its inline data via ext4_destroy_inline_data_nolock(), the value of S_DAX can change. Currently these changes are

[PATCH 5/9] ext4: ext4_change_inode_journal_flag error handling

Rework the error handling in ext4_change_inode_journal_flag() so that multiple paths can re-use portions of the same cleanup code via gotos instead of each path doing their own cleanup. This will benefit later patches that add more paths to this function that must be unwound on error.

[PATCH 5/9] ext4: ext4_change_inode_journal_flag error handling

Rework the error handling in ext4_change_inode_journal_flag() so that multiple paths can re-use portions of the same cleanup code via gotos instead of each path doing their own cleanup. This will benefit later patches that add more paths to this function that must be unwound on error.

[PATCH 8/9] ext4: add sanity check for encryption + DAX

We prevent DAX from being used on inodes which are using ext4's built in encryption via a check in ext4_should_use_dax(). We do have what appears to be an unsafe transition of S_DAX in ext4_set_context(), though, where S_DAX can get disabled without us doing a proper writeback + invalidate. I

[PATCH 8/9] ext4: add sanity check for encryption + DAX

We prevent DAX from being used on inodes which are using ext4's built in encryption via a check in ext4_should_use_dax(). We do have what appears to be an unsafe transition of S_DAX in ext4_set_context(), though, where S_DAX can get disabled without us doing a proper writeback + invalidate. I

[PATCH 4/9] ext4: add ext4_should_use_dax()

This helper, in the spirit of ext4_should_dioread_nolock() et al., replaces the complex conditional in ext4_set_inode_flags() and will soon be called in multiple places. Signed-off-by: Ross Zwisler --- fs/ext4/ext4_jbd2.h | 15 +++ fs/ext4/inode.c |

[PATCH 9/9] ext4: add per-inode DAX flag

Follow the lead of XFS and add a per-inode flag that allows the choice of whether or not to use DAX to be made for individual files. As with XFS this flag can also be set on a directory, in which case it will be inherited by new inodes (both subdirectories and files) created within that

[PATCH 4/9] ext4: add ext4_should_use_dax()

This helper, in the spirit of ext4_should_dioread_nolock() et al., replaces the complex conditional in ext4_set_inode_flags() and will soon be called in multiple places. Signed-off-by: Ross Zwisler --- fs/ext4/ext4_jbd2.h | 15 +++ fs/ext4/inode.c | 4 +--- 2 files changed, 16

[PATCH 9/9] ext4: add per-inode DAX flag

Follow the lead of XFS and add a per-inode flag that allows the choice of whether or not to use DAX to be made for individual files. As with XFS this flag can also be set on a directory, in which case it will be inherited by new inodes (both subdirectories and files) created within that

[PATCH 2/9] xfs: always use DAX if mount option is used

The current code has an issue where the user can't reliably tell whether or not DAX is being used to service page faults and I/O when the DAX mount option is used. In this case each inode within the mounted filesystem starts with S_DAX set due to the mount option, but it can be cleared if someone

[PATCH 1/9] ext4: remove duplicate extended attributes defs

The following commit: commit 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support") added several defines related to extended attributes to ext4.h. They were added within an #ifndef FS_IOC_FSGETXATTR block with the comment: /* Until the uapi changes get merged for

[PATCH 2/9] xfs: always use DAX if mount option is used

The current code has an issue where the user can't reliably tell whether or not DAX is being used to service page faults and I/O when the DAX mount option is used. In this case each inode within the mounted filesystem starts with S_DAX set due to the mount option, but it can be cleared if someone

[PATCH 1/9] ext4: remove duplicate extended attributes defs

The following commit: commit 9b7365fc1c82 ("ext4: add FS_IOC_FSSETXATTR/FS_IOC_FSGETXATTR interface support") added several defines related to extended attributes to ext4.h. They were added within an #ifndef FS_IOC_FSGETXATTR block with the comment: /* Until the uapi changes get merged for

[PATCH 3/9] xfs: validate bdev support for DAX inode flag

Currently only the blocksize is checked, but we should really be calling bdev_dax_supported() which also tests to make sure we can get a struct dax_device and that the dax_direct_access() path is working. This is the same check that we do for the "-o dax" mount option in xfs_fs_fill_super().

[PATCH 3/9] xfs: validate bdev support for DAX inode flag

Currently only the blocksize is checked, but we should really be calling bdev_dax_supported() which also tests to make sure we can get a struct dax_device and that the dax_direct_access() path is working. This is the same check that we do for the "-o dax" mount option in xfs_fs_fill_super().

Re: [GIT PULL] x86/mm changes for v4.14: PCID support, 5-level paging support, Secure Memory Encryption support

On Tue, Sep 5, 2017 at 3:33 PM, Linus Torvalds wrote: > On Tue, Sep 5, 2017 at 2:45 PM, Linus Torvalds > wrote: >> >> I have bisected a bit deeper, and the pcid code is definitely in that >> bisection window still. But are a fair

Re: [GIT PULL] x86/mm changes for v4.14: PCID support, 5-level paging support, Secure Memory Encryption support

On Tue, Sep 5, 2017 at 3:33 PM, Linus Torvalds wrote: > On Tue, Sep 5, 2017 at 2:45 PM, Linus Torvalds > wrote: >> >> I have bisected a bit deeper, and the pcid code is definitely in that >> bisection window still. But are a fair number of other commits (about >> 160 right now) > > Now down to

Re: [GIT PULL] x86/mm changes for v4.14: PCID support, 5-level paging support, Secure Memory Encryption support

On Tue, Sep 5, 2017 at 2:45 PM, Linus Torvalds wrote: > > I have bisected a bit deeper, and the pcid code is definitely in that > bisection window still. But are a fair number of other commits (about > 160 right now) Now down to 18. And one of those 18 is commit

Re: [GIT PULL] x86/mm changes for v4.14: PCID support, 5-level paging support, Secure Memory Encryption support

On Tue, Sep 5, 2017 at 2:45 PM, Linus Torvalds wrote: > > I have bisected a bit deeper, and the pcid code is definitely in that > bisection window still. But are a fair number of other commits (about > 160 right now) Now down to 18. And one of those 18 is commit 10af6235e0d3 ("x86/mm: Implement

[PATCH v2 01/40] tracing: Exclude 'generic fields' from histograms

There are a small number of 'generic fields' (comm/COMM/cpu/CPU) that are found by trace_find_event_field() but are only meant for filtering. Specifically, they unlike normal fields, they have a size of 0 and thus wreak havoc when used as a histogram key. Exclude these (return -EINVAL) when used

[PATCH v2 01/40] tracing: Exclude 'generic fields' from histograms

There are a small number of 'generic fields' (comm/COMM/cpu/CPU) that are found by trace_find_event_field() but are only meant for filtering. Specifically, they unlike normal fields, they have a size of 0 and thus wreak havoc when used as a histogram key. Exclude these (return -EINVAL) when used

[PATCH v2 03/40] tracing: Remove code which merges duplicates

From: Vedang Patel We now have the logic to detect and remove duplicates in the tracing_map hash table. The code which merges duplicates in the histogram is redundant now. So, modify this code just to detect duplicates. The duplication detection code is still kept to

[PATCH v2 03/40] tracing: Remove code which merges duplicates

From: Vedang Patel We now have the logic to detect and remove duplicates in the tracing_map hash table. The code which merges duplicates in the histogram is redundant now. So, modify this code just to detect duplicates. The duplication detection code is still kept to ensure that any rare race

[PATCH v2 06/40] ring-buffer: Add interface for setting absolute time stamps

Define a new function, tracing_set_time_stamp_abs(), which can be used to enable or disable the use of absolute timestamps rather than time deltas for a trace array. This resets the buffer to prevent a mix of time deltas and absolute timestamps. Only the interface is added here; a subsequent

[PATCH v2 06/40] ring-buffer: Add interface for setting absolute time stamps

Define a new function, tracing_set_time_stamp_abs(), which can be used to enable or disable the use of absolute timestamps rather than time deltas for a trace array. This resets the buffer to prevent a mix of time deltas and absolute timestamps. Only the interface is added here; a subsequent

[PATCH v2 05/40] tracing: Reimplement log2

log2 as currently implemented applies only to u64 trace_event_field derived fields, and assumes that anything it's applied to is a u64 field. To prepare for synthetic fields like latencies, log2 should be applicable to those as well, so take the opportunity now to fix the current problems as well

[PATCH v2 05/40] tracing: Reimplement log2

log2 as currently implemented applies only to u64 trace_event_field derived fields, and assumes that anything it's applied to is a u64 field. To prepare for synthetic fields like latencies, log2 should be applicable to those as well, so take the opportunity now to fix the current problems as well

[PATCH v2 04/40] tracing: Add hist_field_name() accessor

In preparation for hist_fields that won't be strictly based on trace_event_fields, add a new hist_field_name() accessor to allow that flexibility and update associated users. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 67

[PATCH v2 10/40] tracing: Add ring buffer event param to hist field functions

Some events such as timestamps require access to a ring_buffer_event struct; add a param so that hist field functions can access that. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 39 --- 1 file changed, 24

[PATCH v2 04/40] tracing: Add hist_field_name() accessor

In preparation for hist_fields that won't be strictly based on trace_event_fields, add a new hist_field_name() accessor to allow that flexibility and update associated users. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 67 +++- 1 file

[PATCH v2 10/40] tracing: Add ring buffer event param to hist field functions

Some events such as timestamps require access to a ring_buffer_event struct; add a param so that hist field functions can access that. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 39 --- 1 file changed, 24 insertions(+), 15 deletions(-)

[PATCH v2 08/40] ring-buffer: Redefine the unimplemented RINGBUF_TIME_TIME_STAMP

RINGBUF_TYPE_TIME_STAMP is defined but not used, and from what I can gather was reserved for something like an absolute timestamp feature for the ring buffer, if not a complete replacement of the current time_delta scheme. This code redefines RINGBUF_TYPE_TIME_STAMP to implement absolute time

[PATCH v2 11/40] tracing: Increase tracing map KEYS_MAX size

The current default for the number of subkeys in a compound key is 2, which is too restrictive. Increase it to a more realistic value of 3. Signed-off-by: Tom Zanussi --- kernel/trace/tracing_map.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v2 08/40] ring-buffer: Redefine the unimplemented RINGBUF_TIME_TIME_STAMP

RINGBUF_TYPE_TIME_STAMP is defined but not used, and from what I can gather was reserved for something like an absolute timestamp feature for the ring buffer, if not a complete replacement of the current time_delta scheme. This code redefines RINGBUF_TYPE_TIME_STAMP to implement absolute time

[PATCH v2 11/40] tracing: Increase tracing map KEYS_MAX size

The current default for the number of subkeys in a compound key is 2, which is too restrictive. Increase it to a more realistic value of 3. Signed-off-by: Tom Zanussi --- kernel/trace/tracing_map.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/trace/tracing_map.h

[PATCH v2 14/40] tracing: Add hist trigger timestamp support

Add support for a timestamp event field. This is actually a 'pseudo-' event field in that it behaves like it's part of the event record, but is really part of the corresponding ring buffer event. To make use of the timestamp field, users can specify "$common_timestamp" as a field name for any

[PATCH v2 14/40] tracing: Add hist trigger timestamp support

Add support for a timestamp event field. This is actually a 'pseudo-' event field in that it behaves like it's part of the event record, but is really part of the corresponding ring buffer event. To make use of the timestamp field, users can specify "$common_timestamp" as a field name for any

Re: [RFC Part2 PATCH v3 01/26] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)

On Tue, Sep 05, 2017 at 04:39:14PM -0500, Brijesh Singh wrote: > I was trying map with SEV firmware spec command names but I see your > point and will call it "KVM_SEV_GET_GUEST_STATUS". > > > > > + > > > +enum { > > > + /* guest state is not known */ > > > + SEV_STATE_INVALID = 0; > > > > not

Re: [RFC Part2 PATCH v3 01/26] Documentation/virtual/kvm: Add AMD Secure Encrypted Virtualization (SEV)

On Tue, Sep 05, 2017 at 04:39:14PM -0500, Brijesh Singh wrote: > I was trying map with SEV firmware spec command names but I see your > point and will call it "KVM_SEV_GET_GUEST_STATUS". > > > > > + > > > +enum { > > > + /* guest state is not known */ > > > + SEV_STATE_INVALID = 0; > > > > not

[PATCH v2 15/40] tracing: Add per-element variable support to tracing_map

In order to allow information to be passed between trace events, add support for per-element variables to tracing_map. This provides a means for histograms to associate a value or values with an entry when it's saved or updated, and retrieved by a subsequent event occurrences. Variables can be

[PATCH v2 15/40] tracing: Add per-element variable support to tracing_map

In order to allow information to be passed between trace events, add support for per-element variables to tracing_map. This provides a means for histograms to associate a value or values with an entry when it's saved or updated, and retrieved by a subsequent event occurrences. Variables can be

[PATCH v2 12/40] tracing: Break out hist trigger assignment parsing

This will make it easier to add variables, and makes the parsing code cleaner regardless. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 56 +--- 1 file changed, 35 insertions(+), 21 deletions(-) diff --git

[PATCH v2 12/40] tracing: Break out hist trigger assignment parsing

This will make it easier to add variables, and makes the parsing code cleaner regardless. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 56 +--- 1 file changed, 35 insertions(+), 21 deletions(-) diff --git

[PATCH v2 16/40] tracing: Add hist_data member to hist_field

Allow hist_data access via hist_field. Some users of hist_fields require or will require more access to the associated hist_data. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-)

[PATCH v2 16/40] tracing: Add hist_data member to hist_field

Allow hist_data access via hist_field. Some users of hist_fields require or will require more access to the associated hist_data. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git

[PATCH v2 18/40] tracing: Add variable support to hist triggers

Add support for saving the value of a current event's event field by assigning it to a variable that can be read by a subsequent event. The basic syntax for saving a variable is to simply prefix a unique variable name not corresponding to any keyword along with an '=' sign to any event field.

[PATCH v2 18/40] tracing: Add variable support to hist triggers

Add support for saving the value of a current event's event field by assigning it to a variable that can be read by a subsequent event. The basic syntax for saving a variable is to simply prefix a unique variable name not corresponding to any keyword along with an '=' sign to any event field.

[PATCH v2 21/40] tracing: Generalize per-element hist trigger data

Up until now, hist triggers only needed per-element support for saving 'comm' data, which was saved directly as a private data pointer. In anticipation of the need to save other data besides 'comm', add a new hist_elt_data struct for the purpose, and switch the current 'comm'-related code over to

[PATCH v2 21/40] tracing: Generalize per-element hist trigger data

Up until now, hist triggers only needed per-element support for saving 'comm' data, which was saved directly as a private data pointer. In anticipation of the need to save other data besides 'comm', add a new hist_elt_data struct for the purpose, and switch the current 'comm'-related code over to

[PATCH v2 19/40] tracing: Account for variables in named trigger compatibility

Named triggers must also have the same set of variables in order to be considered compatible - update the trigger match test to account for that. The reason for this requirement is that named triggers with variables are meant to allow one or more events to set the same variable. Signed-off-by:

[PATCH v2 19/40] tracing: Account for variables in named trigger compatibility

Named triggers must also have the same set of variables in order to be considered compatible - update the trigger match test to account for that. The reason for this requirement is that named triggers with variables are meant to allow one or more events to set the same variable. Signed-off-by:

[PATCH v2 22/40] tracing: Pass tracing_map_elt to hist_field accessor functions

Some accessor functions, such as for variable references, require access to a corrsponding tracing_map_elt. Add a tracing_map_elt param to the function signature and update the accessor functions accordingly. Signed-off-by: Tom Zanussi ---

[PATCH v2 30/40] tracing: Add 'onmax' hist trigger action support

Add an 'onmax(var).save(field,...)' hist trigger action which is invoked whenever an event exceeds the current maximum. The end result is that the trace event fields or variables specified as the onmax.save() params will be saved if 'var' exceeds the current maximum for that hist trigger entry.

[PATCH v2 22/40] tracing: Pass tracing_map_elt to hist_field accessor functions

Some accessor functions, such as for variable references, require access to a corrsponding tracing_map_elt. Add a tracing_map_elt param to the function signature and update the accessor functions accordingly. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 91

[PATCH v2 30/40] tracing: Add 'onmax' hist trigger action support

Add an 'onmax(var).save(field,...)' hist trigger action which is invoked whenever an event exceeds the current maximum. The end result is that the trace event fields or variables specified as the onmax.save() params will be saved if 'var' exceeds the current maximum for that hist trigger entry.

[PATCH v2 24/40] tracing: Add variable reference handling to hist triggers

Add the necessary infrastructure to allow the variables defined on one event to be referenced in another. This allows variables set by a previous event to be referenced and used in expressions combining the variable values saved by that previous event and the event fields of the current event.

[PATCH v2 24/40] tracing: Add variable reference handling to hist triggers

Add the necessary infrastructure to allow the variables defined on one event to be referenced in another. This allows variables set by a previous event to be referenced and used in expressions combining the variable values saved by that previous event and the event fields of the current event.

[PATCH v2 26/40] tracing: Add hist trigger action hook

Add a hook for executing extra actions whenever a histogram entry is added or updated. The default 'action' when a hist entry is added to a histogram is to update the set of values associated with it. Some applications may want to perform additional actions at that point, such as generate

[PATCH v2 26/40] tracing: Add hist trigger action hook

Add a hook for executing extra actions whenever a histogram entry is added or updated. The default 'action' when a hist entry is added to a histogram is to update the set of values associated with it. Some applications may want to perform additional actions at that point, such as generate

[PATCH v2 31/40] tracing: Allow whitespace to surround hist trigger filter

The existing code only allows for one space before and after the 'if' specifying the filter for a hist trigger. Add code to make that more permissive as far as whitespace goes. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 19 +++

[PATCH v2 31/40] tracing: Allow whitespace to surround hist trigger filter

The existing code only allows for one space before and after the 'if' specifying the filter for a hist trigger. Add code to make that more permissive as far as whitespace goes. Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 19 +++ 1 file changed, 15

[PATCH v2 32/40] tracing: Add cpu field for hist triggers

A common key to use in a histogram is the cpuid - add a new cpu 'synthetic' field for that purpose. This field is named cpu rather than $cpu or $common_cpu because 'cpu' already exists as a special filter field and it makes more sense to match that rather than add another name for the same thing.

[PATCH v2 32/40] tracing: Add cpu field for hist triggers

A common key to use in a histogram is the cpuid - add a new cpu 'synthetic' field for that purpose. This field is named cpu rather than $cpu or $common_cpu because 'cpu' already exists as a special filter field and it makes more sense to match that rather than add another name for the same thing.

[PATCH v2 33/40] tracing: Add hist trigger support for variable reference aliases

Add support for alias=$somevar where alias can be used as onmatch($alias). Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 61 ++-- 1 file changed, 58 insertions(+), 3 deletions(-) diff --git

[PATCH v2 33/40] tracing: Add hist trigger support for variable reference aliases

Add support for alias=$somevar where alias can be used as onmatch($alias). Signed-off-by: Tom Zanussi --- kernel/trace/trace_events_hist.c | 61 ++-- 1 file changed, 58 insertions(+), 3 deletions(-) diff --git a/kernel/trace/trace_events_hist.c

[PATCH v2 34/40] tracing: Add 'last error' error facility for hist triggers

With the addition of variables and actions, it's become necessary to provide more detailed error information to users about syntax errors. Add a 'last error' facility accessible via the erroring event's 'hist' file. Reading the hist file after an error will display more detailed information

[PATCH v2 34/40] tracing: Add 'last error' error facility for hist triggers

With the addition of variables and actions, it's become necessary to provide more detailed error information to users about syntax errors. Add a 'last error' facility accessible via the erroring event's 'hist' file. Reading the hist file after an error will display more detailed information

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