mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	kvm@vger.kernel.org, kvmarm@lists.linux.dev, will@kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
	aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com,
	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,
	sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com
Subject: Re: [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM
Date: Wed, 21 Oct 2026 15:30:07 +0100	[thread overview]
Message-ID: <86ld7ryvm8.wl-maz@kernel.org> (raw)
In-Reply-To: <5d487949-9195-442f-97af-acb9e3fdfb0d@arm.com>

On Wed, 21 Oct 2026 10:58:13 +0100,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> 
> On 29/09/2026 12:15, Catalin Marinas wrote:
> > On Mon, Sep 28, 2026 at 07:28:20PM +0100, Suzuki K Poulose wrote:
> >> On 28/09/2026 19:01, Catalin Marinas wrote:
> >>> possible, to defer the RMM activation until the first user (still do the
> >>> RMI probing as an initcall). If we run on RME-capable hardware and
> >>> firmware but don't care about realms or TSM, we still get the normal OS
> >>> functionality.
> >> 
> >> Would you prefer this in the first drop of the RMM ? Or is this
> >> something we could add as a separate series ?
> > 
> > I think we could add the deferring as a separate patch, maybe together
> > with the KVM bits. An advantage of keeping it here if we merge this
> > first is that we still exercise the activation path without full realm
> > support or TSM. Otherwise a lot of this would be dead code until the
> > other series arrive. Either way, do it as as separate patch on top of
> > this series.
> > 
> 
> I have been looking at the "on-demand" activation support and came
> across the following design decision.
> 
> * We have KVM_CAP_ARM_RME which advertises that KVM can create Realm VMs
>   to the userspace. A VMM could check this before it creates a Realm VM
>   using KVM_CREATE_VM with type=RealmVM.
> 
> 
> Now, we could delay the RMM activation as late as the KVM_CREATE_VM and
> kick it off while we initialise the kvm as part of kvm_arch_init_vm().
> But if that fails, we would fail the KVM_CREATE_VM.
> 
> The question is, what should KVM_CAP_ARM_RME indicate ?  We could
> initially enable the cap based on the presence of RMM (but not
> activated). However, should we turn the KVM_CAP_ARM_RME=off when we
> fail to activate the RMM ? Is that senisble ? (i.e., runtime
> disabling a cap).

I think this sets a bad precedent. If activation can fail, KVM end-up
not delivering on the promise that it makes, and that's not great.

My take is that the least surprising behaviour is best. If you have
bought into the CCA kool-aid by enabling it on the kernel command
line, that's not by accident. You expect your VMs to reliably be
created when KVM tells you that CCA is available.

So KVM_CAP_ARM_RME should indicate whether the RMM has been
successfully activated, and nothing else.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2026-10-21 14:30 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 13:51 [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 1/7] firmware: arm_rmm: Add SMC definitions for calling the RMM Suzuki K Poulose
2026-09-24 16:57   ` Jonathan Cameron
2026-09-24 22:15     ` Suzuki K Poulose
2026-09-24 17:05   ` Ackerley Tng
2026-09-24 22:49     ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 2/7] firmware: arm_rmm: Check for RMI support at init Suzuki K Poulose
2026-09-24 16:58   ` Jonathan Cameron
2026-09-25  0:00   ` Gavin Shan
2026-09-25  8:51     ` Suzuki K Poulose
2026-09-25  5:43   ` Gavin Shan
2026-09-25  8:50     ` Suzuki K Poulose
2026-09-25 10:42   ` Catalin Marinas
2026-09-25 15:23     ` Suzuki K Poulose
2026-09-27  9:29       ` Marc Zyngier
2026-09-28  8:05         ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 3/7] firmware: arm_rmm: Configure the RMM with the host's page size Suzuki K Poulose
2026-09-24 17:03   ` Jonathan Cameron
     [not found]     ` <d4b768e5-c942-43cf-aea2-c266a8bab353@oss.qualcomm.com>
2026-09-25 14:56       ` Suzuki K Poulose
2026-09-26 13:38         ` Venkata Rao Kakani
2026-09-25  0:03   ` Gavin Shan
2026-09-24 13:51 ` [PATCH v19 4/7] firmware: arm_rmm: Add support for SRO Suzuki K Poulose
2026-09-24 19:13   ` Jonathan Cameron
2026-09-24 23:10     ` Suzuki K Poulose
2026-09-25  5:24   ` Gavin Shan
2026-09-29 12:52     ` Suzuki K Poulose
2026-09-25 11:50   ` Catalin Marinas
2026-09-25 15:11     ` Suzuki K Poulose
2026-09-28  9:28   ` Catalin Marinas
2026-09-28 10:13     ` Suzuki K Poulose
2026-09-28 17:28       ` Catalin Marinas
2026-09-28 20:45         ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM Suzuki K Poulose
2026-09-25 12:17   ` Catalin Marinas
2026-09-25 15:02     ` Suzuki K Poulose
2026-09-25 15:34       ` Alper Gun
2026-09-25 16:42       ` Catalin Marinas
2026-09-25 17:50         ` Suzuki K Poulose
2026-09-28  9:08           ` Suzuki K Poulose
2026-09-28 13:55             ` Suzuki K Poulose
2026-09-28 18:01               ` Catalin Marinas
2026-09-28 18:28                 ` Suzuki K Poulose
2026-09-29 11:15                   ` Catalin Marinas
2026-10-21  9:58                     ` Suzuki K Poulose
2026-10-21 14:30                       ` Marc Zyngier [this message]
2026-09-24 13:52 ` [PATCH v19 6/7] firmware: arm_rmm: Ensure the RMM has GPT entries for memory Suzuki K Poulose
2026-09-24 21:38   ` Jonathan Cameron
2026-09-24 23:30     ` Suzuki K Poulose
2026-09-25 15:30       ` Jonathan Cameron
2026-09-25  0:07   ` Gavin Shan
2026-09-29 11:01   ` Catalin Marinas
2026-09-29 12:15     ` Suzuki K Poulose
2026-09-29 22:17   ` Shanker Donthineni
2026-09-29 22:25     ` Suzuki K Poulose
2026-09-29 22:29   ` Shanker Donthineni
2026-09-30  8:17     ` Suzuki K Poulose
2026-09-24 13:52 ` [PATCH v19 7/7] firmware: arm_rmm: Add wrappers for Realm related RMI commands Suzuki K Poulose
2026-09-25 11:56   ` Catalin Marinas
2026-09-29 12:15     ` Suzuki K Poulose
2026-09-25  6:29 ` [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Gavin Shan
2026-09-25  9:03   ` Suzuki K Poulose
2026-09-29 10:50 ` Catalin Marinas
2026-09-29 12:14   ` 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=86ld7ryvm8.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --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=gshan@redhat.com \
    --cc=joey.gouly@arm.com \
    --cc=jonathan.cameron@oss.qualcomm.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=oupton@kernel.org \
    --cc=sdonthineni@nvidia.com \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®