On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
Updates from the previous version [1]:
This version proposes another approach based on an alternate load and boot
of the coprocessor. Therefore, the constraint introduced by tee_remoteproc
is that the firmware has to be authenticated and loaded
On 2/14/2024 10:51 PM, Arnaud Pouliquen wrote:
From: Arnaud Pouliquen
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 device offers a client
interface to load a firmware in
On Sun, Feb 18, 2024 at 02:13:39PM +0530, Krishna chaitanya chundru wrote:
> User space tools can't map strings if we use directly, as the string
> address is internal to kernel.
>
> So add trace point strings for the user space tools to map strings
> properly.
>
> Signed-off-by: Krishna
On Wed, Feb 21, 2024 at 09:11:03AM -0500, Steven Rostedt wrote:
> On Wed, 21 Feb 2024 11:41:46 +0530
> Manivannan Sadhasivam wrote:
>
> > On Sun, Feb 18, 2024 at 02:13:39PM +0530, Krishna chaitanya chundru wrote:
> > > User space tools can't map strings if we use directly, as the string
> > >
On LoongArch system, ipi hw uses iocsr registers, there is one iocsr
register access on ipi sending, and two iocsr access on ipi receiving
which is ipi interrupt handler. On VM mode all iocsr accessing will
cause VM to trap into hypervisor. So with one ipi hw notification
there will be three times
Physical cpuid is used for interrupt routing for irqchips such as
ipi/msi/extioi interrupt controller. And physical cpuid is stored
at CSR register LOONGARCH_CSR_CPUID, it can not be changed once vcpu
is created and physical cpuid of two vcpus cannot be the same.
Different irqchips have different
Paravirt interface pv_ipi_init() is added here for guest kernel, it
firstly checks whether system runs on VM mode. If kernel runs on VM mode,
it will call function kvm_para_available() to detect current VMM type.
Now only KVM VMM type is detected,the paravirt function can work only if
current VMM
On LoongArch system, there is hypercall instruction special for
virtualization. When system executes this instruction on host side,
there is illegal instruction exception reported, however it will
trap into host when it is executed in VM mode.
When hypercall is emulated, A0 register is set with
Instruction cpucfg can be used to get processor features. And there
is trap exception when it is executed in VM mode, and also it is
to provide cpu features to VM. On real hardware cpucfg area 0 - 20
is used. Here one specified area 0x4000 -- 0x40ff is used
for KVM hypervisor to privide
On physical machine, ipi HW uses IOCSR registers, however there is trap
into hypervisor when vcpu accesses IOCSR registers if system is in VM
mode. SWI is a interrupt mechanism like SGI on ARM, software can send
interrupt to CPU, only that on LoongArch SWI can only be sent to local CPU
now. So SWI
It is code refine about ipi handling on LoongArch platform, there are
three modifications.
1. Add generic function get_percpu_irq(), replacing some percpu irq
functions such as get_ipi_irq()/get_pmc_irq()/get_timer_irq() with
get_percpu_irq().
2. Change definition about parameter action called by
Hi All
I hit a similar issue when doing a regression testing from my side.
For the error messages please help review the attachment.
The latest commit:
commit c02197fc9076e7d991c8f6adc11759c5ba52ddc6 (HEAD -> master,
origin/master, origin/HEAD)
Merge: f2667e0c3240 0846dd77c834
Author: Linus
User programs can now ask user_events to handle the synchronization of
multiple different formats for an event with the same name via the new
USER_EVENT_REG_MULTI_FORMAT flag.
Add a section for USER_EVENT_REG_MULTI_FORMAT that explains the intended
purpose and caveats of using it. Explain how
The current code for finding and deleting events assumes that there will
never be cases when user_events are registered with the same name, but
different formats. Scenarios exist where programs want to use the same
name but have different formats. An example is multiple versions of a
program
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs
User_events now has multi-format events which allow for the same
register name, but with different formats. When this occurs, different
tracepoints are created with unique names.
Add a new test that ensures the same name can be used for two different
formats. Ensure they are isolated from each
Currently user_events supports 1 event with the same name and must have
the exact same format when referenced by multiple programs. This opens
an opportunity for malicous or poorly thought through programs to
create events that others use with different formats. Another scenario
is user programs
Hi!
> > + reset-gpios:
> > +maxItems: 1
>
> blank line
>
> > + avdd10-supply:
> > +description:
> > + 1.0V power supply
>
> Keep description in one line and add a blank line. This code is not that
> readable.
>
> > + i2c-supply:
> > +description:
> > + Power supply
>
On Tue, Feb 20, 2024 at 11:55 PM Michal Hocko wrote:
>
> Hi,
> sorry I have missed this before.
>
> On Thu 11-01-24 21:05:30, Carlos Galo wrote:
> > The current implementation of the mark_victim tracepoint provides only
> > the process ID (pid) of the victim process. This limitation poses
> >
Existing runtime PM ftrace events (`rpm_suspend`, `rpm_resume`,
`rpm_return_int`) offer limited visibility into the exact timing of device
runtime power state transitions, particularly when asynchronous operations
are involved. When the `rpm_suspend` or `rpm_resume` functions are invoked
with the
On Wed, Feb 21, 2024 at 10:33 AM Steven Rostedt wrote:
>
> On Wed, 21 Feb 2024 09:57:03 -0800
> Vilas Bhat wrote:
>
> > > You could do what everyone else does:
> > >
> > > #define RPM_STATUS_STRINGS \
> > > EM( RPM_INVALID, "RPM_INVALID" )\
> > > EM(
On Wed, 21 Feb 2024 09:57:03 -0800
Vilas Bhat wrote:
> > You could do what everyone else does:
> >
> > #define RPM_STATUS_STRINGS \
> > EM( RPM_INVALID, "RPM_INVALID" )\
> > EM( RPM_ACTIVE, "RPM_ACTIVE" ) \
> > EM( RPM_RESUMING,
On Wed, Feb 21, 2024 at 9:12 AM Steven Rostedt wrote:
>
> On Wed, 21 Feb 2024 16:41:10 +
> Vilas Bhat wrote:
>
>
> > diff --git a/include/trace/events/rpm.h b/include/trace/events/rpm.h
> > index 3c716214dab1..f1dc4e95dbce 100644
> > --- a/include/trace/events/rpm.h
> > +++
+ live-patching folks,
Finally, things are starting to be much clearer. Thanks for the time
for working on this, some more comments below and a question which
I think deserves some attention.
On Sat, Feb 17, 2024 at 04:18:10PM +0800, Changbin Du wrote:
> The synchronization here is just to
On Wed, 21 Feb 2024 16:41:10 +
Vilas Bhat wrote:
> diff --git a/include/trace/events/rpm.h b/include/trace/events/rpm.h
> index 3c716214dab1..f1dc4e95dbce 100644
> --- a/include/trace/events/rpm.h
> +++ b/include/trace/events/rpm.h
> @@ -101,6 +101,42 @@ TRACE_EVENT(rpm_return_int,
>
On Wed, Feb 21, 2024 at 10:17:21AM -0500, Steven Rostedt wrote:
> On Wed, 14 Feb 2024 17:50:43 +
> Beau Belgrave wrote:
>
> So the patches look good, but since I gave you some updates, I'm now going
> to go though "nits". Like grammar and such ;-)
>
Sure thing.
> > The current code for
On Wed, Feb 21, 2024 at 10:08:33AM -0500, Steven Rostedt wrote:
> On Wed, 14 Feb 2024 17:50:44 +
> Beau Belgrave wrote:
>
> > +static char *user_event_group_system_multi_name(void)
> > +{
> > + char *system_name;
> > + int len = sizeof(USER_EVENTS_MULTI_SYSTEM) + 1;
>
> FYI, the
On Wed, Feb 21, 2024 at 10:21:04AM -0500, Steven Rostedt wrote:
> On Wed, 14 Feb 2024 17:50:44 +
> Beau Belgrave wrote:
>
> > Currently user_events supports 1 event with the same name and must have
> > the exact same format when referenced by multiple programs. This opens
> > an opportunity
Existing runtime PM ftrace events (`rpm_suspend`, `rpm_resume`,
`rpm_return_int`) offer limited visibility into the exact timing of device
runtime power state transitions, particularly when asynchronous operations
are involved. When the `rpm_suspend` or `rpm_resume` functions are invoked
with the
On Wed, 14 Feb 2024 17:50:44 +
Beau Belgrave wrote:
> Currently user_events supports 1 event with the same name and must have
> the exact same format when referenced by multiple programs. This opens
> an opportunity for malicous or poorly thought through programs to
> create events that
On Wed, 14 Feb 2024 17:50:43 +
Beau Belgrave wrote:
So the patches look good, but since I gave you some updates, I'm now going
to go though "nits". Like grammar and such ;-)
> The current code for finding and deleting events assumes that there will
> never be cases when user_events are
On Wed, 14 Feb 2024 17:50:44 +
Beau Belgrave wrote:
> +static char *user_event_group_system_multi_name(void)
> +{
> + char *system_name;
> + int len = sizeof(USER_EVENTS_MULTI_SYSTEM) + 1;
FYI, the sizeof() will include the "\0" so no need for "+ 1", but I don't
think this matters
On 21/02/2024 2:23 pm, Steven Rostedt wrote:
On Fri, 2 Feb 2024 08:33:38 +
Metin Kaya wrote:
Add sched_[start, finish]_task_selection trace events to measure the
latency of PE patches in task selection.
Moreover, introduce trace events for interesting events in PE:
1.
On Fri, 2 Feb 2024 08:33:38 +
Metin Kaya wrote:
> Add sched_[start, finish]_task_selection trace events to measure the
> latency of PE patches in task selection.
>
> Moreover, introduce trace events for interesting events in PE:
> 1. sched_pe_enqueue_sleeping_task: a task gets enqueued on
On Wed, 21 Feb 2024 11:41:46 +0530
Manivannan Sadhasivam wrote:
> On Sun, Feb 18, 2024 at 02:13:39PM +0530, Krishna chaitanya chundru wrote:
> > User space tools can't map strings if we use directly, as the string
> > address is internal to kernel.
> >
> > So add trace point strings for the
On Wed, Feb 21, 2024 at 6:01 PM John Garry wrote:
>
> On 08/02/2024 10:08, John Garry wrote:
> > On 05/02/2024 23:10, Masahiro Yamada wrote:
> I think what you can contribute are:
>
> - Explore the UTS_RELEASE users, and check if you can get rid of it.
> >>> Unfortunately I
On Wed, 21 Feb 2024 11:37:22 +, wangyunjian wrote:
> > -Original Message-
> > From: Xuan Zhuo [mailto:xuanz...@linux.alibaba.com]
> > Sent: Wednesday, February 21, 2024 5:53 PM
> > To: wangyunjian
> > Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > k...@vger.kernel.org;
> -Original Message-
> From: Xuan Zhuo [mailto:xuanz...@linux.alibaba.com]
> Sent: Wednesday, February 21, 2024 5:53 PM
> To: wangyunjian
> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
> k...@vger.kernel.org; virtualizat...@lists.linux.dev; xudingke
> ; wangyunjian ;
>
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> To determine if any page available for reclamation at the global level,
> only checking for emptiness of the global LRU is not adequate when pages
> are tracked in multiple LRUs, one per cgroup. For this
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> 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_lru_list() returns
On Mon, 2024-02-05 at 13:06 -0800, Haitao Huang wrote:
> From: Kristen Carlson Accardi
>
> When cgroup is enabled, all reclaimable pages will be tracked in cgroup
> LRUs. The global reclaimer needs to start reclamation from the root
> cgroup. Expose the top level cgroup reclamation function so
> -int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg)
> +int sgx_epc_cgroup_try_charge(struct sgx_epc_cgroup *epc_cg, bool reclaim)
> {
> - return misc_cg_try_charge(MISC_CG_RES_SGX_EPC, epc_cg->cg, PAGE_SIZE);
> + for (;;) {
> + if
On Wed, 2024-02-21 at 00:44 -0600, Haitao Huang wrote:
> [...]
> >
> > Here the @nr_to_scan is reduced by the number of pages that are
> > isolated, but
> > not actually reclaimed (which is reflected by @cnt).
> >
> > IIUC, looks you want to make this function do "each cycle" as what you
> >
On Wed, 2024-02-21 at 00:23 -0600, Haitao Huang wrote:
> StartHi Kai
> On Tue, 20 Feb 2024 03:52:39 -0600, Huang, Kai wrote:
> [...]
> >
> > So you introduced the work/workqueue here but there's no place which
> > actually
> > queues the work. IMHO you can either:
> >
> > 1) move relevant
On Wed, 24 Jan 2024 17:37:38 +0800, Yunjian Wang wrote:
> Now dma mappings are used by the physical NICs. However the vNIC
> maybe do not need them. So remove non-zero 'dma_page' check in
> xp_assign_dev.
Could you tell me which one nic can work with AF_XDP without DMA?
Thanks.
>
>
On 08/02/2024 10:08, John Garry wrote:
On 05/02/2024 23:10, Masahiro Yamada wrote:
I think what you can contribute are:
- Explore the UTS_RELEASE users, and check if you can get rid of it.
Unfortunately I expect resistance for this. I also expect places like FW
loader it is necessary. And
Hello Christoph,
On 2/20/24 10:01, Christoph Hellwig wrote:
On Mon, Feb 19, 2024 at 06:06:06PM +0100, Maxime Coquelin wrote:
Since commit 295525e29a5b ("virtio_net: merge dma
operations when filling mergeable buffers"), VDUSE device
require support for DMA's .sync_single_for_cpu() operation
as
Hi Mathieu,
On 2/20/24 19:58, Mathieu Poirier wrote:
> Good morning,
>
> On Wed, Feb 14, 2024 at 06:21:21PM +0100, Arnaud Pouliquen wrote:
>> From: Arnaud Pouliquen
>>
>> Add a remoteproc TEE (Trusted Execution Environment) driver
>> that will be probed by the TEE bus. If the associated Trusted
48 matches
Mail list logo
