nyuuzyou/wikis huggingface dataset:
Xen VGA Passthrough to Windows 8 with Xen 4.2-unstable

It shows:
* Xen VGA Passthrough
* to a Windows 8 Consumer Preview HVM Virtual Machine
* with Xen 4.2-unstable Changeset 25099 and Linux Kernel 3.3.0 in Ubuntu 11.10 oneiric ocelot amd64 Final Release Dom0
----
Download link for PDF document: Xen VGA Passthrough
----
Category:Xen
Category:PVOPS
Category:Beginners
Category:Users
Category:Developers
Category:HowTo
Category:Tutorial
Category:Example
Category:VGA
Xen VGA Passthrough with NVIDIA and Intel IGD Display Adapters

It shows:
* Xen VGA Passthrough
* to a Windows 8 Consumer Preview HVM Virtual Machine
* with Xen 4.2-unstable Changeset 25099 and Linux Kernel 3.3.0 in Ubuntu 11.10 oneiric ocelot amd64 Final Release Dom0
----
Download link for PDF document: Xen VGA Passthrough
----
Category:Xen
Category:PVOPS
Category:Beginners
Category:Users
Category:Developers
Category:HowTo
Category:Tutorial
Category:Example
Category:VGA
Xen Windows GplPv/XenVbd

__NOTOC__
== About ==
xenvbd is the driver that interfaces between the Windows scsiport miniport driver and the Linux blockback driver.
=== scsiport ===
Almost all of the Windows scsiport code runs at a very high IRQL, and there is a long list of things that cannot be done at a high IRQL. The main things are spinlocks, memory allocation, and waiting for events. scsiport makes sure that all the code is properly synchronised so spinlocks aren't a problem, and xenpci takes care of all the xenbus stuff so waiting for events isn't a problem. Not being able to allocate memory is a huge pain though.
=== x32 vs x64 ===
Because of some alignment issues, the block front/back ring structure is different between 32 and 64 bit environments. This is a problem if Dom0 is one and DomU is the other. Later versions of xen (3.2+ I think) take care of this by publishing the abi used in xenbus and adjusting accordingly. My Dom0 is Debian which at the time or writing has blockback code which predates this. To get around this we put a few requests on the ring and see what they look like when they come back. If our alignment is wrong we switch ring configurations on the fly. It's messy, but it works.
=== Unaligned buffers ===
xenvbd only allows buffers aligned on a 512 byte (sector size) boundary. Windows doesn't have this limitation, so will hand xenvbd buffers on almost any alignment, but only sometimes. Almost all of the time the buffers are 512 bytes in size, rarely they are up to 4096 bytes in size, very rarely they are up to 8192 bytes in size, and even more rarely they are more than that (I've only seen it when Windows does a chkdsk on boot).
Unfortunately we can't allocate bounce buffers on the fly, so to get around this we tell windows we want a per-SRB (Windows SCSI request structure) buffer of 4096 bytes, and pass that to blockback, and copy the data to the buffer (on write) or from the buffer (on read). If windows wants to transfer more than that we have to go through the SRB multiple times. This is slower, but should happen rarely enough that performance it isn't a problem.
Category:Xen
Category:Users
Category:Windows PV Drivers
Xen and Intel Hardware-Assisted Virtualization Security

== Intel Software Guard Extensions (SGX) - Secure Enclave ==
 - Preliminary patches
 - ITL thoughts on SGX: part1 · part2 (2013)
 - Intel slides · video (2017)
== Intel Trusted Execution Technology (TXT) - DRTM ==
 - Intel Verifying the Xen launch (2007)
 - Intel White paper (2012) · Lab handout (2010) · Book (2009)
 - Qubes Anti Evil Maid (2011)
 - Secure policy engine in hypervisor (2015)
 - TXT measured launch with TPM 2.0 and OTA update (2017)
Xen based Products with a Safety Angle

