All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gavin Shan <gshan@redhat.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev
Cc: maz@kernel.org, will@kernel.org, catalin.marinas@arm.com,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
	aneesh.kumar@kernel.org, oupton@kernel.org, joey.gouly@arm.com,
	tabba@google.com, yuzenghui@huawei.com,
	linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com,
	sdonthineni@nvidia.com, alpergun@google.com,
	fj0570is@fujitsu.com, WeiLin.Chang@arm.com,
	lpieralisi@kernel.org, enju.kohei@fujitsu.com
Subject: Re: [PATCH v19 05/20] KVM: arm64: Track the type of VM in kvm_arch
Date: Thu, 24 Sep 2026 20:37:46 +1000	[thread overview]
Message-ID: <aa6133dd-bc9a-4bf1-877d-3a1230efa644@redhat.com> (raw)
In-Reply-To: <f926af3f-2109-4da7-9b18-cc49eac6ce1e@arm.com>

On 9/24/26 6:48 PM, Suzuki K Poulose wrote:
> On 24/09/2026 02:11, Gavin Shan wrote:
>> On 9/24/26 7:37 AM, Suzuki K Poulose wrote:
>>> On 23/09/2026 17:27, Suzuki K Poulose wrote:
>>>> On 23/09/2026 14:23, Gavin Shan wrote:
>>>>> On 9/23/26 8:24 PM, Suzuki K Poulose wrote:
>>>>>> On 23/09/2026 07:19, Gavin Shan wrote:
>>>>>>> On 9/23/26 4:05 PM, Gavin Shan wrote:
>>>>>>>> On 9/21/26 7:28 AM, Suzuki K Poulose wrote:
>>>>>>>>> KVM arm64 has different types of VMs with all the different modes in which
>>>>>>>>> the hypervisor code can be run. e.g., VHE, nVHE, pKVM etc. Then there is
>>>>>>>>> protected VM and normal VMs with pKVM. We might soon add other types,
>>>>>>>>> e.g., Arm CCA Realm. So in an effort to make the handling of these
>>>>>>>>> different types of VMs a bit more friendly to the eyes, add a VM flavor to
>>>>>>>>> the kvm_arch and we could then add handlers for different operations based
>>>>>>>>> on the VM type.
>>>>>>>>>
>>>>>>>>> Keep the flavor initialisation at the beginning to allow for the detection
>>>>>>>>> early enough and fail out on any unsupported requests.
>>>>>>>>>
>>>>>>>>> With that, add wrappers for checking the "type" of a VM and replace the
>>>>>>>>> existing users with the new wrappers.
>>>>>>>>>
>>>>>>>>> Given we already have the construct of "kvm_vm_is_protected" in the core
>>>>>>>>> KVM code, use that for all confidential compute guests including Realms
>>>>>>>>> that we are about to add.
>>>>>>>>>
>>>>>>>>> Adds __VM_PROTECTED marker vm flavor to generalize kvm_vm_is_protected()
>>>>>>>>> to predicate all confidential guests running on KVM. In later patches, we
>>>>>>>>> would add Realm VMs, which would also be classified as protected.
>>>>>>>>>
>>>>>>>>> Add explicit helper to detect if a given VM is a "protected" VM under pKVM.
>>>>>>>>> Change the existing users that precisely want to check the VM type. These
>>>>>>>>> include :
>>>>>>>>>    - kvm_arch_prepare_memory_region - For preventing memslot changes after
>>>>>>>>>      pVM creation.
>>>>>>>>>
>>>>>>>>> All the others are retained as a wider check for confidential guest VMs.
>>>>>>>>> These are:
>>>>>>>>>   - kvm_vm_ioctl_set_counter_offset - For disallowing timer offset
>>>>>>>>>     configuration
>>>>>>>>>   - io_mem_abort for dabt handling without valid syndrome information
>>>>>>>>>
>>>>>>>>> Both of which are true for Realms too.
>>>>>>>>>
>>>>>>>>> Realms support is restricted to VHE host and thus "kvm_vm_is_protected()"
>>>>>>>>> checks in the pkvm hyp specific code doesn't need to change, as the only
>>>>>>>>> protected guests it deals with is "protected pKVM" guests. To tighten this
>>>>>>>>> init_pkvm_hyp_vm() restricts the hyp copy of the vm_flavor to the ones it
>>>>>>>>> supports.
>>>>>>>>>
>>>>>>>>> Suggested-by: Marc Zyngier <maz@kernel.org>
>>>>>>>>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>>>>>>> ---
>>>>>>>>> Changes since v18:
>>>>>>>>>   - Merge the __VM_PROTECTED marker and the widening of kvm_vm_is_protected()
>>>>>>>>>     to this patch.
>>>>>>>>>   - Merge the use of kvm_vm_is_unprotected_pkvm() for ! kvm_vm_is_protected()
>>>>>>>>>     given the scope changes here.
>>>>>>>>>   - Drop Fuad's review tag, as this patch has multiple merges
>>>>>>>>>   - Restrict the VM flavors to the supported types in init_pkvm_hyp_vm().
>>>>>>>>>   - Drop kvm_vm_hyp_is_pkvm() and revert to is_protected_kvm_enabled()
>>>>>>>>>   - Use is_protected_kvm_enabled() to make the pKVM guest flavor checks.
>>>>>>>>>   - s/PKVM/pKVM for commit descriptions too
>>>>>>>>>
>>>>>>>>> Changes since v17:
>>>>>>>>>   * s/PKVM/pKVM for the comments
>>>>>>>>>   * Drop type argument for pkvm_init_host_vm and also drop protected variable.
>>>>>>>>>   * Add helpers for checking if the VM is running on pKVM (kvm_vm_hyp_is_pkvm())
>>>>>>>>>   * Use kvm_vm_hyp_is_pkvm() to replace is_protected_kvm_enabled() with valid
>>>>>>>>>     kvm instance
>>>>>>>>> ---
>>>>>>>>>   arch/arm64/include/asm/kvm_host.h | 22 +++++++++++++++++++---
>>>>>>>>>   arch/arm64/include/asm/kvm_pkvm.h |  4 ++--
>>>>>>>>>   arch/arm64/kvm/arm.c              | 31 +++++++++++++++++++++++ ++ +-----
>>>>>>>>>   arch/arm64/kvm/handle_exit.c      |  2 +-
>>>>>>>>>   arch/arm64/kvm/hyp/nvhe/pkvm.c    |  6 +++++-
>>>>>>>>>   arch/arm64/kvm/mmu.c              |  2 +-
>>>>>>>>>   arch/arm64/kvm/pkvm.c             |  6 ++----
>>>>>>>>>   7 files changed, 56 insertions(+), 17 deletions(-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> This causes broken nVHE mode. I applied PATCH[01-05] to v7.3.rc4 whose head commit
>>>>>>>> is f0100363d8c3, and kselftests/kvm/guest_print causes host crash (as below). I don't
>>>>>>>> see the crash if only PATCH[01-04] are applied.
>>>>>>>>
>>>>>>>> host$ cat /proc/cmdline | grep kvm-arm\.mode
>>>>>>>> BOOT_IMAGE=(hd0,gpt2)/vmlinuz-7.3.0-rc4-gavin+ root=/dev/mapper/ rhel_nvidia--grace--hopper--01-root ro crashkernel=2G-4G:406M,4G-64G:470M,64G-:726M rd.lvm.lv=rhel_nvidia- grace-hopper-01/root rd.lvm.lv=rhel_nvidia-grace-hopper-01/swap video=simplefb:off kvm-arm.mode=nvhe
>>>>>>>>
>>>>>>>> host$ cd linux/tools/testing/selftests/kvm
>>>>>>>> host$ ./guest_print_test
>>>>>>>> Random seed: 0x193a0ed3
>>>>>>>> [  192.754328] kvm [6674]: nVHE hyp panic at: [<ffff8000811da044>] __kvm_nvhe___timer_enable_traps+0x4/0x160!
>>>>>>>> [  192.754338] kvm [6674]: nVHE call trace:
>>>>>>>> [  192.754339] kvm [6674]:  [<ffff8000811dcf34>] __kvm_nvhe_hyp_panic+0xb4/0xe0
>>>>>>>> [  192.754342] kvm [6674]:  [<ffff8000811dcba4>] __kvm_nvhe___kvm_vcpu_run+0x164/0x440
>>>>>>>> [  192.754344] kvm [6674]:  [<ffff8000811dfe90>] __kvm_nvhe_handle___kvm_vcpu_run+0x40/0x1f0
>>>>>>>> [  192.754346] kvm [6674]:  [<ffff8000811e0238>] __kvm_nvhe_handle_trap+0x158/0x280
>>>>>>>> [  192.754347] kvm [6674]:  [<ffff8000811dd8fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4
>>>>>>>> [  192.754348] kvm [6674]: ---[ end nVHE call trace ]---
>>>>>>>> [  192.754350] Code: d2818002 17fffff7 d503201f f9400001 (b94a6821)
>>>>>>>> [  192.754350] kvm [6674]: Hyp Offset: 0xfffeb0d7fe2e0000
>>>>>>>> [  192.754351] Kernel panic - not syncing: HYP panic:
>>>>>>>> [  192.754351] PS:834003c9 PC:0000cf2882efa044 ESR:0000000096000004
>>>>>>>> [  192.754351] FAR:ffff00009b286a68 HPFAR:8000000000000000 PAR:1d00ec7edbadc8de
>>>>>>>> [  192.754351] VCPU:0000cf011848a350
>>>>>>>> [  192.845154] CPU: 12 UID: 0 PID: 6674 Comm: guest_print_tes Kdump: loaded Not tainted 7.3.0-rc4-gavin+ #7 PREEMPT(full)
>>>>>>>> [  192.856182] Hardware name:  GH200 P5042, BIOS 02.04.01 20250422
>>>>>>>> [  192.862231] Call trace:
>>>>>>>> [  192.864725]  show_stack+0x20/0x38 (C)
>>>>>>>> [  192.868471]  dump_stack_lvl+0x88/0xb8
>>>>>>>> [  192.872215]  dump_stack+0x18/0x30
>>>>>>>> [  192.875598]  vpanic+0x280/0x498
>>>>>>>> [  192.878806]  panic+0x68/0x70
>>>>>>>> [  192.881745]  nvhe_hyp_panic_handler+0x184/0x190
>>>>>>>> [  192.886372]  kvm_arm_vcpu_enter_exit+0x24/0x100
>>>>>>>> [  192.891003]  kvm_arch_vcpu_ioctl_run+0x254/0x7c0
>>>>>>>> [  192.895726]  kvm_vcpu_ioctl+0x174/0xb40
>>>>>>>> [  192.899645]  __arm64_sys_ioctl+0xb0/0x120
>>>>>>>> [  192.903745]  invoke_syscall.constprop.0+0xa8/0x100
>>>>>>>> [  192.908639]  do_el0_svc+0xb8/0xe0
>>>>>>>> [  192.912022]  el0_svc+0x48/0x1f8
>>>>>>>> [  192.915228]  el0t_64_sync_handler+0xa0/0xe8
>>>>>>>> [  192.919500]  el0t_64_sync+0x1ac/0x1b0
>>>>>>>> [  192.923243] SMP: stopping secondary CPUs
>>>>>>>> [  192.927653] Starting crashdump kernel...
>>>>>>>> [  192.931658] Bye!
>>>>>>>>
>>>>>>>
>>>>>>> With the following changes applied after PATCH[01-05] on top of v7.3.rc4, the crash
>>>>>>> is avoided.
>>>>>>>
>>>>>>> In arch/arm64/include/asm/kvm_host.h:
>>>>>>>
>>>>>>> -#define kvm_vm_is_protected(kvm)       ((kvm)->arch.vm_flavor >= __VM_PROTECTED)
>>>>>>> +#define kvm_vm_is_protected(kvm)       \
>>>>>>> +       (is_protected_kvm_enabled() && (kvm)->arch.vm_flavor >= __VM_PROTECTED)
>>>>>>
>>>>>> That only papers over the problem. We can't use the vcpu_is_*
>>>>>> constructs from nvhe hyp, without converting the vcpu->kvm to
>>>>>> the hyp address, before accessing it. The fix is a bit more
>>>>>> involved. One option is to define the vcpu_is_* helpers only
>>>>>> for the !NVHE hyp code in the kvm_host.h (to avoid pulling
>>>>>> in the asm/kvm_mmu.h in to kvm_host.h and then make a mess
>>>>>> with header dependencies) and define the NVHE version in
>>>>>> asm/kvm_hyp.h. Something like :
>>>>>>
>>>>>>
>>>>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/ include/ asm/kvm_host.h
>>>>>> index 46a7f6c1e426c..4016d09ed39c3 100644
>>>>>> --- a/arch/arm64/include/asm/kvm_host.h
>>>>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>>>>> @@ -1545,11 +1545,14 @@ struct kvm *kvm_arch_alloc_vm(void);
>>>>>>   #define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE
>>>>>>
>>>>>>   #define kvm_vm_is_protected(kvm)       ((kvm)->arch.vm_flavor >= __VM_PROTECTED)
>>>>>> +
>>>>>> +#ifndef __KVM_NVHE_HYPERVISOR__
>>>>>>   #define vcpu_is_protected(vcpu) kvm_vm_is_protected((vcpu)->kvm)
>>>>>> +#define vcpu_is_protected_pkvm(vcpu) kvm_vm_is_protected_pkvm((vcpu)- >kvm)
>>>>>> +#endif
>>>>>>
>>>>>>   #define kvm_vm_is_protected_pkvm(kvm)          \
>>>>>>          (is_protected_kvm_enabled() && ((kvm)->arch.vm_flavor == VM_PROTECTED_PKVM))
>>>>>> -#define vcpu_is_protected_pkvm(vcpu) kvm_vm_is_protected_pkvm(vcpu- >kvm)
>>>>>>
>>>>>>   #define kvm_vm_is_unprotected_pkvm(kvm)                \
>>>>>>          (is_protected_kvm_enabled() && ((kvm)->arch.vm_flavor == VM_PKVM))
>>>>>> diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/ asm/kvm_hyp.h
>>>>>> index 4974492744cc8..3bf87e81af430 100644
>>>>>> --- a/arch/arm64/include/asm/kvm_hyp.h
>>>>>> +++ b/arch/arm64/include/asm/kvm_hyp.h
>>>>>> @@ -137,6 +137,19 @@ int __pkvm_init(phys_addr_t phys, unsigned long size, unsigned long *per_cpu_bas
>>>>>>   void __noreturn __host_enter(struct kvm_cpu_context *host_ctxt);
>>>>>>   #endif
>>>>>>
>>>>>> +#ifdef __KVM_NVHE_HYPERVISOR__
>>>>>> +#define vcpu_is_protected(vcpu)        \
>>>>>> + ({                                                              \
>>>>>> +               struct kvm *__kvm = READ_ONCE((vcpu)- >kvm);             \
>>>>>> +               __kvm && kvm_vm_is_protected((kern_hyp_va(__kvm)));     \
>>>>>> +       })
>>>>>> +#define vcpu_is_protected_pkvm(vcpu)                                   \
>>>>>> + ({                                                              \
>>>>>> +               struct kvm *__kvm = READ_ONCE((vcpu)- >kvm);             \
>>>>>> +               __kvm && kvm_vm_is_protected_pkvm((kern_hyp_va(__kvm)));\
>>>>>> +       })
>>>>>> +#endif
>>>>>> +
>>>>>>
>>>>>>
>>>>>> Or explicitly convert all nvhe accessors to a new "nvhe_vcpu_is_protected"
>>>>>>
>>>>>> The second one sounds like a better option to me.
>>>>>>
>>>>>
>>>>> We just need to include "asm/kvm_mmu.h" to "arch/arm64/mmio.c". With it,
>>>>> we can have unified functions (macros) in kvm_host.h to accomodate all
>>>>> cases, like below.
>>>>>
>>>>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/ asm/ kvm_host.h
>>>>> index 9b1cf9c59e81..b9c9a9f203f9 100644
>>>>> --- a/arch/arm64/include/asm/kvm_host.h
>>>>> +++ b/arch/arm64/include/asm/kvm_host.h
>>>>> @@ -1514,11 +1514,36 @@ struct kvm *kvm_arch_alloc_vm(void);
>>>>>   #define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE
>>>>>
>>>>>   #define kvm_vm_is_protected(kvm)       ((kvm)->arch.vm_flavor >= __VM_PROTECTED)
>>>>> -#define vcpu_is_protected(vcpu) kvm_vm_is_protected((vcpu)->kvm)
>>>>> +#define vcpu_is_protected(vcpu)                                                \
>>>>> + ({                                                              \
>>>>> +               struct kvm *__kvm = READ_ONCE((vcpu)- >kvm);             \
>>>>> +               bool __protected = false;                               \
>>>>> +                                                                       \
>>>>> +               if (__kvm) {                                            \
>>>>> +                       if (is_nvhe_hyp_code())                         \
>>>
>>> This needs to be :
>>>                if (is_nvhe_hyp_code() && !is_protected_kvm_enabled())
>>>
>>
>> Yes.
>>
>>>>> +                               __kvm = kern_hyp_va(__kvm);             \
>>>
>>> Otherwise, we unnecessarily convert the vcpu->kvm for a hyp_vcpu and
>>> that is not going to end well for pKVM.
>>>
>>
>> Yes. kern_hyp_va() isn't needed when is_protected_kvm_enabled() is true.
> 
> nit : It is not that it is needed, but it is incorrect to convert the vcpu->kvm which is already a HYP VA via kern_hyp_va() which is not
> idempotent and thus we end up accessing something junk.
> 

Yes.

>> Besides, vcpu_is_protected_pkvm() can be further simplifed by fully exploiting
>> the check (is_protected_kvm_enabled()) done in vcpu_is_protected_pkvm(),
>> see below.
> 
> Good point.
> 
>>
>>> Cheers
>>> Suzuki
>>>
>>>
>>>>> +                       __protected = kvm_vm_is_protected(__kvm);       \
>>>>> +               }                                                       \
>>>>> +                                                                       \
>>>>> + __protected;                                            \
>>>>> +        })
>>>>> +
>>>>>
>>>>>   #define kvm_vm_is_protected_pkvm(kvm)          \
>>>>>          (is_protected_kvm_enabled() && ((kvm)->arch.vm_flavor == VM_PROTECTED_PKVM))
>>>>> -#define vcpu_is_protected_pkvm(vcpu) kvm_vm_is_protected_pkvm(vcpu- >kvm)
>>>>> +#define vcpu_is_protected_pkvm(vcpu)                                   \
>>>>> + ({                                                              \
>>>>> +               struct kvm *__kvm = READ_ONCE((vcpu)- >kvm);             \
>>>>> +               bool __protected = false;                               \
>>>>> +                                                                       \
>>>>> +               if (__kvm) {                                            \
>>>>> +                       if (is_nvhe_hyp_code())                         \
>>>>> +                               __kvm = kern_hyp_va(__kvm);             \
>>>>> +                       __protected = kvm_vm_is_protected_pkvm(__kvm);  \
>>>>> +               }                                                       \
>>>>> +                                                                       \
>>>>> + __protected;                                            \
>>>>> +        })
>>
>> This can be further simplified by fully expliting the check (is_protected_kvm_enabled())
>> in kvm_vm_is_protected_pkvm(), as below. The point is that the check is_protected_kvm_enabled()
>> gurantees that kern_hyp_va() isn't needed.
>>
>> #define vcpu_is_protected_pkvm(vcpu)                                    \
>>          ({                                                              \
>>                  struct kvm *__kvm = READ_ONCE((vcpu)->kvm);             \
>>                  bool __protected = false;                               \
>>                                                                          \
>>                  if (__kvm)                                              \
>>                          __protected = kvm_vm_is_protected_pkvm(__kvm);  \
>>                                                                          \
>>                  __protected;                                            \
>>          })
>>
> 
> Ack, I have reduced this to:
> 
> 
> /*
>   * Rely on is_protected_kvm_enabled() check in kvm_vm_is_protected_pkvm() to
>   * make sure the vcpu->kvm is always valid VA in the context
>   */
> #define vcpu_is_protected_pkvm(vcpu)                                    \
>          ({                                                              \
>                  struct kvm *__kvm = READ_ONCE((vcpu)->kvm);             \
>                                                                          \
>                  (__kvm) && kvm_vm_is_protected_pkvm(__kvm));            \
>          })
> 

Parentheses for the local variable '__kvm' can be dropped. With this, this
looks good to me.

                    (__kvm && kvm_vm_is_protected_pkvm(__kvm));

Thanks,
Gavin

> 
> Cheers
> Suzuki
> 
>>>>>
>>>>>   #define kvm_vm_is_unprotected_pkvm(kvm)                \
>>>>>          (is_protected_kvm_enabled() && ((kvm)->arch.vm_flavor == VM_PKVM))
>>>>> diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
>>>>> index d1c3a352d5a2..ab1d2fef9a52 100644
>>>>> --- a/arch/arm64/kvm/mmio.c
>>>>> +++ b/arch/arm64/kvm/mmio.c
>>>>> @@ -6,6 +6,7 @@
>>>>>
>>>>>   #include <linux/kvm_host.h>
>>>>>   #include <asm/kvm_emulate.h>
>>>>> +#include <asm/kvm_mmu.h>
>>>>>   #include <trace/events/kvm.h>
>>>>>
>>>>>   #include "trace.h"
>>>>>
>>>>
>>>> Thanks Gavin, that works and looks neat. I will incorporate it.
>>>>
>>
>> Thanks,
>> Gavin
>>
> 


  reply	other threads:[~2026-09-24 10:38 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-20 21:28 [PATCH v19 00/20] KVM: arm64: CCA: Add basic plumbing for Realms Suzuki K Poulose
2026-09-20 21:28 ` [PATCH v19 01/20] KVM: arm64: protected VM: Handle user writes to CNTVCT_EL0/CNTPCT_EL0 Suzuki K Poulose
2026-09-22 19:25   ` Jonathan Cameron
2026-09-22 21:53     ` Suzuki K Poulose
2026-09-23 16:48       ` Jonathan Cameron
2026-09-22 22:04     ` Suzuki K Poulose
2026-09-23 16:51       ` Jonathan Cameron
2026-09-20 21:28 ` [PATCH v19 02/20] KVM: arm64: Disable Steal time accounting for protected guests Suzuki K Poulose
2026-09-20 21:44   ` sashiko-bot
2026-09-20 22:24     ` Suzuki K Poulose
2026-09-21 23:07       ` Suzuki K Poulose
2026-09-28  0:14   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 03/20] KVM: arm64: Include kvm_emulate.h in kvm/arm_psci.h Suzuki K Poulose
2026-09-22 19:32   ` Jonathan Cameron
2026-09-20 21:28 ` [PATCH v19 04/20] KVM: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h Suzuki K Poulose
2026-09-20 21:38   ` sashiko-bot
2026-09-21  8:25     ` Suzuki K Poulose
2026-09-20 21:28 ` [PATCH v19 05/20] KVM: arm64: Track the type of VM in kvm_arch Suzuki K Poulose
2026-09-20 21:38   ` sashiko-bot
2026-09-21  8:18     ` Suzuki K Poulose
2026-09-22 19:40   ` Jonathan Cameron
2026-09-23  6:05   ` Gavin Shan
2026-09-23  6:19     ` Gavin Shan
2026-09-23 10:24       ` Suzuki K Poulose
2026-09-23 13:23         ` Gavin Shan
2026-09-23 13:29           ` Gavin Shan
2026-09-23 13:54             ` Suzuki K Poulose
2026-09-23 16:27           ` Suzuki K Poulose
2026-09-23 21:37             ` Suzuki K Poulose
2026-09-24  1:11               ` Gavin Shan
2026-09-24  8:48                 ` Suzuki K Poulose
2026-09-24 10:37                   ` Gavin Shan [this message]
2026-09-20 21:28 ` [PATCH v19 06/20] KVM: arm64: Refactor the vcpu_load to allow for VM specific callbacks Suzuki K Poulose
2026-09-22 19:57   ` Jonathan Cameron
2026-09-22 22:09     ` Suzuki K Poulose
2026-09-20 21:28 ` [PATCH v19 07/20] KVM: arm64: Add vcpu load/put call backs for flavors Suzuki K Poulose
2026-09-22 22:12   ` Jonathan Cameron
2026-09-20 21:28 ` [PATCH v19 08/20] KVM: arm64: Reuse kvm_stage2_unmap_range in kvm_unmap_gfn_range Suzuki K Poulose
2026-09-22 22:15   ` Jonathan Cameron
2026-09-28  0:17   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 09/20] KVM: arm64: Add VM specific callback for S2 MMU operations Suzuki K Poulose
2026-09-22 22:29   ` Jonathan Cameron
2026-09-22 23:21     ` Suzuki K Poulose
2026-09-23 16:54       ` Jonathan Cameron
2026-09-24 15:11         ` Suzuki K Poulose
2026-09-28  1:09   ` Gavin Shan
2026-09-28  1:25     ` Gavin Shan
2026-09-28  8:13       ` Suzuki K Poulose
2026-09-28  8:10     ` Suzuki K Poulose
2026-09-20 21:28 ` [PATCH v19 10/20] KVM: arm64: Abstract out memory abort handling Suzuki K Poulose
2026-09-22 22:38   ` Jonathan Cameron
2026-09-22 23:55     ` Suzuki K Poulose
2026-09-20 21:28 ` [PATCH v19 11/20] KVM: arm64: Mandate VGIC v3 for for VMs running on hyp that don't trust the host Suzuki K Poulose
2026-09-22 22:42   ` Jonathan Cameron
2026-09-22 23:38     ` Suzuki K Poulose
2026-09-28  1:10   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 12/20] KVM: arm64: CCA: Add a new mode for supporting Realm guests Suzuki K Poulose
2026-09-22 22:43   ` Jonathan Cameron
2026-09-20 21:28 ` [PATCH v19 13/20] KVM: arm64: CCA: Add VCPU load/put for Realms Suzuki K Poulose
2026-09-28  1:22   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 14/20] KVM: arm64: CCA: Add bare minimal S2 operations for Realm Suzuki K Poulose
2026-09-28  1:27   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 15/20] KVM: arm64: CCA: Introduce Realms Suzuki K Poulose
2026-09-22 22:49   ` Jonathan Cameron
2026-09-28  1:27   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 16/20] KVM: arm64: CCA: Don't expose unsupported capabilities for realm guests Suzuki K Poulose
2026-09-22 22:53   ` Jonathan Cameron
2026-09-20 21:28 ` [PATCH v19 17/20] KVM: arm64: CCA: WARN on injected undef exceptions Suzuki K Poulose
2026-09-22 22:54   ` Jonathan Cameron
2026-09-28  1:28   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 18/20] KVM: arm64: CCA: Support timers in realm RECs Suzuki K Poulose
2026-09-20 21:28 ` [PATCH v19 19/20] KVM: arm64: CCA: Expose SVE VL register before VCPU finalization Suzuki K Poulose
2026-09-28  1:29   ` Gavin Shan
2026-09-20 21:28 ` [PATCH v19 20/20] KVM: arm64: CCA: Control user register access for Realms Suzuki K Poulose
2026-09-28  1:30   ` Gavin Shan
2026-09-24 10:40 ` [PATCH v19 00/20] KVM: arm64: CCA: Add basic plumbing " Gavin Shan
2026-09-24 10:49   ` Suzuki K Poulose

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=aa6133dd-bc9a-4bf1-877d-3a1230efa644@redhat.com \
    --to=gshan@redhat.com \
    --cc=WeiLin.Chang@arm.com \
    --cc=alpergun@google.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=enju.kohei@fujitsu.com \
    --cc=fj0570is@fujitsu.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sdonthineni@nvidia.com \
    --cc=steven.price@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.