Add a generic function for TCP option parsing. So far we're
interested only in MSS option value, so that's what it handles.
Use it to parse MSS value in net_context incoming SYN packet
handler.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Calculates full TCP header length (with options). Macro introduced
for reuse, to avoid "magic formula". (E.g., it would be needed to
parse TCP options).
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
MSS is Maximum Segment Size (data payload) of TCP. In SYN packets,
each side of the connection shares an MSS it wants to use (receive)
via the corresponding TCP option. If the option is not available,
the RFC mandates use of the value 536.
This patch handles storage of the send MSS (in the TCP structure,
in TCP backlog), with follow up patch handling actual parsing it
from the SYN TCP options.
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
For the dummy thread, contents in the mem_domain structure
is insignificant hence setting it to NULL.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Added arch specific calls to handle memory domain destroy
and removal of partition.
GH-3852
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
During swap the required page tables are configured. The outgoing
thread's memory domain pages are reset and the incoming thread's
memory domain is loaded. The pages are configured if userspace
is enabled and if memory domain has been initialized before
calling swap.
GH-3852
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Added architecture specific support for memory domain destroy
and remove partition for arm and nxp. An optimized version of
remove partition was also added.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Additional arch specific interfaces to handle memory domain
destroy and single partition removal.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
Add support for selecting Endpoint numbers and move it under USB
Device Networking menu.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Boot serial recovery feature consume additional
memory size so the mcuboot partition must been
expanded on cost of images partitions.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
Boot serial recovery feature consume additional
memory size so the mcuboot partition must been
expanded on cost of images partitions.
Signed-off-by: Andrzej Puzdrowski <andrzej.puzdrowski@nordicsemi.no>
This is intended for memory-constrained systems and will save
4K per thread, since we will no longer reserve room for or
activate a kernel stack guard page.
If CONFIG_USERSPACE is enabled, stack overflows will still be
caught in some situations:
1) User mode threads overflowing stack, since it crashes into the
kernel stack page
2) Supervisor mode threads overflowing stack, since the kernel
stack page is marked non-present for non-user threads
Stack overflows will not be caught:
1) When handling a system call
2) When the interrupt stack overflows
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Dumping out the entire page table contents is extremely spammy.
Don't do this unless --verbose is passed twice.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
There are some PTS tests, which expect the IUT to send some beacons
after provisioning, so enable the feature by default.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
If we are a Friend node with multiple LPNs, we need to iterate through
all available Friendship credentials to find the right keys.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh spec expects us to fall back to master credentials if
friendship ones are not available. Also remove an unnecessary branch
with the help of a new 'idx' variable.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The friend_cred and new_key information is common for all segments of
a segmented transaction, so it makes sense to store them as part of
struct seg_tx instead of each buffer's user data.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The friend_cred hint needs to be set already at the point of
segmenting, i.e. doing it in bt_mesh_net_send() is too late. Move the
setting to bt_mesh_trans_send() and bt_mesh_ctl_send().
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
MESH/NODE/FRND/LPN/BI-02-C requires us to ignore unknown Transport
OpCodes instead of treating them as valid responses to a Friend Poll.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh Specification recommends retrying up to 6 times the Friend
Poll when establishing Friendship as LPN.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We should not have any valid key material in key slot 0 if the KR flag
is set, since then the new key/old key information will be incorrect
when network PDUs get decrypted.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
According to the Mesh Profile Specification: "The acknowledgment timer
shall be set to a minimum of 150 + 50 * TTL milliseconds".
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Mesh Profile Specification states that replay protection must be
done for all control and access messages. Furthermore, the replay
protection list must be updated with the sequence from the last
segment of a segmented message (the code was only updating based on
SeqZero).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that Friend support is complete we can create a full
implementation of the LPN PollTimeout Get message.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Besides the fact that we did not have that for the current supported
boards, that makes sense for this new, virtualized mode, that is meant
to be run on top of full-fledged x86 64 CPUs.
By having xAPIC mode access only, Jailhouse has to intercept those MMIO
reads and writes, in order to examine what they do and arbitrate if it's
safe or not (e.g. not all values are accepted to ICR register). This
means that we can't run away from having a VM-exit event for each and
every access to APIC memory region and this impacts the latency the
guest OS observes over bare metal a lot.
When in x2APIC mode, Jailhouse does not require VM-exits for MSR
accesses other that writes to the ICR register, so the latency the guest
observes is reduced to almost zero.
Here are some outputs of the the command line
$ sudo ./tools/jailhouse cell stats tiny-demo
on a Jailhouse's root cell console, for one of the Zephyr demos using
LOAPIC timers, left for a couple of seconds:
Statistics for tiny-demo cell (x2APIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 7 0
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, xAPIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_xapic 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_msr 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xsetbv 0 0
Statistics for tiny-demo cell (xAPIC root, x2APIC inmate)
COUNTER SUM PER SEC
vmexits_total 4087 40
vmexits_msr 4080 40
vmexits_management 3 0
vmexits_cr 2 0
vmexits_cpuid 1 0
vmexits_exception 0 0
vmexits_hypercall 0 0
vmexits_mmio 0 0
vmexits_pio 0 0
vmexits_xapic 0 0
vmexits_xsetbv 0 0
See that under x2APIC mode on both Jailhouse/root-cell and guest, the
interruptions from the hypervisor are minimal. That is not the case when
Jailhouse is on xAPIC mode, though. Note also that, as a plus, x2APIC
accesses on the guest will map to xAPIC MMIO on the hypervisor just
fine.
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
This is an introductory port for Zephyr to be run as a Jailhouse
hypervisor[1]'s "inmate cell", on x86 64-bit CPUs (running on 32-bit
mode). This was tested with their "tiny-demo" inmate demo cell
configuration, which takes one of the CPUs of the QEMU-VM root cell
config, along with some RAM and serial controller access (it will even
do nice things like reserving some L3 cache for it via Intel CAT) and
Zephyr samples:
- hello_world
- philosophers
- synchronization
The final binary receives an additional boot sequence preamble that
conforms to Jailhouse's expectations (starts at 0x0 in real mode). It
will put the processor in 32-bit protected mode and then proceed to
Zephyr's __start function.
Testing it is just a matter of:
$ mmake -C samples/<sample_dir> BOARD=x86_jailhouse JAILHOUSE_QEMU_IMG_FILE=<path_to_image.qcow2> run
$ sudo insmod <path to jailhouse.ko>
$ sudo jailhouse enable <path to configs/qemu-x86.cell>
$ sudo jailhouse cell create <path to configs/tiny-demo.cell>
$ sudo mount -t 9p -o trans/virtio host /mnt
$ sudo jailhouse cell load tiny-demo /mnt/zephyr.bin
$ sudo jailhouse cell start tiny-demo
$ sudo jailhouse cell destroy tiny-demo
$ sudo jailhouse disable
$ sudo rmmod jailhouse
For the hello_world demo case, one should then get QEMU's serial port
output similar to:
"""
Created cell "tiny-demo"
Page pool usage after cell creation: mem 275/1480, remap 65607/131072
Cell "tiny-demo" can be loaded
CPU 3 received SIPI, vector 100
Started cell "tiny-demo"
***** BOOTING ZEPHYR OS v1.9.0 - BUILD: Sep 12 2017 20:03:22 *****
Hello World! x86
"""
Note that the Jailhouse's root cell *has to be started in xAPIC
mode* (kernel command line argument 'nox2apic') in order for this to
work. x2APIC support and its reasoning will come on a separate commit.
As a reminder, the make run target introduced for x86_jailhouse board
involves a root cell image with Jailhouse in it, to be launched and then
partitioned (with >= 2 64-bit CPUs in it).
Inmate cell configs with no JAILHOUSE_CELL_PASSIVE_COMMREG flag
set (e.g. apic-demo one) would need extra code in Zephyr to deal with
cell shutdown command responses from the hypervisor.
You may want to fine tune CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC for your
specific CPU—there is no detection from Zephyr with regard to that.
Other config differences from pristine QEMU defaults worth of mention
are:
- there is no HPET when running as Jailhouse guest. We use the LOAPIC
timer, instead
- there is no PIC_DISABLE, because there is no 8259A PIC when running
as a Jailhouse guest
- XIP makes no sense also when running as Jailhouse guest, and both
PHYS_RAM_ADDR/PHYS_LOAD_ADD are set to zero, what tiny-demo cell
config is set to
This opens up new possibilities for Zephyr, so that usages beyond just
MCUs come to the table. I see special demand coming from
functional-safety related use cases on industry, automotive, etc.
[1] https://github.com/siemens/jailhouse
Reference to Jailhouse's booting preamble code:
Origin: Jailhouse
License: BSD 2-Clause
URL: https://github.com/siemens/jailhouse
commit: 607251b44397666a3cbbf859d784dccf20aba016
Purpose: Dual-licensing of inmate lib code
Maintained-by: Zephyr
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
The port will enable Zephyr to run as a guest OS on x86-64 systems. It
comes with a test on QEMU to validate that, thus this new board
introduction. It's "make run" target will issue QEMU with the same
configuration Jailhouse upstream uses for their confis/qemu-x86.c root
cell configuration:
Test configuration for QEMU Q35 VM, 1 GB RAM, 4 cores,
6 MB hypervisor, 60 MB inmates (-4K shared mem device)
This will work provided qemu-system-x86_64 is installed in the system
and a given (qcow2) image with the Jailhouse root cell in it is
provided (any of those will ever ship with Zephyr, it's out of its
scope).
Signed-off-by: Gustavo Lima Chaves <gustavo.lima.chaves@intel.com>
