On Thu, Oct 05, 2023 at 12:24:03PM -0400, Kris Van Hees wrote:
> On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat)
> wrote:
> > It is not uncommon for drivers or modules related to similar peripherals
> > to have symbols with the exact same name.
> > While this is not a
On Thu, Oct 05, 2023 at 03:55:20PM +0530, Krishna chaitanya chundru wrote:
> This change adds ftrace support for following:
> 1. mhi_intvec_threaded_handler
> 2. mhi_process_data_event_ring
> 3. mhi_process_ctrl_ev_ring
> 4. mhi_gen_tre
> 5. mhi_update_channel_state
> 6. mhi_tryset_pm_state
> 7.
Hi Jo,
Just FYI I won't review the rest patches in this series. One of the reasons is
I am not that familiar with the rest. Jarkko has reviewed anyway :-).
On Thu, 2023-10-05 at 17:38 +0200, Jo Van Bulck wrote:
> Hi,
>
> This patch series ensures that all SGX selftests succeed when compiling
Vishal Verma wrote:
> The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
> 'memblock_size' chunks of memory being added. Adding a larger span of
> memory precludes memmap_on_memory semantics.
>
> For users of hotplug such as kmem, large amounts of memory might get
> added from
Vishal Verma wrote:
> Large amounts of memory managed by the kmem driver may come in via CXL,
> and it is often desirable to have the memmap for this memory on the new
> memory itself.
>
> Enroll kmem-managed memory for memmap_on_memory semantics if the dax
> region originates via CXL. For
> ---
> arch/x86/Kconfig | 13 +
> arch/x86/kernel/cpu/sgx/Makefile | 1 +
> arch/x86/kernel/cpu/sgx/epc_cgroup.c | 415 +++
> arch/x86/kernel/cpu/sgx/epc_cgroup.h | 59
> arch/x86/kernel/cpu/sgx/main.c | 68 -
>
On Thu, 2023-10-05 at 14:33 -0500, Haitao Huang wrote:
> On Thu, 05 Oct 2023 07:30:46 -0500, Huang, Kai wrote:
>
> > On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> > > +static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct
> > > sgx_epc_page *epc_page)
> > > +{
> > > + return
> > >
> > > -/*
> > > +/**
> > > + * sgx_reclaim_epc_pages() - Reclaim EPC pages from the consumers
> > > + * @nr_to_scan: Number of EPC pages to scan for reclaim
> > > + * @ignore_age: Reclaim a page even if it is young
> > > + *
> > > * Take a fixed number of pages from
On Thu, 05 Oct 2023 07:30:46 -0500, Huang, Kai wrote:
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
+static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct
sgx_epc_page *epc_page)
+{
+ return _global_lru;
+}
+
+static inline bool sgx_can_reclaim(void)
+{
+ return
On Thu, 05 Oct 2023 07:24:12 -0500, Huang, Kai wrote:
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
From: Sean Christopherson
Adjust and expose the top-level reclaim function as
sgx_reclaim_epc_pages() for use by the upcoming EPC cgroup, which will
initiate reclaim to enforce the
On 10/5/2023 8:28 PM, Wilczynski, Michal wrote:
>
> On 10/5/2023 7:57 PM, Rafael J. Wysocki wrote:
>> On Monday, September 25, 2023 4:48:35 PM CEST Michal Wilczynski wrote:
>>> Some devices implement ACPI driver as a way to manage devices
>>> enumerated by the ACPI. This might be confusing as a
The MHP_MEMMAP_ON_MEMORY flag for hotplugged memory is restricted to
'memblock_size' chunks of memory being added. Adding a larger span of
memory precludes memmap_on_memory semantics.
For users of hotplug such as kmem, large amounts of memory might get
added from the CXL subsystem. In some cases,
The dax/kmem driver can potentially hot-add large amounts of memory
originating from CXL memory expanders, or NVDIMMs, or other 'device
memories'. There is a chance there isn't enough regular system memory
available to fit the memmap for this new memory. It's therefore
desirable, if all other
Large amounts of memory managed by the kmem driver may come in via CXL,
and it is often desirable to have the memmap for this memory on the new
memory itself.
Enroll kmem-managed memory for memmap_on_memory semantics if the dax
region originates via CXL. For non-CXL dax regions, retain the
On Thu, Oct 5, 2023 at 8:27 PM Wilczynski, Michal
wrote:
>
>
>
> On 10/5/2023 7:03 PM, Rafael J. Wysocki wrote:
> > On Thursday, October 5, 2023 5:30:59 PM CEST Rafael J. Wysocki wrote:
> >> On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
> >> wrote:
> >>> On 10/5/2023 12:57 PM, Rafael J.
On 10/5/2023 7:57 PM, Rafael J. Wysocki wrote:
> On Monday, September 25, 2023 4:48:35 PM CEST Michal Wilczynski wrote:
>> Some devices implement ACPI driver as a way to manage devices
>> enumerated by the ACPI. This might be confusing as a preferred way to
>> implement a driver for devices not
On 10/5/2023 7:03 PM, Rafael J. Wysocki wrote:
> On Thursday, October 5, 2023 5:30:59 PM CEST Rafael J. Wysocki wrote:
>> On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
>> wrote:
>>> On 10/5/2023 12:57 PM, Rafael J. Wysocki wrote:
On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
Hello Dinghao,
On 01.10.23 09:19, kernel test robot wrote:
Hi Dinghao,
kernel test robot noticed the following build warnings:
[auto build test WARNING on linus/master]
[also build test WARNING on v6.6-rc3 next-20230929]
[If your patch is applied to the wrong git tree, kindly drop us a note.
On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> +/**
> + * struct execmem_range - definition of a memory range suitable for
> code and
> + * related data allocations
> + * @start: address space start
> + * @end: address space end (inclusive)
> + * @pgprot:
On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote:
> On Wed, Oct 04, 2023 at 03:39:26PM +, Edgecombe, Rick P wrote:
> > On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> > > It seems a bit weird to copy all of this. Is it trying to be
> > > faster
> > > or
> > > something?
> > >
On Monday, September 25, 2023 4:48:35 PM CEST Michal Wilczynski wrote:
> Some devices implement ACPI driver as a way to manage devices
> enumerated by the ACPI. This might be confusing as a preferred way to
> implement a driver for devices not connected to any bus is a platform
> driver, as stated
On Thursday, October 5, 2023 5:30:59 PM CEST Rafael J. Wysocki wrote:
> On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
> wrote:
> > On 10/5/2023 12:57 PM, Rafael J. Wysocki wrote:
> > > On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
> > > wrote:
>
> [cut]
>
> > >>>
> > >>> That said,
Hi Krishna,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 3006adf3be79cde4d14b1800b963b82b6e5572e0]
url:
https://github.com/intel-lab-lkp/linux/commits/Krishna-chaitanya-chundru/bus-mhi-host-Add-tracing-support/20231005-231430
base
As the selftest enclave is *not* intended for production, simplify the
code by not initializing CPU configuration registers as expected by the
ABI on enclave entry or cleansing caller-save registers on enclave exit.
Link:
Attach the "used" attribute to instruct the compiler to preserve the static
encl_buffer, even if it appears it is not entirely referenced in the enclave
code, as expected by the external tests manipulating page permissions.
Link:
On Wed, Sep 27, 2023 at 05:35:16PM +, Alessandro Carminati (Red Hat) wrote:
> It is not uncommon for drivers or modules related to similar peripherals
> to have symbols with the exact same name.
> While this is not a problem for the kernel's binary itself, it becomes an
> issue when attempting
DEFINED only considers symbols, not section names. Hence, replace the
check for .got.plt with the _GLOBAL_OFFSET_TABLE_ symbol and remove other
(non-essential) asserts.
Signed-off-by: Jo Van Bulck
Reviewed-by: Jarkko Sakkinen
---
tools/testing/selftests/sgx/test_encl.lds | 6 +-
1 file
The current combination of -static and -fPIC creates a static executable
with position-dependent addresses for global variables. Use -static-pie
and -fPIE to create a proper static position independent executable that
can be loaded at any address without a dynamic linker.
When building the
Remove redundant push/pop pair that stores and restores the enclave base
address in the test enclave, as it is never used after the pop and can
anyway be easily retrieved via the __encl_base symbol.
Signed-off-by: Jo Van Bulck
Reviewed-by: Jarkko Sakkinen
Acked-by: Kai Huang
---
Fixes "'linker' input unused [-Wunused-command-line-argument]" errors when
compiling with clang.
Signed-off-by: Jo Van Bulck
Reviewed-by: Jarkko Sakkinen
---
tools/testing/selftests/sgx/Makefile | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git
Ensure sym_tab and sym_names are zero-initialized and add an early-out
condition in the unlikely (erroneous) case that the enclave ELF file would
not contain a symbol table.
This addresses -Werror=maybe-uninitialized compiler warnings for gcc -O2.
Fixes: 33c5aac3bf32 ("selftests/sgx: Test
Static-pie binaries normally include a startup routine to perform any ELF
relocations from .rela.dyn. Since the enclave loading process is different
and glibc is not included, do the necessary relocation for encl_op_array
entries manually at runtime relative to the enclave base to ensure correct
Add the "memory" clobber to the EMODPE and EACCEPT asm blocks to tell the
compiler the assembly code accesses to the secinfo struct. This ensures
the compiler treats the asm block as a memory barrier and the write to
secinfo will be visible to ENCLU.
Fixes: 20404a808593 ("selftests/sgx: Add test
Building the test enclave with -static-pie may produce a dynamic symbol
table, but this is not supported for enclaves and any relocations need to
happen manually (e.g., as for "encl_op_array"). Thus, opportunistically
discard ".dyn*" and ".gnu.hash" which the enclave loader cannot handle.
Hi,
This patch series ensures that all SGX selftests succeed when compiling with
optimizations (as tested with -O{0,1,2,3,s} for both gcc 11.3.0 and clang
14.0.0). The aim of the patches is to avoid reliance on undefined,
compiler-specific behavior that can make the test results fragile.
As far
Ensure ctx is zero-initialized, such that the encl_measure function will
not call EVP_MD_CTX_destroy with an uninitialized ctx pointer in case of an
early error during key generation.
Fixes: 2adcba79e69d ("selftests/x86: Add a selftest for SGX")
Signed-off-by: Jo Van Bulck
Reviewed-by: Jarkko
Use -ffreestanding to assert the enclave compilation targets a
freestanding environment (i.e., without "main" or standard libraries).
This fixes clang reporting "undefined reference to `memset'" after
erroneously optimizing away the provided memset/memcpy implementations.
Still need to instruct
The external tests manipulating page permissions expect encl_buffer to be
placed at the start of the test enclave's .data section. As this is not
guaranteed per the C standard, explicitly place encl_buffer in a separate
section that is explicitly placed at the start of the .data segment in the
On Mon, 02 Oct 2023 09:00:11 +0200, Luca Weiss wrote:
> There's not much point in having unused labels in the binding example,
> so drop them.
>
> This patch was originally motivated by ea25d61b448a ("arm64: dts: qcom:
> Use plural _gpios node label for PMIC gpios") updating all dts files to
>
On Thu, Oct 5, 2023 at 2:05 PM Wilczynski, Michal
wrote:
> On 10/5/2023 12:57 PM, Rafael J. Wysocki wrote:
> > On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
> > wrote:
[cut]
> >>>
> >>> That said, why exactly is it better to use acpi_handle instead of a
> >>> struct acpi_device pointer?
>
The default MODLIB value is composed of two variables and the hardcoded
string '/lib/modules/'.
MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
Defining this middle part as a variable was rejected on the basis that
users can pass the whole MODLIB to make, such as
make
On Wed, 2023-10-04 at 23:22 -0500, Haitao Huang wrote:
> On Wed, 04 Oct 2023 16:13:41 -0500, Huang, Kai wrote:
>
> > On Wed, 2023-10-04 at 10:03 -0500, Haitao Huang wrote:
> > > On Tue, 03 Oct 2023 15:07:42 -0500, Huang, Kai
> > > wrote:
> > >
> > > > On Tue, 2023-10-03 at 01:45 -0500,
>> Is this fine?
>> Should I send a V2 with the signoff and reserved-memory changes?
>I don't quite get it, what signoff?
Krzysztof noticed that the Signed-off-by are in the wrong order.
But I was told this alone is not worth a V2.
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> From: Sean Christopherson
>
> Adjust and expose the top-level reclaim function as
> sgx_reclaim_epc_pages() for use by the upcoming EPC cgroup, which will
> initiate reclaim to enforce the max limit.
>
> Make these adjustments to the
On Wed, 04 Oct 2023 16:13:41 -0500, Huang, Kai wrote:
On Wed, 2023-10-04 at 10:03 -0500, Haitao Huang wrote:
On Tue, 03 Oct 2023 15:07:42 -0500, Huang, Kai
wrote:
> On Tue, 2023-10-03 at 01:45 -0500, Haitao Huang wrote:
> > >
> > > Btw, probably a dumb question:
> > >
> > > Theoretically
On Fri, 2023-09-22 at 20:06 -0700, Haitao Huang wrote:
> +static inline struct sgx_epc_lru_lists *sgx_lru_lists(struct sgx_epc_page
> *epc_page)
> +{
> + return _global_lru;
> +}
> +
> +static inline bool sgx_can_reclaim(void)
> +{
> + return !list_empty(_global_lru.reclaimable);
> +}
> +
On Wed, Oct 04, 2023 at 02:55:47PM +0200, Artem Savkov wrote:
> On Tue, Oct 03, 2023 at 09:38:44PM -0400, Steven Rostedt wrote:
> > On Mon, 2 Oct 2023 15:52:42 +0200
> > Artem Savkov wrote:
> >
> > > linux-rt-devel tree contains a patch that adds an extra member to struct
> > > trace_entry.
+
+ TP_ARGS(name, state),
+
+ TP_STRUCT__entry(
+ __string(name, name)
+ __string(state, state)
+ ),
+
+ TP_fast_assign(
+ __assign_str(name, name);
+ __assign_str(state, state);
+ ),
+
+ TP_printk("%s: Handling state transition: %s\n", __get_str(name),
__get_str(state))
+);
+
+#endif
+#include
---
base-commit: 3006adf3be79cde4d14b1800b963b82b6e5572e0
change-id: 20231005-ftrace_support-6869d4156139
Best regards,
--
Krishna chaitanya chundru
On 10/5/2023 12:57 PM, Rafael J. Wysocki wrote:
> On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
> wrote:
>> Hi,
>>
>> Thanks for your review !
>>
>> On 10/4/2023 9:09 PM, Rafael J. Wysocki wrote:
>>> On Mon, Sep 25, 2023 at 6:31 PM Michal Wilczynski
>>> wrote:
On Thu, Oct 5, 2023 at 10:10 AM Wilczynski, Michal
wrote:
>
> Hi,
>
> Thanks for your review !
>
> On 10/4/2023 9:09 PM, Rafael J. Wysocki wrote:
> > On Mon, Sep 25, 2023 at 6:31 PM Michal Wilczynski
> > wrote:
> >> acpi_dev_install_notify_handler() and acpi_dev_remove_notify_handler()
> >> are
Hi,
Thanks for your review !
On 10/4/2023 9:09 PM, Rafael J. Wysocki wrote:
> On Mon, Sep 25, 2023 at 6:31 PM Michal Wilczynski
> wrote:
>> acpi_dev_install_notify_handler() and acpi_dev_remove_notify_handler()
>> are wrappers around ACPICA installers. They are meant to save some
>> duplicated
51 matches
Mail list logo
