Re: Regarding building NOVA kernel

[Stefan Kalkowski]

Hello,

On Mon, Feb 05, 2018 at 12:15:04PM +0530, ROHIT JAISWAL cs16m053 wrote:
> Hi,
>  I have tried to build NOVA kernel but I am getting error.
> 
> spawn qemu-system-x86_64 -no-kvm -display sdl -cpu core2duo -serial
> mon:stdio -m 512 -cdrom var/run/demo.iso -cdrom var/run/demo.iso -cdrom
> var/run/demo.iso
> qemu-system-x86_64: -display sdl: SDL support is disabled
> Aborting, received EOF
> Log step failed, retry.
> Boot process failed 3 times in series. I give up!
> make: *** [run/demo] Error 255
> 
> I have tried to comment -display sdl in build.conf but i didn't get any
> output.
> Please provide solution.

This is not an issue of the Genode build system or the NOVA kernel,
which got already built successful. It is an issue of your Linux
environment and Qemu instance.

The problem is clearly reported by your qemu-system-x86_64 binary:
"SDL support is disabled", which means your qemu binary was
compiled without libSDL support. Therefore, it is senseless to state
"-display sdl" on the command-line.

The solution is to install an appropriated qemu variant, e.g., using a
pre-compiled Qemu of your Linux distribution, or configure and compile Qemu
yourself with the libSDL headers and libraries in place.

Regards
Stefan

> 
> 
> -- 
> 
> Regards,
> Rohit Jaiswal

> --
> 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

Regarding building NOVA kernel

[ROHIT JAISWAL cs16m053]

Hi,
 I have tried to build NOVA kernel but I am getting error.

spawn qemu-system-x86_64 -no-kvm -display sdl -cpu core2duo -serial
mon:stdio -m 512 -cdrom var/run/demo.iso -cdrom var/run/demo.iso -cdrom
var/run/demo.iso
qemu-system-x86_64: -display sdl: SDL support is disabled
Aborting, received EOF
Log step failed, retry.
Boot process failed 3 times in series. I give up!
make: *** [run/demo] Error 255

I have tried to comment -display sdl in build.conf but i didn't get any
output.
Please provide solution.


-- 

Regards,
Rohit Jaiswal
--
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

Re: Share a variable of Core with other components

[Jaemin Park]

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();
 ...
}

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  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.kalkow...@genode-labs.com> 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
>> 

Re: Memory write tracing/logging of an application / Watchpoints in Genode/Fiasco.OC

[Josef Stark]

Hey Martin,

the next problem that I'm facing now is that I don't know how to access 
the instruction that caused the pagefault. I have the instruction 
pointer but not the instruction itself (opcode and operands).
Your vinit code [1] uses an imprint to identify the corresponding 
Rm_client and then find the correct region by the IP address:

Rm_client * const rm_client = Rm_client::by_id(state.imprint);
addr_t off, ip = client_state->ip;
Rm_session_component * const rm = rm_client->session();
Region * const region = rm->_find_region((void *)ip, );
Dataspace_capability ds_cap = region->ds_cap();
void * local = env()->rm_session()->attach(ds_cap, 0, region->offset());
unsigned instr = *(unsigned *)((addr_t)local + off);
However, I'm again wondering if there's an easier way to find the 
dataspace considering that my checkpointer only has this one child (and 
I also know the binary name), and for the thread state it was already 
possible after you explained it to me.
Where do I look? I tried looking through the RAM dataspaces, but so far, 
trial and error didn't yield any success. Probably because I'm doing 
something wrong, and due to the architectural changes introduced between 
12.11 and 16.08 it's again hard for me to re-use vinit code, so maybe 
you can push me in the right direction again.


Another thing that I don't completely understand: The pagefault report 
includes the memory address where the pagefault occured. I can 
successfully find the corresponding data space. Experimenting a bit 
showed me that the reported address seems to be 8-Byte-aligned. (Because 
incrementing the accessed address in the test application byte by byte 
only results in an 8-byte jump of the reported address 'state.addr' 
every 8 bytes. Inside an 8-byte group it stays the same.)
But how can I find out which of the 8 byte(s) was actually accessed? 
Especially considering that single-byte access doesn't have to be 
aligned. I think that for your emulator this information was not 
necessary, so [2] doesn't provide it. But is it even contained in the 
instruction?



Best regards,
Josef

[1] os/src/vinit/include/rm_session/component.h: state()
[2] os/src/vinit/arm_v7a/instruction.h: load_store()

--
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