* Re: [PATCH v14 13/44] arm64: RMI: Define the user ABI
From: Steven Price @ 2026-06-04 15:27 UTC (permalink / raw)
To: Wei-Lin Chang, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, Lorenzo.Pieralisi2
In-Reply-To: <vixej2afqamvr7eaksoepr3wmpwzp73rtgrageeyuawa6azotw@payxzyhymwbt>
On 26/05/2026 23:17, Wei-Lin Chang wrote:
> On Wed, May 13, 2026 at 02:17:21PM +0100, Steven Price wrote:
>> There is one CAP which identified the presence of CCA, and one ioctl.
>> The ioctl is used to populate memory during creation of the realm as
>> this requires the RMM to copy data from an unprotected address to the
>> protected memory - CCA does not support memory conversion where the
>> memory contents is preserved as this is incompatible with memory
>> encryption.
>
> Nit:
> I believe spelling out the CAP and ioctl names can improve the commit
> message. Also "memory conversion" is a little vague, maybe
>
> ... CCA does not support shared <-> private memory conversion where ...
>
> would make this clearer?
Thanks for the suggestions - yes I agree that would make it clearer.
Thanks,
Steve
> Thanks,
> Wei-Lin Chang
>
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * KVM_ARM_VCPU_RMI_PSCI_COMPLETE removed.
>> * KVM_ARM_RMI_POPULATE documentation updated to reflect that the
>> structure is written by the kernel.
>> * CAP number bumped.
>> Changes since v12:
>> * Change KVM_ARM_RMI_POPULATE to update the structure with the amount
>> that has been progressed rather than return the number of bytes
>> populated.
>> * Describe the flag KVM_ARM_RMI_POPULATE_FLAGS_MEASURE.
>> * CAP number is bumped.
>> * NOTE: The PSCI ioctl may be removed in a future spec release.
>> Changes since v11:
>> * Completely reworked to be more implicit. Rather than having explicit
>> CAP operations to progress the realm construction these operations
>> are done when needed (on populating and on first vCPU run).
>> * Populate and PSCI complete are promoted to proper ioctls.
>> Changes since v10:
>> * Rename symbols from RME to RMI.
>> Changes since v9:
>> * Improvements to documentation.
>> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
>> Changes since v8:
>> * Minor improvements to documentation following review.
>> * Bump the magic numbers to avoid conflicts.
>> Changes since v7:
>> * Add documentation of new ioctls
>> * Bump the magic numbers to avoid conflicts
>> Changes since v6:
>> * Rename some of the symbols to make their usage clearer and avoid
>> repetition.
>> Changes from v5:
>> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
>> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
>> ---
>> Documentation/virt/kvm/api.rst | 40 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/kvm.h | 13 +++++++++++
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index 52bbbb553ce1..ca68aae7faa2 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -6553,6 +6553,37 @@ KVM_S390_KEYOP_SSKE
>> Sets the storage key for the guest address ``guest_addr`` to the key
>> specified in ``key``, returning the previous value in ``key``.
>>
>> +4.145 KVM_ARM_RMI_POPULATE
>> +--------------------------
>> +
>> +:Capability: KVM_CAP_ARM_RMI
>> +:Architectures: arm64
>> +:Type: vm ioctl
>> +:Parameters: struct kvm_arm_rmi_populate (in/out)
>> +:Returns: 0 on success, < 0 on error
>> +
>> +::
>> +
>> + struct kvm_arm_rmi_populate {
>> + __u64 base;
>> + __u64 size;
>> + __u64 source_uaddr;
>> + __u32 flags;
>> + __u32 reserved;
>> + };
>> +
>> +Populate a region of protected address space by copying the data from the
>> +(non-protected) user space pointer provided into a protected region (backed by
>> +guestmem_fd). It implicitly sets the destination region to RIPAS RAM. This is
>> +only valid before any VCPUs have been run. The ioctl might not populate the
>> +entire region and in this case the kernel updates the fields `base`, `size` and
>> +`source_uaddr`. User space may have to repeatedly call it until `size` is 0 to
>> +populate the entire region.
>> +
>> +`flags` can be set to `KVM_ARM_RMI_POPULATE_FLAGS_MEASURE` to request that the
>> +populated data is hashed and added to the guest's Realm Initial Measurement
>> +(RIM).
>> +
>> .. _kvm_run:
>>
>> 5. The kvm_run structure
>> @@ -8904,6 +8935,15 @@ helpful if user space wants to emulate instructions which are not
>> This capability can be enabled dynamically even if VCPUs were already
>> created and are running.
>>
>> +7.47 KVM_CAP_ARM_RMI
>> +--------------------
>> +
>> +:Architectures: arm64
>> +:Target: VM
>> +:Parameters: None
>> +
>> +This capability indicates that support for CCA realms is available.
>> +
>> 8. Other capabilities.
>> ======================
>>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 6c8afa2047bf..b8cff0938041 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -996,6 +996,7 @@ struct kvm_enable_cap {
>> #define KVM_CAP_S390_USER_OPEREXEC 246
>> #define KVM_CAP_S390_KEYOP 247
>> #define KVM_CAP_S390_VSIE_ESAMODE 248
>> +#define KVM_CAP_ARM_RMI 249
>>
>> struct kvm_irq_routing_irqchip {
>> __u32 irqchip;
>> @@ -1669,4 +1670,16 @@ struct kvm_pre_fault_memory {
>> __u64 padding[5];
>> };
>>
>> +/* Available with KVM_CAP_ARM_RMI, only for VMs with KVM_VM_TYPE_ARM_REALM */
>> +#define KVM_ARM_RMI_POPULATE _IOWR(KVMIO, 0xd7, struct kvm_arm_rmi_populate)
>> +#define KVM_ARM_RMI_POPULATE_FLAGS_MEASURE (1 << 0)
>> +
>> +struct kvm_arm_rmi_populate {
>> + __u64 base;
>> + __u64 size;
>> + __u64 source_uaddr;
>> + __u32 flags;
>> + __u32 reserved;
>> +};
>> +
>> #endif /* __LINUX_KVM_H */
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH v14 13/44] arm64: RMI: Define the user ABI
From: Steven Price @ 2026-06-04 15:27 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Gavin Shan,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <86jysovpxf.wl-maz@kernel.org>
On 27/05/2026 16:21, Marc Zyngier wrote:
> On Wed, 13 May 2026 14:17:21 +0100,
> Steven Price <steven.price@arm.com> wrote:
>>
>> There is one CAP which identified the presence of CCA, and one ioctl.
>> The ioctl is used to populate memory during creation of the realm as
>> this requires the RMM to copy data from an unprotected address to the
>> protected memory - CCA does not support memory conversion where the
>> memory contents is preserved as this is incompatible with memory
>> encryption.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * KVM_ARM_VCPU_RMI_PSCI_COMPLETE removed.
>> * KVM_ARM_RMI_POPULATE documentation updated to reflect that the
>> structure is written by the kernel.
>> * CAP number bumped.
>> Changes since v12:
>> * Change KVM_ARM_RMI_POPULATE to update the structure with the amount
>> that has been progressed rather than return the number of bytes
>> populated.
>> * Describe the flag KVM_ARM_RMI_POPULATE_FLAGS_MEASURE.
>> * CAP number is bumped.
>> * NOTE: The PSCI ioctl may be removed in a future spec release.
>> Changes since v11:
>> * Completely reworked to be more implicit. Rather than having explicit
>> CAP operations to progress the realm construction these operations
>> are done when needed (on populating and on first vCPU run).
>> * Populate and PSCI complete are promoted to proper ioctls.
>> Changes since v10:
>> * Rename symbols from RME to RMI.
>> Changes since v9:
>> * Improvements to documentation.
>> * Bump the magic number for KVM_CAP_ARM_RME to avoid conflicts.
>> Changes since v8:
>> * Minor improvements to documentation following review.
>> * Bump the magic numbers to avoid conflicts.
>> Changes since v7:
>> * Add documentation of new ioctls
>> * Bump the magic numbers to avoid conflicts
>> Changes since v6:
>> * Rename some of the symbols to make their usage clearer and avoid
>> repetition.
>> Changes from v5:
>> * Actually expose the new VCPU capability (KVM_ARM_VCPU_REC) by bumping
>> KVM_VCPU_MAX_FEATURES - note this also exposes KVM_ARM_VCPU_HAS_EL2!
>> ---
>> Documentation/virt/kvm/api.rst | 40 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/kvm.h | 13 +++++++++++
>> 2 files changed, 53 insertions(+)
>
> $SUBJECT looks wrong. This is a KVM change, not an RMI change.
Ah, true I guess "KVM: arm64: Define the user ABI for CCA" is more accurate.
>>
>> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
>> index 52bbbb553ce1..ca68aae7faa2 100644
>> --- a/Documentation/virt/kvm/api.rst
>> +++ b/Documentation/virt/kvm/api.rst
>> @@ -6553,6 +6553,37 @@ KVM_S390_KEYOP_SSKE
>> Sets the storage key for the guest address ``guest_addr`` to the key
>> specified in ``key``, returning the previous value in ``key``.
>>
>> +4.145 KVM_ARM_RMI_POPULATE
>> +--------------------------
>> +
>> +:Capability: KVM_CAP_ARM_RMI
>> +:Architectures: arm64
>> +:Type: vm ioctl
>> +:Parameters: struct kvm_arm_rmi_populate (in/out)
>> +:Returns: 0 on success, < 0 on error
>> +
>> +::
>> +
>> + struct kvm_arm_rmi_populate {
>> + __u64 base;
>> + __u64 size;
>> + __u64 source_uaddr;
>> + __u32 flags;
>> + __u32 reserved;
>> + };
>> +
>> +Populate a region of protected address space by copying the data from the
>> +(non-protected) user space pointer provided into a protected region (backed by
>> +guestmem_fd). It implicitly sets the destination region to RIPAS RAM. This is
>> +only valid before any VCPUs have been run. The ioctl might not populate the
>> +entire region and in this case the kernel updates the fields `base`, `size` and
>> +`source_uaddr`. User space may have to repeatedly call it until `size` is 0 to
>> +populate the entire region.
>> +
>> +`flags` can be set to `KVM_ARM_RMI_POPULATE_FLAGS_MEASURE` to request that the
>> +populated data is hashed and added to the guest's Realm Initial Measurement
>> +(RIM).
>
> Where is that measurement stored? And retrieved? At least a pointer to
> that would help.
It's stored within the RMM and retrieved by the guest (using the RSI
interface). I'll update to:
`flags` can be set to `KVM_ARM_RMI_POPULATE_FLAGS_MEASURE` to request
that the populated data is hashed and added to the guest's Realm Initial
Measurement (RIM) stored by the RMM. This can then be retrieved by the
guest (using the RSI interface) to present to an attestation server.
Thanks,
Steve
>> +
>> .. _kvm_run:
>>
>> 5. The kvm_run structure
>> @@ -8904,6 +8935,15 @@ helpful if user space wants to emulate instructions which are not
>> This capability can be enabled dynamically even if VCPUs were already
>> created and are running.
>>
>> +7.47 KVM_CAP_ARM_RMI
>> +--------------------
>> +
>> +:Architectures: arm64
>> +:Target: VM
>> +:Parameters: None
>> +
>> +This capability indicates that support for CCA realms is available.
>> +
>> 8. Other capabilities.
>> ======================
>>
>> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
>> index 6c8afa2047bf..b8cff0938041 100644
>> --- a/include/uapi/linux/kvm.h
>> +++ b/include/uapi/linux/kvm.h
>> @@ -996,6 +996,7 @@ struct kvm_enable_cap {
>> #define KVM_CAP_S390_USER_OPEREXEC 246
>> #define KVM_CAP_S390_KEYOP 247
>> #define KVM_CAP_S390_VSIE_ESAMODE 248
>> +#define KVM_CAP_ARM_RMI 249
>>
>> struct kvm_irq_routing_irqchip {
>> __u32 irqchip;
>> @@ -1669,4 +1670,16 @@ struct kvm_pre_fault_memory {
>> __u64 padding[5];
>> };
>>
>> +/* Available with KVM_CAP_ARM_RMI, only for VMs with KVM_VM_TYPE_ARM_REALM */
>> +#define KVM_ARM_RMI_POPULATE _IOWR(KVMIO, 0xd7, struct kvm_arm_rmi_populate)
>> +#define KVM_ARM_RMI_POPULATE_FLAGS_MEASURE (1 << 0)
>> +
>> +struct kvm_arm_rmi_populate {
>> + __u64 base;
>> + __u64 size;
>> + __u64 source_uaddr;
>> + __u32 flags;
>> + __u32 reserved;
>> +};
>> +
>> #endif /* __LINUX_KVM_H */
>
> Thanks,
>
> M.
>
^ permalink raw reply
* Re: [PATCH v2 0/2] KVM: arm64: Sanitise host vCPU fields copied in flush_hyp_vcpu()
From: Fuad Tabba @ 2026-06-04 15:29 UTC (permalink / raw)
To: Hyunwoo Kim
Cc: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm
In-Reply-To: <20260604151210.1304051-1-imv4bel@gmail.com>
On Thu, 4 Jun 2026 at 16:12, Hyunwoo Kim <imv4bel@gmail.com> wrote:
>
> flush_hyp_vcpu() copies the host vCPU context and vGIC state into the
> hyp's private vCPU on every run. This series sanitises two fields that
> it currently copies verbatim (host -> EL2): __hyp_running_vcpu is
> cleared in the guest context, and used_lrs is bounded by the number of
> implemented list registers.
>
> v1 -> v2: split into two patches, one per field, per review.
For the series:
Reviewed-by: Fuad Tabba <tabba@google.com>
Tested-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
>
> Hyunwoo Kim (2):
> KVM: arm64: Clear __hyp_running_vcpu when flushing the pKVM hyp vCPU
> KVM: arm64: Bound used_lrs when flushing the pKVM hyp vCPU
>
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v14 14/44] arm64: RMI: Basic infrastructure for creating a realm.
From: Steven Price @ 2026-06-04 15:55 UTC (permalink / raw)
To: Suzuki K Poulose, Marc Zyngier
Cc: kvm, kvmarm, Catalin Marinas, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Gavin Shan, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <1bb9da2a-bcc2-4232-944e-0730e9e1f45a@arm.com>
On 02/06/2026 15:49, Suzuki K Poulose wrote:
> Hi Marc
>
> On 28/05/2026 08:10, Marc Zyngier wrote:
>> On Wed, 13 May 2026 14:17:22 +0100,
>> Steven Price <steven.price@arm.com> wrote:
>>>
>>> Introduce the skeleton functions for creating and destroying a realm.
>>> The IPA size requested is checked against what the RMM supports.
>>>
>>> The actual work of constructing the realm will be added in future
>>> patches.
>>
>> Again, $SUBJECT doesn't reflect that this is purely a KVM patch.
Indeed - "KVM: arm64: CCA" is a better prefix.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> Changes since v13:
>>> * Rebased and updated to RMM-v2.0-bet1.
>>> * Auxiliary granules have been removed in RMM-v2.0-bet1
>>> Changes since v12:
>>> * Drop the RMM_PAGE_{SHIFT,SIZE} defines - the RMM is now
>>> configured to
>>> be the same as the host's page size.
>>> * Rework delegate/undelegate functions to use the new RMI range based
>>> operations.
>>> Changes since v11:
>>> * Major rework to drop the realm configuration and make the
>>> construction of realms implicit rather than driven by the VMM
>>> directly.
>>> * The code to create RDs, handle VMIDs etc is moved to later patches.
>>> Changes since v10:
>>> * Rename from RME to RMI.
>>> * Move the stage2 cleanup to a later patch.
>>> Changes since v9:
>>> * Avoid walking the stage 2 page tables when destroying the realm -
>>> the real ones are not accessible to the non-secure world, and the
>>> RMM
>>> may leave junk in the physical pages when returning them.
>>> * Fix an error path in realm_create_rd() to actually return an
>>> error value.
>>> Changes since v8:
>>> * Fix free_delegated_granule() to not call
>>> kvm_account_pgtable_pages();
>>> a separate wrapper will be introduced in a later patch to deal with
>>> RTTs.
>>> * Minor code cleanups following review.
>>> Changes since v7:
>>> * Minor code cleanup following Gavin's review.
>>> Changes since v6:
>>> * Separate RMM RTT calculations from host PAGE_SIZE. This allows the
>>> host page size to be larger than 4k while still communicating
>>> with an
>>> RMM which uses 4k granules.
>>> Changes since v5:
>>> * Introduce free_delegated_granule() to replace many
>>> undelegate/free_page() instances and centralise the comment on
>>> leaking when the undelegate fails.
>>> * Several other minor improvements suggested by reviews - thanks for
>>> the feedback!
>>> Changes since v2:
>>> * Improved commit description.
>>> * Improved return failures for rmi_check_version().
>>> * Clear contents of PGD after it has been undelegated in case the RMM
>>> left stale data.
>>> * Minor changes to reflect changes in previous patches.
>>> ---
>>> arch/arm64/include/asm/kvm_emulate.h | 29 ++++++++++++++
>>> arch/arm64/include/asm/kvm_rmi.h | 51 +++++++++++++++++++++++++
>>> arch/arm64/kvm/arm.c | 12 ++++++
>>> arch/arm64/kvm/mmu.c | 12 +++++-
>>> arch/arm64/kvm/rmi.c | 57 ++++++++++++++++++++++++++++
>>> 5 files changed, 159 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/kvm_emulate.h b/arch/arm64/
>>> include/asm/kvm_emulate.h
>>> index 5bf3d7e1d92c..82fd777bd9bb 100644
>>> --- a/arch/arm64/include/asm/kvm_emulate.h
>>> +++ b/arch/arm64/include/asm/kvm_emulate.h
>>> @@ -688,4 +688,33 @@ static inline void vcpu_set_hcrx(struct kvm_vcpu
>>> *vcpu)
>>> vcpu->arch.hcrx_el2 |= HCRX_EL2_EnASR;
>>> }
>>> }
>>> +
>>> +static inline bool kvm_is_realm(struct kvm *kvm)
>>> +{
>>> + if (static_branch_unlikely(&kvm_rmi_is_available))
>>> + return kvm->arch.is_realm;
>>> + return false;
>>> +}
>>> +
>>> +static inline enum realm_state kvm_realm_state(struct kvm *kvm)
>>> +{
>>> + return READ_ONCE(kvm->arch.realm.state);
>>> +}
>>> +
>>> +static inline void kvm_set_realm_state(struct kvm *kvm,
>>> + enum realm_state new_state)
>>> +{
>>> + WRITE_ONCE(kvm->arch.realm.state, new_state);
>>> +}
>>> +
>>> +static inline bool kvm_realm_is_created(struct kvm *kvm)
>>> +{
>>> + return kvm_is_realm(kvm) && kvm_realm_state(kvm) !=
>>> REALM_STATE_NONE;
>>> +}
>>> +
>>> +static inline bool vcpu_is_rec(const struct kvm_vcpu *vcpu)
>>> +{
>>> + return false;
>>> +}
>>> +
>>> #endif /* __ARM64_KVM_EMULATE_H__ */
>>> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/
>>> asm/kvm_rmi.h
>>> index 4936007947fd..9de34983ee52 100644
>>> --- a/arch/arm64/include/asm/kvm_rmi.h
>>> +++ b/arch/arm64/include/asm/kvm_rmi.h
>>> @@ -6,12 +6,63 @@
>>> #ifndef __ASM_KVM_RMI_H
>>> #define __ASM_KVM_RMI_H
>>> +#include <asm/rmi_smc.h>
>>> +
>>> +/**
>>> + * enum realm_state - State of a Realm
>>> + */
>>> +enum realm_state {
>>> + /**
>>> + * @REALM_STATE_NONE:
>>> + * Realm has not yet been created. rmi_realm_create() has not
>>> + * yet been called.
>>> + */
>>> + REALM_STATE_NONE,
>>> + /**
>>> + * @REALM_STATE_NEW:
>>> + * Realm is under construction, rmi_realm_create() has been
>>> + * called, but it is not yet activated. Pages may be
>>> populated.
>>> + */
>>> + REALM_STATE_NEW,
>>> + /**
>>> + * @REALM_STATE_ACTIVE:
>>> + * Realm has been created and is eligible for execution with
>>> + * rmi_rec_enter(). Pages may no longer be populated with
>>> + * rmi_data_create().
>>> + */
>>> + REALM_STATE_ACTIVE,
>>> + /**
>>> + * @REALM_STATE_DYING:
>>> + * Realm is in the process of being destroyed or has
>>> already been
>>> + * destroyed.
>>> + */
>>> + REALM_STATE_DYING,
>>> + /**
>>> + * @REALM_STATE_DEAD:
>>> + * Realm has been destroyed.
>>> + */
>>> + REALM_STATE_DEAD
>>> +};
>>
>> What is the ABI status of this state? Is it purely internal to KVM? Or
>> is it something that the RMM actively tracks?
>
> The states are in line with what the RMM maintains for the Realm state,
> (Section A2.2.5 Realm Lifecycle)
> except for :
>
> 1. REALM_STATE_DYING is really a KVM internal state to indicate, we
> are in the process of destroying the Realm and no further requests
> needs to be serviced
>
> 2. We don't track the REALM_SYSTEM_OFF, REALM_ZOMBIE states separately
> as we :
> a) Always TERMINATE the Realm, just before the DESTROY
> b) SYSTEM_OFF is naturally triggering the tear down path, leading to
> DYING.
>
I'll add a comment:
+ * Mirrors the RMM's Realm lifecycle states where they are meaningful to KVM,
+ * with REALM_STATE_DYING being a KVM-internal state used to prevent further
+ * requests while teardown is in progress. KVM does not track REALM_SYSTEM_OFF
+ * or REALM_ZOMBIE separately as they naturally lead to teardown.
>
>
>>
>>> +
>>> /**
>>> * struct realm - Additional per VM data for a Realm
>>> + *
>>> + * @state: The lifetime state machine for the realm
>>> + * @rd: Kernel mapping of the Realm Descriptor (RD)
>>> + * @params: Parameters for the RMI_REALM_CREATE command
>>> + * @ia_bits: Number of valid Input Address bits in the IPA
>>> */
>>> struct realm {
>>> + enum realm_state state;
>>> + void *rd;
>>
>> Why is this void? Doesn't it have a proper type?
>
> Not really. This is an object that RMM manages (Realm Descriptor)
> in the Realm world. We use it as a parameter to address the Realm.
>
>
>>
>>> + struct realm_params *params;
>>> + unsigned int ia_bits;
>>
>> Consider reordering this structure to avoid holes.
Sure
>>> };
>>> void kvm_init_rmi(void);
>>> +u32 kvm_realm_ipa_limit(void);
>>
>> The use of 'realm' is confusing. This is not a per-realm property, but
>> something global. I'd rather reserve the term 'realm' for CCA VMs (cue
>> the two prototypes below).
>
> Agreed. Perhaps, kvm_rmm_ipa_limit() ?
Sounds good to me.
>
>>
>>> +
>>> +int kvm_init_realm(struct kvm *kvm);
>>> +void kvm_destroy_realm(struct kvm *kvm);
>>> #endif /* __ASM_KVM_RMI_H */
>>> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
>>> index 247e03b33035..18251e561524 100644
>>> --- a/arch/arm64/kvm/arm.c
>>> +++ b/arch/arm64/kvm/arm.c
>>> @@ -264,6 +264,13 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned
>>> long type)
>>> bitmap_zero(kvm->arch.vcpu_features, KVM_VCPU_MAX_FEATURES);
>>> + /* Initialise the realm bits after the generic bits are
>>> enabled */
>>> + if (kvm_is_realm(kvm)) {
>>> + ret = kvm_init_realm(kvm);
>>> + if (ret)
>>> + goto err_uninit_mmu;
>>> + }
>>> +
>>> return 0;
>>> err_uninit_mmu:
>>> @@ -326,6 +333,8 @@ void kvm_arch_destroy_vm(struct kvm *kvm)
>>> kvm_unshare_hyp(kvm, kvm + 1);
>>> kvm_arm_teardown_hypercalls(kvm);
>>> + if (kvm_is_realm(kvm))
>>> + kvm_destroy_realm(kvm);
>>> }
>>> static bool kvm_has_full_ptr_auth(void)
>>> @@ -486,6 +495,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm,
>>> long ext)
>>> else
>>> r = kvm_supports_cacheable_pfnmap();
>>> break;
>>> + case KVM_CAP_ARM_RMI:
>>> + r = static_key_enabled(&kvm_rmi_is_available);
>>> + break;
>>> default:
>>> r = 0;
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index d089c107d9b7..ba8286472286 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -877,10 +877,14 @@ static struct kvm_pgtable_mm_ops kvm_s2_mm_ops = {
>>> static int kvm_init_ipa_range(struct kvm_s2_mmu *mmu, unsigned
>>> long type)
>>> {
>>> + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
>>> u32 kvm_ipa_limit = get_kvm_ipa_limit();
>>> u64 mmfr0, mmfr1;
>>> u32 phys_shift;
>>> + if (kvm_is_realm(kvm))
>>> + kvm_ipa_limit = kvm_realm_ipa_limit();
>>> +
>>> phys_shift = KVM_VM_TYPE_ARM_IPA_SIZE(type);
>>> if (is_protected_kvm_enabled()) {
>>> phys_shift = kvm_ipa_limit;
>>> @@ -974,6 +978,8 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct
>>> kvm_s2_mmu *mmu, unsigned long t
>>> return -EINVAL;
>>> }
>>> + mmu->arch = &kvm->arch;
>>> +
>>> err = kvm_init_ipa_range(mmu, type);
>>> if (err)
>>> return err;
>>> @@ -982,7 +988,6 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct
>>> kvm_s2_mmu *mmu, unsigned long t
>>> if (!pgt)
>>> return -ENOMEM;
>>> - mmu->arch = &kvm->arch;
>>
>> Why moving this init?
>
> Because, we need to know the "kvm" instance for kvm_init_ipa_range to
> detect the limit that applies to Realms.
>
>>
>>> err = KVM_PGT_FN(kvm_pgtable_stage2_init)(pgt, mmu,
>>> &kvm_s2_mm_ops);
>>> if (err)
>>> goto out_free_pgtable;
>>> @@ -1114,7 +1119,10 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
>>> write_unlock(&kvm->mmu_lock);
>>> if (pgt) {
>>> - kvm_stage2_destroy(pgt);
>>> + if (!kvm_is_realm(kvm))
>>> + kvm_stage2_destroy(pgt);
>>> + else
>>> + kvm_pgtable_stage2_destroy_pgd(pgt);
>>
>> Why can't you make kvm_stage2_destroy() do the right thing? Surely the
>> PTs have to be reclaimed one way or another.
>
> Actually yes, we could make it work. We need to skip walking the page
> table for Realms. We may be able to do the checks via pgt->mmu->arch-
>>kvm and skip the walking for Realms. ( The S2 is unmapped and torn
> down before the RD is destroyed in kvm_destroy_realm(). We can't
> rely on the contents of the PGDs to be zero - e.g., with MEC.)
Yes I'll move the check into kvm_stage2_destroy() instead with a comment
explaining what's going on.
>>
>>> kfree(pgt);
>>> }
>>> }
>>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>>> index 6e28b669ded2..f51ec667445e 100644
>>> --- a/arch/arm64/kvm/rmi.c
>>> +++ b/arch/arm64/kvm/rmi.c
>>> @@ -5,6 +5,8 @@
>>> #include <linux/kvm_host.h>
>>> +#include <asm/kvm_emulate.h>
>>> +#include <asm/kvm_mmu.h>
>>> #include <asm/kvm_pgtable.h>
>>> #include <asm/rmi_cmds.h>
>>> #include <asm/virt.h>
>>> @@ -14,6 +16,61 @@ static bool rmi_has_feature(unsigned long feature)
>>> return !!u64_get_bits(rmm_feat_reg0, feature);
>>> }
>>> +u32 kvm_realm_ipa_limit(void)
>>> +{
>>> + return u64_get_bits(rmm_feat_reg0, RMI_FEATURE_REGISTER_0_S2SZ);
>>> +}
>>> +
>>> +void kvm_destroy_realm(struct kvm *kvm)
>>> +{
>>> + struct realm *realm = &kvm->arch.realm;
>>> + size_t pgd_size = kvm_pgtable_stage2_pgd_size(kvm->arch.mmu.vtcr);
>>> +
>>> + if (realm->params) {
>>> + free_page((unsigned long)realm->params);
>>> + realm->params = NULL;
>>> + }
>>> +
>>> + if (!kvm_realm_is_created(kvm))
>>> + return;
>>> +
>>> + kvm_set_realm_state(kvm, REALM_STATE_DYING);
>>> +
>>> + write_lock(&kvm->mmu_lock);
>>> + kvm_stage2_unmap_range(&kvm->arch.mmu, 0,
>>> + BIT(realm->ia_bits - 1), true);
>>> + write_unlock(&kvm->mmu_lock);
>>> +
>>> + if (realm->rd) {
>>> + phys_addr_t rd_phys = virt_to_phys(realm->rd);
>>> +
>>> + if (WARN_ON(rmi_realm_terminate(rd_phys)))
>>> + return;
>>> +
>>> + if (WARN_ON(rmi_realm_destroy(rd_phys)))
>>> + return;
>>> + free_delegated_page(rd_phys);
>>> + realm->rd = NULL;
>>> + }
>>> +
>>> + if (WARN_ON(rmi_undelegate_range(kvm->arch.mmu.pgd_phys,
>>> pgd_size)))
>>> + return;
>>> +
>>> + kvm_set_realm_state(kvm, REALM_STATE_DEAD);
>>> +
>>> + /* Now that the Realm is destroyed, free the entry level RTTs */
>>> + kvm_free_stage2_pgd(&kvm->arch.mmu);
>>> +}
>>
>> This really needs documentation: what happens at each stage? What
>> memory is reclaimed when?
>
> Agreed.
>
>>
>> But even more importantly, why is this built in a completely parallel
>> way, potentially deviating from the existing KVM S2 management?
>
>
> RMM requires a Realm is not live at the time of REALM_DESTROY.
> (See section A2.2.4 Realm Liveness).
> i.e., All RECs are destroyed, Root RTTs wiped clean (no live mappings)
> before the RD is destroyed. So, we need to make sure all of this is
> done at Realm Destroy. Hence we delay the kvm_free_stage2_pgd() until
> we destroy the RD.
>
> Does that help? May be we could improve the comments around it.
I'll add a comment in kvm_destroy_realm().
Thanks,
Steve
>
> Suzuki
>
>
>
>> Thanks,>
>> M.
>>
>
^ permalink raw reply
* Re: [PATCH v2 1/5] arm64: Rename page table BSS section to .bss..pgtbl
From: Mark Brown @ 2026-06-04 16:09 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, catalin.marinas,
Ard Biesheuvel, Kevin Brodsky, Marc Zyngier
In-Reply-To: <20260604151151.150377-8-ardb+git@google.com>
[-- Attachment #1: Type: text/plain, Size: 863 bytes --]
On Thu, Jun 04, 2026 at 05:11:53PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Rename the .pgdir.bss section to .bss..pgtbl so that the compiler will
> notice the leading ".bss" and mark it as NOBITS by default (rather than
> PROGBITS, which would take up space in Image binary, forcing all of the
> preceding BSS to be emitted into the image as well). This supersedes the
> NOLOAD linker directive, which achieves the same thing, and can be
> therefore be dropped.
>
> Also, rename .pgdir to .pgtbl to be more generic, as page tables of
> various levels will reside here.
This addresses the boot failure, I'm still seeing KUnit failures due to
an unrelated bug that was fixed post -rc1 but we get into actually
trying to run KUnit tests which was the relevant thing:
Tested-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: defconfig: Enable ILI7807S DSI panel driver
From: Krzysztof Kozlowski @ 2026-06-04 16:12 UTC (permalink / raw)
To: Nabige Aala, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krishna Manikandan, Loic Poulain, Bjorn Andersson, Konrad Dybcio,
Will Deacon, Robin Murphy, Joerg Roedel (AMD)
Cc: linux-arm-msm, dri-devel, freedreno, devicetree, linux-kernel,
iommu, linux-arm-kernel
In-Reply-To: <0bbfd60c-236e-43e5-a150-93738961f3de@kernel.org>
On 04/06/2026 14:53, Krzysztof Kozlowski wrote:
> On 04/06/2026 14:30, Nabige Aala wrote:
>> Enable the ILI7807S 1080x1920 video-mode DSI panel driver as a module,
>> used on the Shikra CQM EVK board.
>
>
> Does Samsung Shikra CQM EVK have it? I guess no.
... and now I see this was already sent, so wasn't this reviewed?
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH v5 1/3] dt-bindings: mfd: aspeed,ast2x00-scu: Support AST2700 SoC1 pinctrl
From: Lee Jones @ 2026-06-04 16:16 UTC (permalink / raw)
To: Linus Walleij, Tony Lindgren, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Bartosz Golaszewski,
Lee Jones, Ryan Chen, Billy Tsai
Cc: patrickw3, linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, BMC-SW, openbmc, Andrew Jeffery, linux-clk,
Conor Dooley
In-Reply-To: <20260521-pinctrl-single-bit-v5-1-308be2c160fc@aspeedtech.com>
On Thu, 21 May 2026 17:17:44 +0800, Billy Tsai wrote:
> The AST2700 SoC integrates two interconnected SoC instances, each
> managed by its own System Control Unit (SCU).
>
> Allow the AST2700 SoC1 pin controller to be described as a child
> node of the SCU by extending the compatible strings accepted by
> the SCU binding.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: mfd: aspeed,ast2x00-scu: Support AST2700 SoC1 pinctrl
commit: e78aa289e86e3e5da6fd115e6a0faf1623bacb05
--
Lee Jones [李琼斯]
^ permalink raw reply
* RE: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Michael Kelley @ 2026-06-04 16:18 UTC (permalink / raw)
To: Aneesh Kumar K.V, Michael Kelley, Jason Gunthorpe, Michael Kelley
Cc: iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <yq5apl26qrof.fsf@kernel.org>
From: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Sent: Thursday, June 4, 2026 7:58 AM
>
> Michael Kelley <mhklinux@outlook.com> writes:
>
> > From: Jason Gunthorpe <jgg@ziepe.ca> Sent: Tuesday, June 2, 2026 5:55 PM
> >>
> >> On Tue, Jun 02, 2026 at 02:24:40PM +0000, Michael Kelley wrote:
> >>
> >> > Except that in a normal VM, the "unencrypted" pool attribute does *not*
> >> > describe the state of the memory itself. In a normal VM, the memory is
> >> > unencrypted, but the "unencrypted" pool attribute is false. That
> >> > contradiction is the essence of my concern.
> >>
> >> I would argue no..
> >>
> >> When CC is enabled the default state of memory in a Linux environment
> >> is "encrypted". You have to take a special action to "decrypt" it.
> >>
> >> Thus the default state of memory in a non-CC environment is also
> >> paradoxically "encrypted" too.
> >
> > The need to have such an unnatural premise is usually an indication
> > of a conceptual problem with the overall model, or perhaps just a
> > terminology problem.
> >
> > Here's a proposal. The new DMA attribute is DMA_ATTR_CC_SHARED.
> > Name the pool attribute "cc_shared" instead of "unencrypted". Having
> > "cc_shared" set to false in a normal VM doesn't lead to the non-sensical
> > situation of claiming that a normal VM is encrypted. The boolean
> > "unencrypted" parameter that has been added to various calls also
> > becomes "cc_shared". If "CC_SHARED" is a suitable name for the DMA
> > attribute, it ought to be suitable as the pool attribute. And everything
> > matches as well.
> >
>
> That is better. It would also simplify:
>
> if (mem->unencrypted != !!(attrs & DMA_ATTR_CC_SHARED))
> return NULL;
>
> to
> if (mem->cc_shared != !!(attrs & DMA_ATTR_CC_SHARED))
> return NULL;
>
>
> I already sent a v6 in the hope of getting this merged for the next
> merge window. Should I send a v7, or would you prefer that I do the
> rename on top of v6?
>
I would advocate for a v7 with the rename, vs. a separate follow-on
patch to do the rename, just to reduce churn. But I don't know what
the tradeoffs are in trying to hit the next merge window. If a follow-on
patch is more practical from a timing standpoint, I won't object.
Michael
^ permalink raw reply
* [PATCH v2] regulator: dt-bindings: mt6311: Convert to DT schema
From: Ninad Naik @ 2026-06-04 16:26 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek, me,
linux-kernel-mentees, skhan, Ninad Naik
Convert mediatek,mt6311 to DT schema.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Changes in v2:
- Correct "MediaTek" in the title.
- Drop "|" in the top-level description.
- Remove unnecessary regulator node description.
- Remove unused labels from example.
.../regulator/mediatek,mt6311-regulator.yaml | 70 +++++++++++++++++++
.../bindings/regulator/mt6311-regulator.txt | 35 ----------
2 files changed, 70 insertions(+), 35 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
delete mode 100644 Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
new file mode 100644
index 000000000000..f65ee2c90298
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6311-regulator.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mediatek,mt6311-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT6311 Regulator
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MediaTek MT6311 is an I2C power management IC that provides one step-down
+ converter and one low-dropout regulator. The regulators are named VDVFS and
+ VBIASN, respectively.
+
+properties:
+ compatible:
+ const: mediatek,mt6311-regulator
+
+ reg:
+ description: I2C slave address.
+ maxItems: 1
+
+ regulators:
+ type: object
+ description: List of regulators provided by this controller.
+
+ patternProperties:
+ "^(VDVFS|VBIASN)$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - regulators
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@6b {
+ compatible = "mediatek,mt6311-regulator";
+ reg = <0x6b>;
+
+ regulators {
+ VDVFS {
+ regulator-name = "VDVFS";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-ramp-delay = <10000>;
+ };
+
+ VBIASN {
+ regulator-name = "VBIASN";
+ regulator-min-microvolt = <200000>;
+ regulator-max-microvolt = <800000>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt b/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
deleted file mode 100644
index 84d544d8c1b1..000000000000
--- a/Documentation/devicetree/bindings/regulator/mt6311-regulator.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Mediatek MT6311 Regulator
-
-Required properties:
-- compatible: "mediatek,mt6311-regulator"
-- reg: I2C slave address, usually 0x6b.
-- regulators: List of regulators provided by this controller. It is named
- to VDVFS and VBIASN.
- The definition for each of these nodes is defined using the standard binding
- for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
-
-The valid names for regulators are:
-BUCK:
- VDVFS
-LDO:
- VBIASN
-
-Example:
- mt6311: pmic@6b {
- compatible = "mediatek,mt6311-regulator";
- reg = <0x6b>;
-
- regulators {
- mt6311_vcpu_reg: VDVFS {
- regulator-name = "VDVFS";
- regulator-min-microvolt = < 600000>;
- regulator-max-microvolt = <1400000>;
- regulator-ramp-delay = <10000>;
- };
- mt6311_ldo_reg: VBIASN {
- regulator-name = "VBIASN";
- regulator-min-microvolt = <200000>;
- regulator-max-microvolt = <800000>;
- };
- };
- };
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v8 2/5] thermal: samsung: Add Exynos ACPM TMU driver GS101
From: Peter Griffin @ 2026-06-04 16:30 UTC (permalink / raw)
To: Tudor Ambarus
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, André Draszik, Alim Akhtar, jyescas,
linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260603-acpm-tmu-v8-2-0f1810a356e6@linaro.org>
On Wed, 3 Jun 2026 at 14:00, Tudor Ambarus <tudor.ambarus@linaro.org> wrote:
>
> Add driver for the Thermal Management Unit (TMU) managed via the Alive
> Clock and Power Manager (ACPM), found on Samsung Exynos SoCs such as
> the Google GS101.
>
> The TMU on the GS101 utilizes a hybrid management model shared between
> the Application Processor (AP) and the ACPM firmware. The driver
> maintains direct memory-mapped access to the TMU interrupt pending
> registers to identify thermal events, while delegating functional
> tasks - such as sensor initialization, threshold configuration, and
> temperature acquisition, to the ACPM firmware via the ACPM IPC
> protocol.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
* [PATCH v01] mailbox/pcc.c: ignore errors on type 4 channels.
From: Adam Young @ 2026-06-04 16:33 UTC (permalink / raw)
To: Sudeep Holla, Jassi Brar
Cc: linux-kernel, linux-hwmon, Rafael J . Wysocki, Len Brown,
linux-acpi, Andi Shyti, Guenter Roeck, Huisong Li, MyungJoo Ham,
Kyungmin Park, Chanwoo Choi, linux-arm-kernel
THE ACPI spec states:
"[The Error status register] Contains the processor relative address,
represented in Generic Address Structure (GAS) format, of the Error status
register. This field is ignored by the OSPM on slave channels"
Which Refers to type 4 channels.
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/14_Platform_Communications_Channel/Platform_Comm_Channel.html#hw-registers-based-communications-subspace-structure-type-5
Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
---
drivers/mailbox/pcc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 636879ae1db7..0deaf7907ed6 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -270,6 +270,9 @@ static int pcc_mbox_error_check_and_clear(struct pcc_chan_info *pchan)
u64 val;
int ret;
+ if (pchan->type == ACPI_PCCT_TYPE_EXT_PCC_SLAVE_SUBSPACE)
+ return 0;
+
ret = pcc_chan_reg_read(&pchan->error, &val);
if (ret)
return ret;
--
2.43.0
^ permalink raw reply related
* [GIT PULL] i.MX SoC driver updates for v7.2
From: Frank.Li @ 2026-06-04 16:45 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-soc-updates-for-v7.2
for you to fetch changes up to ccb4b54b8ecf1ebafef96d538cd6c5c8455bb390:
ARM: imx31: Fix IIM mapping leak in revision check (2026-06-01 15:58:13 -0400)
----------------------------------------------------------------
i.MX Soc Changes for v7.2
- Fix IIM mapping leak in imx31 revision check
- Fix CCM node reference leak in imx3
- Make scmi_imx_misc_ctrl_nb variable static in firmware driver
----------------------------------------------------------------
Krzysztof Kozlowski (1):
firmware: imx: sm-misc: Make scmi_imx_misc_ctrl_nb variable static
Yuho Choi (2):
ARM: imx3: Fix CCM node reference leak
ARM: imx31: Fix IIM mapping leak in revision check
arch/arm/mach-imx/cpu-imx31.c | 9 +++++++--
arch/arm/mach-imx/mm-imx3.c | 2 ++
drivers/firmware/imx/sm-misc.c | 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
^ permalink raw reply
* [GIT PULL] clk: samsung: drivers for v7.2
From: Krzysztof Kozlowski @ 2026-06-04 16:47 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: Krzysztof Kozlowski, Chanwoo Choi, linux-clk, Sylwester Nawrocki,
Alim Akhtar, Peter Griffin, linux-arm-kernel, linux-samsung-soc,
linux-kernel
Hi Stephen and Michael,
Notable change outside of this pull: Peter Griffin was added as co-maintainer
to Samsung SoC and Samsung SoC clocks. See also commit 20550601bf4 in
linux-next and
https://lore.kernel.org/all/178015858043.36212.8088079079471293822.b4-ty@b4/
Best regards,
Krzysztof
The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-clk-7.2
for you to fetch changes up to e11560b050ce867bd7d3ccea138231db54e2250a:
clk: samsung: exynos990: Fix PERIC0/1 USI clock types (2026-05-30 18:50:36 +0200)
----------------------------------------------------------------
Samsung SoC clock drivers changes for v7.2
1. Exynos850: Mark APM (Active Power Management) I3C clocks as critical,
because they are necessary for communication with firmware but we do
not have any consumer of them so far.
2. Exynos990: Correct the parents of a few muxes and propagate rate
requests up.
----------------------------------------------------------------
Alexey Klimov (1):
clk: samsung: exynos850: mark APM I3C clocks as critical
Denzeel Oliva (1):
clk: samsung: exynos990: Fix PERIC0/1 USI clock types
drivers/clk/samsung/clk-exynos850.c | 5 +-
drivers/clk/samsung/clk-exynos990.c | 307 +++++++++++++++++-------------------
2 files changed, 146 insertions(+), 166 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 4/5] KVM: arm64: Omit tag sync on stage-2 mappings of the zero page
From: Catalin Marinas @ 2026-06-04 16:50 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-arm-kernel, linux-kernel, will, Ard Biesheuvel,
Kevin Brodsky, Mark Brown, Marc Zyngier, stable
In-Reply-To: <20260604151151.150377-11-ardb+git@google.com>
On Thu, Jun 04, 2026 at 05:11:56PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> Commit
>
> f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
>
> removed the PG_mte_tagged flag from the zero page, but missed a KVM code
> path that may set this flag on the zero page when it is used in a
> stage-2 CoW mapping of anonymous memory.
>
> So disregard the zero page explicitly in sanitise_mte_tags().
>
> Fixes: f620d66af316 ("arm64: mte: Do not flag the zero page as PG_mte_tagged")
> Cc: <stable@vger.kernel.org> # 5.10.x
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [GIT PULL] i.MX ARM device tree changes for v7.2
From: Frank.Li @ 2026-06-04 17:02 UTC (permalink / raw)
To: soc, arm; +Cc: Frank.Li, kernel, imx, linux-arm-kernel
From: Frank.Li@nxp.com
The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-dt-7.2
for you to fetch changes up to 8772e1f64c7d69986821d71d8e58fd10594c9aa1:
dt-bindings: soc: imx: Add fsl,aipi-bus and fsl,emi-bus (2026-06-04 12:47:24 -0400)
----------------------------------------------------------------
i.MX ARM device tree changes for 7.2:
DT Binding Cleanup:
- Replaced undocumented compatible strings with proper ones:
* edt,edt-ft5x06 -> edt,edt-ft5206
* marvell,88E1510 -> ethernet-phy-ieee802.3-c22
* karo,imx6qdl-tx6-sgtl5000 -> simple-audio-card
- Fixed incorrect VAR-SOM-MX6UL references (corrected to VAR-SOM-MX6)
- Added missing required properties:
* #phy-cells for usb-nop-xceiv
* #io-channel-cells to ADC nodes
* bus-type for ov5642/ov5640 cameras
* ti,deskew = <0> for ti,tfp410
- Added missing supply properties (power-supply, vdd-supply, dvdd-supply, avdd-supply)
- Removed redundant/empty properties (bus-width for video-mux, empty clock-names)
- Fixed boolean property warnings and non-existent property references
- Converted TS-4800 watchdog to DT schema
- Renamed wdt nodes to watchdog for consistency
New Features Added:
- PCIe Root Port nodes and PERST property for imx6qdl, imx6sx, and imx7d
- OV5645 camera support for imx7d-pico-pi
- LVDS display panel support for imx6ul-var-som
- WiFi and Bluetooth support for VAR-SOM boards
- nvmem-layout support for imx7
- New bus bindings: fsl,aipi-bus and fsl,emi-bus
- New board binding: variscite,var-som-imx6ull
Code Refactoring:
- VAR-SOM-MX6UL/ULL: factored out common parts for CPU variants
- Separated audio, ethernet (ENET1/ENET2), and SD card support into reusable components
----------------------------------------------------------------
Alexander Feilke (1):
ARM: dts: imx7: add nvmem-layout
Alice Guo (1):
ARM: dts: freescale: add bootph-all to i.MX7ULP watchdog nodes
Eduard Bostina (2):
dt-bindings: watchdog: Convert TS-4800 to DT schema
ARM: dts: nxp: imx51-ts4800: Rename wdt node to watchdog
Frank Li (12):
ARM: dts: imx35: remove empty clock-names for nand-controller@bb000000
ARM: dts: imx25: remove empty clock-names for nand-controller@bb000000
ARM: dts: imx: add ti,deskew = <0> for ti,tfp410
ARM: dts: imx53-qsb: add dvdd and avdd supply for panel sii,43wvf1g
ARM: dts: imx53-ppd: add '#phy-cells' for usb-nop-xceiv
ARM: dts: imx: add (power|vdd)-supply for related node
ARM: dts: imx: remove redundant bus-width for video-mux
ARM: dts: imx: Add bus-type for ov5642/ov5640
ARM: dts: imx6qdl-tx6: remove undocumented karo,imx6qdl-tx6-sgtl5000 and keep only simple-audio-card
ARM: dts: imx: replace undocumented compatible string edt,edt-ft5x06 with edt,edt-ft5206
ARM: dts: imx6-display5: replace marvell,88E1510 with ethernet-phy-ieee802.3-c22
dt-bindings: soc: imx: Add fsl,aipi-bus and fsl,emi-bus
Hugo Villeneuve (14):
ARM: dts: imx6ul-var-som: fix warning for non-existent dc-supply property
ARM: dts: imx6ul-var-som: fix warning for boolean property with a value
ARM: dts: imx6ul-var-som: change incorrect VAR-SOM-MX6UL references
dt-bindings: arm: fsl: change incorrect VAR-SOM-MX6UL references
dt-bindings: arm: fsl: add variscite,var-som-imx6ull
ARM: dts: imx6ul-var-som: Factor out common parts for all CPU variants
ARM: dts: imx6ul-var-som-concerto: Factor out common parts for all CPU variants
ARM: dts: imx6ul-var-som-concerto: order DT properties
ARM: dts: imx6ul-var-som: factor out SD card support
ARM: dts: imx6ul-var-som: add proper Wifi and Bluetooth support
ARM: dts: imx6ul-var-som: factor out ENET2 ethernet support
ARM: dts: imx6ul-var-som: add support for EC configuration option (ENET1)
ARM: dts: imx6ul-var-som: factor out audio support
ARM: dts: imx6ul-var-som: add support for LVDS display panel
Lech Perczak (1):
ARM: dts: imx7d-pico-pi: add OV5645 camera support
Markus Niebel (1):
ARM: dts: imx6ul: add #io-channel-cells to ADC
Sherry Sun (3):
ARM: dts: imx6qdl: Add Root Port node and PERST property
ARM: dts: imx6sx: Add Root Port node and PERST property
ARM: dts: imx7d: Add Root Port node and PERST property
Documentation/devicetree/bindings/arm/fsl.yaml | 8 +-
.../devicetree/bindings/bus/fsl,spba-bus.yaml | 4 +
.../bindings/watchdog/technologic,ts4800-wdt.yaml | 40 +++
.../devicetree/bindings/watchdog/ts4800-wdt.txt | 25 --
arch/arm/boot/dts/nxp/imx/Makefile | 3 +
arch/arm/boot/dts/nxp/imx/imx25.dtsi | 1 -
arch/arm/boot/dts/nxp/imx/imx35.dtsi | 1 -
arch/arm/boot/dts/nxp/imx/imx51-babbage.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx53-cx9020.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx53-m53menlo.dts | 11 +-
arch/arm/boot/dts/nxp/imx/imx53-ppd.dts | 2 +
arch/arm/boot/dts/nxp/imx/imx53-qsb-common.dtsi | 10 +
.../boot/dts/nxp/imx/imx53-sk-imx53-atm0700d4.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx53-sk-imx53.dts | 7 +
arch/arm/boot/dts/nxp/imx/imx53-smd.dts | 2 +
arch/arm/boot/dts/nxp/imx/imx53-tx53-x03x.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6dl-gw53xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6dl-gw54xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6q-display5.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6q-gw52xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6q-gw53xx.dts | 2 -
arch/arm/boot/dts/nxp/imx/imx6q-gw54xx.dts | 4 -
arch/arm/boot/dts/nxp/imx/imx6q-novena.dts | 1 +
arch/arm/boot/dts/nxp/imx/imx6q-utilite-pro.dts | 18 +-
.../boot/dts/nxp/imx/imx6q-var-dt6customboard.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-gw51xx.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-gw551x.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-gw553x.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-nit6xlite.dtsi | 2 +-
.../boot/dts/nxp/imx/imx6qdl-nitrogen6_max.dtsi | 2 +-
.../boot/dts/nxp/imx/imx6qdl-nitrogen6_som2.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-nitrogen6x.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-pico.dtsi | 2 +-
arch/arm/boot/dts/nxp/imx/imx6qdl-sabreauto.dtsi | 2 -
arch/arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6qdl-tx6.dtsi | 5 +-
arch/arm/boot/dts/nxp/imx/imx6qdl.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx6qp-sabreauto.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 5 +
arch/arm/boot/dts/nxp/imx/imx6sx.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 1 +
arch/arm/boot/dts/nxp/imx/imx6ul-pico-hobbit.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-pico-pi.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx6ul-tx6ul.dtsi | 2 +-
.../arm/boot/dts/nxp/imx/imx6ul-var-som-audio.dtsi | 30 ++
.../boot/dts/nxp/imx/imx6ul-var-som-common.dtsi | 187 ++++++++++++
.../nxp/imx/imx6ul-var-som-concerto-common.dtsi | 215 ++++++++++++++
.../dts/nxp/imx/imx6ul-var-som-concerto-full.dts | 22 ++
.../boot/dts/nxp/imx/imx6ul-var-som-concerto.dts | 318 +--------------------
.../arm/boot/dts/nxp/imx/imx6ul-var-som-enet1.dtsi | 44 +++
.../arm/boot/dts/nxp/imx/imx6ul-var-som-enet2.dtsi | 79 +++++
.../dts/nxp/imx/imx6ul-var-som-lvds-panel.dtsi | 112 ++++++++
arch/arm/boot/dts/nxp/imx/imx6ul-var-som-sd.dtsi | 27 ++
arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi | 75 +++++
arch/arm/boot/dts/nxp/imx/imx6ul-var-som.dtsi | 215 +-------------
arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 1 +
.../dts/nxp/imx/imx6ull-var-som-concerto-full.dts | 22 ++
.../boot/dts/nxp/imx/imx6ull-var-som-concerto.dts | 21 ++
arch/arm/boot/dts/nxp/imx/imx6ull-var-som.dtsi | 36 +++
arch/arm/boot/dts/nxp/imx/imx7-tqma7.dtsi | 10 +
arch/arm/boot/dts/nxp/imx/imx7d-pico-dwarf.dts | 2 +-
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 68 ++++-
arch/arm/boot/dts/nxp/imx/imx7d-sdb.dts | 5 +
arch/arm/boot/dts/nxp/imx/imx7d.dtsi | 11 +
arch/arm/boot/dts/nxp/imx/imx7ulp.dtsi | 12 +
67 files changed, 1143 insertions(+), 594 deletions(-)
create mode 100644 Documentation/devicetree/bindings/watchdog/technologic,ts4800-wdt.yaml
delete mode 100644 Documentation/devicetree/bindings/watchdog/ts4800-wdt.txt
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-audio.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-common.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-concerto-common.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-concerto-full.dts
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-enet1.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-enet2.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-lvds-panel.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-sd.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ul-var-som-wifi.dtsi
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som-concerto-full.dts
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som-concerto.dts
create mode 100644 arch/arm/boot/dts/nxp/imx/imx6ull-var-som.dtsi
^ permalink raw reply
* Re: [PATCH net 1/2] net: airoha: Fix use-after-free in metadata dst teardown
From: Jacob Keller @ 2026-06-04 17:38 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Felix Fietkau, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Florian Westphal, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260602-airoha-mtk-metadata-uaf-fix-v1-1-3aaa99d83351@kernel.org>
On 6/2/2026 2:21 AM, Lorenzo Bianconi wrote:
> airoha_metadata_dst_free() runs metadata_dst_free() which frees the
> metadata_dst with kfree() immediately, bypassing the RCU grace period.
> In the RX path, skb_dst_set_noref() sets a non-refcounted pointer from
> the skb to the metadata_dst. This function requires RCU read-side
> protection and the dst must remain valid until all RCU readers complete.
> Since metadata_dst_free() calls kfree() directly, an use-after-free can
> occur if any skb still holds a noref pointer to the dst when the driver
> tears it down.
> Replace metadata_dst_free() with dst_release() which properly goes
> through the refcount path: when the refcount drops to zero, it schedules
> the actual free via call_rcu_hurry(), ensuring all RCU readers have
> completed before the memory is freed.
>
> Fixes: af3cf757d5c9 ("net: airoha: Move DSA tag in DMA descriptor")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index cecd66251dba..eab6a98d62b9 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -2936,7 +2936,7 @@ static void airoha_metadata_dst_free(struct airoha_gdm_port *port)
> if (!port->dsa_meta[i])
> continue;
>
> - metadata_dst_free(port->dsa_meta[i]);
> + dst_release(&port->dsa_meta[i]->dst);
> }
> }
>
>
the port->dsa_meta is allocated using metadata_dst_alloc().. how is it
safe to use dst_release here? Seems like we should be calling dst_alloc
instead of metadata_dst_alloc in order to use dst_release??
metadata_dst_alloc does call __metadata_dst_init which calls dst_init..
I guess the start of the metadata_dst structure is also the same address
as the internal dst_entry struct...
But dst_destroy does a whole lot more than metadata_dst_release so I
don't feel confident in this actually being a drop-in replacement... It
calls netdev_put, it calls the dst->ops->destroy, it releases child
refs.. Or for metadata dst entries is that all basically a no-op??
I feel like I'm missing something here.. The driver also calls
metadata_dst_free in the remove path and that wasn't changed by this
patch either.
Generally it seems like we should be using the same API to allocate as
to release the object... This is confusing. What am I missing?
^ permalink raw reply
* Re: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Jason Gunthorpe @ 2026-06-04 18:24 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Michael Kelley, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Mostafa Saleh, Petr Tesarik, Alexey Kardashevskiy, Dan Williams,
Xu Yilun, linuxppc-dev@lists.ozlabs.org,
linux-s390@vger.kernel.org, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <yq5apl26qrof.fsf@kernel.org>
On Thu, Jun 04, 2026 at 08:27:36PM +0530, Aneesh Kumar K.V wrote:
> I already sent a v6 in the hope of getting this merged for the next
> merge window. Should I send a v7, or would you prefer that I do the
> rename on top of v6?
I think it is too late for such a major change, but this should be
imaginged to be for rc2ish next cycle. You also have to spell out how
the pkvm patch will get sequenced as well, it would be best to push
that it gets picked up right away.
Jason
^ permalink raw reply
* [PATCH] KVM: arm64: Reallocate the nested_mmus array under the mmu_lock
From: Hyunwoo Kim @ 2026-06-04 18:30 UTC (permalink / raw)
To: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, christoffer.dall
Cc: linux-arm-kernel, kvmarm, imv4bel
Code that walks kvm->arch.nested_mmus[] holds kvm->mmu_lock. By contrast,
kvm_vcpu_init_nested() reallocates the array and frees the old buffer while
holding only kvm->arch.config_lock, so a walker can reference the freed
array.
Allocate the new array outside the lock, as the allocation can sleep, and
do only the copy and the pointer swap under the mmu_lock. After the swap no
walker can reach the old buffer, so free it once the lock has been
released.
Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
---
arch/arm64/kvm/nested.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
index 38f672e940878..6f7bc9a9992e0 100644
--- a/arch/arm64/kvm/nested.c
+++ b/arch/arm64/kvm/nested.c
@@ -89,21 +89,28 @@ int kvm_vcpu_init_nested(struct kvm_vcpu *vcpu)
* again, and there is no reason to affect the whole VM for this.
*/
num_mmus = atomic_read(&kvm->online_vcpus) * S2_MMU_PER_VCPU;
- tmp = kvrealloc(kvm->arch.nested_mmus,
- size_mul(sizeof(*kvm->arch.nested_mmus), num_mmus),
- GFP_KERNEL_ACCOUNT | __GFP_ZERO);
- if (!tmp)
- return -ENOMEM;
- swap(kvm->arch.nested_mmus, tmp);
+ if (num_mmus > kvm->arch.nested_mmus_size) {
+ tmp = kvcalloc(num_mmus, sizeof(*tmp), GFP_KERNEL_ACCOUNT);
+ if (!tmp)
+ return -ENOMEM;
- /*
- * If we went through a realocation, adjust the MMU back-pointers in
- * the previously initialised kvm_pgtable structures.
- */
- if (kvm->arch.nested_mmus != tmp)
- for (int i = 0; i < kvm->arch.nested_mmus_size; i++)
- kvm->arch.nested_mmus[i].pgt->mmu = &kvm->arch.nested_mmus[i];
+ write_lock(&kvm->mmu_lock);
+
+ if (kvm->arch.nested_mmus_size) {
+ memcpy(tmp, kvm->arch.nested_mmus,
+ size_mul(sizeof(*tmp), kvm->arch.nested_mmus_size));
+
+ for (int i = 0; i < kvm->arch.nested_mmus_size; i++)
+ tmp[i].pgt->mmu = &tmp[i];
+ }
+
+ swap(kvm->arch.nested_mmus, tmp);
+
+ write_unlock(&kvm->mmu_lock);
+
+ kvfree(tmp);
+ }
for (int i = kvm->arch.nested_mmus_size; !ret && i < num_mmus; i++)
ret = init_nested_s2_mmu(kvm, &kvm->arch.nested_mmus[i]);
--
2.43.0
^ permalink raw reply related
* Re: [PACTH v2] i2c: imx-lpi2c: mark I2C adapter when hardware is powered down
From: Frank Li @ 2026-06-04 18:54 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: aisheng.dong, andi.shyti, s.hauer, kernel, festevam, carlos.song,
linux-i2c, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260520090910.2879570-1-carlos.song@oss.nxp.com>
On Wed, May 20, 2026 at 05:09:10PM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> Mark the I2C adapter as suspended during system suspend to block further
> transfers, and resume it on system resume. This prevents potential hangs
> when the hardware is powered down but clients still attempt I2C transfers.
>
> Fixes: 1ee867e465c1 ("i2c: imx-lpi2c: add target mode support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Change for v2:
> - Call i2c_mark_adapter_suspended() before pm_runtime_force_suspend()
> to prevent potential deadlock if a transfer is active during suspend.
> - Roll back with i2c_mark_adapter_resumed() if pm_runtime_force_suspend()
> fails.
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index a01c23696481..01ee38131ef2 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -1635,7 +1635,18 @@ static int __maybe_unused lpi2c_runtime_resume(struct device *dev)
>
> static int __maybe_unused lpi2c_suspend_noirq(struct device *dev)
> {
> - return pm_runtime_force_suspend(dev);
> + struct lpi2c_imx_struct *lpi2c_imx = dev_get_drvdata(dev);
> + int ret;
> +
> + i2c_mark_adapter_suspended(&lpi2c_imx->adapter);
> +
> + ret = pm_runtime_force_suspend(dev);
> + if (ret) {
> + i2c_mark_adapter_resumed(&lpi2c_imx->adapter);
> + return ret;
> + }
> +
> + return 0;
> }
>
> static int __maybe_unused lpi2c_resume_noirq(struct device *dev)
> @@ -1655,6 +1666,8 @@ static int __maybe_unused lpi2c_resume_noirq(struct device *dev)
> if (lpi2c_imx->target)
> lpi2c_imx_target_init(lpi2c_imx);
>
> + i2c_mark_adapter_resumed(&lpi2c_imx->adapter);
> +
> return 0;
> }
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v3] i2c: imx-lpi2c: reset controller in probe stage
From: Frank Li @ 2026-06-04 18:58 UTC (permalink / raw)
To: Carlos Song (OSS)
Cc: aisheng.dong, andi.shyti, s.hauer, kernel, festevam, linux-i2c,
imx, linux-arm-kernel, linux-kernel, Carlos Song
In-Reply-To: <20260521103530.2988866-1-carlos.song@oss.nxp.com>
On Thu, May 21, 2026 at 06:35:30PM +0800, Carlos Song (OSS) wrote:
> From: Carlos Song <carlos.song@nxp.com>
>
> Reset I2C controller in probe stage to avoid unexpected LPI2C controller
> state left from previous stages and hang system boot.
>
> Per the LPI2C reference manual, section 7.1.4 "Controller Control (MCR)"
> and 7.1.20 Target Control (SCR), the RST bit (bit 1) description states:
>
> "The reset takes effect immediately and remains asserted until negated
> by software. There is no minimum delay required before clearing the
> software reset."
>
> Therefore, it is safe to write 0 to MCR and SCR immediately after
> asserting the RST bit without any additional delay.
>
> Signed-off-by: Carlos Song <carlos.song@nxp.com>
> ---
> Change for v3:
> - Reset the Target logic via LPI2C_SCR.
> - Replacing pm_runtime_put_sync() with pm_runtime_disable() +
> pm_runtime_set_suspended() + pm_runtime_put_noidle() to avoid
> triggering the suspend callback, and explicitly calling
> clk_bulk_disable_unprepare() for clock cleanup.
> - Add new error path free_irq and clk_disable to cover more
> complete error recovery.
> - Remake commit log adding SCR RST section.
> Change for v2:
> - Jump to rpm_disable instread of returning directly if the IRQ request
> fails
> ---
> drivers/i2c/busses/i2c-imx-lpi2c.c | 52 +++++++++++++++++++++---------
> 1 file changed, 37 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
> index e6c24a9d934d..4929f85ab485 100644
> --- a/drivers/i2c/busses/i2c-imx-lpi2c.c
> +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
> @@ -1510,11 +1510,6 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> if (ret)
> lpi2c_imx->bitrate = I2C_MAX_STANDARD_MODE_FREQ;
>
> - ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
> - pdev->name, lpi2c_imx);
> - if (ret)
> - return dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
> -
> i2c_set_adapdata(&lpi2c_imx->adapter, lpi2c_imx);
> platform_set_drvdata(pdev, lpi2c_imx);
>
> @@ -1527,14 +1522,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> * each transfer
> */
> ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
> - if (ret)
> - return dev_err_probe(&pdev->dev, ret,
> - "can't lock I2C peripheral clock rate\n");
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret,
> + "can't lock I2C peripheral clock rate\n");
> + goto clk_disable;
> + }
>
> lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
> - if (!lpi2c_imx->rate_per)
> - return dev_err_probe(&pdev->dev, -EINVAL,
> - "can't get I2C peripheral clock rate\n");
> + if (!lpi2c_imx->rate_per) {
> + ret = dev_err_probe(&pdev->dev, -EINVAL,
> + "can't get I2C peripheral clock rate\n");
> + goto clk_disable;
> + }
>
> if (lpi2c_imx->hwdata->need_prepare_unprepare_clk)
> pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_LONG_TIMEOUT_MS);
> @@ -1546,27 +1545,43 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
> pm_runtime_set_active(&pdev->dev);
> pm_runtime_enable(&pdev->dev);
>
> + /*
> + * Reset all internal controller logic and registers to avoid effects of previous status
> + * Reset both Master and Target logic to prevent interrupt storms
> + */
> + writel(MCR_RST, lpi2c_imx->base + LPI2C_MCR);
> + writel(SCR_RST, lpi2c_imx->base + LPI2C_SCR);
> + writel(0, lpi2c_imx->base + LPI2C_MCR);
> + writel(0, lpi2c_imx->base + LPI2C_SCR);
> +
This patch should only include this part. other adjust should be new patch
> temp = readl(lpi2c_imx->base + LPI2C_PARAM);
> lpi2c_imx->txfifosize = 1 << (temp & 0x0f);
> lpi2c_imx->rxfifosize = 1 << ((temp >> 8) & 0x0f);
>
> + ret = devm_request_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx_isr, IRQF_NO_SUSPEND,
> + pdev->name, lpi2c_imx);
> + if (ret) {
> + dev_err_probe(&pdev->dev, ret, "can't claim irq %d\n", lpi2c_imx->irq);
> + goto rpm_disable;
> + }
> +
> /* Init optional bus recovery function */
> ret = lpi2c_imx_init_recovery_info(lpi2c_imx, pdev);
> /* Give it another chance if pinctrl used is not ready yet */
> if (ret == -EPROBE_DEFER)
> - goto rpm_disable;
> + goto free_irq;
>
> /* Init DMA */
> ret = lpi2c_dma_init(&pdev->dev, phy_addr);
> if (ret) {
> if (ret == -EPROBE_DEFER)
> - goto rpm_disable;
> + goto free_irq;
> dev_info(&pdev->dev, "use pio mode\n");
> }
>
> ret = i2c_add_adapter(&lpi2c_imx->adapter);
> if (ret)
> - goto rpm_disable;
> + goto free_irq;
>
> pm_runtime_put_autosuspend(&pdev->dev);
>
> @@ -1574,10 +1589,17 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
>
> return 0;
>
> +free_irq:
> + devm_free_irq(&pdev->dev, lpi2c_imx->irq, lpi2c_imx);
> +
if use devm_(), need devm_free_irq() here.
Frank
> rpm_disable:
> pm_runtime_dont_use_autosuspend(&pdev->dev);
> - pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> + pm_runtime_set_suspended(&pdev->dev);
> + pm_runtime_put_noidle(&pdev->dev);
> +
> +clk_disable:
> + clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
>
> return ret;
> }
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH] net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
From: Jacob Keller @ 2026-06-04 19:05 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade, netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, maxime.chevallier, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On 6/4/2026 1:30 AM, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
> and increment the corresponding ethtool statistics counters. This allows
> users to observe L3/L4 filter hit rates via ethtool -S.
>
> Signed-off-by: Rohan G Thomas <rohan.g.thomas@altera.com>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 ++
> drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> index 51943705a2b0..95fdf3133208 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h
> @@ -429,6 +429,8 @@
> #define XGMAC_TDES3_VLTV BIT(16)
> #define XGMAC_TDES3_VT GENMASK(15, 0)
> #define XGMAC_TDES3_FL GENMASK(14, 0)
> +#define XGMAC_RDES2_L4FM BIT(28)
> +#define XGMAC_RDES2_L3FM BIT(27)
> #define XGMAC_RDES2_HL GENMASK(9, 0)
> #define XGMAC_RDES3_OWN BIT(31)
> #define XGMAC_RDES3_CTXT BIT(30)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> index b5f200a87484..6719ac6e395b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> @@ -27,6 +27,7 @@ static int dwxgmac2_get_rx_status(struct stmmac_extra_stats *x,
> struct dma_desc *p)
> {
> u32 rdes3 = le32_to_cpu(p->des3);
> + u32 rdes2 = le32_to_cpu(p->des2);
>
> if (unlikely(rdes3 & XGMAC_RDES3_OWN))
> return dma_own;
> @@ -37,6 +38,11 @@ static int dwxgmac2_get_rx_status(struct stmmac_extra_stats *x,
> if (unlikely((rdes3 & XGMAC_RDES3_ES) && (rdes3 & XGMAC_RDES3_LD)))
> return discard_frame;
>
> + if (rdes2 & XGMAC_RDES2_L3FM)
> + x->l3_filter_match++;
> + if (rdes2 & XGMAC_RDES2_L4FM)
> + x->l4_filter_match++;
> +
> return good_frame;
> }
>
Right. The l3_filter_match and l4_filter_match already get reported in
stmmac_ethtool.c
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply
* Re: [PATCH] net: stmmac: xgmac: report L3/L4 filter match count in ethtool stats
From: Andrew Lunn @ 2026-06-04 19:30 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, alexandre.torgue, rmk+kernel, maxime.chevallier,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260604083037.24407-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Thu, Jun 04, 2026 at 01:30:37AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Read the L3FM and L4FM bits from the RX descriptor status word (RDES2)
> and increment the corresponding ethtool statistics counters. This allows
> users to observe L3/L4 filter hit rates via ethtool -S.
Are there any more bits which are missing?
dwmac4 has RDES2_L3_L4_FILT_NB_MATCH_MASK for example.
Andrew
^ permalink raw reply
* Re: [PATCH v7 1/2] mm: bypass mmap_miss heuristic for VM_EXEC readahead
From: Pedro Falcato @ 2026-06-04 19:30 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack,
Andrew Donnellan, apopple, baohua, baolin.wang, brauner,
catalin.marinas, dev.jain, kees, kevin.brodsky, lance.yang,
Liam R. Howlett, linux-arm-kernel, linux-fsdevel, linux-kernel,
ljs, mhocko, npache, pasha.tatashin, rmclure, rppt, surenb,
vbabka, Al Viro, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260601102205.3985788-2-usama.arif@linux.dev>
On Mon, Jun 01, 2026 at 03:21:17AM -0700, Usama Arif wrote:
> The mmap_miss heuristic is intended to stop speculative mmap readahead
> when a file looks like a random-access workload. That does not fit the
> VM_EXEC path very well.
>
> VM_EXEC readahead is already constrained differently from ordinary mmap
> read-around: it is bounded by the VMA, uses exec_folio_order() to choose
> an order useful for executable mappings, and sets async_size to 0 so it
> does not create follow-on readahead. When VM_HUGEPAGE is also present,
> the larger readahead is an explicit userspace opt-in.
>
> The mmap_miss counter is decremented from cache-hit paths in
> do_async_mmap_readahead() and filemap_map_pages(). Those paths are not
> always enough to balance the synchronous miss increments for executable
> mappings. In particular, when fault-around is effectively disabled, such
> as configurations where fault_around_pages is 1, filemap_map_pages() is
> not reached from the fault path. The counter can then become a stale
> throttle for VM_EXEC mappings and suppress the readahead behavior that
> the executable-specific path is trying to provide.
>
> Skip both mmap_miss increments and decrements for VM_EXEC mappings,
> matching the existing VM_SEQ_READ treatment and keeping the counter
> accounting symmetric.
>
> Signed-off-by: Usama Arif <usama.arif@linux.dev>
> Reviewed-by: Jan Kara <jack@suse.cz>
> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
> ---
> mm/filemap.c | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/mm/filemap.c b/mm/filemap.c
> index cca20e350c95..a16b33e0fc71 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -3339,7 +3339,7 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
> }
> }
>
> - if (!(vm_flags & VM_SEQ_READ)) {
> + if (!(vm_flags & (VM_SEQ_READ | VM_EXEC))) {
Just a side comment: I really hate these adhoc criteria all around
filemap/readahead. One day we ought to actually write things down, and
write things in a way that isn't entirely mysterious. I might see if I send
a patch for this down the line...
> /* Avoid banging the cache line if not needed */
> mmap_miss = READ_ONCE(ra->mmap_miss);
> if (mmap_miss < MMAP_LOTSAMISS * 10)
> @@ -3434,12 +3434,12 @@ static struct file *do_async_mmap_readahead(struct vm_fault *vmf,
> * times for a single folio and break the balance with mmap_miss
> * increase in do_sync_mmap_readahead().
> *
> - * VM_SEQ_READ mappings skip the mmap_miss increment in
> + * VM_SEQ_READ and VM_EXEC mappings skip the mmap_miss increment in
> * do_sync_mmap_readahead(), so skip the decrement here as well to
> * keep the counter symmetric.
> */
> if (likely(!folio_test_locked(folio)) &&
> - !(vmf->vma->vm_flags & VM_SEQ_READ)) {
> + !(vmf->vma->vm_flags & (VM_SEQ_READ | VM_EXEC))) {
> mmap_miss = READ_ONCE(ra->mmap_miss);
> if (mmap_miss)
> WRITE_ONCE(ra->mmap_miss, --mmap_miss);
> @@ -3941,14 +3941,14 @@ vm_fault_t filemap_map_pages(struct vm_fault *vmf,
> * Don't decrease mmap_miss in this scenario to make sure
> * we can stop read-ahead.
> *
> - * VM_SEQ_READ mappings skip the mmap_miss increment in
> - * do_sync_mmap_readahead(), so skip the decrement here as
> - * well to keep the counter symmetric.
> + * VM_SEQ_READ and VM_EXEC mappings skip the mmap_miss
> + * increment in do_sync_mmap_readahead(), so skip the
> + * decrement here as well to keep the counter symmetric.
> */
> if ((map_ret & VM_FAULT_NOPAGE) &&
> !(vmf->flags & FAULT_FLAG_TRIED) &&
> !folio_test_workingset(folio) &&
> - !(vma->vm_flags & VM_SEQ_READ)) {
> + !(vma->vm_flags & (VM_SEQ_READ | VM_EXEC))) {
> unsigned short mmap_miss;
>
> mmap_miss = READ_ONCE(file->f_ra.mmap_miss);
> --
> 2.52.0
>
--
Pedro
^ permalink raw reply
* Re: [PATCH v7 2/2] mm: use mapping_max_folio_order() for force_thp_readahead order
From: Pedro Falcato @ 2026-06-04 19:33 UTC (permalink / raw)
To: Usama Arif
Cc: Andrew Morton, david, willy, ryan.roberts, linux-mm, r, jack,
Andrew Donnellan, apopple, baohua, baolin.wang, brauner,
catalin.marinas, dev.jain, kees, kevin.brodsky, lance.yang,
Liam R. Howlett, linux-arm-kernel, linux-fsdevel, linux-kernel,
ljs, mhocko, npache, pasha.tatashin, rmclure, rppt, surenb,
vbabka, Al Viro, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <20260601102205.3985788-3-usama.arif@linux.dev>
On Mon, Jun 01, 2026 at 03:21:18AM -0700, Usama Arif wrote:
> The force_thp_readahead path in do_sync_mmap_readahead() is gated on
> HPAGE_PMD_ORDER <= MAX_PAGECACHE_ORDER and always requests
> HPAGE_PMD_ORDER / HPAGE_PMD_NR. On configurations where HPAGE_PMD_ORDER
> exceeds MAX_PAGECACHE_ORDER, notably arm64 with a 64K base page size,
> VM_HUGEPAGE mappings cannot use this path and fall back to the non-forced
> mmap readahead path even when the mapping supports useful large folios.
>
> Enable forced readahead for mappings that support large folios and request
> the max folio order supported by the mapping, capped at 2M.
> 2MB is chosen as the cap because it matches the PMD size on x86_64
> and on arm64 with 4K base pages, so the size/memory-pressure tradeoff
> for folios of that size is already well understood. On arm64 with 16K
> and 64K base page sizes, 2MB is also the contiguous-PTE (contpte)
> block size, so the resulting folios coalesce into a single TLB entry
> and reduce TLB pressure on the readahead path. This will result
> in 32M folios not being faulted in with 16K base page size for arm64,
> but with contpte, the performance difference should be negligible.
>
> The final allocation order may still be clamped by page_cache_ra_order()
> to the mapping and request geometry, but this gives VM_HUGEPAGE mappings
> on such configurations a large-folio readahead request instead of
> dropping back to base-page readahead.
>
> Signed-off-by: Usama Arif <usama.arif@linux.dev>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Overall LGTM. Lets see if performance doesn't degrade.
/me hides in cover
--
Pedro
^ permalink raw reply
* Re: [PATCH v2 2/2] PCI: imx6: Assert ref_clk_en after reference clock stabilizes on i.MX95
From: Frank Li @ 2026-06-04 19:34 UTC (permalink / raw)
To: Richard Zhu
Cc: l.stach, lpieralisi, kwilczynski, mani, robh, bhelgaas, s.hauer,
kernel, festevam, linux-pci, linux-arm-kernel, imx, linux-kernel,
stable
In-Reply-To: <20260518072715.3166514-3-hongxing.zhu@nxp.com>
On Mon, May 18, 2026 at 03:27:15PM +0800, Richard Zhu wrote:
> According to the PHY Databook Common Block Signals section, the
> ref_clk_en signal must remain de-asserted until the reference clock is
> running at the appropriate frequency. Once the clock is stable,
> ref_clk_en can be asserted. For lower power states where the reference
> clock to the PHY is disabled, ref_clk_en should also be de-asserted.
>
> Move the ref_clk_en bit manipulation into imx95_pcie_enable_ref_clk()
> to ensure the reference clock stabilizes before ref_clk_en is asserted
> and before the PHY reset is de-asserted. This aligns with the timing
> requirements specified in the PHY documentation.
>
> Fixes: d8574ce57d76 ("PCI: imx6: Add external reference clock input mode support")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/pci/controller/dwc/pci-imx6.c | 28 +++++++++++++++++++++------
> 1 file changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 66e760015c92..c4b079c93648 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -270,8 +270,6 @@ static int imx95_pcie_init_pre_reset(struct imx_pcie *imx_pcie)
>
> static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
> {
> - bool ext = imx_pcie->enable_ext_refclk;
> -
> /*
> * ERR051624: The Controller Without Vaux Cannot Exit L23 Ready
> * Through Beacon or PERST# De-assertion
> @@ -290,10 +288,6 @@ static int imx95_pcie_init_phy(struct imx_pcie *imx_pcie)
> IMX95_PCIE_PHY_CR_PARA_SEL,
> IMX95_PCIE_PHY_CR_PARA_SEL);
>
> - regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
> - IMX95_PCIE_REF_CLKEN,
> - ext ? 0 : IMX95_PCIE_REF_CLKEN);
> -
> return 0;
> }
>
> @@ -742,7 +736,29 @@ static void imx95_pcie_clkreq_override(struct imx_pcie *imx_pcie, bool enable)
>
> static int imx95_pcie_enable_ref_clk(struct imx_pcie *imx_pcie, bool enable)
> {
> + bool ext = imx_pcie->enable_ext_refclk;
> +
> imx95_pcie_clkreq_override(imx_pcie, enable);
> + /*
> + * The ref_clk_en signal must remain de-asserted until the
> + * reference clock is running at appropriate frequency, at which
> + * point this bit can be asserted. For lower power states where
> + * the reference clock to the PHY is disabled, it may also be
> + * de-asserted.
> + * +------------------- -+--------+----------------+
> + * | External clock mode | Enable | PCIE_REF_CLKEN |
> + * +---------------------+--------+----------------+
> + * | TRUE | X | 1b'0 |
> + * +---------------------+--------+----------------+
> + * | FALSE | TRUE | 1b'1 |
> + * +---------------------+--------+----------------+
> + * | FALSE | FALSE | 1b'0 |
> + * +---------------------+--------+----------------+
> + */
> + regmap_update_bits(imx_pcie->iomuxc_gpr, IMX95_PCIE_SS_RW_REG_0,
> + IMX95_PCIE_REF_CLKEN,
> + ext || !enable ? 0 : IMX95_PCIE_REF_CLKEN);
> +
> return 0;
> }
>
> --
> 2.37.1
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox