Hi,

Ok. It seems to be some effect of memory management of kernel and I don’t know details about that. Otherwise, your FVP/QEMU setup seems fine.

Best Regards

Soby Mathew

From: neptune <awsomered@foxmail.com>
Sent: Wednesday, August 6, 2025 10:49 AM
To: Soby Mathew <Soby.Mathew@arm.com>
Subject: Re:[tf-rmm] Re: question about rmm

test both on qemu and fvp.When use fvp, I follow the step of cca-3world in shrinkwrap but with da support.But i don't think da will cause this.And when use qemu, I follow the step in 

Building+an+RME+stack+for+QEMU without da support.

And then, what's strange is that when i use allocated memory,it will cause gpf.Like this.

static void *allocate_granule(void) {

void *page = (void *)__get_free_pages(GFP_KERNEL, 0); // Allocate one page

if (!page) {

printk(KERN_ERR "Failed to allocate granule\n");

    }

return page;

}

int create_realm(void)

{

struct smc_result result;

int ret = 10;

void* tmp = allocate_granule();

if (!tmp) {

pr_err("Failed to allocate tmp buffer\n");

return -ENOMEM;

    }

memset(tmp, 0, PAGE_SIZE);

memcpy(tmp, (void *)realm_start, PAGE_SIZE);

host_rmi_granule_delegate(virt_to_phys(tmp), &result);

CHECK_RMI_RESULT();

pr_info("host_rmi_granule_delegate %p\n", (uintptr_t)virt_to_phys(tmp));

char dst[9] = {0};

memcpy(dst, tmp, 8);

pr_info("memcpy done %x\n", *(uint64_t *)dst);

host_rmi_granule_undelegate(virt_to_phys(tmp), &result);

CHECK_RMI_RESULT();

pr_info("host_rmi_granule_undelegate done\n");

return 0;

}

------------------ Original ------------------

From: "Soby Mathew" <tf-rmm@lists.trustedfirmware.org>;

Date: Wed, Aug 6, 2025 04:38 PM

To: "neptune"<awsomered@foxmail.com>;"tf-rmm"<tf-rmm@lists.trustedfirmware.org>;

Cc: "nd"<nd@arm.com>;

Subject: [tf-rmm] Re: question about rmm

Hi Neptune

You are right, I would have expected a Granule protection fault (GPF) when accessing a physical address delegated to realm world. It is difficult to say why, without further information about the platform , EL3 firmware used etc. If the platform is FVP, then the FVP cmd line options would need to be verified.

Would recommend reproducing your test in a shrinkwrap setup https://shrinkwrap.docs.arm.com/en/latest/userguide/configstore/cca-3world.html and see the behavior.

Best Regards

Soby Mathew

From: neptune via tf-rmm <tf-rmm@lists.trustedfirmware.org>
Sent: Tuesday, August 5, 2025 2:02 PM
To: tf-rmm <tf-rmm@lists.trustedfirmware.org>
Subject: [tf-rmm] question about rmm

I'm doing some tests on tf-rmm while found something interesting.

Why this code can execute without error?This code is part of a driver.

__attribute__((aligned(4096)))

static int realm_start(void)

{

return 11;

}

int create_realm(void)

{

struct smc_result result;

int ret = 10;

flush_cache_all();

flush_tlb_all();

isb();

host_rmi_granule_delegate(virt_to_phys(realm_start), &result);

CHECK_RMI_RESULT();

pr_info("host_rmi_granule_delegate %lx\n", (uintptr_t)virt_to_phys(realm_start));

flush_cache_all();

flush_tlb_all();

isb();

ret = realm_start();

pr_info("run realm start %d\n", ret);

char dst[9] = {0};

memcpy(dst, realm_start, 8);

pr_info("memcpy done %x\n", *(uint64_t *)dst);

host_rmi_granule_undelegate(virt_to_phys(realm_start), &result);

CHECK_RMI_RESULT();

pr_info("host_rmi_granule_undelegate done\n");

return 0;

}

Here is the output of linux and tf-rmm

[  743.248076] realm: loading out-of-tree module taints kernel.

[  743.260986] realm_create: Module loaded

[  743.261778] SMC_GRANULE_DELEGATE: addr = 0xeda70000 eda70000

[  743.265428] host_rmi_granule_delegate eda70000

[  743.266110] run realm start 11

[  743.266581] memcpy done 52800160

[  743.268005] host_rmi_granule_undelegate done

SMC_RMI_GRANULE_DELEGATE      eda70000 > RMI_SUCCESS

SMC_RMI_GRANULE_UNDELEGATE    eda70000 > RMI_SUCCESS