nyuuzyou/wikis huggingface dataset:
Hyperlaunch

Hyperlaunch is a new, flexible system for launching the Xen hypervisor and virtual machines.
The design enables seamless transition for existing systems that require a dom0, and provides a new general capability to build and launch alternative configurations of virtual machines, including support for static partitioning and accelerated start of VMs during host boot, while adhering to the principles of least privilege. It incorporates the existing dom0less functionality, extended to fold in the new developments from the DomB project, with support for both x86 and Arm platform architectures, building upon and replacing the earlier 'late hardware domain' feature for disaggregation of dom0.
Hyperlaunch is designed to be flexible and reusable across multiple use cases, and our aim is to ensure
that it is capable, widely exercised, comprehensively tested, and well understood by the Xen community.
* Committed version of the Hyperlaunch Design Document, merged 8th July 2021
* Committed version of the Hyperlaunch Device Tree Design Document, merged 8th July 2021
* Xen Hyperlaunch: From Zero to Assurance - Keynote at the Xen Summit 2022 video
* Hyperlaunch: A New Start for Xen - Keynote at the Xen Summit 2021 video
* XSM Roles: A New Role Model for Xen - at the Xen Summit 2021 video 
* Hyperlaunch Design Session at the Xen Summit 2021 video
* Minutes of working group meeting, 18th March 2021
* Hypervisor code developed for the hyperlaunch prototype, initial development milestone
=== Implementation ===
* Version 4 patch series: Boot modules for Hyperlaunch contains the fourth version of changes proposed to the Xen Hypervisor towards integrating Hyperlaunch. This v4 series is initial integration work rather than a full Hyperlaunch feature implementation -- see the earlier Version 1 series for a posted full implementation of the Hyperlaunch feature.
* Slides and notes from Design Session at Xen Summit 2023
* Version 1 patch series posted to xen-devel mailing list in July 2022
* RFC version of preparatory work on boot logic posted May 2022
* Version 6 of the XSM Roles patch series, posted September 2021
== DomB mode of dom0less ==
* Xen Summit 2019: Keynote: Xen Dom0-less
* Embedded Linux Conference 2019: Static Partitioning Made Simple
* xen-devel, June 2018: RFC: Boot domain, DomB
* Dec 2019 design meeting in Cambridge 
* May 2020 domB design doc v1
* Xen Summit 2020 Talk video: Xen System Boot: Launching VMs (DomB)
* Xen Summit 2020 Design Session video: Next steps for Xen system boot: launching VMs (DomB)
== Related work ==
* TrenchBoot and Dynamic Root of Trust for Measurement (DRTM)
* OpenXT & Boot Integrity references
* Platform Security Summit 2018 videos
* Platform Security Summit 2019 videos
* System Device Tree specification, 16th March 2021
== Earlier design document revisions ==
* Version 4 of the Hyperlaunch Design Document - posted May 2021
* Device Tree Design Document for Version 4
* Version 3 of the Hyperlaunch Design Document - posted March 2021
* Draft of Device Tree Design Document - posted March 2021
* Version 1 of the domB Design Document - posted May 2020
__NOTOC__
Hypervisor

__NOTOC__
The hypervisor is Xen itself. It goes between the hardware and the operating systems of the various domains. The hypervisor is responsible for checking page tables, allocating resources for new domains, and scheduling domains. It presents the domains with a VirtualMachine that looks similar but not identical to the native architecture. It is also responsible for booting the machine enough that it can start dom0.
Just as applications can interact with an OS by giving it syscalls, domains interact with the hypervisor by giving it hypercalls. The hypervisor responds by sending the domain an event, which fulfils the same function as an IRQ on real hardware.
Category:Xen
Category:Glossary
Importing documents into the Wiki

== Attaching files ==
We enabled attachment of PDF files to the Wiki, but no other documents. Jost go to Special:Upload and upload the file and then ling to it via [[File:filename.pdf]]
== Converting documents ==
=== Software needed === 
* LibreOffice
* Wiki Publisher Extension
* If we use LibreOffice 3.3+ the Wiki Publisher Extension comes with the base install 
=== Steps === 
# Load the document into LibreOffice Writer (note that PDF files load into LibreOffice Draw, you need to convert a PDF into another format using something like http://www.pdfonline.com/pdf-to-word-converter/ before loading it)
# Export: variant 1
## Export to Mediawiki.txt
## Copy into wiki page
# Export: variant 2
## Send to Mediawiki
Note that this does not always work perfectly for converted PDF files.
Category:Wiki Management
Category:Community
Improved NUMA memory allocation

__NOTOC__
= Areas of interest =
== NUMA node affinity of Xen domains ==
Xen has the DOMCTL hypercall XEN_DOMCTL_setnodeaffinity to configure the NUMA node affinity of Xen domains for allocating memory.
Main article: NUMA node affinity in the Xen hypervisor
= Issues =
While Xen is in has some NUMA-awareness, there are potential issues where memory allocation might not be ideal for NUMA.
== Parallel boot issues ==
Booting multiple VMs in parallel will result in potentially allocating both on the same NUMA node:
This race condition can happen when multiple VMs are booted in parallel, because the XAPI toolstack does not wait until Xen has constructed each domain before constructing the next VM.
That would serialize domain construction, which is currently parallel.
The current understanding of this parallel boot race is that, while creating the p2m (this is before the domain starts running) you could run into a problem without reservations, where during the parallel contruction boot of two domains, the toolstack may think they have individually enough free memory before the VMs are actually fully booted during which the VMs start to populate their p2m, but collectively when theil p2m is fully populated, they don't fit onto the same NUMA node and Xen has to populate the p2m of part of these VMs from other NUMA nodes.
Documentation on now how `meminit_hvm()` allocates memory on domain creation is here:
https://github.com/xenserver-next/xen/blob/xenguest-numa/docs/designs/numa/x86/meminit_hvm.md
The current plan of Bernhard Kaindl is to investigate further on what would be needed use the vmemranges described in the page about meminit_hvm() code described below https://github.com/xenserver-next/xen/blob/xenguest-numa/docs/designs/numa/memory_alloc.md to allocate memory from (a) specific NUMA node when XAPI creates a domain VM using xenguest.
== See also ==
- The allocation policy of RHEL.
Category:NUMA
Category:NUMA Initiatives 2025
Category:Resource Management
Install-multiple-versions

=Purpose of this page=
Sometimes, you may want to install two versions of Xen (e.g., Xen-4.6.0 and Xen-4.7.0) on the same host. In order to do that, you need two install two versions of the xen kernel and the xen-tools.
This wiki will describe how to use two different versions of Xen on the same host.
=Notations and Assumptions=
This wiki assumes Ubuntu 12.04 as dom0.
We use SRC46 to represent the path to the source code of Xen 4.6.0, for example, /home/username/xen-4.6.0;
We use SRC47 to represent the path to the source code of Xen 4.7.0, for example, /home/username/xen-4.7.0;
We use INSTALL46 to represent the path to the installation path for Xen 4.6.0, for example, /home/username/install/xen460;
We use INSTALL47 to represent the path to the installation path for Xen 4.7.0, for example, /home/username/install/xen470;
=How to install two versions of Xen on the same host=
Step 1: Install two versions of the Xen kernel under /boot; 
You just need to install the two xen kernels into /boot on the host;
The commands to install one version of Xen kernel are as follows:
cd ${SRC46}
configure --prefix=${INSTALL46} --sysconfdir=${INSTALL46}/etc --enable-rpath
make
sudo make install-xen 
cd ${SRC47}
configure --prefix=${INSTALL47} --sysconfdir=${INSTALL47}/etc --enable-rpath
make
sudo make install-xen 
Step 2: Configure the grub entry for each version of Xen. 
Step 3: Install Xen toolstack into the installation folder for each version:
cd ${SRC46}
make install-tools 
cd ${SRC47}
make install-tools 
Now you have install two versions of Xen kernels and Xen toolstacks into your host. 
You can reboot your system and select one version, say, Xen 4.6.0.
The version of Xen toolstack has to match with the version of Xen kernel you are using. 
So you need to go to the installation folder for the specific version of xen toolstack and run the xen-related commands, such as xl.
Since you boot into Xen 4.6.0, you can run the following commands to list the domain informations.
cd ${INSTALL46}
./sbin/xl list
NB: If you find the domain 0's name is (null), you need to run the xen-init-dom0 to initialize the domain 0 in xenstore. In the above example, you need to run the following commands:
cd ${INSTALL46}
./lib/xen/bin/xen-init-dom0
=Reference=
[1] Question about the best practice to install two versions of Xen toolstack on the same machine. http://www.gossamer-threads.com/lists/xen/devel/432095
Installing Linux on Kronos

