vm-arm: inline memory initializtion module #68

axel-h · 2023-03-10T11:45:12Z

Is there a reason why init_ram.c exists as a module. To me this seems overly complicated in the current implementation and I do not really understand the benefit for RAM, as it is essential and not optional.

hlyytine · 2023-03-10T12:08:14Z

+1 for removing the init_ram module. But can we make it a weak function, so that VMs could use custom code for overriding how the RAM is mapped?

If you happen to remember our presentation at seL4 summit 2022, we are experimenting with providing virtio backends by Linux application (QEMU, crosvm, you name it) running in another VM. Our first prototype was sharing guest memory to this another VM and in order to do that, we used weak attribute of init_ram_module() and provided our own version, which mapped guest physical addresses to dataport frames.

Now I know sharing the whole guest memory is inacceptable in seL4 world and principle of least authority and we are working to share only needed pages with SMMU (work in progress) or with software bounce buffers like Linux SWIOTLB (which we have already working). But we would like to maintain this insecure "share all" version as well, to be able to benchmark how much SMMU/SWIOTLB brings overhead.

I guess mapping RAM from dataport frames is not desirable / wanted to be merged into CAmkES-VM as such, but please provide facilities to be able to override RAM initialization. Weak symbol is the easiest.

axel-h · 2023-03-10T12:18:50Z

I have seen that we were experimenting with this in you fork. What I can do is wrap this in a internal helper function that is weak. What we could als do it on call vm_ram_register_at() if ram_size is not zero, ie. if there is any exclusive VM RAM. In your case there would be another class of RAM then that can be added via the module hooks, which is just configures in the CMake file then. So there is no need for any weak functions.

axel-h · 2023-03-10T12:27:08Z

@hlyytine What do you think about this implementation?

chrisguikema

The changes look good to me.

Is your logic for removing the init_ram module just that its a small function? In my mind, modules should be for optional things. So things like device tree generation, virtio devices, etc. Basically you want to end up with as small of a VMM as possible, right? Since RAM initialization isn't optional (you need it to load in the guest images), I'm okay with removing it as a module.

chrisguikema · 2023-03-10T17:22:00Z

components/VM_Arm/src/main.c

