On 09.05.25 17:55, Lorenzo Stoakes wrote:
On Fri, May 09, 2025 at 05:30:32PM +0200, David Hildenbrand wrote:
Let's test some basic functionality using /dev/mem. These tests will
implicitly cover some PAT (Page Attribute Handling) handling on x86.
These tests will only run when /dev/mem access t
On linux-next, build for bpf selftest displays an error due to
mismatch in the expected function signature of bpf_testmod_test_read
and bpf_testmod_test_write.
Commit 97d06802d10a ("sysfs: constify bin_attribute argument of
bin_attribute::read/write()")
changed the required type for struct bin_at
On linux-next, build for bpf selftest displays a warning:
Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h'
differs from latest version at 'include/uapi/linux/if_xdp.h'.
Commit 8066e388be48 ("net: add UAPI to the header guard in various network
headers")
changed the header guard
This selftest tests all the currently emulated instruction (except for
the RV32 compressed ones which are left as a future exercise for a RV32
user). For the FPU instructions, all the FPU registers are tested.
This commit can be tested using
Signed-off-by: Clément Léger
---
Note: this test can
On Mon, May 12, 2025 at 02:45:11PM +0530, Saket Kumar Bhaskar wrote:
> On linux-next, build for bpf selftest displays a warning:
>
> Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h'
> differs from latest version at 'include/uapi/linux/if_xdp.h'.
>
> Commit 8066e388be48 ("net: add
On Sun, Apr 13, 2025 at 05:52:20PM -0500, Ira Weiny wrote:
> A dynamic capacity device (DCD) sends events to signal the host for
> changes in the availability of Dynamic Capacity (DC) memory. These
> events contain extents describing a DPA range and meta data for memory
> to be added or removed.
On Mon, May 12, 2025 at 09:43:10AM -0700, Jeff Johnson wrote:
> On 5/9/2025 11:18 PM, Greg KH wrote:
> > On Fri, May 09, 2025 at 11:34:30PM +0300, Alexey Dobriyan wrote:
> >> Require set of curlies {} in all if/else branches and all loops
> >> not matter how simple.
> >
> > Sorry, but no, we are n
On Mon, May 12, 2025 at 07:08:53PM +0300, Alexey Dobriyan wrote:
> On Sat, May 10, 2025 at 04:05:29AM -0600, Jonathan Corbet wrote:
> > Alexey Dobriyan writes:
> >
> > > Every time I open Documentation/CodingStyle it says the party moved
> > > somewhere else. :-(
> > >
> > > Of course, I forget w
On 5/9/25 7:19 PM, Linus Torvalds wrote:
At a minimum, the *description* of this bug is garbage.
It talks about an "uninitialized completion pointer", but then the fix
actually depends on it being initialized - just initialized to NULL.
I do believe that it always is initialized, and I have pu
Hello RT-list!
I'm pleased to announce the 5.10.237-rt131 stable release.
This release is just an update to the new stable 5.10.237
version and no RT specific changes have been made.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt
Extend set_id_regs test to run guest code wth NV eanbled. Also added a
check to avoid the writes to TGRAN*_2 fields when NV is enabled.
NV is enabled using command line argument and it is disabled by default.
Signed-off-by: Ganapatrao Kulkarni
---
.../testing/selftests/kvm/arm64/set_id_regs.c |
Modify the test to run the guest code with NV enabled.
Added code is only applicable to ARM64.
NV is enabled using command line argument and it is disabled by default.
Signed-off-by: Ganapatrao Kulkarni
---
.../testing/selftests/kvm/guest_print_test.c | 32 +++
1 file changed,
Add simple test to run guest code with NV enabled. With NV enabled,
guest code runs in vEL2 context.
Signed-off-by: Ganapatrao Kulkarni
---
.../selftests/kvm/arm64/nv_guest_hypervisor.c | 68 +++
1 file changed, 68 insertions(+)
create mode 100644 tools/testing/selftests/kvm/arm
> On Wed, May 07, 2025 at 02:14:00PM +0300, Elena Reshetova wrote:
>
> > diff --git a/arch/x86/kernel/cpu/sgx/driver.c
> b/arch/x86/kernel/cpu/sgx/driver.c
> > index 7f8d1e11dbee..669e44d61f9f 100644
> > --- a/arch/x86/kernel/cpu/sgx/driver.c
> > +++ b/arch/x86/kernel/cpu/sgx/driver.c
> > @@ -19,6
On 5/10/25 23:01, Kent Overstreet wrote:
> Static keys can now be a module parameter, e.g.
>
> module_param_named(foo, foo.key, static_key_t, 0644)
>
> bcachefs is now using this.
>
> Cc: Luis Chamberlain
> Cc: Petr Pavlu
> Cc: Sami Tolvanen
> Cc: Daniel Gomez
> Cc: linux-modu...@vger.kernel
On Mon May 12, 2025 at 12:40 AM WEST, Matti Lehtimäki wrote:
> Recent change to handle platforms with only single power domain broke
> pronto-v3 which requires power domains and doesn't have fallback voltage
> regulators in case power domains are missing. Add a check to verify
> the number of fallb
Hi Peng,
On Mon, May 12, 2025 at 12:56:13PM +0800, Peng Fan wrote:
>
> Ulf's new API dev_pm_genpd_is_on needs to run after power domain attached.
>
> But if run after power domain attached, there is no API to know whether
> M4 is kicked by bootloader or now.
>
> Even imx_rproc_attach_pd has a chec
On 5/9/25 18:42, Alexey Gladkov wrote:
> For some modules, modalias is generated using the modpost utility and
> the section is added to the module file.
>
> When a module is added inside vmlinux, modpost does not generate
> modalias for such modules and the information is lost.
>
> As a result k
On 5/10/25 00:54, Thomas Weißschuh wrote:
Hi Shuah and Kees,
On 2025-05-05 17:15:18+0200, Thomas Weißschuh wrote:
Nolibc is useful for selftests as the test programs can be very small,
and compiled with just a kernel crosscompiler, without userspace support.
Currently nolibc is only usable with
On Mon, 24 Mar 2025 09:41:00 +0100, Luca Weiss wrote:
> The driver for the SM6350 videocc has been lying around in some branches
> of my git tree for a long time, let's upstream it. It doesn't get any
> better by letting it age!
>
>
Applied, thanks!
[2/4] dt-bindings: clock: add SM6350 QCOM v
On Thu, 08 May 2025 16:11:05 +0200, Stanislav Jakubek wrote:
> This series improves the accuracy of motorola-falcon's DTS.
>
> As a side note, I wanted to ask how to describe the Hall effect sensor's
> vdd-supply. The sensor's currently described as part of the gpio-keys node.
> According to the
From: Ashish Kalra
During platform init, SNP initialization may fail for several reasons,
such as firmware command failures and incompatible versions. However,
the KVM capability may continue to advertise support for it.
The platform may have SNP enabled but if SNP_INIT fails then SNP is
not sup
On Sat, May 10, 2025 at 5:35 AM Lorenz Bauer wrote:
>
> Teach libbpf to use mmap when parsing vmlinux BTF from /sys. We don't
> apply this to fall-back paths on the regular file system because there
> is no way to ensure that modifications underlying the MAP_PRIVATE
> mapping are not visible to th
From: Ashish Kalra
During platform init, SNP initialization may fail for several reasons,
such as firmware command failures and incompatible versions. However,
the KVM capability may continue to advertise support for it.
The platform may have SNP enabled but if SNP_INIT fails then SNP is
not sup
On 5/12/25 16:04, Ashish Kalra wrote:
> From: Ashish Kalra
>
> During platform init, SNP initialization may fail for several reasons,
> such as firmware command failures and incompatible versions. However,
> the KVM capability may continue to advertise support for it.
>
> The platform may have S
On 5/12/2025 5:16 PM, Ashish Kalra wrote:
> From: Ashish Kalra
>
> During platform init, SNP initialization may fail for several reasons,
> such as firmware command failures and incompatible versions. However,
> the KVM capability may continue to advertise support for it.
>
> The platform may
On Mon, May 12, 2025 at 2:23 AM Greg KH wrote:
>
> On Mon, May 12, 2025 at 02:45:11PM +0530, Saket Kumar Bhaskar wrote:
> > On linux-next, build for bpf selftest displays a warning:
> >
> > Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h'
> > differs from latest version at 'includ
Kdamond.update_schemes_tried_regions() reads and stores tried regions
information out of address order. It makes debugging a test failure
difficult. Change the behavior to do the reading and writing in the
address order.
Signed-off-by: SeongJae Park
---
tools/testing/selftests/damon/_damon_sys
DAMOS filters' default reject behavior is not very simple. Actually
there was a mistake[1] during the development. Add a kunit test for
validating the behavior.
[1] https://lore.kernel.org/20250227002913.19359-1...@kernel.org
Signed-off-by: SeongJae Park
---
mm/damon/tests/core-kunit.h | 70 +
On Mon, May 12, 2025 at 07:20:23PM +0300, Alexey Dobriyan wrote:
> On Sat, May 10, 2025 at 07:56:03PM +0100, David Laight wrote:
> > On Fri, 9 May 2025 23:34:29 +0300
> > Alexey Dobriyan wrote:
> >
> > > Signed-off-by: Alexey Dobriyan
> > > ---
> > > Documentation/process/coding-style.rst | 16
On Mon, 12 May 2025 19:20:23 +0300
Alexey Dobriyan wrote:
> On Sat, May 10, 2025 at 07:56:03PM +0100, David Laight wrote:
> > On Fri, 9 May 2025 23:34:29 +0300
> > Alexey Dobriyan wrote:
> >
> > > Signed-off-by: Alexey Dobriyan
> > > ---
> > > Documentation/process/coding-style.rst | 16 ++
On 5/12/25 5:20 AM, Lijuan Gao wrote:
>
>
> 在 5/9/2025 4:54 PM, Konrad Dybcio 写道:
>> On 5/9/25 9:37 AM, Lijuan Gao wrote:
>>>
>>>
>>> 在 5/8/2025 10:41 PM, Konrad Dybcio 写道:
On 5/7/25 12:26 PM, Lijuan Gao wrote:
> Add a simple-mfd representing IMEM on QCS615 and define the PIL
> reloc
On Mon, 12 May 2025 at 11:14, Dmitry Antipov wrote:
>
> Technically speaking you're right, and I will take notice on that for
> further commits. OTOH replying with "please adjust commit message and
> send v2" could be the way faster.
I suspect it ends up depending on the people.
Personally, I te
The TI-SCI processor control handle, 'tsp', will be refactored from
k3_r5_core struct into k3_r5_rproc struct in a future commit. So, the
'tsp' pointer will be initialized inside k3_r5_cluster_rproc_init() now.
Move the k3_r5_release_tsp() function, which releases the tsp handle,
above k3_r5_clust
Currently, struct members such as mem, num_mems, reset, tsp, ti_sci and
ti_sci_id are part of the k3_r5_core structure. To align the rproc->priv
data structure of the R5 remote processor with that of the DSP and M4,
move the above members from k3_r5_core to k3_r5_rproc struct.
Additionally, introd
This series refactors a lot of functions & callbacks from
ti_k3_dsp_remoteproc.c, ti_k3_r5_remoteproc.c and ti_k3_m4_remoteproc.c
drivers. This is a consolidated and final series as part of the
refactoring of K3 remoteproc drivers. Below is the breakdown:
1. PATCHES #1-#4 fixes important bugs in R5
From: Siddharth Vadapalli
Commit ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during
probe routine") introduced a check in the "k3_dsp_rproc_mbox_callback()"
and "k3_dsp_rproc_kick()" callbacks, causing them to exit if the remote
core's state is "RPROC_DETACHED". However, the "__rpro
The existing implementation of the waiting mechanism in
"k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to
be set as part of the firmware boot process in "k3_r5_rproc_start()".
The "k3_r5_cluster_rproc_init()" function is invoked in the probe
routine which causes unexpected fa
The internal memory struct pointer, 'mem', will be refactored from
k3_r5_core struct into k3_r5_rproc struct in a future commit.
Therefore, move the internal memory initialization function,
k3_r5_core_of_get_internal_memories() above k3_r5_cluster_rproc_init()
so that the former can be invoked by
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Reviewed-by: An
From: Siddharth Vadapalli
Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()"
and "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote
core's state is "RPROC_DETACHED". However, the "__rproc_a
The rproc_detach() function invokes __rproc_detach() before
rproc_unprepare_device(). The __rproc_detach() function sets the
rproc->state to "RPROC_DETACHED".
However, the TI K3 M4 driver erroneously looks for "RPROC_ATTACHED"
state in its .unprepare ops to identify IPC-only mode; which leads to
r
The mailbox .rx_callback implementations in TI K3 R5, DSP and M4
remoteproc drivers handle inbound mailbox messages in the same way.
Introduce a common driver 'ti_k3_common.c' and refactor the
implementations into a common function 'k3_rproc_mbox_callback'() in it.
Signed-off-by: Beleswar Padhi
T
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Men
Add a pointer to the rproc struct within k3_m4_rproc internal struct.
This is done to align the M4 internal rproc data structure with R5
driver which can be factored out at a later stage.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Mendez
Reviewed-by: Andrew Davis
---
v12: Changelog:
1. Car
Introduce a void pointer in the k3_{m4/dsp}_rproc internal data
structure which can be used to point to any private data needed by the
driver. Currently, the M4/DSP drivers do not have any private data, so
the pointer can be left pointing to NULL.
This is done to align the data structures with R5
The .kick rproc ops implementations in TI K3 R5, DSP and M4 remoteproc
drivers sends a mailbox message to the remote processor in the same
way. Refactor the implementations into a common function
'k3_rproc_kick()' in the ti_k3_common.c driver.
Signed-off-by: Beleswar Padhi
Acked-by: Andrew Davis
The k3_dsp_rproc_reset() function erroneously asserts the local reset
even for devices which do not support it. Even though it results in a
no-operation, Update the logic to explicitly assert the local reset for
devices that support it and only the global reset for those that do not.
Signed-off-by
The TI K3 R5, DSP and M4 remoteproc drivers share the same data
structure definitions. Refactor the shared data structures into a new
common header file, 'ti_k3_common.h', and update the drivers to use the
unified data structures.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Mendez
Reviewed-b
The rproc_reset() implementations in TI K3 DSP and M4 remoteproc drivers
assert reset in the same way. Refactor the above function into the
ti_k3_common.c driver as k3_rproc_reset() and use it throughout DSP and
M4 drivers for resetting the remote processor.
Signed-off-by: Beleswar Padhi
Tested-b
Currently, the TI K3 M4 remoteproc driver assumes all of the M4 devices
have local resets. Even though its true for all existing M4 devices,
keep room for future devices which possibly may not have local resets
and only have a module reset.
Therefore introduce a central function, k3_m4_rproc_relea
Currently, the TI K3 M4 remoteproc driver assumes all of the M4 devices
have local resets. Even though its true for all existing M4 devices,
keep room for future devices which possibly may not have local resets
and only have a module reset.
Therefore introduce a central function, k3_m4_rproc_reset
Currently, the driver overrides the rproc ops when booting in IPC-only
mode. Remove these overrides and register the ops unconditionally. This
requires to have IPC-only mode checks in the .prepare and .unprepare ops
and returning early. The other rproc ops are invoked when booting either
in IPC-onl
The ti_k3_dsp_remoteproc.c driver asserts the local reset in probe
and releases the module reset in .prepare callback. This is done to
ensure the core does not execute bogus code when module reset is
deasserted.
Put both of these operations together in .prepare callback, which is
more suitable as
The .unprepare rproc ops implementations in TI K3 DSP and M4 remoteproc
drivers assert the module reset on the remote processor. Refactor the
implementations into ti_k3_common.c driver as k3_rproc_unprepare() and
register this common function as .unprepare ops in DSP and M4 drivers.
Signed-off-by:
The rproc_request_mbox() implementations in TI K3 R5, DSP and M4
remoteproc drivers acquire the mailbox channel and send the same message
through the acquired channel.
Refactor the above function into the ti_k3_common.c driver as
k3_rproc_request_mbox() and use it throughout R5, DSP and M4 drivers
The .prepare rproc ops implementations in TI K3 DSP and M4 remoteproc
drivers deasserts the local and module reset of the processor to allow
firmware loading into internal memory.
Refactor the implementations into the ti_k3_common.c driver as
k3_rproc_prepare() and register this common function as
The .stop rproc ops implementations in TI K3 DSP and M4 remoteproc
drivers put the remote processor into reset. Refactor the
implementations into ti_k3_common.c driver as k3_rproc_stop() and
register this common function as .stop ops in DSP and M4 drivers.
Signed-off-by: Beleswar Padhi
Tested-by:
The reserved_mem_init() implementations in the R5, DSP and M4 remoteproc
drivers initialize the reserved memory regions associated with the
remote processor.
Refactor these functions into the ti_k3_common.c driver as
k3_reserved_mem_init() and use this common function throughout in R5,
DSP and M4
The of_get_memories() implementations in the TI K3 R5, DSP and M4
remoteproc drivers initialize and assign memory regions used by the
remote processor in the same way. Refactor these implementations into
ti_k3_common.c driver as k3_rproc_of_get_memories() use this common
function for mem initializa
The k3_dsp_rproc_start() function sets the boot vector and releases the
reset on the remote processor. Whereas, the k3_m4_rproc_start() function
only needs to release the reset.
Refactor the k3_m4_rproc_start() into ti_k3_common.c as k3_rproc_start()
and align the DSP and M4 drivers to invoke this
The .get_loaded_rsc_table rproc ops implementations in TI K3 R5, DSP and
M4 remoteproc drivers return a pointer to the resource table that was
pre-loaded at the base address of the DDR region reserved for firmware
usage.
Refactor the implementations into ti_k3_common.c driver as
k3_get_loaded_rsc_
The mem_release() implementations in the TI K3 R5, DSP and M4 remoteproc
drivers release the reserved memory of the device, which get auto
triggered upon device removal.
Refactor these functions into ti_k3_common.c driver as k3_mem_release()
and use this common function in R5, DSP and M4 drivers.
The .attach rproc ops implementations in TI K3 R5, DSP and M4 drivers
are NOPs. Refactor the implementations into ti_k3_common.c driver
as k3_rproc_attach() and register this common function as .attach ops in
R5, DSP and M4 drivers.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Mendez
Reviewed
On Wed, Apr 30, 2025 at 5:27 PM Michael S. Tsirkin wrote:
>
> On Wed, Apr 30, 2025 at 11:34:49AM +0800, Jason Wang wrote:
> > On Tue, Apr 29, 2025 at 6:56 PM Michael S. Tsirkin wrote:
> > >
> > > On Tue, Apr 29, 2025 at 11:39:37AM +0800, Jason Wang wrote:
> > > > On Mon, Apr 21, 2025 at 11:46 AM
The .detach rproc ops implementations in TI K3 R5, DSP and M4
remoteproc drivers are NOPs. Refactor the implementations into
ti_k3_common.c driver as k3_rproc_detach() and register this common
function as .detach ops in R5, DSP and M4 drivers.
Signed-off-by: Beleswar Padhi
Tested-by: Judith Mende
On 13.05.25 07:55, Xin Li wrote:
On 5/12/2025 4:24 AM, Juergen Gross wrote:
Now with the mentioned patch really attached. :-)
Does it allow patching with an instruction more than 6 bytes long?
The immediate form MSR instructions are 9 bytes long.
Yes, shouldn't be a problem.
Juergen
Op
On 2025-05-12 15:32:40-0600, Shuah Khan wrote:
> On 5/10/25 00:54, Thomas Weißschuh wrote:
> > Hi Shuah and Kees,
> >
> > On 2025-05-05 17:15:18+0200, Thomas Weißschuh wrote:
> > > Nolibc is useful for selftests as the test programs can be very small,
> > > and compiled with just a kernel crosscom
On Mon, May 12, 2025 at 07:08:53PM +0300, Alexey Dobriyan wrote:
> I split them like referendum ballots to see where the consensus at and
> not have big single discussion thread.
Just in case - consensus would look like a lot of replies in support and not
simply the lack of replies, right?
The .da_to_va rproc ops implementations in TI K3 R5, DSP and M4
remoteproc drivers return the Kernel virtual address for a
corresponding rproc device address.
Refactor the implementations into the ti_k3_common.c driver as
k3_rproc_da_to_va and use this common function for address translation
of DD
The release_tsp() implementations in the TI K3 R5, DSP and M4 remoteproc
drivers release the TI-SCI processor control of a remote processor,
which is auto triggered upon device removal.
Refactor these functions into ti_k3_common.c driver as k3_release_tsp()
and use this common function throughout
The k3_dsp_rproc_release() function erroneously deasserts the local
reset even for devices which do not support it. Even though it results
in a no-operation, Update the logic to explicitly deassert only the
global reset for devices that do not have a local reset.
Signed-off-by: Beleswar Padhi
Tes
On 5/12/2025 4:24 AM, Juergen Gross wrote:
Now with the mentioned patch really attached. :-)
Does it allow patching with an instruction more than 6 bytes long?
The immediate form MSR instructions are 9 bytes long.
Thanks!
Xin
The TI K3 M4 remoteproc driver acquires the mailbox channel in probe but
sends a message through the acquired channel later in .attach()/.start()
callbacks.
Put both the things together in the form of 'k3_m4_rproc_request_mbox()'
function and invoke that in the probe routine. This is done to align
The rproc_release() implementations in TI K3 DSP and M4 remoteproc
drivers deassert reset in the same way. Refactor the above function into
the ti_k3_common.c driver as k3_rproc_release() and use it throughout
DSP and M4 drivers for releasing the reset from the remote processor.
Signed-off-by: Bel
Hi Hiago,
On Wed, May 07, 2025 at 01:00:54PM -0300, Hiago De Franco wrote:
>From: Hiago De Franco
>
>Move imx_sc_get_pd_power() from pmdomain/imx/scu-pd.c to
>firmware/imx/misc.c and rename it to imx_sc_pm_get_resource_power_mode()
>to maintain the same naming logic with other functions in misc.c
This patch series makes the selftest work with NV enabled. The guest code
is run in vEL2 instead of EL1. We add a command line option to enable
testing of NV. The NV tests are disabled by default.
Modified around 12 selftests in this series.
Changes since v1:
- Updated NV helper functions
Extend the testing of AArch32 ID registers with guest code
with NV enabled.
NV is enabled using command line argument and it is disabled by default.
Signed-off-by: Ganapatrao Kulkarni
---
.../selftests/kvm/arm64/aarch32_id_regs.c | 34 +--
1 file changed, 32 insertions(+), 2
Adding required changes to enable and test HVTIMER and HPTIMER
in vEL2. In default case, PTIMER and VTIMER are validated and with
NV enabled (with argument "-g 1"), HPTIMER and HVTIMER are validated
by injecting respective timer interrupts.
Signed-off-by: Ganapatrao Kulkarni
---
tools/testing/se
On Mon, May 12, 2025 at 10:18:05AM +0200, David Hildenbrand wrote:
> On 09.05.25 17:55, Lorenzo Stoakes wrote:
> > On Fri, May 09, 2025 at 05:30:32PM +0200, David Hildenbrand wrote:
> > > Let's test some basic functionality using /dev/mem. These tests will
> > > implicitly cover some PAT (Page Attr
On 09.05.25 10:18, Xin Li wrote:
On 5/6/2025 2:20 AM, Juergen Gross wrote:
Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to avoid
overhead with the call interface.
To me, this is a beneficial addition to the exist
This patch adds required changes to vcpu init to run a guest code
in vEL2 context and also adds NV specific helper functions.
Signed-off-by: Ganapatrao Kulkarni
---
tools/testing/selftests/kvm/Makefile.kvm | 2 +
.../kvm/include/arm64/kvm_util_arch.h | 3 +
.../selftests/kvm/inclu
Extend the vgic_init, vgic_irq and vgic_lpi_stress to run with NV
enabled(vEL2). NV enabled using command line argument and it is
disabled by default. The NV mode is applicable to GICv3 tests only.
Signed-off-by: Ganapatrao Kulkarni
---
tools/testing/selftests/kvm/arm64/vgic_init.c | 54
Adding code to run guest_code in vEL2.
NV is enabled using command line argument and it is disabled by default.
NV is only enabled on ARM64, for other architectures the test will exit
with an ASSERT, if tried to run with NV enabled.
Signed-off-by: Ganapatrao Kulkarni
---
.../selftests/kvm/kvm_p
Extend page_fault_test to run guest code with NV enabled.
NV is enabled using command line argument and it is disabled by default.
Signed-off-by: Ganapatrao Kulkarni
---
.../selftests/kvm/arm64/page_fault_test.c | 35 ---
1 file changed, 30 insertions(+), 5 deletions(-)
diff
Now with the mentioned patch really attached. :-)
On 12.05.25 13:20, Jürgen Groß wrote:
On 09.05.25 10:18, Xin Li wrote:
On 5/6/2025 2:20 AM, Juergen Gross wrote:
Instead of having callback functions for rdmsr/wrmsr on native, switch
to inline the respective instructions directly in order to a
On 5/7/25 10:26, Stefano Garzarella wrote:
> On Wed, 7 May 2025 at 00:47, Michal Luczaj wrote:
>>
>> On 5/6/25 11:46, Stefano Garzarella wrote:
>>> On Tue, 6 May 2025 at 11:43, Stefano Garzarella wrote:
On Thu, May 01, 2025 at 10:05:24AM +0200, Michal Luczaj wrote:
> There was an is
> >>> +static bool sgx_has_eupdatesvn;
> >>
> >> We have CPUID "caches" of sorts. Why open code this?
> >
> > You mean X86_FEATURE_*?
>
> Yes.
>
> > SGX CPUID is only defined in SGX code currently (btw, I am not sure
> > why they are made special) so it doesn’t support this.
>
> It's only used i
On 5/9/25 18:42, Alexey Gladkov wrote:
> In order to avoid symbol conflicts if they appear in the same binary, a
> more unique alias identifier can be generated.
>
> Signed-off-by: Alexey Gladkov
Reviewed-by: Petr Pavlu
-- Petr
On 5/9/25 18:42, Alexey Gladkov wrote:
> The __MODULE_INFO macros always use __MODULE_INFO_PREFIX. The only way
> to use a different prefix is to override __MODULE_INFO_PREFIX, which is
> not very useful.
>
> The new macro will be used in file2alias.c to generate modalias for
> builtin modules.
>
> On Apr 30, 2025, at 9:21 PM, Jon Kohler wrote:
>
>
>
>> On Apr 16, 2025, at 6:15 AM, Eugenio Perez Martin
>> wrote:
>>
>> !---|
>> CAUTION: External Email
>>
>> |-
On Tue, May 06, 2025 at 09:59:44AM -0700, Tanmay Shah wrote:
> Powering off RPU using force_pwrdwn call results in system failure
> if there are multiple users of that RPU node. Better mechanism is to use
> request_node and release_node EEMI calls. With use of these EEMI calls,
> platform managemen
On Sat, May 10, 2025 at 10:51:58PM +1000, Alexey Kardashevskiy wrote:
>
>
> On 10/5/25 08:07, Jason Gunthorpe wrote:
> > On Fri, May 09, 2025 at 12:57:18PM +1000, Alexey Kardashevskiy wrote:
> > >
> > >
> > > On 7/5/25 22:24, Jason Gunthorpe wrote:
> > > > On Wed, May 07, 2025 at 09:18:29PM +10
On Sat, May 10, 2025 at 04:05:29AM -0600, Jonathan Corbet wrote:
> Alexey Dobriyan writes:
>
> > Every time I open Documentation/CodingStyle it says the party moved
> > somewhere else. :-(
> >
> > Of course, I forget where it moved to by the next time.
> >
> > Signed-off-by: Alexey Dobriyan
> >
On Sat, May 10, 2025 at 07:56:03PM +0100, David Laight wrote:
> On Fri, 9 May 2025 23:34:29 +0300
> Alexey Dobriyan wrote:
>
> > Signed-off-by: Alexey Dobriyan
> > ---
> > Documentation/process/coding-style.rst | 16 +++-
> > 1 file changed, 15 insertions(+), 1 deletion(-)
> >
> >
On 5/9/2025 11:18 PM, Greg KH wrote:
> On Fri, May 09, 2025 at 11:34:30PM +0300, Alexey Dobriyan wrote:
>> Require set of curlies {} in all if/else branches and all loops
>> not matter how simple.
>
> Sorry, but no, we are not going to change this long-term coding style
> rule for no real reason a
On 5/13/2025 12:16 AM, Ashish Kalra wrote:
From: Ashish Kalra
During platform init, SNP initialization may fail for several reasons,
such as firmware command failures and incompatible versions. However,
the KVM capability may continue to advertise support for it.
The platform may have SNP enab
在 5/13/2025 3:10 AM, Konrad Dybcio 写道:
On 5/12/25 5:20 AM, Lijuan Gao wrote:
在 5/9/2025 4:54 PM, Konrad Dybcio 写道:
On 5/9/25 9:37 AM, Lijuan Gao wrote:
在 5/8/2025 10:41 PM, Konrad Dybcio 写道:
On 5/7/25 12:26 PM, Lijuan Gao wrote:
Add a simple-mfd representing IMEM on QCS615 and define
On 5/12/2025 11:06 PM, Jürgen Groß wrote:
On 13.05.25 07:55, Xin Li wrote:
On 5/12/2025 4:24 AM, Juergen Gross wrote:
Now with the mentioned patch really attached. :-)
Does it allow patching with an instruction more than 6 bytes long?
The immediate form MSR instructions are 9 bytes long.
99 matches
Mail list logo