==Installing Linux==
*Note*: before proceeding further, ensure that you have a symlink from /usr/share/qemu/keymaps to the real directory /usr/share/qemu-linaro/keymaps.
This example will walk you through installing Ubuntu 10.04 (64 bit) on Kronos. Various other Linux distros and versions are supported (as are Windows versions): you can find out which by using the command
xe template-list
* The script below will require you to log directly into the VM in order to complete the installation. It is possible to use a pre-seed file to perform the installation process - see the xe documentation for more details.
* The script assumes that you are performing the installation from Dom0 on the local machine. It is possible to perform this task from a remote machine - again, see the xe documentation for more details.
You'll probably want to change the following settings:
* "vm-label" - to something useful to allow you to reference the vm from Dom0
* "hostname" - to whatever you'd like the hostname to be
* "domain" - to your local domain
#!/bin/bash
set -e
set -x
template=`xe template-list name-label="Ubuntu Lucid Lynx 10.04 (64-bit)" --minimal`
vm=`xe vm-install template=$template new-name-label=vm-label`
network=`xe network-list bridge=xenbr0 --minimal`
vif=`xe vif-create vm-uuid=$vm network-uuid=$network device=0`
xe vm-param-set uuid=$vm other-config:install-repository=http://archive.ubuntu.com/ubuntu
xe vm-param-set uuid=$vm PV-args="auto-install/enable=true interface=auto netcfg/dhcp_timeout=600 hostname=vm-host-name domain=mydomain.is.best"
xe vm-start uuid=$vm
===Completing installation===
By far the easiest way to complete installation is to use the "xe console" command to connect to the VM's console. In order to do this, you will need to start the xapissl daemon:
/usr/lib/xcp/lib/xapissl start
It should report as "stunnel4". Note that if you're running Apache/Apache2, you may find that it's already bound to 443, but then again you probably stopped it anyway so that you could use xcp in the first place. You then need to identify to which VM you need to connect. Use this command to find all VMs:
xe console-list
You need to find the vm-uuid for the VM with the label you set up before (e.g. vm-label, as above), and then to connect to it using a command such as this:
xe console uuid=593c6788-1ddc-e7d7-c6b1-0de0778c78b7
You should now be connected (you may need to press <Return> once or twice), and can now complete the installation. I suggest that you install an ssh daemon and record the IP address of the guest, so that you can easily reconnect in the future.
===If things go wrong===
If things go wrong, and you want to delete the vm, you can do so very easily with the following command (use with care!):
xe vm-uninstall name-label=vm-label --multiple
Installing Windows on Kronos

===Installing Windows===
To install windows, you'll need an iso. These can be served by an NFS server. Try this:
xe-mount-iso-sr nfs-server:/path/to/isos
Then create a windows VM:
xe vm-install template=Windows\ 7\ \(32-bit\) new-name-label=windows
xe vm-cd-add vm=windows cd-name=win7.iso device=3
xe vm-start vm=windows
===PV drivers for Windows===
wget http://downloads.xen.org/XCP/debian/xs-tools-5.9.960.iso
mv xs-tools-5.9.960.iso /usr/lib/xen-common/xapi/packages/iso
After doing this, rescan the SR to pick up the new ISO.
Installing Windows on Xapi

===Installing Windows===
To install windows, you'll need an iso. These can be served by an NFS server. Try this:
xe-mount-iso-sr nfs-server:/path/to/isos
Then create a windows VM:
xe vm-install template=Windows\ 7\ \(32-bit\) new-name-label=windows
xe vm-cd-add vm=windows cd-name=win7.iso device=3
xe vm-start vm=windows
To get networking working, you'll need to set up the bridge manually:
brctl addbr xenbr0
brctl addif xenbr0 eth0
You may need to move the IP address to the bridge rather than the physical interface. Having done this, try a pif-scan:
xe pif-scan
This might create the network for your interface.
===PV drivers for Windows===
wget http://downloads.xen.org/XCP/debian/xs-tools-5.9.960.iso
mv xs-tools-5.9.960.iso /usr/lib/xen-common/xapi/packages/iso
After doing this, rescan the SR to pick up the new ISO.
Category:Guest Install
Instruction Set Architecture

