Share a variable of Core with other components
Jaemin Park
jmpark81 at ...9...
Tue Feb 6 01:20:03 CET 2018
Hi,
I'd like to add some log information for clarification.
In Core, the address of populated rm_session(local_addr) is 0x12d000.
When Rom_module is created inside Core, the address of it(rom_module) is
also 0x12d000.
In tz_vmm, the address of local_data(attached to Dataspace_capability) is
0xc000.
The error message displayed in the previous e-mail happens when tz_vmm
attempted to access local_data(0xc000) by memcpy().
I hope this clarification can help you give me an advice or any comments.
Jaemin Park
On Mon, Feb 5, 2018 at 9:59 AM, Jaemin Park <jmpark81 at ...9...> wrote:
> Hi,
>
> I attempted to implement a read-only method to share a variable of Core.
>
> My attempt showed me an error as follows:
> Error: init -> tz_vmm -> ep: raised unhandled data abort DFSR=0x1008
> ISFR=0x7 DFAR=0xc000 ip=0x70010c40 sp=0xe02fef00
>
> My implementation is as follows(blue-colored parts):
>
> 1) Core(repos/base/src/core/main.cc)
>
> static unsigned char core_data[32]; /* data I'd like to share */
>
> int main()
> {
> ...
> Pd_connection init_pd("init");
> Core_child *init = new (env()->heap())
> Core_child(Rom_session_client(init_rom_session_cap).dataspac
> e(),
> init_pd, init_ram_session_cap, init_cpu.cap(),
> local_services);
>
> /* allocate dataspace used for creating shared memory between
> core and init */
> 342 Dataspace_capability ds = env()->ram_session()->alloc(4096);
> 343 void* local_addr = env()->rm_session()->attach(ds);
> 344 Genode::printf("local_addr=0x%p\n", local_addr);
> 345 Genode::memcpy((void*)local_addr, (const void*) core_data, 32);
> 346
> 347 /* add to ROM FS */
> 348 Rom_module *rom_module = new (platform()->core_mem_alloc())
> 349 Rom_module((addr_t)local_addr, 4096, "core_data");
> 350 platform()->rom_fs()->insert(rom_module);
> 351
> platform()->wait_for_exit();
> ...
> }
>
> 2) tz_vmm(repos/os/src/server/tz_vmm/spec/imx53/main.cc)
>
> int main()
> {
> 149 /* obtain core_data */
> 150 Dataspace_capability ds;
> 151 try{
> 152 static Genode::Rom_connection rom("core_data");
> 153 ds = rom.dataspace();
> 154 }catch(...){
> 155 error("ROM module \"core_data\" not present");}
> 156
> 157 void* core_data =
> 158 (void*) Genode::env()->rm_session()->attach(ds);
> 159 Genode::size_t size = Genode::Dataspace_client(ds).size();
> 160 static unsigned char local_data[32];
> 161 Genode::memcpy((void*)local_data, (const void*)core_data, size);
> /* data abort happens here */
> 162 Genode::env()->rm_session()->detach(measurement);
>
> static Vm vm("linux", cmdline_tablet,
> Trustzone::NONSECURE_RAM_BASE,
> Trustzone::NONSECURE_RAM_SIZE,
> KERNEL_OFFSET, MACH_TYPE_QSB);
> static Vmm::Vmm vmm(&vm);
> ...
> }
>
> Is there any comment on my implementation?
> Any comment comments would be highly appreciated.
>
> JaeminPark
>
>
> On Fri, Feb 2, 2018 at 9:49 PM, Jaemin Park <jmpark81 at ...9...> wrote:
>
>> Hi,
>>
>> I really appreciate your kind and quick response.
>>
>> In my case, a one-way read-only fashion is enough.
>> I'd like to share an information that other components can read only.
>>
>> If you can give me an example or any reference code published in the git
>> repository, please let me know.
>>
>> Sorry for a newbie's request.
>>
>> JaeminPark
>>
>> On Fri, Feb 2, 2018 at 6:27 PM, Stefan Kalkowski <
>> stefan.kalkowski at ...1...> wrote:
>>
>>> Hi Jaemin,
>>>
>>> On Fri, Feb 02, 2018 at 11:28:53AM +0900, Jaemin Park wrote:
>>> > Hi,
>>> >
>>> > I'd like to ask a question about a way to "share a variable of Core
>>> with
>>> > other components".
>>> >
>>> > I'm using i.MX53 QSB, so this question is based on 'base-hw'
>>> implementation.
>>> >
>>> > Suppose that 'Core' has a variable "A" and makes it visible to other
>>> > components like 'Init' or else.
>>> >
>>> > For this, I added a routine to use a Dataspace_capability for "A" in
>>> main()
>>> > of 'Core' as follows:
>>> > *[repos/base/src/core/main.cc]*
>>> > *Dataspace_capability ds = env()->ram_session()->alloc(4096);*
>>> > *unsigned char *local_addr = env()->rm_session()->attach(ds);*
>>> >
>>> > However, I faced a difficulty to implement an RPC to delegate(share)
>>> the
>>> > Dataspace_capability to other components.
>>> >
>>> > Is there any simple or proper way to share "A" of 'Core' with other
>>> > components?
>>> > If possible, please give me an example.
>>>
>>> Well, in general there are only few examples where core 'shares'
>>> memory with other components. Due to core being the security critical
>>> kernel component, it is a bad idea to widen the interface to it too
>>> much. Apart from this disclaimer, there are some information needed to
>>> be exported from core to specific components, e.g., platform
>>> information like ACPI etc. from the booting infrastructure exported to
>>> the platform driver. Those information are shared in a one-way
>>> read-only fashion. Therefore, it is enough to create a dataspace
>>> within core, and export it as a ROM module using a dedicated name for
>>> it. The user-level component can open that dataspace using the normal
>>> ROM session interface of core.
>>>
>>> If you want to share information bi-directional this approach
>>> obviously is no way. On the other hand it is not recommended at all to
>>> import data into the kernel beyond the existing system calls.
>>> An exception is the VM session interface of base-hw's core, which
>>> exports a dataspace to the VMM component used to reflect the machine
>>> register set of the VM under control of the VMM. Those register
>>> contents can be altered by the VMM, e.g., after doing some device
>>> emulation, and is taken by the kernel to reload the registers when
>>> switching to the VM again. Of course, when sharing data in such a way
>>> both sides need to synchronize before accessing the shared data.
>>> Because core/kernel cannot block on any user-level component, signals
>>> are used to hint the VMM about a change of the VM state, whereby the
>>> VMM calls core via IPC (VM session interface) to mark that the VM
>>> state handling has finished, and the VM is re-runnable.
>>>
>>> I hope this clarifies your question. If not you may explain your
>>> use-case in more details.
>>>
>>> Best regards
>>> Stefan
>>>
>>> >
>>> > Any comment comments would be highly appreciated.
>>> >
>>> > JaeminPark
>>>
>>> > ------------------------------------------------------------
>>> ------------------
>>> > Check out the vibrant tech community on one of the world's most
>>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>> > _______________________________________________
>>> > genode-main mailing list
>>> > genode-main at lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
>>>
>>> --
>>> Stefan Kalkowski
>>> Genode labs
>>>
>>> https://github.com.skalk | https://genode.org
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> genode-main mailing list
>>> genode-main at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20180206/41b1eed4/attachment.html>
More information about the users
mailing list