-*-Mode: outline-*- Light-weight System Calls for IA-64 ----------------------------------- Started: 13-Jan-2003 Last update: 27-Sep-2003 David Mosberger-Tang Using the "epc" instruction effectively introduces a new mode of execution to the ia64 linux kernel. We call this mode the "fsys-mode". To recap, the normal states of execution are: - kernel mode: Both the register stack and the memory stack have been switched over to kernel memory. The user-level state is saved in a pt-regs structure at the top of the kernel memory stack. - user mode: Both the register stack and the kernel stack are in user memory. The user-level state is contained in the CPU registers. - bank 0 interruption-handling mode: This is the non-interruptible state which all interruption-handlers start execution in. The user-level state remains in the CPU registers and some kernel state may be stored in bank 0 of registers r16-r31. In contrast, fsys-mode has the following special properties: - execution is at privilege level 0 (most-privileged) - CPU registers may contain a mixture of user-level and kernel-level state (it is the responsibility of the kernel to ensure that no security-sensitive kernel-level state is leaked back to user-level) - execution is interruptible and preemptible (an fsys-mode handler can disable interrupts and avoid all other interruption-sources to avoid preemption) - neither the memory-stack nor the register-stack can be trusted while in fsys-mode (they point to the user-level stacks, which may be invalid, or completely bogus addresses) In summary, fsys-mode is much more similar to running in user-mode than it is to running in kernel-mode. Of course, given that the privilege level is at level 0, this means that fsys-mode requires some care (see below). * How to tell fsys-mode Linux operates in fsys-mode when (a) the privilege level is 0 (most privileged) and (b) the stacks have NOT been switched to kernel memory yet. For convenience, the header file provides three macros: user_mode(regs) user_stack(task,regs) fsys_mode(task,regs) The "regs" argument is a pointer to a pt_regs structure. The "task" argument is a pointer to the task structure to which the "regs" pointer belongs to. user_mode() returns TRUE if the CPU state pointed to by "regs" was executing in user mode (privilege level 3). user_stack() returns TRUE if the state pointed to by "regs" was executing on the user-level stack(s). Finally, fsys_mode() returns TRUE if the CPU state pointed to by "regs" was executing in fsys-mode. The fsys_mode() macro is equivalent to the expression: !user_mode(regs) && user_stack(task,regs) * How to write an fsyscall handler The file arch/ia64/kernel/fsys.S contains a table of fsyscall-handlers (fsyscall_table). This table contains one entry for each system call. By default, a system call is handled by fsys_fallback_syscall(). This routine takes care of entering (full) kernel mode and calling the normal Linux system call handler. For performance-critical system calls, it is possible to write a hand-tuned fsyscall_handler. For example, fsys.S contains fsys_getpid(), which is a hand-tuned version of the getpid() system call. The entry and exit-state of an fsyscall handler is as follows: ** Machine state on entry to fsyscall handler: - r10 = 0 - r11 = saved ar.pfs (a user-level value) - r15 = system call number - r16 = "current" task pointer (in normal kernel-mode, this is in r13) - r32-r39 = system call arguments - b6 = return address (a user-level value) - ar.pfs = previous frame-state (a user-level value) - PSR.be = cleared to zero (i.e., little-endian byte order is in effect) - all other registers may contain values passed in from user-mode ** Required machine state on exit to fsyscall handler: - r11 = saved ar.pfs (as passed into the fsyscall handler) - r15 = system call number (as passed into the fsyscall handler) - r32-r39 = system call arguments (as passed into the fsyscall handler) - b6 = return address (as passed into the fsyscall handler) - ar.pfs = previous frame-state (as passed into the fsyscall handler) Fsyscall handlers can execute with very little overhead, but with that speed comes a set of restrictions: o Fsyscall-handlers MUST check for any pending work in the flags member of the thread-info structure and if any of the TIF_ALLWORK_MASK flags are set, the handler needs to fall back on doing a full system call (by calling fsys_fallback_syscall). o Fsyscall-handlers MUST preserve incoming arguments (r32-r39, r11, r15, b6, and ar.pfs) because they will be needed in case of a system call restart. Of course, all "preserved" registers also must be preserved, in accordance to the normal calling conventions. o Fsyscall-handlers MUST check argument registers for containing a NaT value before using them in any way that could trigger a NaT-consumption fault. If a system call a
# Copyright (c) 2016-2017 Intel Corporation
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

schema: "nsb:traffic_profile:0.1"

name:            fixed
description:     Fixed traffic profile to run UDP traffic

traffic_profile:
  traffic_type: ProxRampProfile
  tolerated_loss: 0.0
  test_precision: 1.0
  packet_sizes: [64<