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+QEMUhttps://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/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.orgmailto:tf-rmm@lists.trustedfirmware.org>; Date: Wed, Aug 6, 2025 04:38 PM To: "neptune"<awsomered@foxmail.commailto:awsomered@foxmail.com>;"tf-rmm"<tf-rmm@lists.trustedfirmware.orgmailto:tf-rmm@lists.trustedfirmware.org>; Cc: "nd"<nd@arm.commailto: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.h... and see the behavior.
Best Regards Soby Mathew
From: neptune via tf-rmm <tf-rmm@lists.trustedfirmware.orgmailto:tf-rmm@lists.trustedfirmware.org> Sent: Tuesday, August 5, 2025 2:02 PM To: tf-rmm <tf-rmm@lists.trustedfirmware.orgmailto: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