Hi,

I am currently performing research for my master thesis which involves seL4 and 
ideally retrofitting a SDN controller application for it.
As a part of retrofitting applications for seL4 the suggested way is the 
incremental cyber retrofit approach wich involves dividing subsystems of the 
application onto several VMs that each runs in a VMM.

Therefore I was wondering if it is currently possible to run several VMs on the 
ARM architecture that has different component configurations in CAmkES?
(ARM is mostly preferable for the simple simulation in QEMU when building for 
qemu-arm-virt, so switching architecture is an option if this is not achievable)

I noted that the macros for VMs on x86 and ARM were different when defining 
components:

x86:
/* VM and per VM componenents */
#define VM_PER_VM_COMPONENTS(num) \
    component Init##num vm##num; \
    /**/

ARM:
#define VM_COMPONENT_DEF(num) \
    component VM vm##num; \

And to clarify using the vm-examples where in the optiplex9020.camkes there are 
two VMs that are configured differently:

component Init0 {
    dataport Buf(STRING_REVERSE_BUFSIZE) dp1;
    dataport Buf(STRING_REVERSE_BUFSIZE) dp2;

    emits Ready ready;
    consumes Done done;

    has mutex cross_vm_event_mutex;

    VM_INIT_DEF()
}

component Init1 {
    VM_INIT_DEF()
}

But in the ARM vm_multi.camkes there is only one VM component that is used for 
all three VMs:

component VM {
    VM_INIT_DEF()
    maybe uses VirtQueueDev recv1;
    maybe uses VirtQueueDrv send1;
    maybe uses VirtQueueDev recv2;
    maybe uses VirtQueueDrv send2;
    attribute vswitch_mapping vswitch_layout[] = [];
    attribute string vswitch_mac_address = "";
}

So it is at least it is not as simple as defining Init##num components for ARM 
since currently only one VM component is allowed in the macros.

Do you have a recommended way that could achieve a CAmkES structure that allows 
for multiple differently configured VMs for ARM without altering the macros?
If it is not possible at the time I assume that switching to x86 is the easiest 
alternative to achive this?

Best regards,
Olof
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to