=== Products with a degree of Safety Certification ===
* DornerWorks Virtuosity
=== Automotive Products ===
* EPAM xen-troops
* Global Logic Nautilus
=== Embedded/Other Products ===
* OpenXT
* Star Lab Crucible
* Xilinx
* DornerWorks Virtuosity for i.MX 8
=== Contributor Spotlights ===
* GlobalLogic
* DornerWorks
* StarLabs
* Stefano Stabellini
Category:Safety_Certification
Category:Embedded and Automotive
Category:XenARM
Xen in Qubes OS Security Architecture

This document describes the architecture of Qubes OS an open source operating system designed to provide strong security for desktop computing. Qubes is based on Xen, X Window System, and Linux, and can run most Linux applications and utilize most of the Linux drivers. In the future it might also run Windows apps. 
Section 3 of this document contains a discussion of the security of the Xen hypervisor as well as KVM. For your convenience, we outlined the content of this section here 
3. The hypervisor and the administrative domain
* The role of the hypervisor
* Xen vs. KVM security architecture comparison
** The thin vs. fat hypervisor argument
** The I/O Emulation vs. PV drivers
** Driver domains support
** Summary
* Securing the hypervisor
** Formal security proofs?
** Reducing hypervisor footprint
** Anti-exploitation mechanisms in the hypervisor
** Reducing Inter-VM covert channels
* The administrative domain (Dom0)
* Power management and ACPI support
** ACPI security concerns
** Preventing ACPI abusing attacks
Category:Xen
Category:Security
Category:RefToExternalArticle
Xen network TODO

This is a list of open work items for Xen network project.
These items are mostly Linux specific. If you need help developing for other OSes, don't hesitate to email Xen-devel with your questions.
== In progress ==
New baseline for Xen network
* split event channels (done)
* kthread + NAPI 1:1 model (done)
After switching to new baseline, you can get better scheduling fairness among vifs, mitigate interrupts to some extend, and have better aggregated throughput.
But please also note that you would need irqbalance to run in Dom0 (or your backend driver domain), otherwise you might get worse performance than before.
Unfortunately most in stock irqbalance would not work in Dom0 as it doesn't classify xen-dyn-event properly, you would need compile from the latest irqbalance master branch.
== Open Work Items ==
Xen on ARM Early Printk

= Introduction =
Early printk can only be enabled if CONFIG_DEBUG=y or in EXPERT mode. You may want to enable it if you are debugging code that executes before the console is initialized.
Note that selecting this option will limit Xen to a single UART definition. Attempting to boot Xen image on a different platform will not work, so this option should not be enable for Xens that are intended to be portable.
== How to enable early printk ==
Select one of the Early printk via UART in the choice possible for Early printk in the Debugging options of Kconfig. You will then need to set other options, which depends on the driver selected.
For more information refer: xen.git:docs/misc/arm/early-printk.txt
=== Platform predefined configurations ===
When in doubt, you can refer to the following list of predefined platform configurations for the early printk.
==== CONFIG_EARLY_UART_BASE_ADDRESS ====
Platform 	Address
Early printk with 8250 on Broadcom 7445D0 boards with A15 processors	0xf040ab00
Early printk with 8250 on DRA7 platform 	0x4806a000
Early printk with the second UART on Exynos5250 	0x12c20000
Early printk with pl011 on ARM Fastmodel software emulators 	0x1c090000
Early printk with pl011 with Hikey 960 	0xfff32000
Early printk with pl011 on Juno platform 	0x7ff80000
Early printk with SCIF0 on Renesas Lager board (R-Car H2 processor) 	0xe6e60000
Early printk with pl011 on Calxeda Midway processors 	0xfff36000
Early printk with MVEBU for Marvell Armada 3700 SoCs 	0xd0012000
Early printk with UART3 on TI OMAP5432 processors 	0x48020000
Early printk with SCIF2 on Renesas R-Car Gen3 processors 	0xe6e88000
Early printk with pl011 for AMD Seattle processor 	0xe1010000
Early printk with 8250 on Allwinner A31 processors 	0x01c28000
Early printk with 8250 on Allwinner A20 processors 	0x01c28000
Early printk with pl011 for Cavium ThunderX processor 	0x87e024000000
Early printk with pl011 for versatile express 	0x1c090000
Early printk with 820 on Xgene mcdivitt platform 	0x1c021000
Early printk with 820 on Xgene storm platform 	0x1c020000
Early printk with Cadence UART for Xilinx ZynqMP SoCs 	0xff000000
==== EARLY_UART_PL011_BAUD_RATE ====
Platform 	Baud rate
Early printk with pl011 on ARM Fastmodel software emulators	115200
==== EARLY_UART_8250_REG_SHIFT ====
Platform 	Shift
Early printk with 8250 on Broadcom 7445D0 boards with A15 processors	2
Early printk with 8250 on DRA7 platform 	2
Early printk with UART3 on TI OMAP5432 processors 	2
Early printk with 8250 on Allwinner A31 processors 	2
Early printk with 8250 on Allwinner A20 processors 	2
Early printk with 820 on Xgene mcdivitt platform 	2
Early printk with 820 on Xgene storm platform 	2
Category:XenARM
XenoBoot

