On Fri, 30 Aug 2024 22:49:50 +0200, André Apitzsch wrote:
> Patch "arm64: dts: qcom: msm8939-longcheer-l9100: Add rear flash" has
> been applied twice. This reverts the older version of the patch.
>
> Revert the commit f98bdb21cfc9 ("arm64: dts: qcom:
> msm8939-longcheer-l9100: Add rear flash")
Hi Miroslav,
On Fri, Aug 30, 2024 at 9:34 AM Miroslav Benes wrote:
>
> yes, this is one of the approaches we use in SLES. We add kabi paddings
> to some structures in advance (see [1] as a random example) and then use
> it later if needed.
>
> It is not the only approach. Much more often we do no
On Thu, Aug 29, 2024 at 12:45 PM Jiri Olsa wrote:
>
> The idea is to create and monitor 3 uprobes, each trigered in separate
typo: triggered
> process and make sure the bpf program gets executed just for the proper
> PID specified via pid filter.
>
> Signed-off-by: Jiri Olsa
> ---
> .../bpf/pr
lt: camera-rear-flash-default-state {
- pins = "gpio9", "gpio16", "gpio51";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
- };
-
gpio_hall_sensor_default: gpio-hall-s
On Fri, Aug 30, 2024 at 1:21 PM Oleg Nesterov wrote:
>
> On 08/30, Andrii Nakryiko wrote:
> >
>
> Andrii, let me reply to your email "out of order". First of all:
>
> > Can we please let me land these patches first? It's been a while. I
> > don't think anything is really broken with the logic.
>
>
Hi Andrii,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on next-20240830]
[cannot apply to perf-tools-next/perf-tools-next perf-tools/perf-tools
linus/master acme/perf/core v6.11-rc5]
[If your patch is applied to the wrong
On 08/30, Andrii Nakryiko wrote:
>
Andrii, let me reply to your email "out of order". First of all:
> Can we please let me land these patches first? It's been a while. I
> don't think anything is really broken with the logic.
OK, agreed.
I'll probably write another email (too late for me today)
On Fri, Aug 30, 2024 at 10:42 AM kernel test robot wrote:
>
> Hi Andrii,
>
> kernel test robot noticed the following build errors:
>
> [auto build test ERROR on tip/perf/core]
> [also build test ERROR on next-20240830]
> [cannot apply to perf-tools-next/perf-tools-ne
Hi Andrii,
kernel test robot noticed the following build errors:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on next-20240830]
[cannot apply to perf-tools-next/perf-tools-next perf-tools/perf-tools
linus/master acme/perf/core v6.11-rc5]
[If your patch is applied to the wrong
AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
R5 cores can access OCM and access is faster than DDR memory but slower
than TCM memories available. Sram region can have optional multiple
power-domains. Platform management firmware is responsible
to operate these power-domains.
Sign
On 08/29, Jiri Olsa wrote:
> hi,
> in response to [1] patch, I'm adding bpf selftest that confirms the
> change fixes problem for bpf programs trigered by return uprobe created
> over perf event.
>
> Oleg pointed out other issues with uprobe_multi pid filter,
> I plan to send another patchset for
From: Sean Christopherson
Add initial documentation of how to regulate the distribution of
SGX Enclave Page Cache (EPC) memory via the Miscellaneous cgroup
controller.
Signed-off-by: Sean Christopherson
Co-developed-by: Kristen Carlson Accardi
Signed-off-by: Kristen Carlson Accardi
Co-develop
From: Kristen Carlson Accardi
Previous patches have implemented all infrastructure needed for
per-cgroup EPC page tracking and reclaiming. But all reclaimable EPC
pages are still tracked in the global LRU as sgx_epc_page_lru() always
returns reference to the global LRU.
Change sgx_epc_page_lru()
From: Kristen Carlson Accardi
In cases EPC pages need be allocated during a page fault and the cgroup
usage is near its limit, an asynchronous reclamation needs to be
triggered to avoid blocking the page fault handling.
To keep implementation simple, use a workqueue instead of kthread to
schedul
From: Kristen Carlson Accardi
The SGX driver tracks reclaimable EPC pages by adding a newly allocated
page into the global LRU list in sgx_mark_page_reclaimable(), and doing
the opposite in sgx_unmark_page_reclaimable().
To support SGX EPC cgroup, the SGX driver will need to maintain an LRU
list
With different cgroups, the script starts one or multiple concurrent SGX
selftests (test_sgx), each to run the unclobbered_vdso_oversubscribed
test case, which loads an enclave of EPC size equal to the EPC capacity
available on the platform. The script checks results against the
expectation set for
With EPC cgroups, the global reclamation function,
sgx_reclaim_pages_global(), can no longer apply to the global LRU as
pages are now in per-cgroup LRUs.
Create a wrapper, sgx_cgroup_reclaim_global() to invoke
sgx_cgroup_reclaim_pages() passing in the root cgroup. The wrapper will
scan and attemp
From: Sean Christopherson
Introduce a data structure to wrap the existing reclaimable list and its
spinlock. Each cgroup later will have one instance of this structure to
track EPC pages allocated for processes associated with the same cgroup.
Just like the global SGX reclaimer (ksgxd), an EPC cg
From: Kristen Carlson Accardi
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The
existing cgroup memory controller cannot be used to limit or account for
SGX EPC memory, which is a desirable feature in some en
sgx_reclaim_direct() was introduced to preemptively reclaim some pages
as the best effort to avoid on-demand reclamation that can stall forward
progress in some situations, e.g., allocating pages to load previously
reclaimed page to perform EDMM operations on [1].
Currently when the global usage i
Enclave Page Cache(EPC) memory can be swapped out to regular system
memory, and the consumed memory should be charged to a proper
mem_cgroup. Currently the selection of mem_cgroup to charge is done in
sgx_encl_get_mem_cgroup(). But it considers all contexts other than the
ksgxd thread are user proc
Currently in the EPC page allocation, the kernel simply fails the
allocation when the current EPC cgroup fails to charge due to its usage
reaching limit. This is not ideal. When that happens, a better way is
to reclaim EPC page(s) from the current EPC cgroup to reduce its usage
so the new allocat
From: Kristen Carlson Accardi
Add SGX EPC memory, MISC_CG_RES_SGX_EPC, to be a valid resource type
for the misc controller.
Signed-off-by: Kristen Carlson Accardi
Co-developed-by: Haitao Huang
Signed-off-by: Haitao Huang
Reviewed-by: Jarkko Sakkinen
Reviewed-by: Kai Huang
Tested-by: Jarkko
From: Kristen Carlson Accardi
The SGX EPC cgroup will reclaim EPC pages when usage in a cgroup reaches
its or ancestor's limit. This requires a walk from the current cgroup up
to the root similar to misc_cg_try_charge(). Expose misc_cg_parent() to
enable this walk.
The SGX driver also needs star
To support the per-cgroup reclamation, each cgroup will have its own
"per-cgroup LRU" and EPC pages will be in its owner cgroup's LRU instead
of the global LRU. Abstract the code that is directly working with the
global LRU into functions reusable with per-cgroup LRUs.
Currently the basic reclamat
From: Kristen Carlson Accardi
The misc cgroup controller (subsystem) currently does not perform
resource type specific action for Cgroups Subsystem State (CSS) events:
the 'css_alloc' event when a cgroup is created and the 'css_free' event
when a cgroup is destroyed.
Define callbacks for those e
Replace boolean parameters for 'reclaim' in the function
sgx_alloc_epc_page() and its callers with an enum.
Also opportunistically remove non-static declaration of
__sgx_alloc_epc_page() and a typo
Signed-off-by: Haitao Huang
Suggested-by: Jarkko Sakkinen
Suggested-by: Dave Hansen
Reviewed-by:
SGX Enclave Page Cache (EPC) memory allocations are separate from normal
RAM allocations, and are managed solely by the SGX subsystem. The existing
cgroup memory controller cannot be used to limit or account for SGX EPC
memory, which is a desirable feature in some environments, e.g., support
for po
On Fri, Aug 30, 2024 at 7:33 AM Oleg Nesterov wrote:
>
> On 08/30, Jiri Olsa wrote:
> >
> > with this change the probe will not get removed in the attached test,
> > it'll get 2 hits, without this change just 1 hit
>
> I don't understand the code in tools/...bpf../ at all, can't comment,
>
> > but
Hi Cindy,
On 30.08.24 15:52, Dragos Tatulea wrote:
>
>
> On 30.08.24 11:12, Cindy Lu wrote:
>> On Thu, 29 Aug 2024 at 18:00, Dragos Tatulea wrote:
>>>
>>>
>>>
>>> On 29.08.24 11:05, Cindy Lu wrote:
On Wed, 28 Aug 2024 at 17:37, Dragos Tatulea wrote:
>
>
>
> On 28.08.24 11:
On 08/30, Jiri Olsa wrote:
>
> with this change the probe will not get removed in the attached test,
> it'll get 2 hits, without this change just 1 hit
I don't understand the code in tools/...bpf../ at all, can't comment,
> but I'm not sure it's a big problem, because seems like that's not the
>
On 08/29, Andrii Nakryiko wrote:
>
> On Thu, Aug 29, 2024 at 4:10 PM Jiri Olsa wrote:
> >
> > > @@ -2101,17 +2110,24 @@ static void handler_chain(struct uprobe *uprobe,
> > > struct pt_regs *regs)
> > > need_prep = true;
> > >
> > > remove &= rc;
> > > +
On 8/29/24 23:02, Aaron Lu wrote:
>> Also, I do think we should probably add some kind of sanity warning to
>> the SGX code in another patch. If a node on an SGX system has CPUs and
>> memory, it's very likely it will also have some EPC. It can be
>> something soft like a pr_info(), but I think i
Hi,
On Wed, 7 Aug 2024, Song Liu wrote:
> With CONFIG_LTO_CLANG, the compiler/linker adds .llvm. suffix to
> local symbols to avoid duplications. Existing scripts/kallsyms sorts
> symbols without .llvm. suffix. However, this causes quite some
> issues later on. Some users of kallsyms, such as liv
On 30.08.24 11:12, Cindy Lu wrote:
> On Thu, 29 Aug 2024 at 18:00, Dragos Tatulea wrote:
>>
>>
>>
>> On 29.08.24 11:05, Cindy Lu wrote:
>>> On Wed, 28 Aug 2024 at 17:37, Dragos Tatulea wrote:
On 28.08.24 11:00, Cindy Lu wrote:
> On Wed, 28 Aug 2024 at 09:51, Jason Wang
On Thu, Aug 29, 2024 at 04:31:18PM -0700, Andrii Nakryiko wrote:
> On Thu, Aug 29, 2024 at 4:10 PM Jiri Olsa wrote:
> >
> > On Thu, Aug 29, 2024 at 11:37:37AM -0700, Andrii Nakryiko wrote:
> > > uprobe->register_rwsem is one of a few big bottlenecks to scalability of
> > > uprobes, so we need to g
Hello,
On 8/29/24 9:31 PM, Jason Wang wrote:
> On Fri, Aug 30, 2024 at 5:08 AM Dragos Tatulea wrote:
>> (resending as I accidentally replied only to Carlos)
>>
>> On 29.08.24 18:16, Carlos Bilbao wrote:
>>> From: Carlos Bilbao
>>>
>>> Include support to update the vDPA configuration fields of sp
On 29.08.24 17:15, Eugenio Perez Martin wrote:
> On Thu, Aug 29, 2024 at 3:54 PM Dragos Tatulea wrote:
>>
>>
>>
>> On 29.08.24 15:10, Eugenio Perez Martin wrote:
>>> On Wed, Aug 21, 2024 at 1:41 PM Dragos Tatulea wrote:
Use the async interface to issue MTT MKEY creation.
Extra c
Now that the mr resources have their own namespace in the
struct, give the lock a clearer name.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 2 +-
drivers/vdpa/mlx5/core/mr.c| 20 ++--
drivers/
Currently, when a new MR is set up, the old MR is deleted. MR deletion
is about 30-40% the time of MR creation. As deleting the old MR is not
important for the process of setting up the new MR, this operation
can be postponed.
This series adds a workqueue that does MR garbage collection at a later
A followup patch will use this name for something else.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 2 +-
drivers/vdpa/mlx5/core/mr.c| 2 +-
drivers/vdpa/mlx5/net/mlx5_vnet.c | 8
3 files changed, 6 insertions(+), 6 deletion
There's currently not a lot of action happening during
the init/destroy of MR resources. But more will be added
in the upcoming patches.
As the mr mutex lock init/destroy has been moved to these
new functions, the lifetime has now shifted away from
mlx5_vdpa_alloc_resources() / mlx5_vdpa_free_reso
Group all mapping related resources into their own structure.
Upcoming patches will add more members in this new structure.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
---
drivers/vdpa/mlx5/core/mlx5_vdpa.h | 13 ++-
drivers/vdpa/mlx5/core/mr.c
Use the async interface to issue MTT MKEY deletion.
This makes destroy_user_mr() on average 8x times faster.
This number is also dependent on the size of the MR being
deleted.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
---
drivers/vdpa/mlx5/core/mr.c | 64
Use the async interface to issue MTT MKEY creation.
Extra care is taken at the allocation of FW input commands
due to the MTT tables having variable sizes depending on
MR.
The indirect MKEY is still created synchronously at the
end as the direct MKEYs need to be filled in.
This makes create_user_
This series improves the time of .set_map() operations by parallelizing
the MKEY creation and deletion for direct MKEYs. Looking at the top
level MKEY creation/deletion functions, the following improvement can be
seen:
|---+-|
| operation | improvement |
|--
On 08/29, Andrii Nakryiko wrote:
>
> v3->v4:
> - added back consumer_rwsem into consumer_del(), which was accidentally
> omitted earlier (Jiri);
still,
Reviewed-by: Oleg Nesterov
This patch centralizing the cleanup of the resource table into a new
helper function rproc_release_fw().
Suggested-by: Mathieu Poirier
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --g
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted Execution Environment
(TEE).
For instance, this compatible is used in both the Linux and OP-TEE device
trees:
- In OP-TEE, a node is defined in the device tree with the
Add support for releasing remote processor firmware through
the Trusted Execution Environment (TEE) interface.
The tee_rproc_release_fw() function is called in the following cases:
- An error occurs in rproc_start() between the loading of the segments and
the start of the remote processor.
- Wh
The new TEE remoteproc driver is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format de
Add a remoteproc TEE (Trusted Execution Environment) driver
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this driver offers a client
interface to load a firmware by the secure part.
This firmware could be authenticated by the secure trusted a
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without remoteproc TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-
When a resource table is loaded by an external entity such as U-boot or
OP-TEE, we do not necessarily get the device address(da) but the physical
address(pa).
This helper performs similar translation than the rproc_da_to_va()
but based on a physical address.
Signed-off-by: Arnaud Pouliquen
---
d
Main updates from version V8[1]:
Add support for tee_rproc_release_fw(), which allows releasing firmware
that has been loaded. This service is used if an error occurs between
the loading of the firmware image and the start of the remote processor.
It is also called on remote processor shutdown.
A
Hi Cindy,
On 30.08.24 11:29, Cindy Lu wrote:
> On Fri, 30 Aug 2024 at 03:03, Dragos Tatulea wrote:
>>
>>
>>
>> On 29.08.24 12:00, Dragos Tatulea wrote:
>>>
>>>
>>> On 29.08.24 11:05, Cindy Lu wrote:
On Wed, 28 Aug 2024 at 17:37, Dragos Tatulea wrote:
>
>
>
> On 28.08.24 11
Hi,
On Thu, 15 Aug 2024, Sami Tolvanen wrote:
> Distributions that want to maintain a stable kABI need the ability to
> add reserved fields to kernel data structures that they anticipate
> will be modified during the ABI support timeframe, either by LTS
> updates or backports.
>
> With genksyms,
Interrupts can be routed to maximal four virtual CPUs with one HW
EIOINTC interrupt controller model, since interrupt routing is encoded with
CPU bitmap and EIOINTC node combined method. Here add the EIOINTC virt
extension support so that interrupts can be routed to 256 vCPUs on
hypervisor mode. CP
Export kernel paravirt features to user space, so that VMM can control
the single paravirt feature. By default paravirt features will be the same
with kvm supported features if VMM does not set it.
Also a new feature KVM_FEATURE_VIRT_EXTIOI is added which can be set from
user space. This feature i
Function kvm_para_has_feature() is to detect supported paravirt features,
it can be used by device driver to detect and enable paravirt features,
such as extioi irqchip driver can detect KVM_FEATURE_VIRT_EXTIOI and do
some optimization.
Signed-off-by: Bibo Mao
---
arch/loongarch/include/asm/kvm_
KVM_FEATURE_VIRT_EXTIOI is paravirt feature defined with EXTIOI
interrupt controller, it can route interrupt to 256 vCPUs and CPU
interrupt pin IP0-IP7. Now EXTIOI irqchip is emulated in user space
rather than kernel space, here interface is provided for VMM to pass
this feature to KVM hypervisor.
On Fri, 30 Aug 2024 at 03:03, Dragos Tatulea wrote:
>
>
>
> On 29.08.24 12:00, Dragos Tatulea wrote:
> >
> >
> > On 29.08.24 11:05, Cindy Lu wrote:
> >> On Wed, 28 Aug 2024 at 17:37, Dragos Tatulea wrote:
> >>>
> >>>
> >>>
> >>> On 28.08.24 11:00, Cindy Lu wrote:
> On Wed, 28 Aug 2024 at 09:
在 2024/8/30 3:26, Andrii Nakryiko 写道:
> On Tue, Aug 27, 2024 at 4:34 AM Liao, Chang wrote:
>>
>> Hi, Mark
>>
>> Would you like to discuss this patch further, or do you still believe
>> emulating
>> STP to push FP/LR into the stack in kernel is not a good idea?
>>
>
> Please send an updated ve
On Thu, 29 Aug 2024 at 18:00, Dragos Tatulea wrote:
>
>
>
> On 29.08.24 11:05, Cindy Lu wrote:
> > On Wed, 28 Aug 2024 at 17:37, Dragos Tatulea wrote:
> >>
> >>
> >>
> >> On 28.08.24 11:00, Cindy Lu wrote:
> >>> On Wed, 28 Aug 2024 at 09:51, Jason Wang wrote:
>
> On Wed, Aug 28, 2024 a
On Thu, Aug 29, 2024 at 07:10:19PM GMT, Gokul Sriram Palanisamy wrote:
> From: Vignesh Viswanathan
>
> Add support to bring up hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ9574 supports secure PIL remoteproc.
Could you please clarify, why this can't be handled by the qcom_q6v5_pas
dri
On Thu, Aug 29, 2024 at 07:10:18PM GMT, Gokul Sriram Palanisamy wrote:
> From: Manikanta Mylavarapu
>
> Add new binding document for hexagon based WCSS secure PIL remoteproc.
> IPQ5332, IPQ9574 follows secure PIL remoteproc.
What is the difference between PAS and secure PIL?
>
> Signed-off-by:
66 matches
Mail list logo
