RE: [PATCH v6 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms

[Michael Kelley <mhklinux@outlook.com>]

From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Wednesday, November 11, 2026 2:37 PM
> 
> On 11/11/2026 10:01 AM, Michael Kelley wrote:
> > From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Friday, October 30, 2026 5:14 PM
> >>
> >> In hv_common_cpu_init(), the per-CPU hypercall input/output pages need
> >> to be marked as decrypted (shared) for confidential VM isolation types.
> >> This is already done for SNP and TDX isolation; extend the same handling
> >> to Arm CCA Realm guests so that the host hypervisor can access the
> >> shared hypercall buffers.
> >>
> >> is_realm_world() is declared in include/linux/arm-rsi-cmds.h which only
> >> builds on arm64 (it includes <asm/memory.h>), so using it directly in
> >> the arch-neutral drivers/hv/hv_common.c would break the x86 build.
> >> Introduce a Hyper-V-specific helper following the established
> >> hv_isolation_type_snp() / hv_isolation_type_tdx() pattern.
> >>
> >> On architectures other than arm64 the weak default keeps the existing
> >> behaviour.
> >>
> >> Reviewed-by: Michael Kelley <mhklinux@outlook.com>
> >> Signed-off-by: Kameron Carr <kameroncarr@linux.microsoft.com>
> >> ---
> >>  arch/arm64/hyperv/mshyperv.c   |  5 +++++
> >>  drivers/hv/hv_common.c         | 17 +++++++++++++----
> >>  include/asm-generic/mshyperv.h |  1 +
> >>  3 files changed, 19 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> >> index 46ab2da..da6c3aa0 100644
> >> --- a/arch/arm64/hyperv/mshyperv.c
> >> +++ b/arch/arm64/hyperv/mshyperv.c
> >> @@ -182,3 +182,8 @@ bool hv_is_hyperv_initialized(void)
> >>  	return hyperv_initialized;
> >>  }
> >>  EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
> >> +
> >> +bool hv_isolation_type_cca(void)
> >> +{
> >> +	return is_realm_world();
> >> +}
> >> diff --git a/drivers/hv/hv_common.c b/drivers/hv/hv_common.c
> >> index 31256cb..a60c92c 100644
> >> --- a/drivers/hv/hv_common.c
> >> +++ b/drivers/hv/hv_common.c
> >> @@ -476,6 +476,7 @@ int hv_common_cpu_init(unsigned int cpu)
> >>  	u64 msr_vp_index;
> >>  	gfp_t flags;
> >>  	const int pgcount = hv_output_page_exists() ? 2 : 1;
> >> +	const size_t alloc_size = ALIGN((size_t)pgcount * HV_HYP_PAGE_SIZE, PAGE_SIZE);
> >>  	void *mem;
> >>  	int ret = 0;
> >>
> >> @@ -489,7 +490,7 @@ int hv_common_cpu_init(unsigned int cpu)
> >>  	 * online and then taken offline
> >>  	 */
> >>  	if (!*inputarg) {
> >> -		mem = kmalloc_array(pgcount, HV_HYP_PAGE_SIZE, flags);
> >> +		mem = kmalloc(alloc_size, flags);
> >>  		if (!mem)
> >>  			return -ENOMEM;
> >>
> >> @@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu)
> >>  		}
> >>
> >>  		if (!ms_hyperv.paravisor_present &&
> >> -		    (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
> >> -			ret = set_memory_decrypted((unsigned long)mem, pgcount);
> >> +		    (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
> >> +		     hv_isolation_type_cca())) {
> >
> > Could this big "if" statement use "hv_is_isolation_supported()" instead
> > of explicitly testing for each CoCo VM type? I ask partly because
> > Mukesh Rathor has just submitted a patch [1] that introduces a new
> > function that does something almost exactly the same as
> > hv_is_isolation_supported() and uses it here.
> >
> > You don't provide the non-stub hv_is_isolation_supported() until
> > Patch 6 of this series, but the weak stub should allow everything to
> > build if a bisection splits this patch series.
> 
> Including your response to Mukesh for context:
> > Any reason not to use hv_is_isolation_supported()? Your
> > new function seems conceptually equivalent, though at a
> > detailed level it handles VBS isolation differently from
> > hv_is_isolation_supported(). But I don't think including
> > VBS isolation here is a problem since set_memory_decrypted()
> > is a no-op with VBS isolation.
> 
> I'm not fully convinced that calling set_memory_decrypted() is always a
> no-op for VBS.
> 
> I see that on VBS VMs, ms_hyperv_init_platform() calls hv_vtom_init().
> If set_memory_decrypted() calls hv_mark_gpa_visibility(), you will try
> to use the inputarg before it has been initialized.
> 
> Please let me know if my understanding is incorrect.

You are right. In general, it *is* okay to call
set_memory_decrypted/encrypted() with VBS isolation. The
decrypt/encrypt paths go through all the normal machinery,
including making the Hyper-V hypercalls. But the net result
is no change in the guest. PTEs remain unchanged and the
vTOM bit is not added to physical addresses. In that sense,
it is a no-op, which is what I was remembering. But in this
case, that doesn't work because of the scenario you point
out. This call to set_memory_decrypted() must be skipped
for VBS isolation. I may do a small patch to add a comment
to the code here identifying this as an exception.

The fully-enlightened (no paravisor) cases for SNP and TDX
are good because they don't call hv_vtom_init(). In those
cases, set_memory_decrypted() uses the "native" callbacks
to update the hypervisor. Those native callbacks don't know
anything about Hyper-V or the per-cpu input page, and so
don't have the chicken-and-egg problem that VBS isolation has.

I need to go review again how all this works for CCA. :-)

Thanks,

Michael