From: Alexandru Elisei <alexandru.elisei@arm.com>
To: James Clark <james.clark@linaro.org>
Cc: mark.rutland@arm.com, james.morse@arm.com, maz@kernel.org,
oliver.upton@linux.dev, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com, will@kernel.org,
catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org,
kvmarm@lists.linux.dev
Subject: Re: [RFC PATCH v6 14/35] KVM: arm64: Add SPE VCPU device attribute to set the max buffer size
Date: Mon, 12 Jan 2026 11:28:03 +0000 [thread overview]
Message-ID: <aWTaw_T6jak7Etj1@raptor> (raw)
In-Reply-To: <c6e1f67c-6c71-4785-a1b9-3be2acee2a3a@linaro.org>
Hi James,
On Fri, Jan 09, 2026 at 04:29:43PM +0000, James Clark wrote:
>
>
> On 14/11/2025 4:06 pm, Alexandru Elisei wrote:
> > During profiling, the buffer programmed by the guest must be kept mapped at
> > stage 2 by KVM, making this memory pinned from the host's perspective.
> >
> > To make sure that a guest doesn't consume too much memory, add a new SPE
> > VCPU device attribute, KVM_ARM_VCPU_MAX_BUFFER_SIZE, which is used by
> > userspace to limit the amount of memory a VCPU can pin when programming
> > the profiling buffer. This value will be advertised to the guest in the
> > PMBIDR_EL1.MaxBuffSize field.
> >
> > Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
> > ---
> > Documentation/virt/kvm/devices/vcpu.rst | 49 ++++++++++
> > arch/arm64/include/asm/kvm_spe.h | 6 ++
> > arch/arm64/include/uapi/asm/kvm.h | 5 +-
> > arch/arm64/kvm/arm.c | 2 +
> > arch/arm64/kvm/spe.c | 116 ++++++++++++++++++++++++
> > 5 files changed, 176 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> > index e305377fadad..bb1bbd2ff6e2 100644
> > --- a/Documentation/virt/kvm/devices/vcpu.rst
> > +++ b/Documentation/virt/kvm/devices/vcpu.rst
> > @@ -347,3 +347,52 @@ attempting to set a different one will result in an error.
> > Similar to KVM_ARM_VCPU_PMU_V3_CTRL(KVM_ARM_VCPU_PMU_SET_PMU), userspace is
> > responsible for making sure that the VCPU is run only on physical CPUs which
> > have the specified SPU.
> > +
> > +5.3 ATTRIBUTE: KVM_ARM_VCPU_MAX_BUFFER_SIZE
> > +------------------------------------------
> > +
> > +:Parameters: in kvm_device_attr.addr the address to an u64 representing the
> > + maximum buffer size, in bytes.
> > +
> > +:Returns:
> > +
> > + ======= =========================================================
> > + -EBUSY Virtual machine has already run
> > + -EDOM Buffer size cannot be represented by hardware
> > + -EFAULT Error accessing the max buffer size identifier
> > + -EINVAL A different maximum buffer size already set or the size is
> > + not aligned to the host's page size
> > + -ENXIO SPE not supported or not properly configured
> > + -ENODEV KVM_ARM_VCPU_HAS_SPE VCPU feature or SPU instance not set
>
> Hi Alex,
>
> I can't reproduce this anymore, but I got this a few times. Or at least I
> think it was this, I've pasted the output from kvmtool below and it doesn't
> say exactly what the issue was.
I'll try to reproduce it.
Do you remember what were the HEAD commits for the host and kvmtool?
>
> If I tried again with a different buffer size it worked, then going back to
> 256M didn't work, then it went away. I might have done something wrong so if
> you didn't see this either then we can probably ignore it for now.
>
> -> sudo lkvm run --kernel /boot/vmlinux-6.18.0-rc2+ -p "earlycon
> kpti=off" -c 4 -m 2000 --pmu --spe --spe-max-buffer-size=256M
>
> Info: # lkvm run -k /boot/vmlinux-6.18.0-rc2+ -m 2000 -c 4 --name
> guest-616
> KVM_SET_DEVICE_ATTR: No such device or address
>
>
> > + -ERANGE Buffer size larger than maximum supported by the SPU
> > + instance.
> > + ======= ==========================================================
> > +
> > +Required.
> > +
> > +Limit the size of the profiling buffer for the VCPU to the specified value. The
> > +value will be used by all VCPUs. Can be set for more than one VCPUs, as long as
> > +the value stays the same.
> > +
> > +Requires that a SPU has been already assigned to the VM. The maximum buffer size
>
> Very minor nit, but would "Initialised with SPE" be better? Because it's
> done through KVM_ARM_VCPU_INIT rather than "ASSIGN_SPU". I think it might
> make it easier to understand how you are supposed to use it.
>
> SPU is never expanded either and I think users probably wouldn't be familiar
> with what that is. A lot of times we could just say "has SPE" and it would
> be clearer. I don't think separating the concepts of SPE and SPU gives us
> anything in this high level of a doc other than potentially confusing users.
Sure.
>
> > +must be less than or equal to the maximum buffer size of the assigned SPU instance,
>
> I don't understand this part. Do you mean "of the assigned physical SPU
> instance"? The ARM states "no limit" is the only valid value here:
Yes, physical instance.
>
> Reads as 0x0000
> The only permitted value is 0x0000, indicating there is no limit to
> the maximum buffer size.
>
> It would be good to expand on where the limit you are talking about comes
> from.
The hardware value might change in the future. Or the host might be running
under nested virtualization, which makes having a different value likely. Like
you said above, I don't think it's necessary to get into this much detail here -
the idea I was trying to convey is that userspace cannot set the maximum buffer
size to a value larger than what the physical SPU instance supports.
>
> > +unless there is no limit on the maximum buffer size for the SPU. In this case
> > +the VCPU maximum buffer size can have any value, including 0, as long as it can
> > +be encoded by hardware. For details on how the hardware encodes this value,
> > +please consult Arm DDI0601 for the field PMBIDR_EL1.MaxBuffSize.
> > +
> > +The value 0 is special and it means that there is no upper limit on the size of
> > +the buffer that the guest can use. Can only be set if the SPU instance used by
> > +the VM has a similarly unlimited buffer size.
>
> This is a comment about changes in kvmtool, but it's semi related so I'll
> leave it here. But you say only half of the buffer is used at a time:
>
> In a guest, perf, when the user is root, uses the default value of 4MB
> for the total size of the profiling memory. This is split in two by
> the SPE driver, and at any given time only one half (2MB) is
> programmed for the SPE buffer.
>
> However, KVM also has to pin the stage 1 translation tables that
> translate the buffer, so if the default were 2MB, KVM would definitely
> exceed this value. Make the default 4MB to avoid potential errors when
> the limit is exceeded.
>
> But isn't that just for snapshot mode? In normal mode the half way point is
> set to perf_output_handle->wakeup which comes from the watermark set by
> userspace? If you set it to the end then in theory the whole buffer could be
> used?
Sure, I'll change the comment to say that 4MiB was chosen because that was the
default in perf, and not go into more details.
Thanks,
Alex
>
> > +
> > +When a guest enables SPE on the VCPU, KVM will pin the host memory backing the
> > +buffer to avoid the statistical profiling unit experiencing stage 2 faults when
> > +it writes to memory. This includes the host pages backing the guest's stage 1
> > +translation tables that are used to translate the buffer. As a result, it is
> > +expected that the size of the memory that will be pinned for each VCPU will be
> > +slightly larger that the maximum buffer set with this ioctl.
> > +
> > +This memory that is pinned will count towards the process RLIMIT_MEMLOCK. To
> > +avoid the limit being exceeded, userspace must increase the RLIMIT_MEMLOCK limit
> > +prior to running the VCPU, otherwise KVM_RUN will return to userspace with an
> > +error.
> > diff --git a/arch/arm64/include/asm/kvm_spe.h b/arch/arm64/include/asm/kvm_spe.h
> > index a4e9f03e3751..e48f7a7f67bb 100644
> > --- a/arch/arm64/include/asm/kvm_spe.h
> > +++ b/arch/arm64/include/asm/kvm_spe.h
> > @@ -12,6 +12,7 @@
> > struct kvm_spe {
> > struct arm_spe_pmu *arm_spu;
> > + u64 max_buffer_size; /* Maximum per VCPU buffer size */
> > };
> > struct kvm_vcpu_spe {
> > @@ -28,6 +29,8 @@ static __always_inline bool kvm_supports_spe(void)
> > #define vcpu_has_spe(vcpu) \
> > (vcpu_has_feature(vcpu, KVM_ARM_VCPU_SPE))
> > +void kvm_spe_init_vm(struct kvm *kvm);
> > +
> > int kvm_spe_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
> > int kvm_spe_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
> > int kvm_spe_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr);
> > @@ -41,6 +44,9 @@ struct kvm_vcpu_spe {
> > #define kvm_supports_spe() false
> > #define vcpu_has_spe(vcpu) false
> > +static inline void kvm_spe_init_vm(struct kvm *kvm)
> > +{
> > +}
> > static inline int kvm_spe_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> > {
> > return -ENXIO;
> > diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
> > index 760c3e074d3d..9db652392781 100644
> > --- a/arch/arm64/include/uapi/asm/kvm.h
> > +++ b/arch/arm64/include/uapi/asm/kvm.h
> > @@ -445,8 +445,9 @@ enum {
> > #define KVM_ARM_VCPU_PVTIME_CTRL 2
> > #define KVM_ARM_VCPU_PVTIME_IPA 0
> > #define KVM_ARM_VCPU_SPE_CTRL 3
> > -#define KVM_ARM_VCPU_SPE_IRQ 0
> > -#define KVM_ARM_VCPU_SPE_SPU 1
> > +#define KVM_ARM_VCPU_SPE_IRQ 0
> > +#define KVM_ARM_VCPU_SPE_SPU 1
> > +#define KVM_ARM_VCPU_SPE_MAX_BUFFER_SIZE 2
> > /* KVM_IRQ_LINE irq field index values */
> > #define KVM_ARM_IRQ_VCPU2_SHIFT 28
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index d7f802035970..9afdf66be8b2 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -194,6 +194,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> > kvm_timer_init_vm(kvm);
> > + kvm_spe_init_vm(kvm);
> > +
> > /* The maximum number of VCPUs is limited by the host's GIC model */
> > kvm->max_vcpus = kvm_arm_default_max_vcpus();
> > diff --git a/arch/arm64/kvm/spe.c b/arch/arm64/kvm/spe.c
> > index c581838029ae..3478da2a1f7c 100644
> > --- a/arch/arm64/kvm/spe.c
> > +++ b/arch/arm64/kvm/spe.c
> > @@ -3,6 +3,7 @@
> > * Copyright (C) 2021 - ARM Ltd
> > */
> > +#include <linux/bitops.h>
> > #include <linux/cpumask.h>
> > #include <linux/kvm_host.h>
> > #include <linux/perf/arm_spe_pmu.h>
> > @@ -41,6 +42,99 @@ void kvm_host_spe_init(struct arm_spe_pmu *arm_spu)
> > static_branch_enable(&kvm_spe_available);
> > }
> > +/*
> > + * The maximum buffer size can be zero (no restrictions on the buffer size), so
> > + * this value cannot be used as the uninitialized value. The maximum buffer size
> > + * must be page aligned, so arbitrarily choose the value '1' for an
> > + * uninitialized maximum buffer size.
> > + */
> > +#define KVM_SPE_MAX_BUFFER_SIZE_UNSET 1
> > +
> > +void kvm_spe_init_vm(struct kvm *kvm)
> > +{
> > + kvm->arch.kvm_spe.max_buffer_size = KVM_SPE_MAX_BUFFER_SIZE_UNSET;
> > +}
> > +
> > +static u64 max_buffer_size_to_pmbidr_el1(u64 size)
> > +{
> > + u64 msb_idx, num_bits;
> > + u64 maxbuffsize;
> > + u64 m, e;
> > +
> > + /*
> > + * size = m:zeros(12); m is 9 bits.
> > + */
> > + if (size <= GENMASK_ULL(20, 12)) {
> > + m = size >> 12;
> > + e = 0;
> > + goto out;
> > + }
> > +
> > + /*
> > + * size = 1:m:zeros(e+11)
> > + */
> > +
> > + num_bits = fls64(size);
> > + msb_idx = num_bits - 1;
> > +
> > + /* MSB is not encoded. */
> > + m = size & ~BIT(msb_idx);
> > + /* m is 9 bits. */
> > + m >>= msb_idx - 9;
> > + /* MSB is not encoded, m is 9 bits wide and 11 bits are zero. */
> > + e = num_bits - 1 - 9 - 11;
> > +
> > +out:
> > + maxbuffsize = FIELD_PREP(GENMASK_ULL(8, 0), m) | \
> > + FIELD_PREP(GENMASK_ULL(13, 9), e);
> > + return FIELD_PREP(PMBIDR_EL1_MaxBuffSize, maxbuffsize);
> > +}
> > +
> > +static u64 pmbidr_el1_to_max_buffer_size(u64 pmbidr_el1)
> > +{
> > + u64 maxbuffsize;
> > + u64 e, m;
> > +
> > + maxbuffsize = FIELD_GET(PMBIDR_EL1_MaxBuffSize, pmbidr_el1);
> > + e = FIELD_GET(GENMASK_ULL(13, 9), maxbuffsize);
> > + m = FIELD_GET(GENMASK_ULL(8, 0), maxbuffsize);
> > +
> > + if (!e)
> > + return m << 12;
> > + return (1ULL << (9 + e + 11)) | (m << (e + 11));
> > +}
> > +
> > +static int kvm_spe_set_max_buffer_size(struct kvm_vcpu *vcpu, u64 size)
> > +{
> > + struct kvm *kvm = vcpu->kvm;
> > + struct kvm_spe *kvm_spe = &kvm->arch.kvm_spe;
> > + u64 decoded_size, spu_size;
> > +
> > + if (kvm_vm_has_ran_once(kvm))
> > + return -EBUSY;
> > +
> > + if (!PAGE_ALIGNED(size))
> > + return -EINVAL;
> > +
> > + if (!kvm_spe->arm_spu)
> > + return -ENODEV;
> > +
> > + if (kvm_spe->max_buffer_size != KVM_SPE_MAX_BUFFER_SIZE_UNSET)
> > + return size == kvm_spe->max_buffer_size ? 0 : -EINVAL;
> > +
> > + decoded_size = pmbidr_el1_to_max_buffer_size(max_buffer_size_to_pmbidr_el1(size));
> > + if (decoded_size != size)
> > + return -EDOM;
> > +
> > + spu_size = pmbidr_el1_to_max_buffer_size(kvm_spe->arm_spu->pmbidr_el1);
> > + if (spu_size != 0 && (size == 0 || size > spu_size))
> > + return -ERANGE;
> > +
> > + kvm_spe->max_buffer_size = size;
> > +
> > + return 0;
> > +}
> > +
> > static int kvm_spe_set_spu(struct kvm_vcpu *vcpu, int spu_id)
> > {
> > struct kvm *kvm = vcpu->kvm;
> > @@ -136,6 +230,15 @@ int kvm_spe_set_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> > return kvm_spe_set_spu(vcpu, spu_id);
> > }
> > + case KVM_ARM_VCPU_SPE_MAX_BUFFER_SIZE: {
> > + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
> > + u64 size;
> > +
> > + if (get_user(size, uaddr))
> > + return -EFAULT;
> > +
> > + return kvm_spe_set_max_buffer_size(vcpu, size);
> > + }
> > }
> > return -ENXIO;
> > @@ -181,6 +284,18 @@ int kvm_spe_get_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> > return 0;
> > }
> > + case KVM_ARM_VCPU_SPE_MAX_BUFFER_SIZE: {
> > + u64 __user *uaddr = (u64 __user *)(long)attr->addr;
> > + u64 size = kvm_spe->max_buffer_size;
> > +
> > + if (size == KVM_SPE_MAX_BUFFER_SIZE_UNSET)
> > + return -EINVAL;
> > +
> > + if (put_user(size, uaddr))
> > + return -EFAULT;
> > +
> > + return 0;
> > + }
> > }
> > return -ENXIO;
> > @@ -194,6 +309,7 @@ int kvm_spe_has_attr(struct kvm_vcpu *vcpu, struct kvm_device_attr *attr)
> > switch(attr->attr) {
> > case KVM_ARM_VCPU_SPE_IRQ:
> > case KVM_ARM_VCPU_SPE_SPU:
> > + case KVM_ARM_VCPU_SPE_MAX_BUFFER_SIZE:
> > return 0;
> > }
>
next prev parent reply other threads:[~2026-01-12 11:28 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-14 16:06 [RFC PATCH v6 00/35] KVM: arm64: Add Statistical Profiling Extension (SPE) support Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 01/35] arm64/sysreg: Add new SPE fields Alexandru Elisei
2025-12-10 18:38 ` Leo Yan
2025-12-12 9:39 ` Alexandru Elisei
2025-12-15 21:42 ` Suzuki K Poulose
2025-11-14 16:06 ` [RFC PATCH v6 02/35] arm64/sysreg: Define MDCR_EL2.E2PB values Alexandru Elisei
2025-12-15 21:33 ` Suzuki K Poulose
2025-11-14 16:06 ` [RFC PATCH v6 03/35] KVM: arm64: Add CONFIG_KVM_ARM_SPE Kconfig option Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-12 11:26 ` Alexandru Elisei
2026-01-12 12:09 ` James Clark
2026-01-12 12:14 ` James Clark
2026-01-12 15:18 ` Alexandru Elisei
2026-01-13 10:25 ` Alexandru Elisei
2026-01-13 15:00 ` James Clark
2026-01-13 17:03 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 04/35] perf: arm_spe_pmu: Move struct arm_spe_pmu to a separate header file Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 05/35] KVM: arm64: Add KVM_CAP_ARM_SPE capability Alexandru Elisei
2025-12-14 12:18 ` Leo Yan
2025-12-15 11:46 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 06/35] KVM: arm64: Add KVM_ARM_VCPU_SPE VCPU feature Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 07/35] HACK! KVM: arm64: Disable SPE virtualization if protected KVM is enabled Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 08/35] HACK! KVM: arm64: Enable SPE virtualization only in VHE mode Alexandru Elisei
2025-12-15 17:49 ` Leo Yan
2025-11-14 16:06 ` [RFC PATCH v6 09/35] HACK! KVM: arm64: Disable SPE virtualization if nested virt is enabled Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 10/35] KVM: arm64: Add a new VCPU device control group for SPE Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 11/35] KVM: arm64: Add SPE VCPU device attribute to set the interrupt number Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 12/35] KVM: arm64: Add SPE VCPU device attribute to set the SPU device Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 13/35] perf: arm_spe_pmu: Add PMBIDR_EL1 to struct arm_spe_pmu Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 14/35] KVM: arm64: Add SPE VCPU device attribute to set the max buffer size Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-12 11:28 ` Alexandru Elisei [this message]
2026-01-12 11:50 ` James Clark
2026-01-12 14:03 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 15/35] KVM: arm64: Add SPE VCPU device attribute to initialize SPE Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 16/35] KVM: arm64: Advertise SPE version in ID_AA64DFR0_EL1.PMSver Alexandru Elisei
2025-12-16 11:40 ` Suzuki K Poulose
2026-01-05 16:42 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 17/35] KVM: arm64: Add writable SPE system registers to VCPU context Alexandru Elisei
2025-12-16 11:54 ` Suzuki K Poulose
2026-01-05 16:42 ` Alexandru Elisei
2025-11-14 16:06 ` [RFC PATCH v6 18/35] perf: arm_spe_pmu: Add PMSIDR_EL1 to struct arm_spe_pmu Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 19/35] KVM: arm64: Trap PMBIDR_EL1 and PMSIDR_EL1 Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-12 11:28 ` Alexandru Elisei
2026-01-12 11:54 ` James Clark
2026-01-13 12:48 ` Alexandru Elisei
2026-01-13 14:22 ` James Clark
2025-11-14 16:07 ` [RFC PATCH v6 20/35] KVM: arm64: config: Use functions from spe.c to test FEAT_SPE_{FnE,FDS} Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 21/35] KVM: arm64: Check for unsupported CPU early in kvm_arch_vcpu_load() Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 22/35] KVM: arm64: VHE: Context switch SPE state Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 23/35] KVM: arm64: Allow guest SPE physical timestamps only if perfmon_capable() Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 24/35] KVM: arm64: Handle SPE hardware maintenance interrupts Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 25/35] KVM: arm64: Add basic handling of SPE buffer control registers writes Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 26/35] KVM: arm64: Add comment to explain how trapped SPE registers are handled Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 27/35] KVM: arm64: Make MTE functions public Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 28/35] KVM: arm64: at: Use callback for reading descriptor Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 29/35] KVM: arm64: Pin the SPE buffer in the host and map it at stage 2 Alexandru Elisei
2026-01-09 16:29 ` James Clark
2026-01-09 16:35 ` James Clark
2026-01-12 12:01 ` Alexandru Elisei
2026-01-13 14:18 ` James Clark
2025-11-14 16:07 ` [RFC PATCH v6 30/35] KVM: Propagate MMU event to the MMU notifier handlers Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 31/35] KVM: arm64: Handle MMU notifiers for the SPE buffer Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 32/35] KVM: Add KVM_EXIT_RLIMIT exit_reason Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 33/35] KVM: arm64: Implement locked memory accounting for the SPE buffer Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 34/35] KVM: arm64: Add hugetlb support for SPE Alexandru Elisei
2025-11-14 16:07 ` [RFC PATCH v6 35/35] KVM: arm64: Allow the creation of a SPE enabled VM Alexandru Elisei
2025-12-11 16:34 ` [RFC PATCH v6 00/35] KVM: arm64: Add Statistical Profiling Extension (SPE) support Leo Yan
2025-12-12 10:18 ` Alexandru Elisei
2025-12-12 11:15 ` Leo Yan
2025-12-12 11:54 ` Alexandru Elisei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aWTaw_T6jak7Etj1@raptor \
--to=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.clark@linaro.org \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox