Share a variable of Core with other components
Jaemin Park
jmpark81 at ...9...
Tue Feb 6 16:23:56 CET 2018
Hi,
First of all, I really appreciate the comments that helped me a lot.
Finally, I solved my problem.
The most critical problem in my implementation was to use a virtual address
to make a Rom_module.
For the reference, I summarized my implementation as follows:
1) Core(repos/base/src/core/main.cc)
static unsigned char core_data[32]; /* data I'd like to share */
int main()
{
...
/* allocate dataspace used for creating shared memory between core
and others*/
Dataspace_capability ds = env()->ram_session()->alloc(4096);
void* local_addr = env()->rm_session()->attach(ds);
Genode::memcpy((void*)local_addr, (const void*) core_data, 32);
/* add to ROM FS */
Rom_module *rom_module = new (platform()->core_mem_alloc())
Rom_module((addr_t)Dataspace_client(ds).phys_addr(), /*
Here, use phys_addr */
4096, "core_data");
platform()->rom_fs()->insert(rom_module);
...
}
2) tz_vmm(repos/or/src/server/tz_vmm/spec/imx53/main.cc)
static unsigned char core_data[32]={0,};
int main()
{
Attached_rom_dataspace rom("core_data");
if(!rom.is_valid())
Genode::log("attached_rom_dataspace() is not valid!");
else{
Genode::memset(core_data, 0, sizeof(core_data));
Genode::memcpy(core_data, rom.local_addr<unsigned char>(),
sizeof(core_data);
}
...
}
I hope this share can help others.
Jaemin Park
On Tue, Feb 6, 2018 at 7:08 PM, Stefan Kalkowski <
stefan.kalkowski at ...1...> wrote:
> Hi Jaemin,
>
> On Tue, Feb 06, 2018 at 09:20:03AM +0900, Jaemin Park wrote:
> > 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.
>
> a Rom_module expects a physical address as the first constructor
> argument, not a core/kernel virtual one.
>
> See my comments below.
>
> >
> > 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");
>
> You have to take the physical memory address of the dataspace "ds"
> instead of "local_addr" here.
>
> > > 350 platform()->rom_fs()->insert(rom_module);
> > > 351
> > > platform()->wait_for_exit();
> > > ...
>
> In general, this generic code location is not appropriated for your
> attempt. I think, the Platform() constructor in:
>
> repos/base-hw/src/core/platform.cc
>
> might be a better place for your snippet. There you will also find an
> example of the "core log" being exported as dataspace in more recent
> Genode development branches, e.g., staging branch.
>
> > > }
> > >
> > > 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 */
>
> Here, you'll copy 4096 bytes to a local variable, which is only 32
> bytes in size!
>
> What kind of data do you export from core to the VMM, and why don't
> you use the VM dataspace therefore?
>
> Regards
> Stefan
>
> > > 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
> > >>>
> > >>
> > >>
> > >
>
> > ------------------------------------------------------------
> ------------------
> > 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/20180207/c6767278/attachment.html>
More information about the users
mailing list