nyuuzyou/wikis huggingface dataset:
OVMF

Tianocore / OVMF the Open-source community's project to enable EFI / UEFI for virtual machines. OVMF is integrated into Xen 4.4 release with essential patches upstreamed. However in 4.4 it is not built by default.
To build Xen with OVMF support, you would need to have --enable-ovmf when running configure.
Then enable EFI for your Xen guest by adding bios='ovmf' to your xl.cfg file. See the example below for more information.
One thing to have in mind is Xen supports both its own QEMU fork called qemu-traditional and upstream QEMU called qemu-xen. OVMF only supports the latter. Xen 4.4 has upstream QEMU configured for all HVM guests by default, so it is fine to not specify which QEMU to use in guest config file. But if you have already configured qemu-traditional for your guest you would need to delete / comment out that line.
A typical guest config file looks like below. Nothing fancy, just the "bios=" option is important. Also read the comment in the example for disk specification.
builder = 'hvm'
name = 's0-efi'
vcpus = 2
memory = 1024
# memory = 6000
vif = ['bridge=xenbr0']
# This is a disk image with EFI guest installed, you can also use live CD if you prefer.
disk = [ '/data/s0-efi.qcow2,qcow2,hda,w' ]
on_crash = 'preserve'
vnc=1
vnclisten='0.0.0.0'
serial='pty'
bios='ovmf' # if you don't have this line, seabios will be used
== Debuging OVMF ==
Here we will describe the different ways one can enable the debug output of OVMF.
=== Log into a file ===
Simply add the following to your guest config file:
device_model_args_hvm = [
 # Debug OVMF
 '-chardev', 'file,id=debugcon,path=/var/log/xen/ovmf.log,',
 '-device', 'isa-debugcon,iobase=0x402,chardev=debugcon',
]
This will tell QEMU to save OVMF's debug output to /var/log/xen/ovmf.log.
(Checkout QEMU's help of -chardev for more options.)
=== Log via the guest console ===
The alternative is to recompile OVMF so that it would log its debug via the guest console.
Recompile OVMF with -D DEBUG_ON_SERIAL_PORT to enable the use of the console.
To recompile OVMF,
you can edit xen.git:tools/firmware/ovmf-makefile
and add -D DEBUG_ON_SERIAL_PORT to the OvmfPkg/build.sh command line
before building OVMF via Xen build system.
Or you can execute OvmfPkg/build.sh -a X64 -b DEBUG -n $(nproc) -D DEBUG_ON_SERIAL_PORT
within the ovmf directory.
OVirt

From the oVirt webpage:
"oVirt manages virtual machines, storage and virtualized networks."
oVirt has been designed for use with KVM, but some experiments have been run with the Xen Project Hypervisor. The link below describes what does and does not work.
== HOWTO ==
The state of oVirt with Xen Project can be found here: http://www.ovirt.org/Xen
Category:Integration
OpenNebula

From the OpenNebula documentation:
"OpenNebula offers a simple but feature-rich and flexible solution to build and manage enterprise clouds and virtualized data centers. OpenNebula is designed to be simple. Simple to install, update and operate by the admins, and simple to use by end users. Being focused on simplicity, we integrate with existing technologies whenever possible. You’ll see that OpenNebula works with MySQL, Ceph, LVM, GlusterFS, Open vSwitch, Ceph, LDAP... This allows us to deliver a light, flexible and robust cloud manager."
== CONFIGURING XEN PROJECT ==
The configuration of the hypervisor for use with OpenNebula is unremarkable. OpenNebula requires only a normal working configuration of the Xen Project software. A few items of note:
* According to the release 4.8 documentation, OpenNebula uses the deprecated "xm" toolset.
* According to the documentation, it is suggested to use SCSI devices on HVM to avoid the limits of the number of IDE drives support.
== HOWTOs ==
* QUICKSTART: Install OpenNebula and Xen on CentOS 6 (this uses Xen4CentOS)
* HOWTO Build OpenNebula and Xen Project into a Hybrid Cloud
* HOWTO Build an OpenNebula Cloud on Xen using openSUSE 12.1
== PRESENTATIONS ==
* Xen Project on ARM with OpenNebula Demonstration
== DOCUMENTATION ==
* Using Xen Project from the OpenNebula Documentation
* QuickStart for Xen/CentOS 6 from the OpenNebula Documentation
* OpenNebula Wikipedia entry
Category:OpenNebula
Category:Integration
OpenStack via DevStack

This page is describing how to quickly deploy an OpenStack by using the development tool DevStack on a single machine. Xen Project via libvirt is going to be used.
This how-to describes the steps took on an Ubuntu 14.04 LTS. Little changes should be required to do the same on the other distribution supported by devstack.
== How to ==
We are going to install the Xen Project Hypervisor then setup devstack.
* Install the Xen Project software:
 sudo apt-get install xen-hypervisor-4.4-amd64
 sudo reboot
* Get devstack:
 git clone https://git.openstack.org/openstack-dev/devstack
* Configure devstack:
Edit local.conf in the devstack working repository. (For more options, take a look at DevStack Configuration.)
 [[local|localrc]]
 ADMIN_PASSWORD=secrete
 DATABASE_PASSWORD=$ADMIN_PASSWORD
 RABBIT_PASSWORD=$ADMIN_PASSWORD
 SERVICE_PASSWORD=$ADMIN_PASSWORD
 SERVICE_TOKEN=a682f596-76f3-11e3-b3b2-e716f9080d50
 
 # Useful logging options for debugging:
 DEST=/opt/stack
 LOGFILE=$DEST/logs/stack.sh.log
 SCREEN_LOGDIR=$DEST/logs/screen
 
 # This is a Xen Project host:
 LIBVIRT_TYPE=xen
* Run devstack:
This might take a while.
 ./stack.sh
* That's it! You are done!
== Video ==
* A 15 minute video demo of this process
== Reference ==
* DevStack - an OpenStack Community Production
Category:OpenStack
Category:Integration
Open vSwitch

Open vSwitch is a production quality, multilayer virtual switch licensed under the open source Apache 2.0 license. It is designed to enable massive network automation through programmatic extension, while still supporting standard management interfaces and protocols (e.g. NetFlow, sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag). In addition, it is designed to support distribution across multiple physical servers similar to VMware's vNetwork distributed vswitch or Cisco's Nexus 1000V. 
== See also ==
* Open vSwitch
* Open vSwitch Documentation
Category:Glossary
OutreachProgramForWomen/Round7

= Xen Project and OPW =
The Xen Project Advisory Board will be sponsoring one intern for Round 7 of the Gnome Outreach Program For Women which runs from December 2013 to March 2014. This program is an internship program specifically targeted at women: our goal is to increase womens' participation in the Xen Project. It is a continuation of the very successful GNOME Outreach Program for Women and we are running the program in conjunction with GNOME and other prominent open source projects.
= Information For Applicants =
== How To Apply ==
The official application period for OPW Round 7 is October 1st to November 11th. Please fill our your initial application and complete your Xen patch by November 11th. Applicants that do not complete the first patch will not be considered for an internship. Please take a look at our application FAQ for more info on how to fill our your initial application. Applicants will be notified by November 25th if they have been accepted.
If you are interested in being a Xen intern, please:
* Join the xen-devel mailing list. Depending on the project you choose, you may also need to join xen-api or cl-mirage (do check the information in the project). Check the list directory.
* Join the #opw IRC channel on irc.gnome.org
* Join the #xen-opw IRC channel on freenode.net
* Read our instructions for applying, and apply by Nov 11th.
* Ask one of our friendly developers on for a bite size bug or work item. This can be reviewing somebodies code, submitting a patch, or similar and will need to be done by Nov 11th.
== Schedule ==
* October 1: program announced and application form made available
* October 1 - November 11: applicants need to get in touch with at least one project and make a contribution to it
* November 11: application deadline
* November 25: accepted participants announced
* December 10 - March 10: internship period
== Community Reviewed Project List ==
This section contains projects that have been reviewed by Xen Maintainers and Committers. Community members are free to add their own project ideas. We have unreviewed project ideas in the following places:
* General List of Development Projects
* List of Unreviewed GSoC 2013 Projects
== Useful Resources ==
Here is some links to guides, tools, development flows etc.
* All Developer Information
* Xen Overview
* Submitting Xen Patches with Git
* Xen Beginners Guide
* Introduction to Git
= Information For Mentors =
See here
Category:Community
Category:OPW
Category:OPW_Round7
PCI Passthrough with Debian Wheezy

= PCI Passthrough with Debian Wheezy =
== Order of module loading ==
Following the instructions about Xen_PCI_Passthrough with a Debian Wheezy dom0, I encountered the problem that the module for the device I wanted to pass through (a network card) was loaded from the initramfs before the xen-pciback module was loaded. This made it impossible to pass the device through to a domU.
Blacklisting the module for the device I wanted to pass through didn't help. To work around the problem, I edited /etc/initramfs-tools/initramfs.conf so that not "most" modules were included into the image but only the ones that are required: "MODULES=dep" instead of "MODULES=most". After making this change, you need to update the initrd image.
On a side note, I recommend to use the lastest kernel from Debian backports. It works a lot better for me than older versions.
The point is that you need to make sure to load the xen-pciback module before loading the module for the device you want to pass through. This is probably true regardless of which distribution you're using.
== permissive option ==
In case you need the permissive option for a device:
It can be a good idea to give the permissive option as a kernel parameter to dom0 even when xen-pciback is loaded as a module. At least it doesn't seem to hurt --- it works for me with it given both as kernel option and as module option.
PVH (v2) Domu

Starting from Xen Project 4.8, the Xen Project team has been working on overhauling the x86 core of the Xen Project Hypervisor. One major work item in progress is PVHv2 (Dom0 and DomU) and splitting the PV and HVM code paths, to enable building a HVM and PVHv2 only hypervisor.
=== PVH (v2) DomU ===
 
Xen 4.10 adds a PVHv2 xl/libxl stable interface for unprivileged guests. Although PVHv2 DomU support has been present in previous Xen releases the lack of a stable toolstack interface prevented users from reliably testing and deploying this feature. From Xen 4.10 onwards PVHv2 DomU is a supported feature.
PVHv2 guests are lightweight HVM guests which use PV drivers for I/O and native interfaces for the rest of the operations. Unlike HVM guests, PVHv2 guests don't use QEMU device emulation. This reduces the memory footprint of Xen Project based systems significantly as for each HVM guest a QEMU instance runs in Dom0.
 
In addition, PVHv2 relies on Hardware Virtualization extensions and does neither use the PV kernel infrastructure nor the PV MMU, significantly reducing the number of Xen specific interfaces a PVHv2 guest uses compared to PV.
 
Consequently, PVHv2 guests have a much smaller TCB and attack surface compared to PV and HVM guests. Removing a large component such as QEMU, which consists of approximately 1.2 million lines of code - twice as much as the Xen Project Hypervisor itself, significantly reduces the potential of security vulnerabilities in a Xen Project based software stack compared to HVM guests.
 
In contrast to HVM based virtualization, PVHv2 does require operating system support, which is available in Linux 4.11 or newer.
 
==== PVH History ====
 
In Xen Project 4.4 and 4.5 we introduced a virtualization mode called PVH: This is essentially a PV guest using PV drivers for boot and I/O and hardware virtualization extensions for everything else. In late 2015, we started an initiative to re-architect and simplify PVH: PVHv2 was born. PVHv2 addresses key limitations of PVHv1, such as: not restricted to a specific paging mode decided at boot time, less usage of hypercalls and availability of some emulated platform devices provided by Xen itself.
Xen Project 4.8 laid the groundwork for PVHv2. In Xen Project 4.9 we completed most of the Hypervisor portion of PVHv2 and removed PVHv1. In Xen Project 4.10 we completed PVHv2 DomU by providing a stable interface in the toolstack in order to manage PVHv2 guests. We also delivered all necessary Linux Functionality for PVHv2 Guest support in Linux 4.11.
 
==== What is next? ====
 
PVHv2 support for FreeBSD is currently being reviewed, but has not yet been committed. Support for Dom0 PVHv2 and pci-passthrough for DomU will follow in a subsequent release. Work on supporting EFI boot in addition to support for Direct Kernel Boot is in progress.
 
In addition, we started the groundwork for wrapping the PV ABI inside a PVH container, which will eventually allow removal of the PV ABI from Xen and the Linux kernel, while allowing users to run legacy PV guest images on hardware with virtualization extension.
Category:Users
Category:Xen 4.10
Category:Xen 4.11
PV Protocol

PV protocol is the protocol used by all PV drivers. Just to name a few users: netfront/netback, blkfront/blkback, xenconsole etc.
Two fundamental elements of PV protocol is:
* Consensual ring(s) shared between frontend driver and backend driver.
* Event channel used to do notification.
The ring is nothing but a piece of memory shared between frontend driver and backend drivers. The ring size is counted in slots. A slot is a union of request and response.
Usually one event channel is used to do notification.
Here is a picture demonstrating the PV protocol.
In this picture we assume frontend produces requests and consumes responses, while backend produces responses and consumes requests. The slots are not explicitly drawn on the picture.
Category:Xen
Category:Developers
Category:Design Document
PV on HVM

== What is it? ==
PV on HVM is a mixture of paravirtualization and full hardware virtualization. The primary goal of PV on HVM is to boost performance of fully virtualized HVM guests through use of specially optimized paravirtual device drivers (also called PVHVM or PV-on-HVM drivers). 
The table shows how PV, HVM and PV on HVM compare in terms of virtualization method:
== Performance ==
PV-on-HVM drivers are optimized PV drivers for HVM environments that bypass the emulation for disk and network IO. They also make use CPU functionality such as Intel EPT or AMD NPT support. Thus, giving you PV-like or better performance on HVM systems. You can find information about performance trade-offs in this presentation. In a nutshell:
* For workloads that favor PV MMUs, PV on HVM is similar to PV 
* For workloads that favor nested paging (in hardware with Intel EPT or AMD NPT support), PV on HVM performs better than PV
== Compatibility ==
The following links provide information about Xen Project PV on HVM compatibility with various operating systems:
* HVM on PV support in the Linux Kernel
* HVM on PV in (legacy) Linux distributions
== Also See ==
* Information about using PV-on-HVM drivers
* HowTo on PV-on-HVM drivers
* Xen Project Windows HVM guests can use the opensource GPLPV drivers
Category:Xen
Category:Overview
Category:Users
Category:Beginners
Category:Glossary
Category:Fundamentals
Papers, Presentations and Videos relevant to Safety Certification

=== Xen Specific ===
* Summary Table Comparing Different Hypervisors (March 2018)
* Xen and the Art of Certification - Nathan Studer, DornerWorks, 2014: video, slides 
=== Industry Wide ===
* The AGL software defined connected car architecture, April 2018: whitepaper
* TSC Sponsored BoF: Can Linux and Automotive Functional Safety Mix ? Take 2: Towards an open source, industry acceptable high assurance OS, Robin Randhawa, 2017: slides
Category:Safety_Certification
Category:Embedded and Automotive
Category:XenARM
Paravirt Linux CPU Hotplug

=== Why does not xl vcpu-set work as expected when I try to increase the number of VCPUs? ===
First, you need maxvcups= to be high enough in the guest configuration settings. You can then check the online vs offline vcpus for a guest by doing xl vcpu-list GUEST.
Second, you are probably hitting the other limitation, which requires an operation to be performed within the guest. It is likely that hotplug events are not handled correctly by udevdin the target domain. To identify the problem, run udevadm monitor as root in target domain, then plug CPUs by doing xl vcpu-set GUEST NUMBER. If you can see similar output:
 KERNEL[1327937839.577165] add /devices/system/cpu/cpu1 (cpu)
 UDEV [1327937839.577368] add /devices/system/cpu/cpu1 (cpu)
 KERNEL[1327937839.577581] add /devices/system/cpu/cpu2 (cpu)
 UDEV [1327937839.577684] add /devices/system/cpu/cpu2 (cpu)
then CPUs are correctly added to system and udev can see it. You then have to write to the corresponding sysfs nodes to bring those CPUs online.
To enable the hot-plugged CPUs manually,
 echo 1 > /sys/devices/system/cpu/cpu15/online
And to automate the process,
 ls -lhF /etc/udev/rules.d/
 ls -lhF /lib/udev/rules.d/
 cat > /etc/udev/rules.d/cpu-online.rules <<-EOF
 SUBSYSTEM=="cpu", ACTION=="add", RUN+="/bin/sh -c 'echo 1 > %S%p/online'"
 EOF
then tell udevd to reload its rules with udevadm control --reload-rules (or restart udevd).
Watching the system logs (tail -F /var/log/messages) helps, as it shows the output of potentially failing udev rules and eventually some message related to a new enabled CPU.
If you've checked every options and configurations and believe that the problem is caused by a bug, please follow instructions in Reporting_Bugs_against_Xen to submit bug report.
=== Additional Notes ===
The following RUN rule may be used as well (checking for the online file beforehand),
 RUN+="/bin/sh -c '[ ! -e %S%p/online ] || echo 1 > %S%p/online'"
=== Background ===
- See this mailing list thread for discussion of the rationale for this behavior.
- https://www.linuxquestions.org/questions/slackware-14/slackware-udev-rules-4175465771/
- https://lwn.net/Articles/528976/
- https://www.kernel.org/doc/html/v4.18/core-api/cpu_hotplug.html
- https://www.kernel.org/doc/Documentation/power/suspend-and-cpuhotplug.txt
Category:Users
Category:Xen
Paravirtualization (PV)

== What is it? ==
 Paravirtualization (PV) is an efficient and lightweight virtualization technique introduced by the Xen Project team, later adopted by other virtualization solutions. PV does not require virtualization extensions from the host CPU and thus enables virtualization on hardware architectures that do not support Hardware-assisted virtualization. However, PV guests and control domains require kernel support and drivers that in the past required special kernel builds, but are now part of the Linux kernel as well as other operating systems.
Paravirtualization implements the following functionality
* Disk and Network drivers
* Interrupts and timers
* Emulated Motherboard and Legacy Boot
* Privileged Instructions and Page Tables
== PV IO Drivers ==
Disk and Network support (but in general the PV approach can also be applied to other peripherals such as audio, USB, etc.) is implemented via a pair of very simple PV back-end and PV front-end drivers. 
Architecturally, PV works by opening additional channels of communication between the hypervisors and the guest operating systems via PV front end and back end drivers as shown in the figure.
== Performance ==
PV delivers higher performance than full virtualization because the operating system and hypervisor work together more efficiently, without the overhead imposed by the emulation of the system's resources. This makes a big difference for disk and network operations, where the use of PV network, bus and block device drivers enable near-native performance. Examples of devices which benefit from Paravirtualization and where drivers are available are block (disks), SCSI, USB, VGA and PCI devices.
== PV and Linux (PVOPS) ==
As stated earlier, PV requires kernel support. In the Linux kernel, PV support is provided by the paravirt operations extensions (PVOPS) and PV front and back-end drivers that are shipped with Linux. PVOPS allows the kernel to determine at run-time, whether it is running under virtualization (Xen Project, KVM, VMI, etc.), which will prompt it to use optimized low-level operations for the specific virtualization stack. Xen Project Guest (DomU) support for Linux was introduced into the Linux kernel with version 2.6.24, whereas Xen Project Control Domain (Dom0) support was added from version 2.6.37. The key drivers have been added to Linux v 3.0 and since additional drivers and optimizations are added.
== PV and Legacy Applications ==
Paravirtualization is a way to extend the life of legacy and custom applications that are only supported on older operating systems. Using Xen Project PV virtualization you can run these workloads on new, more powerful, energy-efficient hardware and save money in the long run.
== Compatibility ==
The following links provide information about Xen and PV compatibility with various operating systems:
* Xen Project Guest support
* Xen Project Control Domain support
* PVOPS support in the Linux Kernel
* Xen Project kernels in (legacy) Linux distributions
Category:Xen
Category:Overview
Category:Users
Category:Beginners
Category:Glossary
Category:Fundamentals
Proposals

== Proposals for Front-Pages ==
{{Info|Feel free to either edit, comment on a proposal using the talk page or if you do not feel comfortable doing either by creating an alternative proposal (you can copy and paste a page and then change it).}
Mail thread announcing the proposals and background.
* Proposals/Main_Page1, Talk:Proposals/Main_Page1
* Proposals/Main_Page2, Talk:Proposals/Main_Page2
* New proposals here!
== Any other proposal ... ==
* Add here
Category:Community
PvGrub/es

PV-GRUB sustituye PyGrub para arrancar imágenes del domU de forma segura: carga el grub normalmente dentro del propio dominio y soporta las utilidades para leer / pedir los ficheros de la red etc.; finalmente carga el kernel PV y lo arranca en cadena.
= Configuración =
* Arrancar el domU desde un disco local:
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"
extra = "(hd0,0)/grub/menu.lst"
* Arrancar el domU desde la red:
kernel = "/usr/lib/xen/boot/pv-grub-x86_32.gz"
extra = "(nd)/grub/menu.lst"
Debería configurar el servidor DHCP y TFTP de forma adecuada. Cree ${tftproot}/grub/menu.lst; copie los ficheros necesarios (vmlinuz, intrd, etc.).
= Referencias =
* Xen PVGRUB Howto: http://backdrift.org/xen-pvgrub-howto
* GNU GRUB Manual.
* Xen PXE Boot Howto.
Category:Xen/es
Category:Users/es
Category:Example/es
Category:HowTo/es
Category:Languages/es
QA Procedures

__NOTOC__
= Introduction =
This page provides information about QA procedures of the GPL releases of Xen.
One of the first and currently most important tasks not handled as of yet for this team is taking care of Xen's Bug database, the tasks for this are described on the page BugManagement. Apart from that, if we have more time to invest, there could be many more tasks done (some describedhere), like:
* Adding missing unit tests for the python tools (and checking the code coverage state of the current code)
* Setting up automated test systems for as much functions as possible, and as much different combinations of hardware and software configurations
* ...
There is already some work being done in these areas, but it's not centrally coordinated - as to my knowledge, some businesses run their internal testing farms and regularly tests some areas of the Xen code. All these efforst could be coordinated or at least documented centrally at this page.
= Coordination and other resources =
As of yet, the following pages are available:
* XenTest - Testing Xen regularly and automatically
* BugManagement - tracking and handling bugs and information about them efficiently
* ReportingBugs - how to report bugs
Category:Xen
Category:Development Process
Category:Developers
Category:Index