__NOTOC__
XenoBoot is the system we use at the University of Cambridge to remotely control the boot process of x86 machines over the Internet. In a secure manner suitable for use on public networks, you can use it to:
* select which OS or kernel to boot
* download and boot a kernel and/or root image
* reinstall or repair the system automatically or interactively
* administer the system
The system is flexible: it can boot pretty much any type of kernel and can understand and administer most types of file system. It is also relatively failsafe: it can recover the system even if the hard disk is corrupted. This safety is achieved by using a bootable CD image, which (being read-only) should survive and remain bootable in any circumstances as long as the hardware and BIOS are still functional. This CD loads Linux and then fetches a script from a central server. The script has access to utilities and applications on the CD, and can be easily adapted to fit each individual machine and the current circumstances.
XenoBoot removes the need to use serial console servers for system administration as it can all be done over a secure network connection. For resetting wedged machines we use a combination of hardware watchdogs and remote power control switches.
XenoBoot is released under the GPL and can be downloaded from http://www.cl.cam.ac.uk/Research/SRG/netos/xeno/xenoboot/
Category:Xen
Category:Glossary
Xenpm command

== xenpm ==
Xenpm is a userspace tool that can list the power information of available processors and control the power policy according to users' preference. Its name stands for Xen Power Management(xenpm for short).
xenpm usage is as follow
<nowiki>
usage: xenpm <command> [args]
xenpm command list:
 get-cpuidle-states [cpuid] list cpu idle info of CPU <cpuid> or all
 get-cpufreq-states [cpuid] list cpu freq info of CPU <cpuid> or all
 get-cpufreq-para [cpuid] list cpu freq parameter of CPU <cpuid> or all
 set-scaling-maxfreq [cpuid] <HZ> set max cpu frequency <HZ> on CPU <cpuid>
 or all CPUs
 set-scaling-minfreq [cpuid] <HZ> set min cpu frequency <HZ> on CPU <cpuid>
 or all CPUs
 set-scaling-speed [cpuid] <num> set scaling speed on CPU <cpuid> or all
 it is used in userspace governor.
 set-scaling-governor [cpuid] <gov> set scaling governor on CPU <cpuid> or all
 as userspace/performance/powersave/ondemand
 set-sampling-rate [cpuid] <num> set sampling rate on CPU <cpuid> or all
 it is used in ondemand governor.
 set-up-threshold [cpuid] <num> set up threshold on CPU <cpuid> or all
 it is used in ondemand governor.
 get-cpu-topology get thread/core/socket topology info
 set-sched-smt enable|disable enable/disable scheduler smt power saving
 set-vcpu-migration-delay <num> set scheduler vcpu migration delay in us
 get-vcpu-migration-delay get scheduler vcpu migration delay
 set-max-cstate <num> set the C-State limitation (<num> >= 0)
 start [seconds] start collect Cx/Px statistics,
 output after CTRL-C or SIGINT or several seconds.
 enable-turbo-mode [cpuid] enable Turbo Mode for processors that support it.
 disable-turbo-mode [cpuid] disable Turbo Mode for processors that support it.
</nowiki>
basically it has following functions:
# Show C-state status with sub-command "get-cpuidle-states"
# Show P-state status with sub-command "get-cpufreq-states"
# Control cpufreq parameter, with sub-command "get-cpufreq-para", "set-scaling-maxfreq", "set-scaling-minfreq", "set-scaling-speed", "set-scaling-governor", "set-sampling-rate", "set-up-threshold"
# Get / set vcpu migration delay
# Set max C-state limitaton
# Sampling C/P state status in specified period, with sub-command "start"
# Enable / Disable turbo mode
the first three functions have already been illustrated in the previous cpufreq and cpuidle section, the fourth function aims to provide a overall picture of PM activity in specified period. For example, the follow command measure the C/P activity in 5 minutes
<nowiki>
# xenpm start & sleep 5; killall -s SIGINT xenpm
Elapsed time (ms): 5028
CPU0:
 residency percentage
 C0 59 ms 1.18%
 C1 0 ms 0.00%
 C2 56 ms 1.13%
 C3 4912 ms 97.69%
 P0 0 ms 0.00%
 P1 0 ms 0.00%
 P2 0 ms 0.00%
 P3 7 ms 100.00%
CPU1:
 residency percentage
 C0 118 ms 2.36%
 C1 0 ms 0.00%
 C2 36 ms 0.73%
 C3 4873 ms 96.91%
 P0 0 ms 0.00%
 P1 0 ms 0.00%
 P2 0 ms 0.00%
 P3 63 ms 100.00%
</nowiki>
== Also see ==
* Xen power management
* Figuring out cpu topology in Xen / Oracle VM 
Category:RefToExternalArticle
Category:Beginners
Category:Users
Category:ManPage
Category:Xen
Xenstored

== xenstored ==
Xen uses a xenstore daemon to allow dom0 and guests get access to information about configuration space for itself and the system. Xen currently supports two versions of the daemons:
 * cxenstored
 * oxenstored
Most solutions today are shipping with only cxenstored, but there are optimizations that were done on oxenstored which should be considered by users who want to scale xen with a large set of hosts. For more details see the information below. Communication to the xenstored can happen through unix domain sockets or through the kernel ring interface, both of which are documented below.
=== The xenstore ===
The XenStore is initialized and maintained xenstored. Go read more details at these two pages:
 * XenStore
 * XenStoreReference
=== xenstored unix sockets ===
Systems which enable unix sockets (non stubdom solutions, and not on the mini OS) get two Unix domain sockets created which enable userspace to communicate with the xenstored. The Unix sockets are created by the xenstored. There are two unix sockets:
 * /var/run/xenstored/socket
 * /var/run/xenstored/socket_ro
=== xenstored kernel ring interface ===
The xenstored kernel ring interace is used by guests as they cannot get access to the unix domain sockets on dom0, instead they use the xenbus for communication with the xenstored. This sections needs some more love.
=== xenstored systemd support ===
Support for systemd is under development. This section will be expanded once the reference implementation is merged upstream.
== cxenstored ==
The cxenstored was the original implementation for the xenstored, it is written in C. The code lives under tools/xenstore/.
== oxenstored ==
The oxenstored is the next generation xenstored and it is written in Ocaml. The code lives under tools/ocaml/xenstore/.
Xentop(1)

== NAME ==
xentop - displays real-time information about a Xen system. It is shipped with xen tools.
== SYNOPSIS ==
xentop [-h] [-V] [-dSECONDS] [-n] [-r] [-x] [-v] [-f] [-b] [-iITERATIONS]
== DESCRIPTION ==
xentop displays information about the Xen system and domain in an ongoing manner in real time. Command-line options and interactive commands can change the information displayed, as well as the level of detail shown.
File:Xentop.png|Screenshot of xentop output
== OPTIONS ==
-h, --help
Show help and exit 
-V, --version
Show version information and exit 
-d, --delay=SECONDS
Seconds between updates (default 3) 
-n, --networks
Show network information 
-x, --vbds
Show vbd block device data 
-r, --repeat-header
Repeat table header before each domain 
-v, --vcpus
Show VCPU data 
-f, --full-name
output the full domain name (not truncated)
-b, --batch
Redirect output data to stdout (batch mode) 
-i, --iterations=ITERATIONS
Maximum number of updates that xentop should produce before ending
== INTERACTIVE COMMANDS ==
All interactive commands are case-insensitive.
D
Set delay between updates 
N
Toggle display of network information 
Q, Esc
Quit 
R
Toggle table header before each domain 
S
Cycle sort order 
V
Toggle display of VCPU information 
Arrows
Scroll domain display
== BUGS ==
Send bugs to xen-devel@lists.xen.org, see http://wiki.xen.org/xenwiki/ReportingBugs on how to send bug reports.
Category:Xen
Category:ManPage
Category:Manual
Category:Beginners
Category:Users
Xentrace

But what we want in upstream is something that will help
us in production. For that to be useful, we need the logging to be as
efficient as possible. Every additional HVM trace point potentially
adds more data to someone else's HVM trace. So we don't want
extraneous information, and we don't want to log something that we can
infer from something else.
In general, it's enough to give information about the decisions that
Xen is making to infer what the previous state is; and then giving
information about what Xen did in response (i.e., return values,
injection of traps, &c) to help figure out how the guest responded.
Youtube Video Xen VGA Passthrough to Windows 8 Consumer Preview HVM Virtual Machine with Xen 4.2-unstable Changeset 25099 and Linux Kernel 3.3.0 in Ubuntu 11.10 oneiric ocelot amd64 Final Release Dom0

#REDIRECT Video: Xen VGA Passthrough to Windows 8 Consumer Preview HVM Virtual Machine with Xen 4.2-unstable Changeset 25099 and Linux Kernel 3.3.0 in Ubuntu 11.10 oneiric ocelot amd64 Final Release Dom0
Hok (Species)

Summary: (WIP)
The Hok were a reptilian-mammalian humanoid species that developed into sentience early on in history, but sadly remained as small close-knit tribes instead of developing into technologically advanced nations. This made it easier for the Sith Empire to enslave the species as a whole.
Appearance: (WIP, done-ish.)
The Hok were a cross of reptilian and mammalian, possessing scales of a standard grayish-white color, but possessed on top of the scales a thin layer of hair. This hair could be variety of colors, the most common being brown, red, and yellow (this later evolved into a hair color-based class system, which would even later evolve into the updated castes of the Golden Empire). They possessed short, stubby, pig-like snouts and some male Hok grew tusks. Eye color varied between two colors, depending on the side of the planet the individual Hok was born on. Hok born on the desert side generally had red eyes, while Hok born in the dark, crystalline side generally had blue eyes. Hok had different physical traits based on gender and common body chemicals. For example, a Hok male with high levels of testosterone would sometimes grow tusks that protruded towards their snouts in an arch, whilst a female Hok with high levels of estrogen would sometimes grow an extra albeit smaller set of breasts below the first. It was possible for a female Hok to grow tusks, but not possible for a male Hok to grow breasts. Hok generally stood tall, the average being 7'1" tall for males and 6'9" for females. They were mostly heavy-set, either muscular or fat. Skinny Hok were possible, but only as a mutation or due to malnutrition/starvation. Hok lifespans were a little above average, generally living up to 130 years.
Culture and Religion: (Major WIP)
The Hok had a form of tribal government, where a Chief ruled a tribe and all its members. Chiefs were chosen by inheritance at first, the first-born son of a Chief was expected to slaughter his father stealthily, without him knowing. Poison was generally used. This was perfectly legal once the son had reached the age of maturity and was even encouraged. If a boy slaughtered his father with him knowing, he would be known as shameful for the rest of his life. Hok generally worshipped spirits and minor deities, who all answered to a single master deity, Tbadu'ka, the god of night, cunning, and anger. They wore head-dresses and robes made of a silk-like material, bone, wood, and crystals.
Lore

