nyuuzyou/wikis huggingface dataset:
Getting Started with XenRT

== XenRT Installation and Basic Operation ==
These instructions are based upon installation to a Debian Wheezy (7.0) 64-bit
host. Other versions of Debian may work, however they have not been tested.
Please note that XenRT installation will update many OS level settings etc,
and it is recommended that it is installed on a dedicated host (e.g. a VM),
to avoid causing any problems to other services on the host.
Required steps are:
1. Configure sudo to work without a password for your user account
2. Ensure you have contrib and non-free selected in your apt configuration, and source packages available
3. Install essential build packages:
 sudo apt-get install build-essential
4. Create some required directories:
 sudo mkdir -p /local/inputs/windows
 sudo chown -R `id -un`:`id -gn` /local/
5. Extract the tests tarball to create /local/inputs/tests:
 cd /local/inputs
 tar -xzf /path/to/tests.tgz
6. Extract the main xenrt tarball to create ~/xenrt.hg:
 cd ~/
 tar -xzf /path/to/xenrt.tgz
7. Enter xenrt.hg, and copy the sample configuration file:
 cd xenrt.hg
 cp build/config.mk.sample build/config.mk
8. Perform the initial XenRT setup:
 make minsetup
The last step will download lots of required Debian packages (if you are on a
slow connection / don't have a local Debian mirror this may take some time!),
and perform the initial XenRT setup (which includes certain bits of compilation
etc). At one stage you may be asked what method you wish to start the apt-cacher
daemon - choose 'manual'.
If you encounter errors associated with packages, ensure you have followed step
2 and enabled contrib, non-free, and source packages.
You can test that the XenRT installation has succeeded by trying to get a XenRT
shell - this is done by running "xrt -V --shell" - after some verbose log text
and a note about no target being specified, you should find a shell prompt that
looks like:
XenRT interactive Python shell.
>>> 
Exit this prompt by pressing ctrl-D.
You are now ready to run your first test - for simplicity we will assume you
have an existing machine with XenServer installed (while XenRT is able to
install machines, this requires more advanced setup which will be documented
elsewhere). While most tests require configuration for guest operating systems,
for now we are going to choose a simple test that retrieves a system status
report from the host.
The host you are using will need to be configured with the root password
'xensource' for this test (the configuration can be updated to use other
passwords if required).
To execute the test, create a new directory to hold the results and run:
xrt -V --existing <ip of host> --testcase xenserver.tc.host.TC6859
This will:
 - Connect to the host
 - Identify the version of XenServer in use
 - Copy over some required scripts to the host
 - Run the test
 - Collect logs from the host
 - Report the results
Log files will be put into a subdirectory called logs
Category:XenRT
GlusterFS

From the GlusterFS documentation:
GlusterFS is an open source, distributed file system capable of scaling to several petabytes (actually, 72 brontobytes!) and handling thousands of clients. GlusterFS clusters together storage building blocks over Infiniband RDMA or TCP/IP interconnect, aggregating disk and memory resources and managing data in a single global namespace. GlusterFS is based on a stackable user space design and can deliver exceptional performance for diverse workloads.
The GlusterFS is a popular filesystem which can be used with Xen Project.
== USING GLUSTERFS ==
The currently recommended way of employing GlusterFS with Xen Project software is as an iSCSI target. This information comes from discussions with members of the Gluster community. It requires no special drivers in either project as the GlusterFS filesystem will be presented as a standard iSCSI device.
A tighter coupling of the projects would probably be of interest to some members of the Xen Project community. So if you are interested in doing same, let us know.
== DOCUMENTATION ==
* Gluster Wikipedia entry
== HOWTOs ==
* Setting up a GlusterFS filesystem as an iSCSI target (article was recommended by Gluster community member)
Category:GlusterFS
Category:Integration
Grant Table

==General Idea==
Interface for granting foreign access to page frames, and receiving page-ownership transfer. Now there are two versions of grant table ABI. Version 1 is maintained for backward compatibility. New guests should use version 2.
Xen's grant tables provide a generic mechanism to memory sharing between domains. This shared memory interface underpins the split device drivers for block and network IO.
Each domain has its own grant table. This is a data structure that is shared with Xen; it allows the domain to tell Xen what kind of permissions other domains have on its pages. Entries in the grant table are identified by grant references. A grant reference is an integer, which indexes into the grant table. It acts as a capability which the grantee can use to perform operations on the granter’s memory. 
This capability-based system allows shared-memory communications between unprivileged domains. A grant reference also encapsulates the details of a shared page, removing the need for a domain to know the real machine address of a page it is sharing. This makes it possible to share memory correctly with domains running in fully virtualised memory.
==Reference Implementation==
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/xen/grant-table.c?id=HEAD
For complete and up-to-date information, please refer to Xen header file include/public/grant_table.h. The content of this page is taken from that header file and slightly modified.
Category:Xen
Category:Developers
Category:Design Document
Guest VM Images

== Guest Virtual Machine Images ==
=== OrionVM PV-HVM Templates ===
OrionVM has made available a library of guest images ready to boot on Xen Project 4.X+ hypervisors and pv-ops dom0.
These images are compatible with the example Debian 6 dom0 in the Xen Beginners Guide.
OrionVM Mirror
=== Aurélien Jarno's Debian Images ===
Aurélien Jarno provides qcow2 formatted installations of Debian which can be used with the Xen Project hypervisor.
http://people.debian.org/~aurel32/qemu/
== Historical Sites ==
Below are references for historical interest only. They currently do not work.
=== Stacklet.com ===
Unable to reach or ping as of 1/10/2024. 
 
Stacklet.com provided a large array of PV guest images for download. One was able to download a sparse image of various flavor of Linux at no charge, then the site when to a subscription model.
Subscription was $10/month. As of January, 2024, the site is no longer accessible, though the domain is still registered.
 
Category:Guest Install
Category:Xen
Category:Users
Category:Beginners
Category:RefToExternalArticle
Category:Fundamentals
HVM timeoffsets

== Time(zone) support for Windows guests ==
=== Introduction ===
This is a brief overview of the components involved in telling the time to
Windows HVM guests with PV drivers.
=== Overview ===
Windows handles all time localisation by setting its hardware clock rather than
keeping hold of and using an offset on the RTC. So if you change the time,
Windows will update the RTC. The same is true if you change timezone.
Although QEMU is used for the device model, the RTC is emulated by Xen
directly. However, since Xen does not interact with XenStore, QEMU does play
a part in communicating the timeoffset to the toolstack so it can be persisted.
The timeoffset for the VM is stored in XenStore at
/vm/<uuid>/rtc/timeoffset.
=== VM start of day ===
# xapi: receives VM.start API call
## xapi: Create domain via libxc (xc_domain_create)
## xapi: write timeoffset from VM record to XenStore (Domain.build_hvm)
## xapi: start qemu (Device.Dm.start)
### qemu: read timeoffset from XenStore (xen_init_fv)
### qemu: update domain time via libxc (xc_domain_set_time_offset)
=== Handling in-guest clock changes ===
# guest: Set clock within guest (e.g. change timezone)
## xen: Handle write to hardware clock (rtc_ioport_write)
## xen: signal qemu via the timeoffset ioreq
### qemu: update cached timeoffset (__handle_io_req)
### qemu: write the value to XenStore (privsep_set_rtc_timeoffset)
=== Suspend/resume ===
This has the added complication that, along with the the same steps in
#VM tart of day the Windows guest agent comes into play. This is because
Windows wouldn't bother to read the time again from the RTC without
provokation. The guest agent makes a hypercall to read XenTime and compares
this with the guest's localtime and makes adjustments where necessary, setting
the RTC through the Win32 API.
Care has now been taken to stop the .NET libraries caching the localisation
settings which has caused problems with handling timezones across
suspend/resume/migrate since the update of the RTC will trigger the steps in
#Handling in-guest clock changes
Category:Xen
Category:Overview
Category:Developers
Hackathon and Dev Meetings

The aim of Xen Project Hackathons and Xen Project Developer Meetings is to give developers the opportunity to meet face to face to discuss development, coordinate, write code and collaborate with other developers as well as allowing everyone to put names with faces. People working on documentation and other aspects of Xen Project, XAPI, Mirage OS and related projects are also welcome.
 
* We aim to have one Hackathon and one Developer meeting per year and aim to have these on different continents
* Hackathons are always 2 day events, that follow a conference format. They are hosted by a vendor in the Xen Project community
* Developer Meetings are 1/2 day events that are co-located with the Xen Project Developer Summit (before or after)
== Design Session Notes ==
* Archived/XDDS/May2021
== Meeting to discuss process changes to enable safety certification for Xen Project Software ==
This is a special meeting discussing community process changes to enable and make safety certification for Xen Project Software cheaper
* Developer_Meeting/March2019
== Recent Hackathons and Developer Meetings ==
* Archived/Hackathon/April2016
* Archived/Developer Meeting/Aug2015-BoFs
* Archived/Developer Meeting/Aug2015
* Archived/Hackathon/April2015
* Archived/Hackathon/May2014
* Archived/Developer Meeting/Oct2013
* Archived/Hackathon/May2013
* Archived/Developer Meeting/Aug2012
* Archived/Hackathon/March2012
== Hackathon Session Notes ==
=== April 2015 [Hackathon Minutes] ===
* Xen Project Maintenance Stable Release Cadence (proposal)
* Xen Project Release Versioning (proposal)
* xSplice Design (RFC)
thumb|left|width=250px|Group picture from the Hackathon
=== May 2014 [Hackathon Minutes] ===
* EFI + GRUB2 + Xen
* libvirt support for Xen 
* Linux
* Xen/ARM
* CentOS
* IO NUMA
* VirtIO and Xen
* benchmarks
* new PV drivers
* netback
* oVirt
=== May 2013 [Hackathon Minutes] ===
* Xen Hackathon XAPI Process Discussion Notes
* PV block improvements
* Credit 2
* PV network improvements
* Xen and UEFI support
* PV frontends/backends and NUMA machines
* Xen 4.4 Planning
== Ideas for Hackathon locations ==
* Suggestion here
Category:Developers
Category:Events
Category:Community Meetings
Category:Design Sessions
HiKey

= Xen ARM64 on 96boards HiKey =
Xen is now supported upstream on the 96boards HiKey, however beware that to run Xen on HiKey you need the 96Boards UART Serial Adapter, available here. Given that the board doesn't come with an ethernet interface, a USB ethernet adapter is also recommended.
= Building Xen =
Make sure to build a version of Xen which is new enough to support PSCI 1.0, which was added during the 4.7 development window by 2831f2099b6175384817d7afd952f7918998b39a.
No other special requirements are needed.
= Building Linux =
HiKey support is not upstream in Linux. The Linux tree with HiKey support provided by 96boards is on github.
At the time of writing this article, 96boards.org recommends the usage of tag "96boards-hikey-15.11", which is based on Linux 3.18. However Linux 3.18 doesn't work very well on Xen on this board, I recommend using a newer branch, like android-hikey-linaro-4.1. Use this kernel config for Dom0, which is based on the default kernel config with a few options removed.
= Installation =
The best way to use your HiKey board is by installing your Linux rootfs on an external microSD card. HiKey comes with UEFI firmware and by default it will look into the external SD card first. For example you could dd a CentOS 7 ARM64 rootfs to the microSD. CentOS 7 supports UEFI booting which is helpful.
Unfortunately changing the UEFI boot entries permanently is not easy on the HiKey at the moment, but it is possible to use Xen as bootloader or boot Linux directly using the startup.nsh UEFI script.
Copy the Linux Image file to the FAT partition on the microSD card. Then write the following lines to a file called startup.nsh:
 FS0:
 Image console=ttyAMA3,115200 root=/dev/mmcblk1p4 rootwait rw efi=noruntime
The root device here is the one of a CentOS 7 installation.
Copy xen.efi to the FAT partition on the microSD card. Write the following lines to a file called xen.cfg:
 options=console=dtuart dom0_mem=512M dom0_max_vcpus=4 conswitch=x dtuart=/smb/uart@f7113000
 kernel=Image console=hvc0 root=/dev/mmcblk1p4 rootwait rw
Be careful that on some device trees the uart path is /soc/uart@f7113000 instead of /smb/uart@f7113000.
The next time you boot the board, type 4 to get into the UEFI shell, then if you just wait for the timeout to run out, Linux will boot by default. Otherwise if you want to boot xen, just type the ESC key, then type xen.
= Known Issues =
* The UEFI firmware on the HiKey is not able to pick up USB drives at boot, so even if you install your Linux system on a USB drive, you still need to copy the Linux and Xen binaries to the FAT partition of the SD card.
* Having a USB ethernet adapter plugged at boot crashes the kernel sometimes. If you see this problem reboot without ethernet adapter and plug it in later.
* There is no support for UHS SD cards
HolidayCalendar

This page contains a calendar with known public holidays. It is used as an information resource by the Xen Project Security Team, and by other Xen Project community members, to try to help with the scheduling of vulnerability disclosures.
(See the Xen Project Security Policy, http://www.xenproject.org/security-policy.html, for background.)
Note that disclosure schedules are determined by the discoverers of vulnerabilities who do not need to follow the guidelines in the Xen Project policy. Where discoverers ask the Xen Project Security Team for advice, or choose to follow the policy, the holiday information here is advisory only. Because the policy requires us to consider other factors too, we cannot guarantee to avoid holidays.
=2017=
Month 	Date 	Holiday 	Territories
May 	25 Mon	Victoria Day 	Canada
May 	29 Mon	Spring BH 	UK
July 	1 Sat 	Canada Day 	Canada
July 	4 Tue 	US Independence day 	US
August 	7 Mon 	Civic Holiday 	Canada
August 	7 Mon 	Picnic Day 	Australia (NT)
August 	28 Mon	Summer BH 	UK
September	3 Mon 	Labor Day 	Canada, US
September	25 Mon	Family and Community Day	Australia (ACT)
September	29 Fri	AFL Grand Final Day 	Australia (VIC)
October 	2 Mon 	Labour Day 	Australia
October 	9 Mon 	Thanksgiving 	Canada
November 	7 Tue 	Melbourne Cup Day 	Australia (VIC)
November 	11 Sat	Rememberance Day 	Canada
November 	23 Thu	Thanksgiving 	US
December 	25 Mon	Christmas Day 	UK; many others
December 	26 Tue	Boxing Day 	UK
=2018=
We will send out a call for contributions to the 2018 calendar, some time around September 2017.
Category:Security
How to Install a FreeBSD domU on a Linux Host

__NOTOC__
The FreeBSD wiki describes the current state of the FreeBSD xen port(s).
FreeBSD will run in 3 configurations:
# 32-bit PV (kernel "XEN"; requires "PAE" option)
# 64-bit HVM with PV drivers (kernel "XENHVM")
# 32- or 64-bit HVM without PV drivers (kernel "GENERIC")
For instructions on building user-space xenstore tools, see HOWTO-xen-tools.txt.
For instructions on building and installing a "XENHVM" kernel on XCP, see this blog post.
= FreeBSD 7.2 domU on a linux dom0 =
It is fairly straightforward to create a FreeBSD DOMU virtual machine inside a linux DOM0.
Here's a sample configuration file. This is set to boot an ISO image file of freebsd7.2, which the author happened to need in order to create a development environment for pfSense firewall.
<nowiki>
import os, re
arch = os.uname()[4]
if re.search('64', arch):
 arch_libdir = 'lib64'
else:
 arch_libdir = 'lib'
kernel = "/usr/lib/xen-4.0/boot/hvmloader"
builder = 'hvm'
memory = 768
vcpus = 1
name = "xenfreebsd"
vif = [ 'type=ioemu, bridge=eth0' ]
acpi = 1
apic = 1
disk = [ 'phy:/dev/xen/xen4-freebsd72-00,hda,w', 'file:/home/download/freebsd-7.2-RELEASE-i386-dvd1.iso,hdc:cdrom,r' ]
device_model = '/usr/' + arch_libdir + '/xen-4.0/bin/qemu-dm'
usbdevice='tablet'
# boot on floppy (a), hard disk (c) or CD-ROM (d)
boot='d'
# use vnc for console not sdl, don't start vnc console
vnc=1
sdl=0
vncconsole=0
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
</nowiki>
The main change required will be to fix the paths to the CD or DVD iso.
Once started with xm create, use "vncviewer localhost:0" to attach to the installer and complete the process.
It may be necessary to use ssh forwarding if the xen server isn't your local machine; e.g. "ssh -L5900:127.0.0.1:myxenhost.example.com" and then "vncviewer localhost:0".
----
The information below is quite out of date and has been kept for reference purposes only. Most of the links are also broken!
----
Category:Users
Category:HowTo
Category:Guest Install
Category:FreeBSD
Hyper

This guide is a step-by-step procedure on how to setup Hyper on Linux, with Xen Project Hypervisor. The complete documentation, with installation instructions for other platforms, can be found on Hyper's official documentation.
= What is Hyper? =
Hyper is a set of Linux kernel, init process and management tools, able to virtualize containers to improve their isolation and management in case of multi-tenant applications, eliminating the need of guest OS and all the components it brings. Hyper provides safe and fast isolated environments (virtual machines), on which portable environments (containers) can be easily scheduled.
= Prerequisite =
* QEMU 2.0 (or later)
* Docker 1.5 (or later)
* Xen Project 4.5 (or later)
= Download & Installation =
If you want to follow the recommended automated procedure to install Hyper, please follow the further instructions.
Otherwise, if you wish to compile (or view) Hyper's sources code, please go to Hyper's Github repository. Installation instructions are available on the following page.
To setup Hyper using Xen Project Hypervisor, please use the following command:
# curl -sSL https://hyper.sh/install-xen | bash
Please note that the current version supports the following Linux distro:
*Ubuntu 64bit
**15.04 Vivid
**14.10 Utopic
**14.04 Trusty
*CentOS 64bit
**7.0
**6.x (upgrade to QEMU 2.0)
*Fedora 20-22 64bit
*Debian 64bit
**8.0 jessie
**7.x wheezy (upgrade to QEMU 2.0)
= Usage =
This is an example of how to run a `Ubuntu` container image using Hyper. For more details about Hyper's CLI usage, please refer to this page.
== Start/Stop HyperD daemon ==
You can `start` hyperd daemon with the following command
# service hyperd start
You can `stop` hyperd daemon with the following command
# service hyperd stop
== List running Pods ==
For more details about what is a Pod, please refer to this page.
You can `list` running pods with the following command
# hyper list [pod|vm|container]
== Pull container image ==
You can `pull` a container image with the following command
# hyper pull ubuntu
== Run a container (Pod) ==
You can `run` a pod with the following command
# hyper run ubuntu
== Stop/Remove Pod ==
You can `stop` a Pod with the following command
# hyper stop POD_ID
You can `remove` a Pod with the following command
# hyper rm POD_ID
== Display help ==
If you need further assistance, you can display Hyper's `help` with the following command
# hyper [COMMAND] -h
note: COMMAND argument is listed in the generic help.
= References =
*Hyper official website: https://hyper.sh
*Hyper official documentation: https://docs.hyper.sh/index.html
*Hyper official CLI documentation: https://docs.hyper.sh/reference/cli.html
*Hyper official Github repository: https://github.com/hyperhq/hyper
*Article about Hyper, containers and guest OS: https://hyper.sh/blog/post/2015/06/29/docker-hyper-and-the-end-of-guest-os.html
*Article about what is Hyper, and how it works: http://thenewstack.io/hyper-a-hypervisor-agnostic-docker-engine
Category:Integration
Hypercall

__NOTOC__
A hypercall is to a syscall what a hypervisor is to an OS. Alternatively, a hypercall is to a hypervisor what a syscall is to a kernel. A hypercall is a software trap from a domain to the hypervisor, just as a syscall is a software trap from an application to the kernel. Domains will use hypercalls to request privileged operations like updating pagetables. Like a syscall, the hypercall is synchronous, but the return path from the hypervisor to the domain uses event channels. An event channel is a queue of asynchronous notifications, and notify of the same sorts of events that interrupts notify on native hardware. When a domain with pending events in its queue is scheduled, the OS's event-callback handler is called to take appropriate action.
See xen/include/public/xen.h in the Xen sources and the
Xen hypercall interface documentation
Category:Xen
Category:Glossary