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.
Any comment comments would be highly appreciated.
JaeminPark
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@...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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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).dataspace(), 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@...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@...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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@...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):
- 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 betweencore 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(); ... }
- 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@...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@...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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@...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):
- 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 betweencore 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.
}
- 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@...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@...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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
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@...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@...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):
- 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 betweencore 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.ccmight 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.
}
- 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@...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@...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@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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi Jaemin,
On 06.02.2018 16:23, Jaemin Park wrote:
First of all, I really appreciate the comments that helped me a lot.
Finally, I solved my problem.
...
I hope this share can help others.
thank you very much for having taken the time to summarize your findings for all of us! :-)
Cheers Norman
-
Jaemin Park -
Norman Feske -
Stefan Kalkowski