__NOTOC__
An instruction-set architecture (ISA), also known as an instruction set or just an architecture. is a specification of what instructions a processor understands. Lots of processor models will use the same ISA, though later models often add extensions by which programmers can use their extra capabilities. For example, x86 is an ISA designed by Intel for their 8086 processor and used by its successors to this day. Motorola 68000 (m68k) is another. MMX and SSE are examples of extensions added to more recent x86 processors. From the programmer's point-of-view, an "instruction-set architecture" and an "assembly language" are pretty much the same thing, though technically the ISA refers to the machine code rather than the text-based assembly language used to produce it.
There are also ISAs that do not run on actual hardware: Java virtual machine code is an example of this.
For more information, see Wikipedia.
Category:Glossary
Inter-domain communication for XAPI

Note: this page is out-of-date and should be replaced with a description of the "message-switch" and "vchan"; see https://github.com/xapi-project/xapi-project.github.io/issues/39
In the future we will have
# storage driver domains
# network driver domains
# qemu stub domain(s)
# ... various other helper domains (e.g. possibly a domain running pygrub)
The XCP toolstack already has several pieces including:
# xapi: handling resource pools
# squeezed: applying ballooning policy
# xenopsd: (new) "babysitting" running VMs on a host
# perfmon: monitors alerts based on performance measurements
We currently use a set of ad-hoc protocols for inter-process communication including
# XMLRPC
# xenstore "rpc"
# JSONRPC
We desire to standardise on a particular messaging/RPC system which
# is available everywhere and very easy to use from many different source languages
# promotes location-transparency (so we don't suffer when a service is moved from dom0 to a domU)
= Proposal: DBUS =
DBUS is a simple IPC system originally designed for graphical desktop environments. It supports
# a message broker which can buffer messages and start receiving services on demand
# an IDL supporting both basic types (string, int etc) and structured types (arrays, structs)
# languages including: C, python, ocaml
# location-transparency via a notion of a "well-known bus address" (like org.xen.foo) used to identify services
It is also the system used by XCI.
Useful links:
# d-feet: a pygtk-based object inspector
# http://wiki.meego.com/D-Bus/Overview: an overview, including instructions for using d-feet
== Concrete example ==
Consider a simplified XCP system containing the following services:
# xapi: running in a domU, handling XenAPI calls from clients
# xenopsd: running in dom0, performing start/shutdown/... on running VMs
# storage: running in a domU i.e. a storage driver domain
We would create a special bus for our communication (we wouldn't use the system or the session default buses)
Each service would bind to: org.xen.xcp.servicename
Each service would place its objects into path: org/xen/xcp/servicename/objectname
TBD: Would we want to expose internal application "objects" (e.g. the VMs being managed by xenopsd or the VDIs within a storage driver domain) as individual objects, so they are introspectable? Or would that require that we broadcast too much internal state?
We would want to specify IDL up-front for interfaces (even though it can be used dynamically e.g. with python)
TBD: Are signals useful for us?
TBD: Are there any default interfaces for heartbeating and diagnostics?
Category:Security
Category:XAPI Devel
Internships/Make a Small Contribution

Once you decide on the project you are most interested in, the most important thing you need to do before submitting an application is to make the required small contribution to that project. The contribution should be relevant to the project you are proposing to work on, meaning it should be for the same software module or show the skills you'll be drawing on in working on the project. You should ask the project's mentor for a suggestion for what a suitable contribution can be. If you have an idea about what you'd like to do for your first contribution, feel free to propose it. While working on your contribution, you should feel free to ask for help from the mentor or from other people in the project's IRC channel. It is typical that once you submit your contribution, your mentor or another person who reviews it will have some feedback about what you can improve in it. Please be sure to follow up on the reviewer's feedback until your contribution is ready to be included in the project. It's best to allocate time over several weeks for this process and to start as early as possible.
Examples of small projects may be
* Fix a coverity scan issue.
* Fix an existing bug. 
* Make a tiny improvement.
* Write some test code (for example for the Xen Hypervisor, see Xen Test Framework)
You will need to download and run the code for the project and create a patch that addresses what the goal of the small project. Your patch may end up being just a few lines of code, but this demonstrates a willingness to learn and get involved. You will need to post and get your patch reviewed and are likely go through several iterations of the patch review, where you will get some comments about how you can improve the patch and will need to follow up with an updated patch. 
While you'll only need to contribute to one project for your application (and GSoC does not require any). While only one contribution is required to be considered for Outreachy, we find that the strongest applicants make multiple contributions throughout the application process, including after the application deadline. After making your initial contribution, you are encouraged to continue working with your mentor on additional contributions as your time allows.
Category:Internships
Interrupts

Category:Developers
The purpose of this page is to document how Xen sets up and uses interrupts. It is a work in progress, and to a certain extent dynamic as patches modify the code. However, the contents of it is accurate of November 14, 2011.
== IDT vector entries ==
Refer to xen/include/asm-x86/mach-default/irq_vectors.h
=== Vector Ranges ===
Section 	Range 	Use
Exceptions 	0x00 - 0x1f	Architecturally reserved
Dynamic IRQs 	0x20 - 0xdf	Free for assignment for devices
Legacy 	0xe0 - 0xef	Reserved range for PIC before switching to APIC
High Priority	0xf0 - 0xff	For IPIs and serial interrupts
=== Specific Vectors ===
Vector	Symbol 	Description
0x20 	IRQ_MOVE_CLEANUP_VECTOR	Clean up references to IRQs in past PCPUs after they have been moved
0x80 	LEGACY_SYSCALL_VECTOR 	
0x82 	HYPERCALL_VECTOR 	
0xf7 	CMCI_APIC_VECTOR 	
0xf8 	PMU_APIC_VECTOR 	
0xf9 	LOCAL_TIMER_VECTOR 	
0xfa 	THERMAL_APIC_VECTOR 	
0xfb 	CALL_FUNCTION_VECTOR 	
0xfc 	EVENT_CHECK_VECTOR 	
0xfd 	INVALIDATE_TLB_VECTOR 	
0xfe 	ERROR_APIC_VECTOR 	
0xff 	SPURIOUS_APIC_VECTOR
Libvirt

The virtualization API libvirt is a toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). It has support for the Xen Project hypervisor, including a libxenlight port
The current URI syntax for libvirt can be found here. This is worth noting, as some older Xen Project-specific URI patterns have been deprecated in favor of a newer, generalized syntax.
== WHO USES LIBVIRT? ==
Libvirt is commonly used by installations which need to support both Xen Project and KVM hypervisors. It is also used by companies like Oracle and SUSE in their OpenStack-based cloud offerings.
Generalized virtualization applications use libvirt so they can (theoretically) support multiple hypervisors with a single interface. The "theoretical" portion of this is that the application must be intelligent enough to avoid calls which don't apply to the selected hypervisor (e.g., employ KVM-specific libvirt calls when controlling a Xen Project VM).
Libvirt can be exercised via Virsh Commands.
Also, the Xen4CentOS effort includes an updated version of libvirt.
== HOWTOs ==
* DomU_Install_with_Virt-Manager gives an example of using Virt-Manager, a GUI which uses libvirt.
* DomU_Install_with_Virt-Install gives an example of using Virt-Install, which uses libvirt.
* Fedora_Host_Installation steps through installing Fedora, and covers the use of libvirt-based tools.
* Using libvirt for Xen Project on Debian from the Debian documentation.
* Install Xen Project 4.4 with Libvirt on Ubuntu 14.04
* Using libvirt to Create a Private Network for Xen Project DomUs by blogger Matt J. Quinn.
* Libvirt configuration for Xen4CentOS from CentOS.org
== PRESENTATIONS ==
* libvirt support for libxenlight as presented by Jim Fehlig at Xen Project Developer Summit 2014
== BLOG POSTS ==
* Libvirt support for the XL toolkit by Jim Fehlig
== REFERENCES ==
* Libvirt documentation from libvirt.org
* The libvirt Xen Project driver from libvirt.org
* Applications using libvirt from libvirt.org
* libvirt Xen Project architecture from libvirt.org
* Xen4Libvirt information from CentOS.org
* Building Libvirt for Xen Project on ArchLinux from ArchLinux.org
Category:OpenStack
Category:Integration
Category:Libvirt