+     * of guest memory, e.g. memory shared with other VM and memory that is
+     * mapped on demand.
+     */
+    if (ram_size > 0) {


if ram_size is 0 or less than zero, we have a problem. I'd change this to:

ZF_LOGF_IF(0 > ram_size, "ram_size must be a positive value, as running a guest without RAM is impossible"); err = vm_ram_register_at(&vm, ram_base, ram_size, vm.mem.map_one_to_one); assert(!err);

ram_size is an unsigned long, so this can never be less than zero. With #63 it will become size_t, which also can't ever get negative. We have zero to disable it now. Allowing negative values here has no use case and it seem to just create more trouble.

Fair point about the negative, but this would still mean a value of 0 is possible, when it would cause a host of issues.

The changes look good to me.

Is your logic for removing the init_ram module just that its a small function? In my mind, modules should be for optional things. So things like device tree generation, virtio devices, etc. Basically you want to end up with as small of a VMM as possible, right? Since RAM initialization isn't optional (you need it to load in the guest images), I'm okay with removing it as a module.

The first part I agree. For example, we have need to customize FDT. I was thinking perhaps we could have DEFINE_MODULE_EXT which allows us to specify hooks, for example, during the device tree generation phase. The second that comes to my mind that the fault handler should be extensible with modules. Of course using the MMIO mapping functions is an option, but not sure if we need hooks for unhandled_mem_fault_callback() (that's how we have been doing it, but not sure if it's 100% necessary).

I was going to say to I disagree with the second part, but but... @axel-h how come could we run our "map guest RAM from dataport" before image loading is done? Perhaps hook or weak function is needed after all?

Still some thoughts about modules... I think in more complex systems they will have dependencies so that hooks from module B must be ran before ones from module A. This extended version of DEFINE_MODULE macro should handle those as well. Perhaps it needs a little more thinking and solving this with weak function is best for short term solution.

Giving 0 has always been possible and I don't really know the use case that my change might break. The observable difference now is:

the APIs are not called at all. But they are not supposed to do anything observable in this case.

the memory node is not created at all in the DTB. I consider this more sane than creating a node with a zero size. But in the end I'm collecting input here and would add this in a comment then why we need such a node in any case.

It seems @hlyytine had a usecase where 0 was used, because memory came from other places any maybe the images also. I don't think the VMM should try to be extra smart to catch insane configuration. It just have a sane error handling, so things will fail gracefully eventually. But I'm open for suggestion and interested in all special use cases out there.

I was going to say to I disagree with the second part, but but... @axel-h how come could we run our "map guest RAM
from dataport" before image loading is done? Perhaps hook or weak function is needed after all?

@hlyytine Not sure I get the question. Modules are initialized before images are loaded, so they can provide memory that the modules are put into then. This will not change with this PR. It's just that this RAM init now runs before any module runs. So I don't think a weak hook needs to be provided.

I was going to say to I disagree with the second part, but but... @axel-h how come could we run our "map guest RAM
from dataport" before image loading is done? Perhaps hook or weak function is needed after all?

@hlyytine Not sure I get the question. Modules are initialized before images are loaded, so they can provide memory that the modules are put into then. This will not change with this PR. It's just that this RAM init now runs before any module runs. So I don't think a weak hook needs to be provided.

OK, that seems to be case. No need for weak function for that reason and I'm fine with that (provided that you give us a way to generate memory node to DTB). But how about backwards compatibility? That init_ram_module() function has been declared weak since ARM VMM got merged into camkes-vm repo and I wouldn't be surprised if somebody somewhere has overridden it. Shall we summon @kent-mcleod to give his opinion?

the memory node is not created at all in the DTB. I consider this more sane than creating a node with a zero size. But in the end I'm collecting input here and would add this in a comment then why we need such a node in any case.

In our use case (map guest RAM from dataport) we need memory node in DTB. We are using autogenerated DTB, so just statically providing it is not enough for us.

In our use case (map guest RAM from dataport) we need memory node in DTB. We are using autogenerated DTB, so just statically providing it is not enough for us.

@hlyytine With the changes in this PR, no "ordinary" memory node is created. Your module would have to create one for the memory it adds. However, this seem impossible in the current code, but I have another PR coming that that allows functions and modules to manipulate the generated DTB according to their "contributions" to the VM. Seems this is exactly what you need then.

hlyytine · 2023-03-10T19:13:25Z

@hlyytine What do you think about this implementation?

Looks good to me now.

axel-h · 2023-03-10T21:55:21Z

@hlyytine I've added a commit that makes the DTB generation more dynamic, so modules can also add data to it. Would this allow you to implement youe use case, if you generate a memory node when ram_size is 0?

hlyytine · 2023-03-11T07:52:15Z

@hlyytine I've added a commit that makes the DTB generation more dynamic, so modules can also add data to it. Would this allow you to implement youe use case, if you generate a memory node when ram_size is 0?

Sorry, too many changes for me to understand. Can you look at #70 and tell me what you think.

Also I'm not sure if we should do those if (generate_dtb) things, perhaps we can also load DTB first (provide_dtb=1) and then customize it (generate_dtb=1), that way there would be no need for dtb_base_name. Also let DTB loading fail gracefully if generate_dtb=1, in that case rely on completely autogenerated DTB. I guess the latter originated from Dornerworks, so what do you @chrisguikema think, can we imagine simplifying DTB loading code flow like this?

axel-h · 2023-03-11T19:09:41Z

I will move the other commits in this PR to a separate one (see #73). Creating the DTB unconditionally is an option, but I think it's not so nice as it does unnecessary work any may cause other issues.

hlyytine · 2023-03-14T09:13:39Z

I got a bit hesitant about using ram_size == 0 notion to disable init_ram module functionality. I think that even we, those familiar with the code, should not rely on our memory. I mean, after successful summer vacation and empty mind, it should be enough to deduce that ram_size variable contains the amount of guest RAM. We should not need to remember that ram_size == 0 means that it does not mean guest does not have any RAM, but rather it is defined somewhere else. Someone might think the guest is emulating XIP ROM and we don't want to steepen seL4 world learning curve, do we?

The second problem is using ram_size == 0 forces alternative means to introduce yet another configuration variable into CAmkES file. For example in our use case, ram_size is the authoritative figure and we just use a CAmkES dataport that is able to provide enough frames to satisfy stage-2 mapping code. It's also kind of self documenting when we set explicitly both ram_size and dataport's size to VMx_RAM_SIZE.

The third problem, or actually an extension of the second, is that seems that you want to get rid of global variables. Good. I think the reason why we want that is to have pure functions. In other words, to get rid of side effects. Now, enabling or disabling some unknown code based on whether ram_size is zero or not does not seem particularly good idea to me. The least we should do is to print a warning message "RAM size is defined as zero, expect some undefined behaviour.

The fourth problem, we have some code (inside seL4 userland libraries) that uses ram_size variable. I guess it is not unreasonable to expect somebody else does the same thing somewhere. Now, are we expected to create a new variable for our differently mapped RAM size and patch all the libraries accordingly? Or shall we assign ram_size ourselves in our "use CAmkES dataport as RAM" code? If yes to latter, how to communicate this needed fix to all those to might have custom RAM mapping code?

Hence I have a proposition, and this time I will try to explain my thoughts in English instead of PR, but let me address another concern first.

I see you didn't particularly like having multiple module API functions (init() and fdt_generate() in #70) and I think you have a point there. I'm fine if we stick with having only init_module() entry point, at least for now. But what bothers me is the void return type. The only way to react to errors is assert() and you cannot propagate the error up the stack to the caller.

Leave it as is.
Leave it as is and return to this problem later.
Introduce an alternative init() function with int return type and use it if defined, otherwise use the old-style init_module() function (in the VMM module loading code). In that case, print warnings also.
Add enum module_state { UNINITIALIZED=0, INITIALIZING=1, FAILED=2, INITIALIZED_IF_RETURNS=3, INITIALIZED=3 } and add the status field to each struct vmm_module. Now before actually calling init_module(), module loading code sets state to INITIALIZED_IF_RETURNS. With this we kind of prepare for future when we have proper int-returning initializer.
Combine 3 and 4.

My personal preference at the moment is 2, followed by 5.

Now back to original problem. The first question is how to allow custom RAM mapping code. I propose that we add a VM attribute modules to CAmkES file, defaulting to all to retain backwards compatibility. The whitespace separated strings could be prefixed with - (remove), otherwise implicit + (add) is assumed. Hence -all and empty string are equal, no modules loaded (just a theoretical example). More practical example in our use case could be -init_ram, our custom module would be included in that "all but init_ram" set. If you need to make sure your VMM has only init_ram module, use "-all init_ram". But like I mentioned, if you don't want to be bothered with this, just ignore this, the default all makes everything work like earlier.

Optionally, we can add Jinja2 code that checks the modules VM attribute and in case some module is explicitly requested in that string but disabled at CMake level, we can issue a warning or halt the build.

Some reasoning about guest RAM: some embedded operating systems don't need DTB and hence we have CAmkES attributes generate_dtb and provide_dtb. But at hand-written C code level, adding RAM to guest and generating DTB for guest are completely (almost) orthogonal things. The only corner case is that guest does not have any RAM, but even in deeply embedded system with XIP program code in ROM, there is small SRAM for working set. Hence we can drop the almost and say they are completely orthogonal things. So if we are generating DTB, we need to create that memory node also in all cases, regardless whether the RAM is mapped to guest using this code or some custom code. Hence it is reasonable to defend the POV that ram_base and ram_size global variables could and should exist after some certain of execution flow (installing VMM modules in this case).

Just a teaser: Therefore, moving DTB generation to module is the most logical conclusion. With Jinja2, we can translate "generate_dtb" : false to -generate_dtb to be appended to modules. Think about seL4 microkernel. It does the bare minimum only, the rest is done in userspace threads. Why should the VMMs on top of it be of any different design? Shouldn't it just do the bare minimum and delegate the rest to modules (analogy to userspace threads?)

Lastly, how and when shall we set ram_base and ram_size. We know that after loading VMM modules they are guaranteed to have sane values and for the remainder of the code, we can take it granted. But where do these values originate? I would imagine that ultimately they are a couple of #define VMx_RAM_{BASE,SIZE} just like before but since guest RAM seems to be a required component of a CAmkES VMM, should this configuration be handled through CAmkES interface some day. Then you hook your VM with a CAmkES component that does the same thing as init_ram does today, or we at SSRC could hook the VM to a RAM-providing component that is really an extended version of seL4SharedCapsWithData. Then my opinions about this:

Overengineered? Perhaps. But why do we one rather well thought of component system and then additional something more or less hackish one.
Shall we start implementing this now? No.
Shall we start coding this in near future? I don't see immediate need.

My opinion concluded: This PR should put on hold, since IMO it really does not improve anything. I suggest that we discuss whether that modules VM attribute approach is more suitable.

Action point: Start discussion on VMM seL4 discourse.

Still one more thought: we really should not compile in code that is not used. Hence perhaps this is best handled at build time at CMake level. This way we could have init_ram for one VM and our customized one for another VM. Also we can use linker, C preprocessor and Jinja2 to deduce at build time that we have all required modules and we don't have clashing modules. Example of this would be #define MODULE_PROVIDES(__x) const int VMM_MODULE_PROVIDES_ ##__x = 0 and then having MODULE_PROVIDES(ram) in both modules. Trying to enable them at the same time will not even link.

Then add #define MODULE_REQUIRES(__x) { extern const int VMM_MODULE_PROVIDES_ ##__x; volatile int __require = VMM_MODULE_PROVIDES_##__x; } and add MODULE_REQUIRES(ram) to make sure some guest RAM providing module is loaded.

hlyytine · 2023-03-15T10:19:19Z

I got even simpler idea: seems that we all agree RAM is needed from VM in any case, which means linker must be able to resolve ram_base and ram_size. Wouldn't it be the most logical place for these global variables to be where the RAM mapping is done, in this case modules/init_ram.c? Or in our SSRC case, in our alternative module. That way you would be forced to provide exactly one implementation of RAM mapping code per VM. Provide none, and linker fails due to missing symbol. Provide more than one, and linker fails due to multiple definitions of symbols.

This change would need moving ram_base and ram_size (and backwards compatibility linux_ram_{base,size}) from templates/seL4VMParameters.template.h to a private header templates/seL4GuestVMRAMConfiguration.h, which is included by RAM mapping modules only.

We would still need a mechanism to turn off init_ram module and add ours, but other than that, no other changes needed at all.

Edit 13:00 Finnish time: I forgot there are no private headers in CAmkES templates. Hence we must guard the contents of templates/seL4VMGuestRAMConfiguration.h with #ifdef that is defined only in init_ram.c (or similar code).

kent-mcleod · 2023-03-16T00:51:15Z

I guess mapping RAM from dataport frames is not desirable / wanted to be merged into CAmkES-VM as such, but please provide facilities to be able to override RAM initialization. Weak symbol is the easiest.

I think this was actually why the init_ram module was made. This example uses a ram dataport to introspect a guest VMs ram device: https://github.com/seL4/camkes-vm-examples/blob/master/apps/Arm/vm_introspect/src/init_dataport_ram.c#L39-L45

kent-mcleod · 2023-03-16T01:04:10Z

Still one more thought: we really should not compile in code that is not used. Hence perhaps this is best handled at build time at CMake level.

I recall that this simple module system was added to allow general code to be configured in CMake to be compiled in/out based on build time configuration and to also support camkes connectors that use templates that define modules and can thus be initialized at start of component runtime.

I also am not sure about the motivation of this PR is as the module was added for the vm_introspect example to perform its own ram installation.

axel-h · 2023-03-17T10:35:07Z

Thanks. I get the point why this should be a weak function. But I still seems a bit odd to me that this is in a module. It would be a bit more intuitive if the weak function is in main.c then with a comment explaining that this is a explicit customization point for modules.

components/VM_Arm/src/main.c

hlyytine · 2023-03-18T07:35:13Z

components/VM_Arm/src/main.c

+ */
+WEAK int init_ram_module(vm_t *vm)
+{
+    if (0 == ram_size) {


While I understand the motivation writing comparison in this way, I think it's best to follow the style of existing code. Understanding code is often challenging enough even without mixed style.

components/VM_Arm/src/main.c

hlyytine · 2023-03-18T07:44:54Z

components/VM_Arm/src/main.c

+                                 vm->mem.map_one_to_one);
+    if (err) {
+        ZF_LOGE("RAM registration failed (%d)", err);
+        return -1;


How about returning err instead of plain -1 where possible?

I'm not sure if we have global error codes that each caller can make sense on. So that is why I think it is better if each specific function prints the error and then returns a generic error to the caller, as the caller may not make much sende of the specific error code. But in non-debug builds the error code would get lost then, so you have a point there, that we should change this in the whole file to ensure error codes bubble up and there is a change to have them in non-debug builds also at the top level.

hlyytine · 2023-03-18T07:45:44Z

components/VM_Arm/src/main.c

@@ -633,7 +656,17 @@ int install_vm_devices(vm_t *vm)
    /* Install virtual devices */
    if (config_set(CONFIG_VM_PCI_SUPPORT)) {
        err = vm_install_vpci(vm, io_ports, pci);
-        assert(!err);
+        if (err) {


I guess this was included accidentally; anyhow, this is not part of inlining init_ram_module().

components/VM_Arm/src/main.c

hlyytine · 2023-03-18T07:55:36Z

components/VM_Arm/src/main.c

+    }
+
+    /* Install and initialize guest RAM. */
+    err = init_ram_module(vm);


As explained above, cookie parameter is missing. I think it is enough to pass NULL here.

Also you can't really check the return value here since overloaded versions do not return any.

hlyytine · 2023-03-18T08:04:11Z

I think this was actually why the init_ram module was made. This example uses a ram dataport to introspect a guest VMs ram device: https://github.com/seL4/camkes-vm-examples/blob/master/apps/Arm/vm_introspect/src/init_dataport_ram.c#L39-L45

Thanks for reminding. Funny enough, that's where I started learning how to share memory between VMs but seems that I forgot it completely. On a more serious note, since there are at least two uses now (vm-introspect and our virtio stuff) one potential idea is to consolidate "RAM as dataport" to a VMM module, but before that, two things need to be solved: a) per-VM configuration and b) how to tell it which dataport to use.

hlyytine · 2023-03-18T08:08:03Z

I also am not sure about the motivation of this PR is as the module was added for the vm_introspect example to perform its own ram installation.

The trouble seems to be the module here is unnecessary. Weak attribute is the one doing the job. The other alternative is to make init_ram a per-VM configurable item, then weak function would not be needed but it would be a API breaking change. Perhaps API is too strong a word, though. If it's not documented, it's not an API, is it?

Personally I would prefer per-VM modules and init_ram reworked somehow along the lines I have presented somewhere in the comments above. But the other altenative is to remove the confusing element, the module, as this PR suggests.

hlyytine · 2023-03-18T08:13:59Z

@axel-h IMO inlining this would be good, as the weak function kind of negates the purpose of the module system. But how about if you just copied & pasted that function without making any non-whitespace changes. Because it is in the same repo, git diff with coloring turned on would show it clearly just as moved code. Then the commit message would explain why the module system does not bring any additional benefits here. If you really insist doing other changes, they could be an another PR / commit.

hlyytine · 2023-04-05T08:20:40Z

components/VM_Arm/src/main.c

+{
+    if (0 == ram_size) {
+        ZF_LOGW("VM%d: no RAM defined", vm->vm_id);
+        return 0;


Another option is to put this check to templates/seL4VMParameters.template.c? Putting it in this function and having the option to overload the function would lead someone to think that non-zero RAM size is important only if the RAM is mapped in this way. But we already agree no matter how and where the RAM is mapped from, it needs to be non-zero in size?

And I have to nag about style issue once again. Could you use vm_config->ram.size == 0 or !vm_config->ram.size instead of this, albeit technically superior but not traditional way to write the comparison? If you want the project to use this style, could you start a discussion on seL4 discourse for example and see whether there's support for this in the community? Up until then I think we should not deviate from the existing style.

components/VM_Arm/src/main.c

hlyytine · 2023-04-05T08:26:47Z

components/VM_Arm/src/main.c

+ * custom initialization, e.g. to use memory shared with other components or
+ * mapped on demand.
+ */
+WEAK int vm_init_ram(vm_t *vm, const vm_config_t *vm_config)


I see you renamed init_ram_module() to vm_init_ram(). This means at least vm_introspect example in https://github.com/seL4/camkes-vm-examples gets broken (it is broken currently for other reasons, but that's another story). Perhaps some code we don't know of.

Personally I'm not against breaking the ABI but others might be.

The different name is intentional, it's based on you last comment that changing the signature of an existing function is not a good idea. It this PR gets merged, I will create an issue for vm_introspect so this gets adapted.

[vm_introspect] is broken currently for other reasons, but that's another story). Perhaps some code we don't know of.

I think seL4/camkes-vm-examples#39 will fix the brokenness you are referring to.

Good spotting but not exactly: at some point CAmkES started using as large as possible frames for dataports. Hence if you had more than 2 MB dataport, it uses ARM large pages. On the other hand, currently VMM always uses 4 kB pages in vm_ram_touch(). To be able to use 2 MB pages from dataport as guest RAM, we use this kind of hack in tiiuae/seL4_projects_libs@fa99679.

Forgot to add that you need to use large pages here as well: https://github.com/seL4/camkes-vm-examples/blob/master/apps/Arm/vm_introspect/src/init_dataport_ram.c

@hlyytine: Could you create an issue in https://github.com/seL4/camkes-vm-examples to track this?

hlyytine · 2023-04-05T08:30:49Z

To be honest, I think this PR creates more problems than it solves.

I know I repeat myself, but I really believe VMM design should be as minimal as it could be and consolidating the module functionality into main.c actually does the opposite.

axel-h · 2023-04-10T20:22:16Z

To be honest, I think this PR creates more problems than it solves.

I think this is similar to vPCI, there I also failed for make it purely module because a certain awareness seems a core part of the VMM. As long as we don't have more flexible module API and a proper dependency handling, avoiding hacky modules appears a better was forward for a cleaner VMM.

- inline code from the module to simplify VMM. - define a weak function vm_init_ram() instead. - improve comments. Signed-off-by: Axel Heider <[email protected]>

axel-h force-pushed the patch-axel-18 branch from 3f866b9 to 8e6df6f Compare March 10, 2023 12:26

axel-h requested a review from chrisguikema March 10, 2023 12:29

axel-h changed the title ~~Patch axel 18~~ vm-arm: inline memory initializtion module Mar 10, 2023

axel-h force-pushed the patch-axel-18 branch from 8e6df6f to c1fd41c Compare March 10, 2023 12:56

chrisguikema reviewed Mar 10, 2023

View reviewed changes

axel-h force-pushed the patch-axel-18 branch 3 times, most recently from 90cd0d1 to 935e312 Compare March 10, 2023 21:27

axel-h force-pushed the patch-axel-18 branch 2 times, most recently from 3d551e8 to 29f1e5c Compare March 10, 2023 21:58

hlyytine mentioned this pull request Mar 11, 2023

Upstream/module hooks #70

Closed

axel-h force-pushed the patch-axel-18 branch from 29f1e5c to 2fff77d Compare March 13, 2023 11:50

axel-h mentioned this pull request Mar 14, 2023

Groups config variables in struct to emulate a namespace #62

Merged

axel-h force-pushed the patch-axel-18 branch 3 times, most recently from 74aa768 to daf56ae Compare March 17, 2023 12:28

hlyytine suggested changes Mar 18, 2023

View reviewed changes

axel-h force-pushed the patch-axel-18 branch 3 times, most recently from 84e7fab to 7990bee Compare March 20, 2023 22:20

axel-h force-pushed the patch-axel-18 branch 4 times, most recently from 8c81335 to 61f4dc8 Compare March 31, 2023 14:57

hlyytine suggested changes Apr 5, 2023

View reviewed changes

axel-h force-pushed the patch-axel-18 branch from 61f4dc8 to 00ef35e Compare April 10, 2023 17:27

axel-h force-pushed the patch-axel-18 branch from 00ef35e to f7d812d Compare April 10, 2023 21:15

axel-h force-pushed the patch-axel-18 branch 3 times, most recently from b70dafc to da09585 Compare April 20, 2023 11:33

axel-h force-pushed the patch-axel-18 branch 2 times, most recently from 8d610df to ef3800a Compare May 8, 2023 12:15

axel-h force-pushed the patch-axel-18 branch 2 times, most recently from adf2e5a to 63fc28e Compare May 25, 2023 11:50

axel-h force-pushed the patch-axel-18 branch from 63fc28e to 607e8af Compare June 2, 2023 09:21

axel-h force-pushed the patch-axel-18 branch from 607e8af to 3c51dbc Compare June 15, 2023 17:29

axel-h force-pushed the patch-axel-18 branch 2 times, most recently from c629f4b to 65971eb Compare January 24, 2024 10:27

axel-h force-pushed the patch-axel-18 branch from 65971eb to fa7d7a6 Compare January 28, 2024 21:48

axel-h mentioned this pull request Jan 29, 2024

[patch-axel-5] vm_introspect: use new API axel-h/camkes-vm-examples#8

Draft

vm_arm: inline init_ram module

1afd5ff

- inline code from the module to simplify VMM. - define a weak function vm_init_ram() instead. - improve comments. Signed-off-by: Axel Heider <[email protected]>

axel-h force-pushed the patch-axel-18 branch from fa7d7a6 to 1afd5ff Compare January 31, 2024 12:57

vm-arm: inline memory initializtion module #68

Are you sure you want to change the base?

vm-arm: inline memory initializtion module #68

Conversation

axel-h commented Mar 10, 2023 • edited Loading

hlyytine commented Mar 10, 2023 • edited Loading

axel-h commented Mar 10, 2023

axel-h commented Mar 10, 2023 • edited Loading

chrisguikema left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hlyytine commented Mar 10, 2023

axel-h commented Mar 10, 2023

hlyytine commented Mar 11, 2023 • edited Loading

axel-h commented Mar 11, 2023 • edited Loading

hlyytine commented Mar 14, 2023 • edited Loading

hlyytine commented Mar 15, 2023 • edited Loading

kent-mcleod commented Mar 16, 2023

kent-mcleod commented Mar 16, 2023

axel-h commented Mar 17, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hlyytine commented Mar 18, 2023

hlyytine commented Mar 18, 2023 • edited Loading

hlyytine commented Mar 18, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hlyytine Apr 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hlyytine commented Apr 5, 2023

axel-h commented Apr 10, 2023

axel-h commented Mar 10, 2023 •

edited

Loading

hlyytine commented Mar 10, 2023 •

edited

Loading

axel-h commented Mar 10, 2023 •

edited

Loading

hlyytine commented Mar 11, 2023 •

edited

Loading

axel-h commented Mar 11, 2023 •

edited

Loading

hlyytine commented Mar 14, 2023 •

edited

Loading

hlyytine commented Mar 15, 2023 •

edited

Loading

hlyytine commented Mar 18, 2023 •

edited

Loading

hlyytine commented Mar 18, 2023 •

edited

Loading

hlyytine Apr 13, 2023 •

edited

Loading