The following is unorganized and should be taken with a grain of salt
The golden empire of Hok was founded several thousand years ago by the Hok, a now extinct humanoid race. It was founded in an era of confusion, when the Sith Empire was temporarily dying out and the Republic didn't even know of it's existence, the Hok, former slaves of the Sith Empire, rose up and defeated their masters, declaring their planet their own Empire.
Several thousand years of simultaneously emulating ancient Sith culture and Hok culture led to what we have today. An elective monarchy.
Nobles rule small pockets of land on the desert planet, these titles either being elected, purchased, or inherited depending on the local laws.
The emperor himself chooses a mononym (for example Xavus Saudelle became Emperor Xooper) and is taught all the knowledge from the former Emperor and former staff before that Emperor commits ritualistic suicide. The Emperor is elected once every hundred years.
There are three "castes" that are not very strict. Workers, priests, and warriors. One may move from caste to caste but it is not very easy. Workers can become warriors very often but it requires force sensitivity and an inherent lust for knowledge to become a priest.
Any member of any caste can become Emperor, Emperor Xooper was once a priest. The former Emperor, Krokel, was a pureblood warrior.
The Emperor is tasked with keeping sacred knowledge as well, he is the only one that has that knowledge and only teaches it rarely or to his successor.
Hok is a melting pot of many races, as many former slaves of the Sith Empire came together on Hok to assist the Hok Empire.
While one side of the planet is covered in sand (this side of the planet is almost always facing the sun, nights last at most two hours) the other side is covered in mineral-rich swampland and is lit only by the moon. The lowest members of Hok society live on that side of the planet. However it is not lawless, it is protected by the warriors just as much as the sandy side.
Force sensitives take a more neutral path on Hok. They don't strictly follow the dark or the light, instead they choose to do what would benefit the Empire and it's people the most.
Droids are given a relative amount of freedom that would not be enjoyed on other planets, as more intelligent droids are allowed citizenship. (Astromech and gonk droids however, are not)
The Golden Empire of Hok is in an alliance with their former masters, the Sith Empire. However, much of the Sith Empire does not know of the existence of Hok.
Later Hok will, a shadow of it's former self defeated by some unknown means by this point, will become a Gran colony. Of course this doesn't happen until a couple hundred years before the Phantom Menace.
Main Page

{| style="width:100%; border:none; background:none;"	
Welcome to WTGC,
the free Where to Go Camping Guide.
 articles in English.	
* BSA Camps
* BSA Camping Events
* BSA Summer Camps	
* Public Camps
* Private Camps
* Camp Programs	
* Location
* Order of the Arrow
* All portals
{| id="mp-left" style="width:100%; vertical-align:top; background:#f5fffa;"	Featured Campground (Updated on Mondays)
Featured Campground (Updated on Wednesdays)	
Featured Campground (Updated on Fridays) 	
{| id="mp-lower" style="margin:4px 0 0 0; width:100%; background:none; border-spacing: 0px;"
| class="MainPageBG" style="width:100%; border:1px solid #ddcef2; background:#faf5ff; vertical-align:top; color:#000;" |
A call for Action!
In order to make this online WTCG guide amazing it needs content. 
Please help make this wiki amazing by submitting content.
__NOTOC____NOEDITSECTION__
Portal:BSA Camping Events

BSA Camping Events refers to all BSA sponsored events that including outdoor activities.
This portal is meant to help organizes these events. 
BSA Camping Events include all BSA events involving the outdoors and is not limited to camping. Summer camps are not included in this portal.
==Events by Council==
===Yankee Clipper Council===
====Council Wide Events====
====Great Eastern District====
====West Wind District====
====Northern Lights District====