Ok, I'm going to answer myself, as I saw there's a kernel module
(connection.c) that does exactly what I'm looking for... I though this was
(only) for inter VM communications but looks like it is used as connector
to camkes components, so I guess I can try to use a Linux PCI device driver
to directly communicate to camkes component, i.e., a UDP server without
having to use Linux TCP/IP stack. I'm really newbie to all this (never ever
had requirement to develop anything) so will be a fun and challenging task
to me, moreover as we deal with a different OS (seL4). Sorry for the
inconvenience of the question.

El jue, 24 jun 2021 a las 17:54, Hugo V.C. (<[email protected]>)
escribió:

> Hi Damon,
>
> reviewing the links you provided I can see that the proposed solutions
> assume/require the guest OS to have a networking support. My Linux guest do
> not have such networking support (I completely removed at compile time). So
> my idea is more something like this:
>
> +--------------------------+ +-----------------------+
> |                          | |                       |
> |                          | |                       |
> |                          | |                       |
> |                          | |         LINUX         |
> |                          | |                       |
> |        UDP SERVER        | |                      <------+
> |                          | |                       |     |
> |                          | +-----------------------+     | VIRTIO PCI ??
> |                          | +-----------------------+     |
> |                          | |                     <-------+
> |                          | |          VMM          |
> |           ^              | |                     <-------+
> +-----------|--------------+ +-----------------------+     |
> +-----------|----------------------------------------+     | VIRTQUEUES
> |           |                                        |     |
> |           +---------------+------------------------------+
> |                      SEL4 - CAMKES                 |
> |                                                    |
> +----------------------------------------------------+
>
> Has anyone tried something similar?
>
> Thank you,
> Hugo
>
>
> El lun, 21 jun 2021 a las 8:13, Lee, Damon (Data61, Eveleigh) (<
> [email protected]>) escribió:
>
>> Hi Hugo,
>>
>> > I wonder how to have seL4 host not passing network frames to Linux VM
>> > guest. I mean, I would like to have seL4 dealing with TCP/IP and
>> processing
>> > packets at the host level but then I want to use a custom communication
>> > channel with the Linux guest. So, the very first step would be to stop
>> > forwarding network frames to the guest. Any hint where I can start
>> > experimenting with this?
>>
>> You could perhaps use the VirtIO networking driver to expose a virtual
>> network
>> card over to the VM and then have that virtual card be backed by the
>> actual
>> Ethernet device on the board. You could then insert a firewall/packet
>> processing
>> layer in between the Ethernet device and the VirtIO networking driver to
>> process
>> packets before they're delivered to the VirtIO networking driver and into
>> the
>> virtual machine. So it'd look like this:
>>
>> Ethernet device -> Packet processing layer -> VirtIO networking driver ->
>> VM
>>
>> There's an example of the VirtIO networking drivers in use in [1] and a
>> Firewall
>> CAmkES component in [2]. [3] shows the Firewall in use.
>>
>> Hope this helps,
>> Damon
>>
>> [1]
>>
>> https://github.com/nomadeel/camkes-vm-examples/tree/master/apps/Arm/vm_virtio_net
>> [2] https://github.com/seL4/camkes-vm/tree/master/components/Firewall
>> [3]
>>
>> https://github.com/nomadeel/camkes-vm-examples/blob/master/apps/x86/cma34cr_centos/cma34cr_centos.camkes
>>
>> _______________________________________________
>> Devel mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>>
>
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to