nyuuzyou/wikis huggingface dataset:
Do﻿m0 Memory — Where It Has Not Gone

If you are upgrading domain 0 Linux kernel from a non-pvops (classic, 2.6.18/2.6.32/etc.) kernel to a pvops one (3.0 or later), you may find that the amount of free memory inside dom0 has decreased significantly. This is because of changes in the way kernel handles the memory given to it by Xen. With some updates and configuration changes, the "lost" memory can be recovered.
If you previously had 'dom0_mem=2G' as a command line to Xen, change this to 'dom0_mem=2G,max:2G'. If that didn't help, read on.
== What Changed? ==
When a domain is started, it is provided with:
# A number of pages of memory. These are contiguous in the guest's pseudo-physical address space and start at address 0.
# The maximum number of pages the domain is allowed to have (the maximum reservation). This may be more than the initial number of pages to allow the the guest to balloon up (increase its number of pages).
#The e820 memory map. For dom0, the physical e820 map is used so dom0 can access all BIOS data areas and PCI device MMIO regions.
The principle differences between the new and old kernels are:
# The new kernel allocates page tables and struct page's for all the pages up to the maximum reservation, the older kernels only allocate enough for the current number of pages. On systems with lots of RAM relative to the number of pages used by dom0 this can result in lots of memory wasted.
# The new kernel tries harder to release pages back to Xen that are unusable (because they are behind reserved regions or holes in the memory map).
== Me Back My Memory! ==
To stop the kernel from wasting memory on page tables etc. for memory it will never use:
# Use Xen dom0_mem=max:LLL command line option to set the maximum reservation to LLL (the M and G suffixes can be used for for MiB and GiB) . e.g., If you previously had dom0_mem=XXXG, change this to dom0_mem=XXXG,max:XXXG.
This requires Xen 4.1.2 or later (which sets the maximum reservation based on the command line) and Linux 3.0.5 or later (which makes use of it)..
To recover the memory released during boot:
# Ensure the balloon driver is enabled in the kernel (CONFIG_XEN_BALLOON).
# Set the balloon driver's target to the desired amount of RAM. Either with the mechanism provided by your toolstack or directly with (XXX is the amount of RAM in KiB):
 echo XXX > /sys/devices/system/xen_memory/xen_memory0/target_kb
== I'm Lazy, Make it So==
A series of patches by Konrad Rzeszutek Wilk will eliminate the need for the balloon driver. With these patches, the otherwise unusable pages will be moved instead of released. These patches are expected in 3.5.
== Also See ==
* Understanding Memory Allocation in Oracle VM \ Xen
Category:RefToExternalArticle
Category:Xen
Category:Xen 4.2
Category:Users
Category:PVOPS
Embedded and Automotive/Archived/PV Drivers

== Project Infrastructure ==
* Mailing list - done
* Code repos on xenbits - not done
* Development repositories are deployed on GitHub Xen Troops project (see below)
* Whitepapers - done, see Automotive Whitepapers
==Reference platforms==
Major platform: Renesas R-Car H3
Additional platforms: TexasInstruments Jacinto 6, NXP i.MX8, Intel Broxton
==Reference architecture==
==Repository structure==
All repositories are deployed on GitHub Xen Troops project.
List of repositories and owners:
* xen + xen-tools @aanisov (upstream through mailing list)
* linux kernel @aanisov (upstream through mailing list)
* u-boot @otyshchenko (upstream through mailing list)
* libxenbe @al1img 
* wayland drm + events backend @al1img 
* alsa backend @al1img 
* optee-core @lorc (upsteram through pull request on github)
* optee-client @lorc (upsteram through pull request on github)
* build @aanisov 
* pv drm frontend @andr2000 
* pv alsa frontend @andr2000
* pv events frontend @andr2000
Category:Embedded and Automotive
Category:Embedded and Automotive/Archived/PV Drivers
Category:Drivers
Category:Archived
Embedded and Automotive/Archived/PV Drivers/Roadmap

Initial contribution by GlobalLogic
* Automotive SoCs support
** TI Jacinto 6 support - done
** Renesas R-Car gen 2 support - done
** Renesas R-Car gen 3 support - done
* QNX IPL and drivers - abandoned, as interest has shifted from QNX to AGL, for which there is an upstream. The risk of having to maintain an unnecessary Xen port was considered too high at this stage
* Initial cpufreq implementation in XEN
* Initial PV drivers APIs implementation (tty, RTC, audio, event, rpmsg)
Xen 4.9 release
* major PV drivers APIs: sound, display, input - done
** frontend and backend implementations available on GitHub
Xen 4.10 release
* "Non-shared" IOMMU support - done
** VMSA-compatible IOMMU in Renesas R-Car gen3 driver - done
* generic co-processor (GPU, DSP, FPGA, TPU, ...) virtualization support
** vcoproc design documentation created
** initial implementation in progress
** drivers to be implemented as deprivileged applications
* integration with ARM TrustZone based on OP-TEE
** SMC/HVC bridge in Xen
** OP-TEE driver as a deprivileged app
** changes in OP-TEE itself: dynamic memory management, multiple domains support
* deprivileged applications in Xen on ARM
** initial stubdom support for ARM done
** initial EL0 deprivilege support done
** will be use for non-upstreamable drivers (GPU, TEE, etc.)
** may be also used for PL011 emulation required by Linaro spec
Future
* power management implementation
* hard real time scheduling integration, RTDS-Based-Scheduler
* yocto-based build management integrations (see meta-virtualization layer on Yocto Project git) (also see Xen_on_ARM_and_Yocto)
* heterogeneous computing support (big.LITTLE, etc.)
* dom0 RTOS support (FreeRTOS? Arctic Core – Open Source Autosar?)
* IEC 61508 safety certification - see similar OSADL Sil2LinuxMP project for Linux
Category:Embedded and Automotive
Category:Embedded and Automotive/Archived/PV Drivers
Category:Yocto
Category:Drivers
[[Category:Archived]
Event Channel Internals

==General idea==
Event channels are the basic primitive provided by Xen for event notifications. An event is the Xen equivalent of a hardware interrupt. They essentially store one bit of information, the event of interest is signalled by transitioning this bit from 0 to 1.
Notifications are received by a guest via an upcall from Xen, indicating when an event arrives (setting the bit). Further notifications are masked until the bit is cleared again (therefore, guests must check the value of the bit after re-enabling event delivery to ensure no missed notifications).
Event notifications can be masked by setting a flag; this is equivalent to disabling interrupts and can be used to ensure atomicity of certain operations in the guest kernel.
There are four kinds of events which can be mapped into event channels in Linux:
* Inter-domain notifications. This includes all the virtual device events, since they're driven by front-ends in another domain (typically dom0). 
* VIRQs, typically used for timers. These are per-cpu events.
* IPIs.
* PIRQs - Hardware interrupts.
Events are stored in a bitmap shared between guest and hypervisor. Several tricks such as N-level search path and per-cpu mask are used to speed up search process.
All versions of Xen support the 2-level event channel implementation. All recent versions of Xen (4.4 and later) also support the FIFO channel implementation.
During the 4.3 cycle, a 3-level event channel implementation was discussed but did not go forward. The FIFO based implementation addresses the scaling concerns that motivated the 3-level implementation. The rationale behind extended event channel ABI is to scale better, as nowadays hardware is getting more and more powerful and can support more DomUs running at the same time. Another approach to address scalability is to disaggregate Dom0 functionalities to separate domains. Here is a write-up done at that time (2013): 
==2-level event channel ABI==
This is the de-factor implementation for event channel mechanism. It is supported across all Xen releases for compatibility.
32 bit domain supports up to 1024 event channels, 64 bit domain supports up to 4096 event channels.
This implementation utilizes 2-level search path to speed up searching. The first level is a bitset of words which contain pending event bits. The second level is a bitset of pending events themselves.
==FIFO-based event channel ABI==
A new FIFO-based event channel is implemented in Xen 4.4 and later. This new ABI utilizes lock-less queues between Xen and guests to achieve FIFO property. Concurrent access in Xen to the event queues is protected by spin lock. This approach has nice features such as event priority, flexible configuration for number of event channels. 
Here is a historical discussion thread.
Category:Xen
Category:Developers
Category:Design Document
Category:Paravirtualised Architecture
FOSS Industry Groups with a stake in Safety Cerification

* Automotive Grade Linux Virtualization Expert Group
:* Members with Xen based products: GlobalLogic (bronze), StarLab (bronze)
:* Members which indirectly support/have supported Xen in this context: Renesas (platinum), Arm (gold)
:* Members which have showed up at Xen channels more than once: ADIT (bronze), Harman (bronze), LG (bronze)
:* Members which are also Advisory Board members: Amazon (silver), Qualcomm(silver), Oracle (bronze)
* Genivi: Hypervisor Team (or a group that will eventually become one)
:* Members with Xen based products: EPAM (2nd tier), GlobalLogic (2nd tier)
:* Members which indirectly support/have supported Xen in this context: Renesas (silicon), Arm (silicon)
:* Members which have showed up at Xen channels more than once: Bosch (1st), Harman (1st), LG (1st)
:* Members which are also Advisory Board members: Intel (silicon), Qualcomm(silicon)
* Linaro: I am not sure whether there is a Linaro group yet, if so it would be worth adding it here
Category:Safety_Certification
Category:Embedded and Automotive
Category:XenARM
FreeBSD PVH

This guide explains how to set up a FreeBSD PVH guest. The usage of PVH requires an Intel chip with EPT support.
This guide assumes that the user already has a working FreeBSD HVM amd64 guest installed, based on HEAD, and a Xen install using -unstable with a revision greater than b5dda35f5aa3ab5c7be2333a8a4e0cfa34226654.
===Moving from PVHVM to PVH===
Copy the FreeBSD kernel from /boot/kernel/kernel to your Dom0.
Add the following lines to /etc/ttys:
xc0 	"/usr/libexec/getty Pc" xterm on secure
And /etc/fstab should also be modified in order to use xbd devices:
# Device	Mountpoint	FStype	Options	Dump	Pass#
/dev/xbd0p2	/		ufs	rw	1	1
/dev/xbd0p3	none		swap	sw	0	0
Now the FreeBSD HVM guest can be stopped, and we need to modify the configuration file so it looks like:
kernel = "/path/to/kernel"
extra="vfs.root.mountfrom=ufs:/dev/xbd0p2"
disk = [
	'phy:/path/to/block/device,xvda,w',
	]
vif = ['bridge=bridge0,mac=00:ff:ff:ff:ff:ff']
memory=4096
vcpus=2
name = "freebsd_pvh"
pvh=1
The main changes are the removal of the builder option, and the addition of kernel and extra instead. Also note the option pvh=1 must be set in order to boot in PVH mode. Then we can boot into the newly created FreeBSD PVH guest:
# xl create -c freebsd_pvh.cfg
Category:Tutorial
Category:HowTo
Category:FreeBSD
Category:Xen
Category:Users
Frontend Driver

__NOTOC__
To access devices that are to be shared between domains, like the disks and network interfaces, the DomUs must communicate with Dom0. This is done by using a two-part driver. The FrontendDriver must be written for the OS used in the DomU, and uses XenBus, XenStore, shared pages, and event notifications to communicate with the BackendDriver, which lives in Dom0 and fulfils requests. To the applications and the rest of the kernel, the FrontendDriver just looks like a normal network interface, disk, or whatever.
Category:Xen
Category:Glossary
FuSa SIG/Charter

= Background =
Modern safety critical systems such as autonomous vehicles or industrial robots are constantly and rapidly increasing their complexity with cloud-connected and dynamically deployed functions. Keeping such systems “safe” may require reducing their complexity by separating critical and non-critical parts which can be achieved with Xen.
= Goal =
Xen can be safety-certified: it has been certified in the past by individual companies, and experts groups have confirmed its certifiability after careful analysts of the codebase and contribution processes. However, the burden of the certification process falls on the user. The goal of the Xen FuSa SIG is to reduce this burden by moving upstream Xen closer to safety-certifiability. The Xen FuSa SIG oversees activities such as improving the Xen code quality and producing artifacts (documentation, tests, traceability matrices, etc.) necessary for certifications.
= Members =
* ARM (Antonio Priore, Bertrand Marquis, Robin Randhawa)
* Citrix (George Dunlap)
* EPAM (Artem Mygaiev, Alex Agizim)
* LF (Kate Stewart)
* Renesas (Hisao Munakata)
* Resiltech (Francesco Rossi)
* AMD (Stefano Stabellini, Ayan Kumar Halder)
Assessors
* Exida (Piotr Serwa)
* MIRA (David Ward)
* TUV Rheinland (Robert Heinen)
* TUV SUD (Bernhard Nalte, Claudio Gregorio)
= Scope =
SIG activities can be represented in several streams:
=== Code Quality ===
Improve Xen code quality and safety. Implement features to improve real-time and reduce interference. Improve Xen coding style and align it with MISRA-C.
Keywords: MISRA, code quality, static analysis, real-time
=== Documentation ===
Define and implement guidelines, templates and examples related to requirements, architecture, design and API documentation. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed.
Keywords: documentation, requirements, architecture, design, APIs, traceability
=== Verification Tests ===
Define and implement guidelines and examples related to the verification of requirements, architecture, design and APIs as required for safety certification. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed.
Keywords: traceability, testing, dynamic analysis
Category:Safety Certification/FuSa SIG Category:Safety Certification
FuSa SIG/Contributing

Join the FuSa SIG meetings to participate in safety improvements for Xen.
In this page we can find a list of small items for newcomers and seasoned contributors alike to improve Xen safety compliance. The development items below are for the hypervisor (xen subdirectory).
Please send fixes to the xen-devel list following the Xen contribution process. For instance, see this example.
= MISRA C =
There is an effort in progress to align Xen with MISRA C coding guidelines. A few MISRA C rules are already officially part of the Xen coding style, they are available here: rules.rst
You can scan the Xen code for violations of this set of MISRA C rules using *cppcheck* (needs to be version 2.7 or greater):
 cd xen.git/xen/
 export CPPCHECK=/path/to/cppcheck/cppcheck
 export CPPCHECK_HTMLREPORT=/path/to/cppcheck/htmlreport/cppcheck-htmlreport
 export CPPCHECK_MISRA=y
 make cppcheck-html
The output will be under *cppcheck-htmlreport/index.html* by default.
Your help to reduce MISRA C violations in Xen is very welcome!
= SPDX =
SPDX is an open standard for communicating software bill of material information, such as the license of a source file. It consists of a single line comment at the top of the file with licensing information, for example:
 // SPDX-License-Identifier: GPL-2.0
Xen wants to be SPDX compliant. Please help! Xen is GPLv2, licensing information available | here.
= Testing =
Xen Project is using Gitlab-CI to test individual hypervisor features. See the existing tests under automation:
* https://gitlab.com/xen-project/xen/-/blob/staging/.gitlab-ci.yml
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/gitlab-ci/test.yaml
* https://gitlab.com/xen-project/xen/-/blob/staging/automation/scripts/qemu-smoke-arm64.sh 
Please add new tests for any features that you see missing, especially static configuration features (e.g. dom0less and related configurations). For instance:
* Boot Time Cpupools: https://gitlab.com/xen-project/xen/-/blob/staging/docs/misc/arm/device-tree/cpupools.txt
FuSa SIG/Presentations

= 2024 =
Xen summit 2024 - Next generation Xen architecture for automotive 
Xen summit 2024 - Xen Functional safety an update 
Xen summit 2024 - Open source safety elements out of context 
Xen summit 2024 - Implementing requirement traceability 
EOSS NA 2024 - Xen Project's progress towards safety certification 
= 2023 =
EOSS NA 2023 - Safety certifying an opensource project 
= 2022 =
Critical Summit North America 2022 | Xen in Safety-Critical Systems
= 2021 =
Embedded & IoT World 2021 | Panel Discussion - Safety certification in the open: How the Xen project is making progress to achieve certification (registration needed to view content)
ELISA Workshop May 2021 | Functional Safety at Xen Project
Xen Developer Summit 2021 | Xen FuSa SIG updates
Category:Safety Certification/FuSa SIG Category:Safety Certification
FuSa SIG/Roadmap

= Short term Roadmap and ongoing activities =
* Misra compliance
** Done:
*** Coverity regular analysis (arm)
*** CI internal checks
*** Eclair scanning (Bugseng)
*** MISRA rules in xen.git (partial) with their status
*** MISRA fixes violations
*** Coding style 
** Ongoing:
*** MISRA fixes (or reasoning) for few rules
* Requirements and Assumption of use
** Done:
*** Created and defined a hierarchy of requirements (Market, Product and Design)
*** Generic Timer
*** Emulated UART
*** Traceability using OpenFastTrace
** Ongoing:
*** Dom0less domain creation
*** Device passthrough
*** P2M
** To do:
*** GICv3, SMMUv3, vGICv3, hyper calls, IOMMU, LAPIC, hypercalls
*** a way to trigger updating the rules in case of code changes
* Architecture specifications
** Done:
*** Pushed the architecture specs in a branch
** To do:
*** Upstream the documents in xen.git
* Features
** Ongoing:
*** Hyperlaunch
*** PCI passthrough
*** virtIO and vPCI
*** Dom0less Domain reset - Xen should be able to reboot a DomU. This may involve saving the kernel and other artefacts and reseting the devices, etc.
** To do:
*** Dom0less vCPU pinning - User should be able to pin a dom0less vcpu to a specific physical cpu
*** Control domain / Hardware domain split - Currently dom0 is the control domain (ie privileged). It can create and destroy other domains and perform special operations. It is also the hardware domain as all the hardware gets assigned to it by default. We wish to split the responsibility between Control domain and hardware domain. IOW, the control domain needs to be separate from the hardware domain. The hardware domain will have the PV or VirtIO backends.
*** XSM module to implement security policy - domctl/sysctl and various hypercalls need to have more granular security controls for different types of domains (control, hardware, driver and domU)
= Roadmap =
* Fault injection investigation
* Coverage (gcov and Qemu)
* MCDC Coverage
* Fuzzing
* HW/SW interface investigation
* Boundary value analysis investigation
* Zephyr as Dom0
** tools license issue
** what functionalities do we actually need ?
* Configuration
** per-domain Xen heap static allocation
** configurability (strip down code)
* Real-time
** communication LinuxRT - Zephyr
** code improvements
*** remove RCU
* Code quality
** Misra-C compliance
*** automatic checks on builds
*** check on patches submitted
*** include the rules in the coding style
** use of a certified compiler
* Documentation and requirements
** process for change requests of reqs
* Tests
** low level testing
FuSa SIG/Status

= Scope Definition =
* Hardware
** Platform core components (no platform drivers): timer, mmu, iommu, irq controller
* System configuration
** Dom0less
** Mixed criticality: a certifiable VM and a non-certifiable VM
= Ongoing Efforts =
* Requirements and documentation
** Doxygen for documentation of internal and external interfaces
** Doorstop to link documentation and requirements to code
** Zephyr solution (originally by Intel) based on Doxygen
** In Progress: conversion of hypercalls docs to Doxygen format
* MISRA C
** MISRA C Working Group established
** MISRA C Working Group is evaluating MISRA C rules and accepting them into the Xen coding style.
** C rules officially accepted in Xen
** cppcheck available to detect violations, see *make cppcheck* and *make cppcheck-html*
** In Progress: violations reduction and MISRA C rules acceptance
* Static System Definition
** Static memory allocation
** Static heap allocation
** Static cpupools
** Done: cpupools
** In Progress: memory and heap allocation
* Determinism and interference reduction
** Interrupt latency analysis in Xen
** Cache Coloring
** In Progress: Cache Coloring upstreaming
* Traceability
** Trace review comments and patch versions all the way to a commit
** Status: script prototype available to retrieve all mailing list discussions from a commit id
Category:Safety Certification/FuSa SIG
Category:Safety Certification
Getting Started/es

= Introducción =
El propósito de este documento es guiar a un nuevo usuario en las decisiones necesarias para poder tener un sistema Xen corriendo adecuadamente y proporcionar un punto inicial desde donde saltar a una documentación más específica.
= Conseguir Xen =
La manera más recomenda para conseguir Xen es instalarlo a través de tu distribución en los casos que esto sea posible. Esta opción es normalmente más simple que otras alternativas ya que así se eliminan ciertas dificultades, al hacerlo a través de paquetes testeados. Otro beneficio es que podrás preguntarle a la comunidad de tu distribución por ayuda que normalmente podrán responderte de forma más específica de acuerdo a tu distribución en cuestión.
== Seleccionar Sistema Operativo para el Domain 0 / Distribución ==
La selección de un sistema operativo para el domain 0 es una elección basada más en preferencias personales y/o habilidades existentes. Si ya te es familiar alguna distribución en particular en contexto fuera de Xen, probablemente esta sea la mejor opción para ti, asumiendo que la distribución tenga soporte para Xen.
Debian, Ubuntu, OpenSuSE, SLES, XCP, Oracle VM, Fedora, NetBSD se sabe que tienen buen soporte para Xen en sus lanzamientos actuales.
Puedes encontrar artículos sobre cómo instalar Xen en varias distribuciones en :Category:Host Install.
== Instalar Xen desde las Fuentes ==
Si planeas desarrollar para Xen o necesitas alguna característica puntera que aun no está disponible en las distribuciones, entonces puede que lo que te venga bien es compilarlo desde las fuentes.
TODO link to a suitable guide
== Seleccionar un Kernel para el Domain 0 ==
Xen ya no trabaja con un kernel en particular recomendado para el uso del domain 0 (igualmente para un domain U para este asunto). Esto es porque el soporte de Xen en las distribuciones y en la linea de desarrollo de los kernels es hoara más que suficiente para la mayoría de los casos de uso.
Para la instalación de Xen en sí, la mejor opción es normalmente, usar el kernel de tu distribución.
Desde el Linux v3.0 todo lo necesario para un domain 0 funcional, está incluído en la linea principal de desarrollo de Linux, y esto ha llevado a un soporte renovado para el domain 0 de Xen por las distribuciones. Véase la lista de distribuciones a continuación, de las que tienen un buen soporte para Xen.
Dom0 Kernels for Xen lista los diferentes kernels para el domain 0 que están disponibles. Para una comparación de las características de los diferentes kernels, puedes ver Xen Kernel Feature Matrix.
TODO link to a suitable guide for building from source
= Seleccionar un Toolstack =
Hay varios toolstacks que pueden usarse con Xen. Elección de Toolstacks discute las características de varios toolstacks y los diferentes casos de uso donde pueden ser más apropiados.
= Instalar un Invitado =
:Category:Guest Install contiene guías sobre cómo instalar una variedad de invitados.
Category:Languages/es