JIRA: https://issues.redhat.com/browse/RHEL-83461
This patch is a backport of the following upstream commit:
commit 15aa8fb852f995dd234a57f12dfb989044968bb6
Author: Ard Biesheuvel <ardb@kernel.org>
Date: Thu May 16 11:05:42 2024 +0200
x86/efistub: Omit physical KASLR when memory reservations exist
The legacy decompressor has elaborate logic to ensure that the
randomized physical placement of the decompressed kernel image does not
conflict with any memory reservations, including ones specified on the
command line using mem=, memmap=, efi_fake_mem= or hugepages=, which are
taken into account by the kernel proper at a later stage.
When booting in EFI mode, it is the firmware's job to ensure that the
chosen range does not conflict with any memory reservations that it
knows about, and this is trivially achieved by using the firmware's
memory allocation APIs.
That leaves reservations specified on the command line, though, which
the firmware knows nothing about, as these regions have no other special
significance to the platform. Since commit
a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
these reservations are not taken into account when randomizing the
physical placement, which may result in conflicts where the memory
cannot be reserved by the kernel proper because its own executable image
resides there.
To avoid having to duplicate or reuse the existing complicated logic,
disable physical KASLR entirely when such overrides are specified. These
are mostly diagnostic tools or niche features, and physical KASLR (as
opposed to virtual KASLR, which is much more important as it affects the
memory addresses observed by code executing in the kernel) is something
we can live without.
Closes: https://lkml.kernel.org/r/FA5F6719-8824-4B04-803E-82990E65E627%40akamai.com
Reported-by: Ben Chaney <bchaney@akamai.com>
Fixes: a1b87d54f4e4 ("x86/efistub: Avoid legacy decompressor when doing EFI boot")
Cc: <stable@vger.kernel.org> # v6.1+
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Charles Haithcock <chaithco@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 27e850c88df0e25474a8caeb2903e2e90b62c1dc
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 28 May 2025 09:49:42 +0100
The notifier callback node allocation is currently done while holding
the notify_lock mutex. While this is safe even if memory allocation may
sleep, we need to move the allocation outside the locked region in
preparation to move from using muxtes to rwlocks.
Move the memory allocation to avoid potential sleeping in atomic context
once the locks are moved from mutex to rwlocks.
Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks")
Message-Id: <20250528-ffa_notif_fix-v1-2-5ed7bc7f8437@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit a833d31ad867103ba72a0b73f3606f4ab8601719
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 28 May 2025 09:49:41 +0100
Commit e0573444edbf ("firmware: arm_ffa: Add interfaces to request
notification callbacks") adds support for notifier callbacks by allocating
and inserting a callback node into a hashtable during registration of
notifiers. However, during unregistration, the code only removes the
node from the hashtable without freeing the associated memory, resulting
in a memory leak.
Resolve the memory leak issue by ensuring the allocated notifier callback
node is properly freed after it is removed from the hashtable entry.
Fixes: e0573444edbf ("firmware: arm_ffa: Add interfaces to request notification callbacks")
Message-Id: <20250528-ffa_notif_fix-v1-1-5ed7bc7f8437@arm.com>
Reviewed-by: Jens Wiklander <jens.wiklander@linaro.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 4567bdaaaaa1744da3d7da07d9aca2f941f5b4e5
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Fri, 21 Mar 2025 11:57:00 +0000
Completion of the FFA_PARTITION_INFO_GET ABI transfers the ownership of
the caller’s Rx buffer from the producer(typically partition mnager) to
the consumer(this driver/OS). FFA_RX_RELEASE transfers the ownership
from the consumer back to the producer.
However, when we set the flag to just return the count of partitions
deployed in the system corresponding to the specified UUID while
invoking FFA_PARTITION_INFO_GET, the Rx buffer ownership shouldn't be
transferred to this driver. We must be able to skip transferring back
the ownership to the partition manager when we request just to get the
count of the partitions as the buffers are not acquired in this case.
Firmware may return FFA_RET_DENIED or other error for the ffa_rx_release()
in such cases.
Fixes: bb1be7498500 ("firmware: arm_ffa: Add v1.1 get_partition_info support")
Message-Id: <20250321115700.3525197-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit c67c2332f8c80b03990914dfb66950c8d2fb87d8
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Sun, 23 Feb 2025 21:39:09 +0000
The FF-A notification id list received in response to the call
FFA_NOTIFICATION_INFO_GET is encoded as: partition ID followed by 0 or
more vCPU ID. The count includes all of them.
Fix the issue by skipping the first/partition ID so that only the list
of vCPU IDs are processed correctly for a given partition ID. The first/
partition ID is read before the start of the loop.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250223213909.1197786-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 3e282f41585c4dd49b688bd6395fd6f21a57c9f7
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Fri, 21 Feb 2025 09:56:32 +0000
The return value ret.a2 is of type unsigned long and FFA_RET_NO_DATA is
a negative value.
Since the return value from the firmware can be just 32-bit even on
64-bit systems as FFA specification mentions it as int32 error code in
w0 register, explicitly casting to s32 ensures correct sign interpretation
when comparing against a signed error code FFA_RET_NO_DATA.
Without casting, comparison between unsigned long and a negative
constant could lead to unintended results due to type promotions.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250221095633.506678-2-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit cecf6a504137aa238d768ae440a1f6488cb2f436
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Fri, 21 Feb 2025 09:56:31 +0000
The return value ver.a0 is unsigned long type and FFA_RET_NOT_SUPPORTED
is a negative value.
Since the return value from the firmware can be just 32-bit even on
64-bit systems as FFA specification mentions it as int32 error code in
w0 register, explicitly casting to s32 ensures correct sign interpretation
when comparing against a signed error code FFA_RET_NOT_SUPPORTED.
Without casting, comparison between unsigned long and a negative
constant could lead to unintended results due to type promotions.
Fixes: 3bbfe98710 ("firmware: arm_ffa: Add initial Arm FFA driver support")
Reported-by: Andrei Homescu <ahomescu@google.com>
Message-Id: <20250221095633.506678-1-sudeep.holla@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 9472fe20d3968743e683bd48dace02b4accd7736
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:39:00 +0000
Currently it is assumed that the driver always calls ffa_notification_get()
at the NS physical FF-A instance to request the SPMC to return pending
SP or SPM Framework notifications. However, in order to support the driver
invoking ffa_notification_get() at virtual FF-A instance, we need to make
sure correct bits are enabled in the bitmaps enable flag.
It is expected to have hypervisor framework and VM notifications bitmap
to be zero at the non-secure physical FF-A instance.
Message-Id: <20250217-ffa_updates-v3-19-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit be61da938576671c664382a059f961d7b4b2fc41
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:59 +0000
A partition can implement multiple UUIDs and currently we successfully
register each UUID service as a FF-A device. However when adding the
same partition info to the XArray which tracks the SRI callbacks more
than once, it fails.
In order to allow multiple UUIDs per partition to register SRI callbacks
the partition information stored in the XArray needs to be extended to
a listed list.
A function to remove the list of partition information in the XArray
is not added as there are no users at the time. All the partitions are
added at probe/initialisation and removed at cleanup stage.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-18-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 285a5ea0f542db94c3ed11e01a71abb47d15cbf5
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:58 +0000
Currently FF-A specification defines only one framework notification:
RX buffer full notification. This notification is signaled by the
partition manager during transmission of a partition message through
indirect messaging to,
1. Notify an endpoint that it has a pending message in its Rx buffer.
2. Inform the message receiver’s scheduler via the schedule receiver
interrupt that the receiver must be run.
In response to an FFA_MSG_SEND2 invocation by a sender endpoint, the
framework performs the following actions after the message is copied
from the Tx buffer of the sender to the Rx buffer of the receiver:
1. The notification is pended in the framework notification bitmap of
the receiver.
2. The partition manager of the endpoint that contains receiver’s
scheduler pends the schedule receiver interrupt for this endpoint.
The receiver receives the notification and copies out the message from
its Rx buffer.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-17-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit c10debfe7f028c11f7a501a0f8e937c9be9e5327
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:57 +0000
Framework notifications are doorbells that are rung by the partition
managers to signal common events to an endpoint. These doorbells cannot
be rung by an endpoint directly. A partition manager can signal a
Framework notification in response to an FF-A ABI invocation by an
endpoint.
Two additional notify_ops interface is being added for any FF-A device/
driver to register and unregister for such a framework notifications.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-16-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit a3d73fe8ae5db389f2108a052c0a9c3c3fbc29cf
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:56 +0000
Currently, we store the type of the notification in the notifier_cb_info
structure that is put into the hast list to identify if the notification
block is for the secure partition or the non secure VM.
In order to support framework notifications to reuse the hash list and
to avoid creating one for each time, we need store the ffa_device pointer
itself as the same notification ID in framework notifications can be
registered by multiple FF-A devices.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-15-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 07b760e713255a2224cfaad62eeaae85de913bac
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:55 +0000
Currently, the framework notifications are not supported at all.
handle_notif_callbacks() doesn't handle them though it is called with
framework bitmap. Make that explicit by adding checks for the same.
Also, we need to further classify the framework notifications as Secure
Partition Manager(SPM) and NonSecure Hypervisor(NS_HYP). Extend/change
notify_type enumeration to accommodate all the 4 type and rejig the
values so that it can be reused in the bitmap enable mask macros.
While at this, move ffa_notify_type_get() so that it can be used in
notifier_hash_node_get() in the future.
No functional change.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-14-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 9982cabf403fbd06a120a2d5b21830effd32b370
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:54 +0000
In order to keep the uniformity, just move the ffa_partitions_cleanup()
before it's first usage and drop the unnecessary forward declaration.
No functional change.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-13-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit efff6a7f16b34fd902f342b58bd8bafc2d6f2fd1
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:53 +0000
When the firmware compatibility was handled previously in the commit
8e3f9da608f1 ("firmware: arm_ffa: Handle compatibility with different firmware versions"),
we only addressed firmware versions that have higher minor versions
compared to the driver version which is should be considered compatible
unless the firmware returns NOT_SUPPORTED.
However, if the firmware reports higher major version than the driver
supported, we need to reject it. If the firmware can work in a compatible
mode with the driver requested version, it must return the same major
version as requested.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-12-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 9fac08d9d9855fbb49bf2342c964ad3d861bfafe
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:52 +0000
The basic and mandatory features of FF-A v1.2 are all supported now.
The driver supported version can be bumped from v1.1 to v1.2
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-11-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 910cc1acc9b42186db586c2fa9b48de34d651e7b
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:51 +0000
FF-A v1.2 introduces UUID field in partition message header used in
FFA_MSG_SEND2 to enable partitions/endpoints exposing multiple UUIDs.
Add the support for passing UUID in FFA_MSG_SEND2.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-10-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 46dcd68aaccac0812c12ec3f4e59c8963e2760ad
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:49 +0000
Both the FF-A core and the bus were in a single module before the
commit 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules").
The arm_ffa_bus_exit() takes care of unregistering all the FF-A devices.
Now that there are 2 distinct modules, if the core driver is unloaded and
reloaded, it will end up adding duplicate FF-A devices as the previously
registered devices weren't unregistered when we cleaned up the modules.
Fix the same by unregistering all the FF-A devices on the FF-A bus during
the cleaning up of the partitions and hence the cleanup of the module.
Fixes: 18c250bd7ed0 ("firmware: arm_ffa: Split bus and driver into distinct modules")
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-8-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 2f622a8b0722d332a2a149794a3add47bc9bdcf3
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:48 +0000
Currently it is assumed that the firmware doesn't present the host
partition in the list of partitions presented as part of the response
to PARTITION_INFO_GET from the firmware. However, there are few
platforms that prefer to present the same in the list of partitions.
It is not manadatory but not restricted as well.
So handle the same by making sure to check the presence of the host
VM ID in the XArray partition information maintained/managed in the
driver before attempting to add it.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-7-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 3c3d6767466ea316869c9f2bdd976aec8ce44545
Author: Viresh Kumar <viresh.kumar@linaro.org>
Date: Mon, 17 Feb 2025 15:38:47 +0000
Move the common code handling addition of the FF-A partition information
into the XArray as a new routine. No functional change.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-6-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 7bc0f589c81d62bc95f9ed142847219fc5d8ef6c
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:46 +0000
Currently the FF-A driver doesn't support big-endian correctly. It is
hard to regularly test the setup due to lack of test infrastructure and
tools.
In order to support full stack, we need to take small steps in getting
the support for big-endian kernel added slowly. This change fixes the
support in __ffa_partition_info_regs_get() so that the response from the
firmware are converted correctly as required. With this change, we can
enumerate all the FF-A devices correctly in the big-endian kernel if the
FFA_PARTITION_INFO_REGS_GET is supported.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-5-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit f94ebb72406779637dbdb2c192a5e99f43375036
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:45 +0000
Currently the FF-A driver doesn't support big-endian correctly. It is
hard to regularly test the setup due to lack of test infrastructure and
tools.
In order to support full stack, we need to take small steps in getting
the support for big-endian kernel added slowly. This change fixes the
support in __ffa_partition_info_get() so that the response from the
firmware are converted correctly as required. With this change, we can
enumerate all the FF-A devices correctly in the big-endian kernel.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-4-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 8768972cbbeacd673f09dc1f8e198e03ccfa9f52
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:44 +0000
Currently ffa_sync_send_receive2() takes UUID as a separate parameter
instead of using the one available in ffa_device structure.
Change the prototype of ffa_sync_send_receive2() to align with the
ffa_sync_send_receive() and use ffa_device->uuid.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-3-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit b7c9f32614f17c76ab26b8ee0109c868d7e054fe
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Mon, 17 Feb 2025 15:38:43 +0000
Currently ffa_partition_info structure holds the UUID in the format
compatible with the firmware interface. However, most of the functions
in the FF-A core driver deals directly with uuid_t type.
Replace UUID buffer to standard UUID format in the ffa_partition_info
structure.
Tested-by: Viresh Kumar <viresh.kumar@linaro.org>
Message-Id: <20250217-ffa_updates-v3-2-bd1d9de615e7@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 6fe437cfe2cdc797b03f63b338a13fac96ed6a08
Author: Levi Yun <yeoreum.yun@arm.com>
Date: Tue, 3 Dec 2024 14:31:08 +0000
Currently, ffa_dev->properties is set after the ffa_device_register()
call return in ffa_setup_partitions(). This could potentially result in
a race where the partition's properties is accessed while probing
struct ffa_device before it is set.
Update the ffa_device_register() to receive ffa_partition_info so all
the data from the partition information received from the firmware can
be updated into the struct ffa_device before the calling device_register()
in ffa_device_register().
Fixes: e781858488 ("firmware: arm_ffa: Add initial FFA bus support for device enumeration")
Signed-off-by: Levi Yun <yeoreum.yun@arm.com>
Message-Id: <20241203143109.1030514-2-yeoreum.yun@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit b0798838418abe996d9b618d341d865462264cbe
Author: Gavin Shan <gshan@redhat.com>
Date: Mon, 14 Oct 2024 10:47:24 +1000
Copying from a 144 byte structure arm_smccc_1_2_regs at an offset of 32
into an 112 byte struct ffa_send_direct_data2 causes a compile-time warning:
| In file included from drivers/firmware/arm_ffa/driver.c:25:
| In function 'fortify_memcpy_chk',
| inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:504:3:
| include/linux/fortify-string.h:580:4: warning: call to '__read_overflow2_field'
| declared with 'warning' attribute: detected read beyond size of field
| (2nd parameter); maybe use struct_group()? [-Wattribute-warning]
| __read_overflow2_field(q_size_field, size);
Fix it by not passing a plain buffer to memcpy() to avoid the overflow
warning.
Fixes: aaef3bc98129 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2")
Signed-off-by: Gavin Shan <gshan@redhat.com>
Message-Id: <20241014004724.991353-1-gshan@redhat.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 629253b2f6d74e7bf9e7e3134ed6c8355a3c8619
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 9 Sep 2024 11:09:24 +0000
Copying to a 16 byte structure into an 8-byte struct member
causes a compile-time warning:
| In file included from drivers/firmware/arm_ffa/driver.c:25:
| In function 'fortify_memcpy_chk',
| inlined from 'export_uuid' at include/linux/uuid.h:88:2,
| inlined from 'ffa_msg_send_direct_req2' at drivers/firmware/arm_ffa/driver.c:488:2:
| include/linux/fortify-string.h:571:25: error: call to '__write_overflow_field'
| declared with attribute warning: detected write beyond size of field
| (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
| __write_overflow_field(p_size_field, size);
Use a union for the conversion instead and make sure the byte order
is fixed in the process.
Fixes: aaef3bc98129 ("firmware: arm_ffa: Add support for FFA_MSG_SEND_DIRECT_{REQ,RESP}2")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Message-Id: <20240909110938.247976-1-arnd@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 61824feae5c07987f70519b1235e50baa138b3c2
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:28:00 +0100
An endpoint can discover the minimum size, maximum size and alignment
boundary for the Rx/Tx buffers by passing the function ID of the
FFA_RXTX_MAP ABI as input in the FFA_FEATURES interface. The maximum
size is an optional field and a value of 0 means that the partition
manager or the hypervisor does not enforce a maximum size.
Use the discovery mechanism and remove the hardcoded 4kB buffer size.
If the discovery fails, it still defaults to 4kB.
Message-Id: <20240820-ffa_v1-2-v2-7-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit eaca7ef8f31a9040021683d381ddb83eb6fd7774
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:27:59 +0100
Successful completion of both direct messaging function can be indicated
through an invocation of FFA_YIELD or GGA_INTERRUPT by the callee.
FFA_INTERRUPT indicates that the direct request was interrupted and must
be resumed through the FFA_RUN interface which is already done in the
driver.
FFA_YIELD indicates that the receiver endpoint has transitioned to the
blocked runtime state and must be resumed through the FFA_RUN interface.
However, the way receiver endpoint gets unblocked is implementation
defined. So, the driver just sleeps for 1 - 2ms and issues FFA_RUN. It
can return to the caller with FFA_YIELD is the receiver endpoint is still
blocked.
Message-Id: <20240820-ffa_v1-2-v2-6-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit aaef3bc98129c86078b336f16788dd733b0728a4
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:27:58 +0100
FFA_MSG_SEND_DIRECT_{REQ,RESP} supported only x3-x7 to pass implementation
defined values as part of the message. This may not be sufficient sometimes
and also it would be good to use all the registers supported by SMCCC v1.2
(x0-x17) for such register based communication.
Also another limitation with the FFA_MSG_SEND_DIRECT_{REQ,RESP} is the
ability to target a specific service within the partition based on it's
UUID.
In order to address both of the above limitation, FF-A v1.2 introduced
FFA_MSG_SEND_DIRECT_{REQ,RESP}2 which has the ability to target the
message to a specific service based on its UUID within a partition as
well as utilise all the available registers(x4-x17 specifically) for
the communication.
This change adds support for FFA_MSG_SEND_DIRECT_REQ2 and
FFA_MSG_SEND_DIRECT_RESP2.
Message-Id: <20240820-ffa_v1-2-v2-5-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit ba85c644ac8dc37d9b01a3332c2f142cb4d46954
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:27:57 +0100
FF-A v1.2 introduced FFA_PARTITION_INFO_GET_REGS which is similar to
FFA_PARTITION_INFO_GET except that the former uses the registers to
get the required information instead of the Rx buffer which the latter
uses.
We need to first check if the platform supports this new API using
FFA_FEATURES so that we can fallback to the FFA_PARTITION_INFO_GET
(which is mandatory) if FFA_PARTITION_INFO_GET_REGS is not implemented.
Message-Id: <20240820-ffa_v1-2-v2-4-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit d37fff98262ddca6b6ef3b63f378136c04067c64
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:27:56 +0100
We need to use ffa_features() in ffa_partition_probe() to detect if
the newer FFA_PARTITION_INFO_GET_REGS API is supported in the platform
or not. To avoid unnecessary forward declaration within the file, let
us just move this ffa_features() earlier.
No funtional change.
Message-Id: <20240820-ffa_v1-2-v2-3-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 7c432a18ad216b4f7b08e93287586d60e12a3b7b
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:27:55 +0100
Arm Firmware Framework for A-profile(FFA) v1.2 introduces register based
discovery mechanism and direct messaging extensions that enables to target
specific UUID within a partition.
Let us add all the newly supported FF-A function IDs in the spec.
Also update to the error values and associated handling.
Message-Id: <20240820-ffa_v1-2-v2-2-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit fbbb0e5fd260dbc54df519b6d8e5b970274e9582
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Tue, 20 Aug 2024 15:27:54 +0100
These changes fixes a set of below coding style issues:
1. spaces required around that '=' (ctx:VxW)
2. possible unnecessary 'out of memory' message
3. unnecessary for single statement blocks
Message-Id: <20240820-ffa_v1-2-v2-1-18c0c5f3c65e@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 18c250bd7ed0fc6917bad13560851ef0f519778d
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 15 May 2024 10:40:28 +0100
Make the FF-A bus on its own as a distinct module initialized at
subsys_initcall level when builtin.
Keep the FF-A driver core stack, together with any configured transport,
in a different module initialized as module_init level.
FF-A drivers initialization is now changed to module_init level.
Acked-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20240515094028.1947976-2-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 9dd15934f60d1298ad1c427711f338a194294a78
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 15 May 2024 10:40:27 +0100
Currently FF-A bus ffa_device_match() handles the workaround for the
FF-A v1.0 devices which are not populated with UUID to match. The FF-A
bus layer calls into FF-A driver and populates the device UUID if it
matches with the driver attempting to match.
But this forces to have both FF-A bus and core driver to be bundled into
a single module. However, keep it as a single module adds problems for
the FF-A driver registrations and their initcall levels.
In preparation to split the FF-A bus and the core driver into distinct
modules, we need to move the workaround away from the FF-A bus layer.
We can add it into the FF-A core driver as a bus notifier.
In order to do so, we need to always match any driver with the device if
the UUID is NULL and then during the driver binding phase, we can populate
the UUID if it matches with the driver UUID table using the bus notifiers.
We also need to add a check for NULL UUID before calling the device/driver
probe as devices with NULL UUID is possible since we match all for that
case.
Acked-by: Sebastian Ene <sebastianene@google.com>
Link: https://lore.kernel.org/r/20240515094028.1947976-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 3a3e2b83e8059679e92be4273c601ea21e105a89
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 24 Apr 2024 14:16:40 +0100
Currently notif_pcpu_irq_work_fn() may get queued from the work that is
already running on the 'notif_pcpu_wq' workqueue. This may add
unnecessary delays and could be avoided if the work is called directly
instead.
This change removes queuing of the work when already running on the
'notif_pcpu_wq' workqueue thereby removing any possible delays in that
path.
Link: https://lore.kernel.org/r/20240424131640.706870-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit ddfade88f49d49b04930ae006ab0974eb547529c
Author: Dan Carpenter <dan.carpenter@linaro.org>
Date: Wed, 24 Apr 2024 14:40:43 +0300
The "msg" pointer is a struct and msg->offset is the sizeof(*msg). The
pointer here math means the memcpy() will write outside the bounds.
Cast "msg" to a u8 pointer to fix this.
Fixes: 02c19d84c7c5 ("firmware: arm_ffa: Add support for FFA_MSG_SEND2")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/cd5fb6b5-81fa-4a6d-b2b8-284ca704bbff@moroto.mountain
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 02c19d84c7c5026624d181b8e4cdc8488134d013
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 17 Apr 2024 10:09:31 +0100
The FFA_MSG_SEND2 can be used to transmit a partition message from
the Tx buffer of the sender(the driver in this case) endpoint to the Rx
buffer of the receiver endpoint.
An invocation of the FFA_MSG_SEND2 transfers the ownership of the Tx
buffer to the receiver endpoint(or any intermediate consumer). Completion
of an FFA_MSG_SEND2 invocation transfers the ownership of the buffer
back to the sender endpoint.
The framework defines the FFA_MSG_SEND2 interface to transmit a partition
message from the Tx buffer of the sender to the Rx buffer of a receiver
and inform the scheduler that the receiver must be run.
Link: https://lore.kernel.org/r/20240417090931.2866487-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 3c258bf6bf29d8c9f9b358c64f6e9f4510c91ff9
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 17 Apr 2024 10:09:21 +0100
The properies obtained from the partition information descriptor as
part of initial partitions discovery is useful as it contain info
if the partition
- Runs in AArch64 or AArch32 execution state
- Can send and/or receive direct requests
- Can send and receive indirect message
- Does support receipt of notifications.
These can be used for querying before attempting to do any of the
above operations.
Link: https://lore.kernel.org/r/20240417090921.2866447-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 0370fb127ce3432a4081fe1415a947308cb827f1
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Thu, 18 Apr 2024 11:29:32 +0100
If the firmware returns incorrect SRI/NRI number, we fail to set it up
in the kernel which is absolutely fine.
However, we don't reset the stashed value of sched_recv or notif_pend
IRQs. When we call ffa_notifications_cleanup() in case of failures to
setup the notifications, we end up calling free_percpu_irq() from
ffa_uninit_pcpu_irq() which results in the following warning:
| genirq: Flags mismatch irq 6. 00004401 (ARM-FFA-NPI) vs. 00004400 (IPI)
| ARM FF-A: Error registering percpu NPI nIRQ 6 : -16
| ARM FF-A: Notification setup failed -16, not enabled
| ------------[ cut here ]------------
| Trying to free already-free IRQ 6
| WARNING: CPU: 2 PID: 1 at kernel/irq/manage.c:2476 __free_percpu_irq+0x6c/0x138
| Modules linked in:
| CPU: 2 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc3 #211
| Hardware name: FVP Base RevC (DT)
| pstate: 614000c9 (nZCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : __free_percpu_irq+0x6c/0x138
| lr : __free_percpu_irq+0x6c/0x138
| Call trace:
| __free_percpu_irq+0x6c/0x138
| free_percpu_irq+0x48/0x84
| ffa_notifications_cleanup+0x78/0x164
| ffa_notifications_setup+0x368/0x3c0
| ffa_init+0x2b4/0x36c
| do_one_initcall+0xe0/0x258
| do_initcall_level+0x8c/0xac
| do_initcalls+0x54/0x94
| do_basic_setup+0x1c/0x28
| kernel_init_freeable+0x108/0x174
| kernel_init+0x20/0x1a4
| ret_from_fork+0x10/0x20
Fix the same by resetting the stashed copy of IRQ values to 0 in case
of any failure to set them up properly.
Cc: Jens Wiklander <jens.wiklander@linaro.org>
Link: https://lore.kernel.org/r/20240418102932.3093576-1-sudeep.holla@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 08530a2aa9214932a7e830f31af68881411c3335
Author: Jens Wiklander <jens.wiklander@linaro.org>
Date: Thu, 11 Apr 2024 13:57:34 +0100
The FF-A uses the notification pending interrupt to inform the receiver
that it has a pending notification. This is a virtual interrupt and is
used by the following type of receivers:
1. A guest/VM running under a hypervisor.
2. An S-EL1 SP running under a S-EL2 SPMC.
The rules that govern the properties of the NPI are the same as the
rules for the SRI with couple of exceptions. Both SRI and NPI can be
supported simultaneously.
The handling of NPI is also same as the handling of notification for the
self/primary VM with ID 0 except the absence of global notification.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Link: https://lore.kernel.org/r/20240411-ffa_npi_support-v2-3-927a670254e6@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit f936c242553febd5052c6178c1ac555adf837fec
Author: Sudeep Holla <sudeep.holla@arm.com>
Date: Thu, 11 Apr 2024 13:57:33 +0100
In preparation to support handling of Notification Pending Interrupt(NPI)
in addition to the existing support for Schedule Receiver Interrupt(SRI),
refactor the code around SRI handling so that NPI support can reuse some
of it. This change shouldn't have any functionality impact. It neither
adds the support for NPIs nor changes any SRI support.
Tested-by: Jens Wiklander <jens.wiklander@linaro.org>
Link: https://lore.kernel.org/r/20240411-ffa_npi_support-v2-2-927a670254e6@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 2b9c66d1abacbef91bdadc47fa8b9a3bd3a8fe99
Author: Jens Wiklander <jens.wiklander@linaro.org>
Date: Thu, 11 Apr 2024 13:57:32 +0100
When the FF-A driver is running inside a guest VM under an hypervisor,
the driver/guest VM doesn't have the permission/capability to request
the creation of notification bitmaps. For a VM, the hypervisor reserves
memory for its VM and hypervisor framework notification bitmaps and the
SPMC reserves memory for its SP and SPMC framework notification bitmaps
before the hypervisor initializes it.
The hypervisor does not initialize a VM if memory cannot be reserved
for all its notification bitmaps. So the creation of all the necessary
bitmaps are already done when the driver initialises and hence it can be
skipped. We rely on FFA_FEATURES(FFA_NOTIFICATION_BITMAP_CREATE) to fail
when running in the guest to handle this in the driver.
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Link: https://lore.kernel.org/r/20240411-ffa_npi_support-v2-1-927a670254e6@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 1a4bd2b128fb5ca62e4d1c5ca298d3d06b9c1e8e
Author: Jens Wiklander <jens.wiklander@linaro.org>
Date: Mon, 11 Mar 2024 12:07:00 +0100
FFA_NOTIFICATION_INFO_GET retrieves information about pending
notifications. Notifications can be either global or per VCPU. Global
notifications are reported with the partition ID only in the list of
endpoints with pending notifications. ffa_notification_info_get()
incorrectly expect no ID at all for global notifications. Fix this by
checking for ID = 1 instead of ID = 0.
Fixes: 3522be48d82b ("firmware: arm_ffa: Implement the NOTIFICATION_INFO_GET interface")
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
Reviewed-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Link: https://lore.kernel.org/r/20240311110700.2367142-1-jens.wiklander@linaro.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-102691
commit 0c565d16b80074e57e3e56240d13fc6cd6ed0334
Author: Cristian Marussi <cristian.marussi@arm.com>
Date: Mon, 8 Jan 2024 12:34:16 +0000
Make ffa_setup_partitions() fail, cleanup and return an error when the Host
partition setup fails: in such a case ffa_init() itself will fail.
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20240108-ffa_fixes_6-8-v1-6-75bf7035bc50@arm.com
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Marcin Juszkiewicz <mjuszkiewicz@redhat.com>
Patrick Talbert
Charles Haithcock
Marcin Juszkiewicz