xen-project/xen
1
0 Fork 1
mirror of https://github.com/xen-project/xen.git synced 2026-10-29 18:50:05 +01:00
Code Issues Activity

bitkeeper revision 1.1159.1.248 (41770cd3xdqfaxecPtOsPCrCe_NtiA)

Browse Source 
Merge ssh://srg//auto/groups/xeno/BK/xeno-unstable.bk
into equilibrium.research:/export/scratch/xeno-balloon.bk
This commit is contained in:
mwilli2@equilibrium.research committed 2004-10-21 01:11:47 +00:00
2 parents f8e32a93e5 9624295add
commit b0b2ccdf54
4 files changed
+336 -267
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

docs/interface.tex
+186 -145
View File
@@ -51,32 +51,33 @@ operating system images to be run simultaneously.
Virtualizing the machine in this manner provides flexibility allowing
different users to choose their preferred operating system (Windows,
Linux, FreeBSD, or a custom operating system). Furthermore, Xen provides
Linux, NetBSD, or a custom operating system). Furthermore, Xen provides
secure partitioning between these 'domains', and enables better resource
accounting and QoS isolation than can be achieved with a conventional
operating system.
The hypervisor runs directly on server hardware and dynamically partitions
it between a number of {\it domains}, each of which hosts an instance
of a {\it guest operating system}. The hypervisor provides just enough
of a {\it guest operating system}. The hypervisor provides just enough
abstraction of the machine to allow effective isolation and resource
management between these domains.
Xen essentially takes a virtual machine approach as pioneered by IBM VM/370.
However, unlike VM/370 or more recent efforts such as VMWare and Virtual PC,
Xen doesn not attempt to completely virtualize the underlying hardware. Instead
parts of the hosted guest operating systems to work with the hypervisor; the
operating system is effectively ported to a new target architecture, typically
requiring changes in just the machine-dependent code. The user-level API is
unchanged, thus existing binaries and operating system distributions can work
unmodified.
Xen essentially takes a virtual machine approach as pioneered by IBM
VM/370. However, unlike VM/370 or more recent efforts such as VMWare
and Virtual PC, Xen doesn not attempt to completely virtualize the
underlying hardware. Instead parts of the hosted guest operating
systems are modified to work with the hypervisor; the operating system
is effectively ported to a new target architecture, typically
requiring changes in just the machine-dependent code. The user-level
API is unchanged, thus existing binaries and operating system
distributions can work unmodified.
In addition to exporting virtualized instances of CPU, memory, network and
block devicees, Xen exposes a control interface to set how these resources
are shared between the running domains. The control interface is privileged
are shared between the running domains. The control interface is privileged
and may only be accessed by one particular virtual machine: {\it domain0}.
This domain is a required part of any Xen-base server and runs the application
software that manages the control-plane aspects of the platform. Running the
software that manages the control-plane aspects of the platform. Running the
control software in {\it domain0}, distinct from the hypervisor itself, allows
the Xen framework to separate the notions of {\it mechanism} and {\it policy}
within the system.
@@ -84,58 +85,59 @@ within the system.
\chapter{CPU state}
All privileged state must be handled by Xen. The guest OS has no direct access
to CR3 and is not permitted to update privileged bits in EFLAGS.
All privileged state must be handled by Xen. The guest OS has no
direct access to CR3 and is not permitted to update privileged bits in
EFLAGS.
\chapter{Exceptions}
The IDT is virtualised by submitting a virtual 'trap
table' to Xen. Most trap handlers are identical to native x86
handlers. The page-fault handler is a noteable exception.
table' to Xen. Most trap handlers are identical to native x86
handlers. The page-fault handler is a noteable exception.
\chapter{Interrupts and events}
Interrupts are virtualized by mapping them to events, which are delivered
asynchronously to the target domain. A guest OS can map these events onto
asynchronously to the target domain. A guest OS can map these events onto
its standard interrupt dispatch mechanisms, such as a simple vectoring
scheme. Each physical interrupt source controlled by the hypervisor, including
scheme. Each physical interrupt source controlled by the hypervisor, including
network devices, disks, or the timer subsystem, is responsible for identifying
the target for an incoming interrupt and sending an event to that domain.
This demultiplexing mechanism also provides a device-specific mechanism for
event coalescing or hold-off. For example, a guest OS may request to only
event coalescing or hold-off. For example, a guest OS may request to only
actually receive an event after {\it n} packets are queued ready for delivery
to it, {\it t} nanoseconds after the first packet arrived (which ever is true
first). This allows latency and throughput requirements to be addressed on a
first). This allows latency and throughput requirements to be addressed on a
domain-specific basis.
\chapter{Time}
Guest operating systems need to be aware of the passage of real time and their
own ``virtual time'', i.e. the time they have been executing. Furthermore, a
own ``virtual time'', i.e. the time they have been executing. Furthermore, a
notion of time is required in the hypervisor itself for scheduling and the
activities that relate to it. To this end the hypervisor provides for notions
of time: cycle counter time, system time, wall clock time, domain virtual
activities that relate to it. To this end the hypervisor provides for notions
of time: cycle counter time, system time, wall clock time, domain virtual
time.
\section{Cycle counter time}
This provides the finest-grained, free-running time reference, with the
approximate frequency being publicly accessible. The cycle counter time is
used to accurately extrapolate the other time references. On SMP machines
approximate frequency being publicly accessible. The cycle counter time is
used to accurately extrapolate the other time references. On SMP machines
it is currently assumed that the cycle counter time is synchronised between
CPUs. The current x86-based implementation achieves this within inter-CPU
CPUs. The current x86-based implementation achieves this within inter-CPU
communication latencies.
\section{System time}
This is a 64-bit value containing the nanoseconds elapsed since boot
time. Unlike cycle counter time, system time accurately reflects the
time. Unlike cycle counter time, system time accurately reflects the
passage of real time, i.e. it is adjusted several times a second for timer
drift. This is done by running an NTP client in {\it domain0} on behalf of
the machine, feeding updates to the hypervisor. Intermediate values can be
drift. This is done by running an NTP client in {\it domain0} on behalf of
the machine, feeding updates to the hypervisor. Intermediate values can be
extrapolated using the cycle counter.
\section{Wall clock time}
This is the actual ``time of day'' Unix style struct timeval (i.e. seconds and
microseconds since 1 January 1970, adjusted by leap seconds etc.). Again, an
NTP client hosted by {\it domain0} can help maintain this value. To guest
microseconds since 1 January 1970, adjusted by leap seconds etc.). Again, an
NTP client hosted by {\it domain0} can help maintain this value. To guest
operating systems this value will be reported instead of the hardware RTC
clock value and they can use the system time and cycle counter times to start
and remain perfectly in time.
@@ -143,118 +145,136 @@ and remain perfectly in time.
\section{Domain virtual time}
This progresses at the same pace as cycle counter time, but only while a
domain is executing. It stops while a domain is de-scheduled. Therefore the
domain is executing. It stops while a domain is de-scheduled. Therefore the
share of the CPU that a domain receives is indicated by the rate at which
its domain virtual time increases, relative to the rate at which cycle
counter time does so.
\section{Time interface}
Xen exports some timestamps to guest operating systems through their shared
info page. Timestamps are provided for system time and wall-clock time. Xen
info page. Timestamps are provided for system time and wall-clock time. Xen
also provides the cycle counter values at the time of the last update
allowing guests to calculate the current values. The cpu frequency and a
allowing guests to calculate the current values. The cpu frequency and a
scaling factor are provided for guests to convert cycle counter values to
real time. Since all time stamps need to be updated and read
real time. Since all time stamps need to be updated and read
\emph{atomically} two version numbers are also stored in the shared info
page.
Xen will ensure that the time stamps are updated frequently enough to avoid
an overflow of the cycle counter values. Guest can check if its notion of
an overflow of the cycle counter values. A guest can check if its notion of
time is up-to-date by comparing the version numbers.
\section{Timer events}
Xen maintains a periodic timer (currently with a 10ms period) which sends a
timer event to the currently executing domain. This allows Guest OSes to
keep track of the passing of time when executing. The scheduler also
timer event to the currently executing domain. This allows Guest OSes to
keep track of the passing of time when executing. The scheduler also
arranges for a newly activated domain to receive a timer event when
scheduled so that the Guest OS can adjust to the passage of time while it
has been inactive.
In addition, Xen exports a hypercall interface to each domain which allows
them to request a timer event send to them at the specified system
time. Guest OSes may use this timer to implemented timeout values when they
them to request a timer event sent to them at the specified system
time. Guest OSes may use this timer to implement timeout values when they
block.
\chapter{Memory}
The hypervisor is responsible for providing memory to each of the domains running
over it. However, the Xen hypervisor's duty is restricted to managing physical
memory and to policing page table updates. All other memory management functions
are handly externally. Start-of-day issues such as building initial page tables
for a domain, loading its kernel image and so on are done by the {\it domain builder}
running in user-space with {\it domain0}. Paging to disk and swapping is handled
by the guest operating systems themselves, if they need it.
The hypervisor is responsible for providing memory to each of the
domains running over it. However, the Xen hypervisor's duty is
restricted to managing physical memory and to policying page table
updates. All other memory management functions are handled
externally. Start-of-day issues such as building initial page tables
for a domain, loading its kernel image and so on are done by the {\it
domain builder} running in user-space in {\it domain0}. Paging to
disk and swapping is handled by the guest operating systems
themselves, if they need it.
On a Xen-based system, the hypervisor itself runs in {\it ring 0}. It has full
access to the physical memory available in the system and is responsible for
allocating portions of it to the domains. Guest operating systems run in and use
{\it rings 1}, {\it 2} and {\it 3} as they see fit, aside from the fact that
segmentation is used to prevent the guest OS from accessing a portion of the
linear address space that is reserved for use by the hypervisor. This approach
allows transitions between the guest OS and hypervisor without flushing the TLB.
We expect most guest operating systems will use ring 1 for their own operation
and place applications (if they support such a notion) in ring 3.
On a Xen-based system, the hypervisor itself runs in {\it ring 0}. It
has full access to the physical memory available in the system and is
responsible for allocating portions of it to the domains. Guest
operating systems run in and use {\it rings 1}, {\it 2} and {\it 3} as
they see fit, aside from the fact that segmentation is used to prevent
the guest OS from accessing a portion of the linear address space that
is reserved for use by the hypervisor. This approach allows
transitions between the guest OS and hypervisor without flushing the
TLB. We expect most guest operating systems will use ring 1 for their
own operation and place applications (if they support such a notion)
in ring 3.
\section{Physical Memory Allocation}
The hypervisor reserves a small fixed portion of physical memory at system boot
time. This special memory region is located at the beginning of physical memory
and is mapped at the very top of every virtual address space.
The hypervisor reserves a small fixed portion of physical memory at
system boot time. This special memory region is located at the
beginning of physical memory and is mapped at the very top of every
virtual address space.
Any physical memory that is not used directly by the hypervisor is divided into
pages and is available for allocation to domains. The hypervisor tracks which
pages are free and which pages have been allocated to each domain. When a new
pages and is available for allocation to domains. The hypervisor tracks which
pages are free and which pages have been allocated to each domain. When a new
domain is initialized, the hypervisor allocates it pages drawn from the free
list. The amount of memory required by the domain is passed to the hypervisor
list. The amount of memory required by the domain is passed to the hypervisor
as one of the parameters for new domain initialization by the domain builder.
Domains can never be allocated further memory beyond that which was requested
for them on initialization. However, a domain can return pages to the hypervisor
if it discovers that its memory requirements have diminished.
Domains can never be allocated further memory beyond that which was
requested for them on initialization. However, a domain can return
pages to the hypervisor if it discovers that its memory requirements
have diminished.
% put reasons for why pages might be returned here.
\section{Page Table Updates}
In addition to managing physical memory allocation, the hypervisor is also in
charge of performing page table updates on behalf of the domains. This is
charge of performing page table updates on behalf of the domains. This is
neccessary to prevent domains from adding arbitrary mappings to their page
tables or introducing mappings to other's page tables.
\section{Writabel Page Tables}
A domain can also request write access to its page tables. In this
mode, Xen notes write attempts to page table pages and makes the page
temporarily writable. In-use page table pages are also disconnect
from the page directory. The domain can now update entries in these
page table pages without the assistance of Xen. As soon as the
writabel page table pages get used as page table pages, Xen makes the
pages read-only again and revalidates the entries in the pages.
\section{Segment Descriptor Tables}
On boot a guest is supplied with a default GDT, which is {\em not}
taken from its own memory allocation. If the guest wishes to use other
taken from its own memory allocation. If the guest wishes to use other
than the default `flat' ring-1 and ring-3 segments that this default
table provides, it must register a custom GDT and/or LDT with Xen,
allocated from its own memory.
int {\bf set\_gdt}(unsigned long *{\em frame\_list}, int {\em entries})
{\em frame\_list}: An array of up to 16 page frames within which the GDT
resides. Any frame registered as a GDT frame may only be mapped
read-only within the guest's address space (e.g., no writeable
{\em frame\_list}: An array of up to 16 page frames within which the
GDT resides. Any frame registered as a GDT frame may only be mapped
read-only within the guest's address space (e.g., no writable
mappings, no use as a page-table page, and so on).
{\em entries}: The number of descriptor-entry slots in the GDT. Note that
the table must be large enough to contain Xen's reserved entries; thus
we must have '{\em entries $>$ LAST\_RESERVED\_GDT\_ENTRY}'. Note also that,
after registering the GDT, slots {\em FIRST\_} through
{\em LAST\_RESERVED\_GDT\_ENTRY} are no longer usable by the guest and may be
overwritten by Xen.
{\em entries}: The number of descriptor-entry slots in the GDT. Note
that the table must be large enough to contain Xen's reserved entries;
thus we must have '{\em entries $>$ LAST\_RESERVED\_GDT\_ENTRY}'.
Note also that, after registering the GDT, slots {\em FIRST\_} through
{\em LAST\_RESERVED\_GDT\_ENTRY} are no longer usable by the guest and
may be overwritten by Xen.
\section{Pseudo-Physical Memory}
The usual problem of external fragmentation means that a domain is unlikely to
receive a contiguous stretch of physical memory. However, most guest operating
systems do not have built-in support for operating in a fragmented physical
address space e.g. Linux has to have a one-to-one mapping for it physical
memory. There a notion of {\it pseudo physical memory} is introdouced.
Once a domain is allocated a number of pages, at its start of the day, one of
the first things it needs to do is build its own {\it real physical} to
{\it pseudo physical} mapping. From that moment onwards {\it pseudo physical}
address are used instead of discontiguous {\it real physical} addresses. Thus,
the rest of the guest OS code has an impression of operating in a contiguous
address space. Guest OS page tables contain real physical addresses. Mapping
{\it pseudo physical} to {\it real physical} addresses is need on page
table updates and also on remapping memory regions with the guest OS.
The usual problem of external fragmentation means that a domain is
unlikely to receive a contiguous stretch of physical memory. However,
most guest operating systems do not have built-in support for
operating in a fragmented physical address space e.g. Linux has to
have a one-to-one mapping for its physical memory. There a notion of
{\it pseudo physical memory} is introdouced. Xen maintains a {\it
real physical} to {\it pseudo physical} mapping which can be consulted
by every domain. Additionally, at its start of day, a domain is
supplied a {\it pseudo physical} to {\it real physical} mapping which
it needs to keep updated itself. From that moment onwards {\it pseudo
physical} addresses are used instead of discontiguous {\it real
physical} addresses. Thus, the rest of the guest OS code has an
impression of operating in a contiguous address space. Guest OS page
tables contain real physical addresses. Mapping {\it pseudo physical}
to {\it real physical} addresses is needed on page table updates and
also on remapping memory regions with the guest OS.
@@ -272,11 +292,11 @@ In terms of networking this means packet transmission and reception.
On the transmission side, the backend needs to perform two key actions:
\begin{itemize}
\item {\tt Validation:} A domain is only allowed to emit packets
\item {\tt Validation:} A domain may only be allowed to emit packets
matching a certain specification; for example, ones in which the
source IP address matches one assigned to the virtual interface over
which it is sent. The backend is responsible for ensuring any such
requirements are met, either by checking or by stamping outgoing
which it is sent. The backend would be responsible for ensuring any
such requirements are met, either by checking or by stamping outgoing
packets with prescribed values for certain fields.
Validation functions can be configured using standard firewall rules
@@ -284,13 +304,13 @@ Validation functions can be configured using standard firewall rules
\item {\tt Scheduling:} Since a number of domains can share a single
``real'' network interface, the hypervisor must mediate access when
several domains each have packets queued for transmission. Of course,
several domains each have packets queued for transmission. Of course,
this general scheduling function subsumes basic shaping or
rate-limiting schemes.
\item {\tt Logging and Accounting:} The hypervisor can be configured
with classifier rules that control how packets are accounted or
logged. For example, {\it domain0} could request that it receives a
logged. For example, {\it domain0} could request that it receives a
log message or copy of the packet whenever another domain attempts to
send a TCP packet containg a SYN.
\end{itemize}
@@ -303,8 +323,8 @@ to which it must be delivered and deliver it via page-flipping.
\section{Data Transfer}
Each virtual interface uses two ``descriptor rings'', one for transmit,
the other for receive. Each descriptor identifies a block of contiguous
physical memory allocated to the domain. There are four cases:
the other for receive. Each descriptor identifies a block of contiguous
physical memory allocated to the domain. There are four cases:
\begin{itemize}
@@ -326,15 +346,15 @@ Real physical addresses are used throughout, with the domain performing
translation from pseudo-physical addresses if that is necessary.
If a domain does not keep its receive ring stocked with empty buffers then
packets destined to it may be dropped. This provides some defense against
packets destined to it may be dropped. This provides some defense against
receiver-livelock problems because an overload domain will cease to receive
further data. Similarly, on the transmit path, it provides the application
further data. Similarly, on the transmit path, it provides the application
with feedback on the rate at which packets are able to leave the system.
Synchronization between the hypervisor and the domain is achieved using
counters held in shared memory that is accessible to both. Each ring has
counters held in shared memory that is accessible to both. Each ring has
associated producer and consumer indices indicating the area in the ring
that holds descriptors that contain data. After receiving {\it n} packets
that holds descriptors that contain data. After receiving {\it n} packets
or {\t nanoseconds} after receiving the first packet, the hypervisor sends
an event to the domain.
@@ -342,7 +362,7 @@ an event to the domain.
\section{Virtual Block Devices (VBDs)}
All guest OS disk access goes through the VBD interface. The VBD
All guest OS disk access goes through the VBD interface. The VBD
interface provides the administrator with the ability to selectively
grant domains access to portions of block storage devices visible to
the the block backend device (usually domain 0).
@@ -360,7 +380,7 @@ Domains which have been granted access to a logical block device are permitted
to read and write it by shared memory communications with the backend domain.
In overview, the same style of descriptor-ring that is used for
network packets is used here. Each domain has one ring that carries
network packets is used here. Each domain has one ring that carries
operation requests to the hypervisor and carries the results back
again.
@@ -390,7 +410,7 @@ assigned domains should be run there.
\section{Standard Schedulers}
These BVT, Atropos and Round Robin schedulers are part of the normal
Xen distribution. BVT provides porportional fair shares of the CPU to
Xen distribution. BVT provides proportional fair shares of the CPU to
the running domains. Atropos can be used to reserve absolute shares
of the CPU for each domain. Round-robin is provided as an example of
Xen's internal scheduler API.
@@ -569,7 +589,7 @@ which also performs all Xen-specific tasks and performs the actual task switch
(unless the previous task has been chosen again).
This method is called with the {\tt schedule\_lock} held for the current CPU
and local interrupts interrupts disabled.
and local interrupts disabled.
\paragraph*{Return values}
@@ -588,9 +608,8 @@ source data from or populate with data, depending on the value of the
\paragraph*{Call environment}
The generic layer guarantees that when this method is called, the
caller was using the caller selected the correct scheduler ID, hence
the scheduler's implementation does not need to sanity-check these
parts of the call.
caller selected the correct scheduler ID, hence the scheduler's
implementation does not need to sanity-check these parts of the call.
\paragraph*{Return values}
@@ -739,21 +758,17 @@ xentrace\_format} and {\tt xentrace\_cpusplit}.
Install trap handler table.
\section{ mmu\_update(mmu\_update\_t *req, int count)}
\section{ mmu\_update(mmu\_update\_t *req, int count, int *success_count)}
Update the page table for the domain. Updates can be batched.
The update types are:
success_count will be updated to report the number of successfull
updates. The update types are:
{\it MMU\_NORMAL\_PT\_UPDATE}:
{\it MMU\_UNCHECKED\_PT\_UPDATE}:
{\it MMU\_MACHPHYS\_UPDATE}:
{\it MMU\_EXTENDED\_COMMAND}:
\section{ console\_write(const char *str, int count)}
Output buffer str to the console.
\section{ set\_gdt(unsigned long *frame\_list, int entries)}
Set the global descriptor table - virtualization for lgdt.
@@ -761,28 +776,24 @@ Set the global descriptor table - virtualization for lgdt.
Request context switch from hypervisor.
\section{ set\_callbacks(unsigned long event\_selector, unsigned long event\_address,
unsigned long failsafe\_selector, unsigned long failsafe\_address) }
Register OS event processing routine. In Linux both the event\_selector and
failsafe\_selector are the kernel's CS. The value event\_address specifies the address for
an interrupt handler dispatch routine and failsafe\_address specifies a handler for
application faults.
\section{ net\_io\_op(netop\_t *op)}
Notify hypervisor of updates to transmit and/or receive descriptor rings.
unsigned long failsafe\_selector, unsigned
long failsafe\_address) } Register OS event processing routine. In
Linux both the event\_selector and failsafe\_selector are the
kernel's CS. The value event\_address specifies the address for an
interrupt handler dispatch routine and failsafe\_address specifies a
handler for application faults.
\section{ fpu\_taskswitch(void)}
Notify hypervisor that fpu registers needed to be save on context switch.
\section{ sched\_op(unsigned long op)}
Request scheduling operation from hypervisor. The options are: {\it yield},
{\it block}, {\it stop}, and {\it exit}. {\it yield} keeps the calling
domain run-able but may cause a reschedule if other domains are
run-able. {\it block} removes the calling domain from the run queue and the
domains sleeps until an event is delivered to it. {\it stop} and {\it exit}
should be self-explanatory.
\section{ set\_dom\_timer(dom\_timer\_arg\_t *timer\_arg)}
Request a timer event to be sent at the specified system time.
Request scheduling operation from hypervisor. The options are: {\it
yield}, {\it block}, and {\it shutdown}. {\it yield} keeps the
calling domain run-able but may cause a reschedule if other domains
are run-able. {\it block} removes the calling domain from the run
queue and the domains sleeps until an event is delivered to it. {\it
shutdown} is used to end the domain's execution and allows to specify
whether the domain should reboot, halt or suspend..
\section{ dom0\_op(dom0\_op\_t *op)}
Administrative domain operations for domain management. The options are:
@@ -790,26 +801,30 @@ Administrative domain operations for domain management. The options are:
{\it DOM0\_CREATEDOMAIN}: create new domain, specifying the name and memory usage
in kilobytes.
{\it DOM0\_STARTDOMAIN}: make domain schedulable
{\it DOM0\_CREATEDOMAIN}: create domain
{\it DOM0\_STOPDOMAIN}: mark domain as unschedulable
{\it DOM0\_PAUSEDOMAIN}: mark domain as unschedulable
{\it DOM0\_UNPAUSEDOMAIN}: mark domain as schedulable
{\it DOM0\_DESTROYDOMAIN}: deallocate resources associated with the domain
{\it DOM0\_GETMEMLIST}: get list of pages used by the domain
{\it DOM0\_BUILDDOMAIN}: do final guest OS setup for domain
{\it DOM0\_BVTCTL}: adjust scheduler context switch time
{\it DOM0\_SCHEDCTL}:
{\it DOM0\_ADJUSTDOM}: adjust scheduling priorities for domain
{\it DOM0\_BUILDDOMAIN}: do final guest OS setup for domain
{\it DOM0\_GETDOMAINFO}: get statistics about the domain
{\it DOM0\_GETPAGEFRAMEINFO}:
{\it DOM0\_IOPL}: set IO privilege level
{\it DOM0\_MSR}:
{\it DOM0\_DEBUG}: interactively call pervasive debugger
{\it DOM0\_SETTIME}: set system time
@@ -827,34 +842,60 @@ in kilobytes.
{\it DOM0\_SCHED\_ID}: get the ID of the current Xen scheduler
{\it DOM0\_SHADOW\_CONTROL}:
{\it DOM0\_SETDOMAINNAME}: set the name of a domain
{\it DOM0\_SETDOMAININITIALMEM}: set initial memory allocation of a domain
{\it DOM0\_SETDOMAINMAXMEM}: set maximum memory allocation of a domain
{\it DOM0\_GETPAGEFRAMEINFO2}:
{\it DOM0\_SETDOMAINVMASSIST}: set domain VM assist options
\section{ set\_debugreg(int reg, unsigned long value)}
set debug register reg to value
\section{ get\_debugreg(int reg)}
get the debug register reg
\section{ update\_descriptor(unsigned long pa, unsigned long word1, unsigned long word2)}
\section{ update\_descriptor(unsigned long ma, unsigned long word1, unsigned long word2)}
\section{ set\_fast\_trap(int idx)}
install traps to allow guest OS to bypass hypervisor
\section{ dom\_mem\_op(unsigned int op, void *pages, unsigned long nr\_pages)}
increase or decrease memory reservations for guest OS
\section{ dom\_mem\_op(unsigned int op, unsigned long *extent_list, unsigned long nr\_extents, unsigned int extent_order)}
Increase or decrease memory reservations for guest OS
\section{ multicall(multicall\_entry\_t *call\_list, int nr\_calls)}
execute a series of hypervisor calls
\section{ multicall(void *call\_list, int nr\_calls)}
Execute a series of hypervisor calls
\section{ kbd\_op(unsigned char op, unsigned char val)}
\section{ update\_va\_mapping(unsigned long page\_nr, unsigned long val, unsigned long flags)}
\section{update\_va\_mapping(unsigned long page\_nr, unsigned long val, unsigned long flags)}
\section{ set\_timer\_op(uint64_t timeout)}
Request a timer event to be sent at the specified system time.
\section{ event\_channel\_op(unsigned int cmd, unsigned int id)}
inter-domain event-channel management, options are: open, close, send, and status.
\section{ event\_channel\_op(void *op)}
Iinter-domain event-channel management.
\section{ xen\_version(int cmd)}
Request Xen version number.
\section{ console\_io(int cmd, int count, char *str)}
Interact with the console, operations are:
{\it CONSOLEIO\_write}: Output count characters from buffer str.
{\it CONSOLEIO\_read}: Input at most count characters into buffer str.
\section{ physdev\_op(void *physdev\_op)}
\section{ grant\_table\_op(unsigned int cmd, void *uop, unsigned int count)}
\section{ vm\_assist(unsigned int cmd, unsigned int type)}
\section{ update\_va\_mapping\_otherdomain(unsigned long page\_nr, unsigned long val, unsigned long flags, uint16_t domid)}
\end{document}
docs/user.tex
+126 -117
View File
@@ -76,29 +76,28 @@ Xen support is available for increasingly many operating systems. The
following OSs have either been ported already or a port is in
progress:
\begin{itemize}
\item Dragonfly BSD
\item FreeBSD 5.3
\item Linux 2.4
\item Linux 2.6
\item NetBSD 2.0
\item Dragonfly BSD
\item FreeBSD 5.3
\item Plan 9
\item Windows XP
% \item Windows XP
\end{itemize}
Right now, Linux 2.4 and 2.6 are available for Xen 2.0. NetBSD
port will be updated to run on Xen 2.0, hopefully in time for the NetBSD
2.0 release. It is intended that Xen support be integrated into the
official releases of Linux 2.6, NetBSD 2.0, FreeBSD and Dragonfly BSD.
Right now, Linux 2.4, Linux 2.6 and NetBSD are available for Xen 2.0.
It is intended that Xen support be integrated into the official
releases of Linux 2.6, NetBSD 2.0, FreeBSD and Dragonfly BSD.
Even running multiple copies of Linux can be very useful, providing a
means of containing faults to one OS image, providing performance
isolation between the various OS instances and trying out multiple
distros.
The Windows XP port is only available to those who have signed the
Microsoft Academic Source License. Publically available XP support
will not be available for the foreseeable future (this may change when
Intel's Vanderpool Technology becomes available).
% The Windows XP port is only available to those who have signed the
% Microsoft Academic Source License. Publically available XP support
% will not be available for the foreseeable future (this may change when
% Intel's Vanderpool Technology becomes available).
Possible usage scenarios for Xen include:
\begin{description}
@@ -170,19 +169,12 @@ at:\\
{\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}\\
Work to port Xen to x86\_64 and IA64 is currently underway.
Xen is targeted at server-class machines, and the current list of
supported hardware very much reflects this, avoiding the need for us
to write drivers for "legacy" hardware. It is likely that some desktop
chipsets will fail to work properly with the default Xen
configuration: specifying {\tt noacpi} or {\tt ignorebiostables} when
booting Xen may help in these cases.
Xen requires a ``P6'' or newer processor (e.g. Pentium Pro, Celeron,
Pentium II, Pentium III, Pentium IV, Xeon, AMD Athlon, AMD Duron).
Multiprocessor machines are supported, and we also have basic support
for HyperThreading (SMT), although this remains a topic for ongoing
research. We're also working on an x86\_64 port (though Xen should
already run on these systems just fine in 32-bit mode).
research. We're also working on an x86\_64 port (though Xen already
runs on these systems just fine in 32-bit mode).
Xen can currently use up to 4GB of memory. It is possible for x86
machines to address up to 64GB of physical memory but (unless an
@@ -190,13 +182,16 @@ external developer volunteers) there are no plans to support these
systems. The x86\_64 port is the planned route to supporting more
than 4GB of memory.
In contrast to previous Xen versions, in Xen 2.0 device drivers run
within a privileged guest OS rather than within Xen itself. This means
that we should be compatible with the majority of device hardware
supported by Linux. The default XenLinux build contains support for
relatively modern server-class network and disk hardware, but you can
add support for other hardware by configuring your XenLinux kernel in
the normal way (e.g. \verb_# make ARCH=xen xconfig_).
Xen offloads most of the hardware support issues to the guest OS
running in Domain 0. Xen itself only contains code to detect and
start additional processors, setup interrupt routing and perform PCI
bus enumeration. Device drivers run within a privileged guest OS
rather than within Xen itself. This means that we should be
compatible with the majority of device hardware supported by Linux.
The default XenLinux build contains support for relatively modern
server-class network and disk hardware, but you can add support for
other hardware by configuring your XenLinux kernel in the normal way
(e.g. \verb_# make ARCH=xen menuconfig_).
\section{History}
@@ -218,9 +213,9 @@ Xen has since grown into a project in its own right, enabling us to
investigate interesting research issues regarding the best techniques
for virtualizing resources such as the CPU, memory, disk and network.
The project has been bolstered by support from Intel Research
Cambridge, and HP Labs, who are now working closely with us. We're
also in receipt of support from Microsoft Research Cambridge to port
Windows XP to run on Xen.
Cambridge, and HP Labs, who are now working closely with us.
% We're also in receipt of support from Microsoft Research Cambridge to
% port Windows XP to run on Xen.
Xen was first described in the 2003 paper at SOSP \\
({\tt http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf}).
@@ -241,7 +236,7 @@ will work to conclusively achieve that position.
\chapter{Installation}
The Xen distribution includes three main components: Xen itself,
The Xen distribution includes three main components: Xen itself,
utilities to convert a standard Linux tree to run on Xen and the
userspace tools required to operate a Xen-based system.
@@ -259,14 +254,14 @@ http://www.twistedmatrix.com}). There may be a package available for
your distribution; alternatively it can be installed by running {\tt \#
make install-twisted} in the root of the Xen source tree.
\item The Linux bridge control tools (see {\tt
http://bridge.sourceforge.net}). There may be a packages of these
tools available for your distribution.
http://bridge.sourceforge.net}). There may be packages of these tools
available for your distribution.
\item Linux IP Routing Tools
\item make
\item python-dev
\item gcc
\item zlib-dev
\item libcurl
\item zlib-dev
\item python-dev
\item python2.3-pycurl
\item python2.3-twisted
\end{itemize}
@@ -302,11 +297,11 @@ run:
# bk clone bk://xen.bkbits.net/xen-2.0.bk
\end{verbatim}
Under your current directory, a new directory named `xen-2.0.bk'
has been created, which contains all the source code for the Xen
hypervisor and the Xen tools. The directory also contains `sparse'
Linux source trees, containing only the files that differ between
XenLinux and standard Linux.
Under your current directory, a new directory named `xen-2.0.bk' has
been created, which contains all the source code for the Xen
hypervisor and the Xen tools. The directory also contains `sparse' OS
source trees, containing only the files that require changes to allow
the OS to run on Xen.
Once you have cloned the repository, you can update to the newest
changes to the repository by running:
@@ -330,8 +325,9 @@ The Xen source code repository is structured as follows:
\item[\path{tools/}] Xen node controller daemon (Xend), command line tools,
control libraries
\item[\path{xen/}] The Xen hypervisor itself.
\item[\path{linux-2.4.27-xen/}] Linux 2.4 support for Xen
\item[\path{linux-2.6.8.1-xen/}] Linux 2.6 support for Xen
\item[\path{linux-2.4.27-xen/}] Xen support for Linux 2.4
\item[\path{linux-2.6.8.1-xen/}] Xen support for Linux 2.6
\item[\path{netbsd-2.0-xen-sparse/}] Xen support for NetBSD 2.0
\item[\path{docs/}] various documentation files for users and developers
\item[\path{extras/}] currently this contains the Mini OS, aimed at developers
\end{description}
@@ -351,37 +347,46 @@ following:
unprivileged virtual machines.
\end{itemize}
Inspect the Makefile if you want to see what goes on during a
build. Building Xen and the tools is straightforward, but XenLinux is
more complicated. The makefile needs a `pristine' linux kernel tree
which it will then add the Xen architecture files to. You can tell the
Inspect the Makefile if you want to see what goes on during a build.
Building Xen and the tools is straightforward, but XenLinux is more
complicated. The makefile needs a `pristine' linux kernel tree which
it will then add the Xen architecture files to. You can tell the
makefile the location of the appropriate linux compressed tar file by
setting the LINUX\_SRC environment variable, e.g. \\
\verb!# LINUX_SRC=/tmp/linux-2.6.8.1.tar.bz2 make world! \\ or by
placing the tar file somewhere in the search path of {\tt LINUX\_SRC\_PATH}
which defaults to ``{\tt .:..}". If the makefile can't find a suitable
kernel tar file it attempts to download it from kernel.org (this won't
work if you're behind a firewall).
placing the tar file somewhere in the search path of {\tt
LINUX\_SRC\_PATH} which defaults to ``{\tt .:..}". If the makefile
can't find a suitable kernel tar file it attempts to download it from
kernel.org (this won't work if you're behind a firewall).
After untaring the pristine kernel tree, the makefile uses the {\tt
mkbuildtree} script to add the Xen patches the kernel. It then builds
two different XenLinux images, one with a ``-xen0'' extension which
contains hardware device drivers and drivers for Xen's virtual devices,
and one with a ``-xenU'' extension that just contains the virtual ones.
mkbuildtree} script to add the Xen patches to the kernel. It then
builds two different XenLinux images, one with a ``-xen0'' extension
which contains hardware device drivers and drivers for Xen's virtual
devices, and one with a ``-xenU'' extension that just contains the
virtual ones.
The procedure is similar to build the Linux 2.4 port: \\
\verb!# LINUX_SRC=/path/to/linux2.4/source make linux24!
In both cases, if you have an SMP machine you may wish to give the
{\tt '-j4'} argument to make to get a parallel build.
The NetBSD port can be built using: \\ \verb!# make netbsd! \\ The
NetBSD port is built using a snapshot of the netbsd-2-0 cvs branch.
The snapshot is downloaded as part of the build process, if it is not
yet present in the {\tt NETBSD_SRC_PATH} search path. The build
process also downloads a toolchain which includes all the tools
necessary to build the NetBSD kernel under Linux.
If you have an SMP machine you may wish to give the {\tt '-j4'}
argument to make to get a parallel build.
XXX Insert details on customising the kernel to be built.
i.e. merging config files
If you have an existing kernel configuration that you would like to
use for domain 0, you should copy it to
If you have an existing Linux kernel configuration that you would like
to use for domain 0, you should copy it to
install/boot/config-2.6.8.1-xen0. During the first build, you may be
asked about some Xen-specific options.
asked about some Xen-specific options. We advised accepting the
defaults for these options.
\framebox{\parbox{5in}{
{\bf Distro specific:} \\
@@ -395,10 +400,10 @@ locations, do: \\
\verb_# make install_
Alternatively, users with special installation requirements may wish
to install them manually by copying file to their appropriate
to install them manually by copying the files to their appropriate
destinations.
Take a look at the files in \path{install/boot/}:
Files in \path{install/boot/} include:
\begin{itemize}
\item \path{install/boot/xen.gz} The Xen 'kernel'
\item \path{install/boot/vmlinuz-2.6.8.1-xen0} Domain 0 XenLinux kernel
@@ -406,7 +411,7 @@ Take a look at the files in \path{install/boot/}:
\end{itemize}
The difference between the two Linux kernels that are built is due to
the configuration file used for each. The "U" suffixed unprivileged
the configuration file used for each. The "U" suffixed unprivileged
version doesn't contain any of the physical hardware device drivers
--- it is 30\% smaller and hence may be preferred for your
non-privileged domains. The ``0'' suffixed privileged version can be
@@ -472,7 +477,7 @@ serial console. Add the line:
Users of the XenLinux 2.6 kernel should disable Thread Local Storage
(e.g. by doing a {\tt mv /lib/tls /lib/tls.disabled}) before
attempting to run with a XenLinux kernel. You can always reenable it
my restoring the directory to its original location (i.e. {\tt mv
by restoring the directory to its original location (i.e. {\tt mv
/lib/tls.disabled /lib/tls}).
The TLS implementation uses segmentation in a way that is not
@@ -504,7 +509,8 @@ should still be able to reboot with your normal Linux kernel.
The first step in creating a new domain is to prepare a root
filesystem for it to boot off. Typically, this might be stored in a
normal partition, a disk file and LVM volume, or on an NFS server.
normal partition, an LVM or other volume manager partition, a disk
file or on an NFS server.
A simple way to do this is simply to boot from your standard OS
install CD and install the distribution into another partition on your
@@ -513,7 +519,7 @@ hard drive.
{\em N.b } you can boot with Xen and XenLinux without installing any
special userspace tools but will need to have the prerequisites
described in Section~\ref{sec:prerequisites} and the Xen control tools
are installed before you proceed.
installed before you proceed.
\section{From the web interface}
@@ -535,10 +541,10 @@ require a more complex setup, you will want to write a custom
configuration file --- details of the configuration file formats are
included in Chapter~\ref{cha:config}.
The \path{xmdefconfig1} file is a simple template configuration file
The \path{xmexample1} file is a simple template configuration file
for describing a single VM.
The \path{xmdefconfig2} file is a template description that is intended
The \path{xmexample2} file is a template description that is intended
to be reused for multiple virtual machines. Setting the value of the
{\tt vmid} variable on the {\tt xm} command line
fills in parts of this template.
@@ -600,8 +606,8 @@ kernel = "/boot/vmlinuz-2.6.8.1-xenU" # or a 2.4 kernel or a xen0 kernel
memory = 64
name = "ttylinux"
cpu = -1 # leave to Xen to pick
nics=1
ip="1.2.3.4"
nics = 1
ip = "1.2.3.4"
disk = ['file:/path/to/ttylinux-disk,sda1,w']
root = "/dev/sda1 ro"
\end{verbatim}
@@ -667,11 +673,11 @@ e.g. \verb_# xm console 1_ (open console to domain 1)
\subsection{\tt xm list}
The output of {\tt xm list} is in rows of the following format:\\
\verb_domid name memory cpu state cputime_
\verb_name domid memory cpu state cputime console_
\begin{description}
\item[domid] The number of the domain ID this virtual machine is running in.
\item[name] The descriptive name of the virtual machine.
\item[domid] The number of the domain ID this virtual machine is running in.
\item[memory] Memory size in megabytes.
\item[cpu] The CPU this domain is running on.
\item[state] Domain state consists of 5 fields:
@@ -683,6 +689,7 @@ The output of {\tt xm list} is in rows of the following format:\\
\item[c] crashed
\end{description}
\item[cputime] How much CPU time (in seconds) the domain has used so far.
\item[console] TCP port accepting connections to the domain's console.
\end{description}
The {\tt xm list} command also supports a long output format when the
@@ -702,8 +709,8 @@ It is possible to use a file in Domain 0 as the primary storage for a
virtual machine. As well as being convenient, this also has the
advantage that the virtual block device will be {\em sparse} --- space
will only really be allocated as parts of the file are used. So if a
virtual machine uses only half its disk space then the file really
takes up a half of the size allocated.
virtual machine uses only half of its disk space then the file really
takes up half of the size allocated.
For example, to create a 2GB sparse file-backed virtual block device
(actually only consumes 1KB of disk):
@@ -717,7 +724,7 @@ Make a file system in the disk file: \\
Populate the file system e.g. by copying from the current root:
\begin{verbatim}
# mount vm1disk /mnt -o loop
# mount -o loop vm1disk /mnt
# cp -ax / /mnt
\end{verbatim}
Tailor the file system by editing \path{/etc/fstab},
@@ -729,8 +736,6 @@ this example put \path{/dev/sda1} to root in fstab.
Now unmount (this is important!):\\
\verb_# umount /mnt_
And detach the file from its loop device:
In the configuration file set:\\
\verb_disk = ['file:/full/path/to/vm1disk,sda1,w']_
@@ -784,7 +789,7 @@ order to handle the {\tt vmid} variable.
\chapter{Xend (Node control daemon)}
\label{cha:xensv}
\label{cha:xend}
The Xen Daemon (Xend) performs system management functions related to
virtual machines. It forms a central point of control for a machine
@@ -801,11 +806,10 @@ Xend command line:
\verb_# xend restart_ & restart Xend if running, otherwise start it \\
\end{tabular}
An SysV init script called {\tt xend} is provided to start Xend at
boot time. The {\tt make install} will install this script in
{\path{/etc/init.d} automatically. To enable it, you can make
symbolic links in the appropriate runlevel directories or use the {\tt
chkconfig} tool, where available.
A SysV init script called {\tt xend} is provided to start Xend at boot
time. {\tt make install} installs this script in {\path{/etc/init.d}.
To enable it, you have to make symbolic links in the appropriate
runlevel directories or use the {\tt chkconfig} tool, where available.
Once Xend is running, more sophisticated administration can be done
using the Xensv web interface (see Chapter~\ref{cha:xensv}).
@@ -822,7 +826,7 @@ It will automatically start Xend if it is not already running.
By default, Xensv will serve out the web interface on port 8080. This
can be changed by editing {\tt
/usr/lib/python2.2/site-packages/xen/sv/params.py}.
/usr/lib/python2.3/site-packages/xen/sv/params.py}.
Once Xensv is running, the web interface can be used to manage running
domains and provides a user friendly domain creation wizard.
@@ -839,13 +843,13 @@ The general format of an xm command line is:
# xm command [switches] [arguments] [variables]
\end{verbatim}
The available {\em switches } and {\em arguments}are dependent on the
The available {\em switches } and {\em arguments} are dependent on the
{\em command} chosen. The {\em variables} may be set using
declarations of the form {\tt variable=value} and may be used to set /
override any of the values in the configuration file being used,
including the standard variables described above and any custom
variables (for instance, the \path{xmdefconfig} file uses a {\tt vmid}
variable).
declarations of the form {\tt variable=value} and command line
declarations override any of the values in the configuration file
being used, including the standard variables described above and any
custom variables (for instance, the \path{xmdefconfig} file uses a
{\tt vmid} variable).
The available commands are as follows:
@@ -1050,7 +1054,7 @@ domains), so the FBVT derivative has been included as an alternative.
\item[ctx\_allow]
the context switch allowance is similar to the "quantum"
in traditional schedulers. It is the minimum time that
a scheduled domain will be allowed to run before be
a scheduled domain will be allowed to run before being
pre-empted. This prevents thrashing of the CPU.
\end{description}
@@ -1124,13 +1128,13 @@ higher throughput.
\chapter{Privileged domains}
There are two possible types of privileges: IO privileges and
There are two possible types of privileges: IO privileges and
administration privileges.
\section{Driver domains (IO Privileges)}
IO privileges can be assigned to allow a domain to drive PCI devices
itself. This is used for to support driver domains.
itself. This is used to support driver domains.
Setting backend privileges is currently only supported in SXP format
config files (??? is this true - there's nothing in xmdefconfig,
@@ -1201,8 +1205,11 @@ make option1=y option2=y
\section{List of options}
{\bf verbose=y }\\
Enable debugging messages when Xen detects an unexpected condition.
Also enables console output from all domains. \\
{\bf debug=y }\\
Enable debug assertions and console output.
Enable debug assertions. Implies {\bf verbose=y }.
(Primarily useful for tracing bugs in Xen). \\
{\bf debugger=y }\\
Enable the in-Xen pervasive debugger (PDB).
@@ -1253,12 +1260,12 @@ editing \path{grub.conf}.
Disable Hyperthreading. \\
{\bf badpage=$<$page number$>$[,$<$page number$>$] } \\
Specify a list of pages not to be allocated for use
because they contain bad bytes. For example, if your
memory tester says that byte 0x12345678 is bad, you would
place 'badpage=0x12345' on Xen's command line (i.e., the
last three digits of the byte address are not
included!). \\
Specify a list of pages not to be allocated for use
because they contain bad bytes. For example, if your
memory tester says that byte 0x12345678 is bad, you would
place 'badpage=0x12345' on Xen's command line (i.e., the
last three digits of the byte address are not
included!). \\
{\bf com1=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] \\
com2=$<$baud$>$,DPS[,$<$io\_base$>$,$<$irq$>$] } \\
@@ -1294,7 +1301,7 @@ editing \path{grub.conf}.
pressed three times. Specifying '`' disables switching.
The <auto-switch-char> specifies whether Xen should
auto-switch input to DOM0 when it boots -- if it is 'x'
then auto-switching is disabled. Any other value, or
then auto-switching is disabled. Any other value, or
omitting the character, enables auto-switching.
[NB. Default for this option is 'a'] \\
@@ -1398,17 +1405,19 @@ Xen domain:
\item Set up Xen 2.0 and test that it's working, as described earlier in
this manual.
\item Create disk images for root-fs and swap (alternatively, you might create
dedicated partitions, LVM logical volumes, etc. if that suits your setup).
\item Create disk images for root-fs and swap (alternatively, you
might create dedicated partitions, LVM logical volumes, etc. if
that suits your setup).
\begin{verbatim}
dd if=/dev/zero of=/path/diskimage bs=1024k count=size_in_mbytes
dd if=/dev/zero of=/path/swapimage bs=1024k count=size_in_mbytes
\end{verbatim}
If you're going to use this filesystem / diskimage only as a `template' for
other vm diskimages, something like 300 MB should be enough.. (of course it
depends what kind of packages you are planning to install to the template)
If you're going to use this filesystem / diskimage only as a
`template' for other vm diskimages, something like 300 MB should
be enough.. (of course it depends what kind of packages you are
planning to install to the template)
\item Create filesystem and swap to the images
\item Create the filesystem and initialise the swap image
\begin{verbatim}
mkfs.ext3 /path/diskimage
mkswap /path/swapimage
@@ -1421,7 +1430,7 @@ mount -o loop /path/diskimage /mnt/disk
\item Install {\tt debootstrap}
Make sure you have debootstrap installed on the host. If you are
Make sure you have debootstrap installed on the host. If you are
running Debian sarge (3.1 / testing) or unstable you can install it by
running {\tt apt-get install debootstrap}. Otherwise, it can be
downloaded from the Debian project website.
@@ -1439,7 +1448,7 @@ You can use any other Debian http/ftp mirror you want.
chroot /mnt/disk /bin/bash
\end{verbatim}
Edit the following files using vi or nano and make needed settings:
Edit the following files using vi or nano and make needed changes:
\begin{verbatim}
/etc/hostname
/etc/hosts
@@ -1460,7 +1469,7 @@ Add Debian mirror to:
/etc/apt/sources.list
\end{verbatim}
And create fstab like this:
Create fstab like this:
\begin{verbatim}
/dev/sda1 / ext3 errors=remount-ro 0 1
/dev/sda2 none swap sw 0 0
@@ -1474,8 +1483,8 @@ Logout
umount /mnt/disk
\end{verbatim}
\item Create Xen 2.0 configuration file for the new domain. You can use the
example-configurations coming with xen as a template.
\item Create Xen 2.0 configuration file for the new domain. You can
use the example-configurations coming with xen as a template.
Make sure you have the following set up:
\begin{verbatim}
@@ -1500,9 +1509,9 @@ xm list
Started domain testdomain2, console on port 9626
\end{verbatim}
There you can see the ID of the console: 26. You can also
list the consoles with {\tt xm consoles"}. (ID is the last two digits of
the portnumber.)
There you can see the ID of the console: 26. You can also list
the consoles with {\tt xm consoles"}. (ID is the last two
digits of the portnumber.)
Attach to the console:
@@ -1510,14 +1519,15 @@ Started domain testdomain2, console on port 9626
xm console 26
\end{verbatim}
or by telnetting to the port 9626 of localhost (the xm console progam works better).
or by telnetting to the port 9626 of localhost (the xm console
progam works better).
\item Log in and run base-config
As a default there's no password for the root.
Check that everything looks OK, and the system started without
errors. Check that the swap is active, and the network settings are
errors. Check that the swap is active, and the network settings are
correct.
Run {\tt /usr/sbin/base-config} to set up the Debian settings.
@@ -1535,4 +1545,3 @@ simply copying the image file. Once this is done, modify the
image-specific settings (hostname, network settings, etc).
\end{document}
xen/arch/x86/memory.c
+21 -2
View File
@@ -1604,7 +1604,11 @@ void ptwr_flush(const int which)
if ( unlikely(__get_user(pte, ptep)) )
{
MEM_LOG("ptwr: Could not read pte at %p\n", ptep);
domain_crash();
/*
* Really a bug. We could read this PTE during the initial fault,
* and pagetables can't have changed meantime. XXX Multi-proc guests?
*/
BUG();
}
PTWR_PRINTK("[%c] disconnected_l1va at %p is %08lx\n",
PTWR_PRINT_WHICH, ptep, pte);
@@ -1627,7 +1631,11 @@ void ptwr_flush(const int which)
if ( unlikely(__put_user(pte, ptep)) )
{
MEM_LOG("ptwr: Could not update pte at %p\n", ptep);
domain_crash();
/*
* Really a bug. We could write this PTE during the initial fault,
* and pagetables can't have changed meantime. XXX Multi-proc guests?
*/
BUG();
}
/* Ensure that there are no stale writable mappings in any TLB. */
@@ -1668,6 +1676,14 @@ void ptwr_flush(const int which)
if ( unlikely(!get_page_from_l1e(nl1e, d)) )
{
MEM_LOG("ptwr: Could not re-validate l1 page\n");
/*
* Make the remaining p.t's consistent before crashing, so the
* reference counts are correct.
*/
memcpy(&pl1e[i], &ptwr_info[cpu].ptinfo[which].page[i],
(ENTRIES_PER_L1_PAGETABLE - i) * sizeof(l1_pgentry_t));
unmap_domain_mem(pl1e);
ptwr_info[cpu].ptinfo[which].l1va = 0;
domain_crash();
}
@@ -1781,6 +1797,9 @@ int ptwr_do_page_fault(unsigned long addr)
{
MEM_LOG("ptwr: Could not update pte at %p\n", (unsigned long *)
&linear_pg_table[addr>>PAGE_SHIFT]);
/* Toss the writable pagetable state and crash. */
unmap_domain_mem(ptwr_info[cpu].ptinfo[which].pl1e);
ptwr_info[cpu].ptinfo[which].l1va = 0;
domain_crash();
}
xen/common/schedule.c
+3 -3
View File
@@ -326,6 +326,9 @@ void __enter_scheduler(void)
task_slice_t next_slice;
s32 r_time; /* time for new dom to run */
cleanup_writable_pagetable(
prev, PTWR_CLEANUP_ACTIVE | PTWR_CLEANUP_INACTIVE);
perfc_incrc(sched_run);
spin_lock_irq(&schedule_data[cpu].schedule_lock);
@@ -373,9 +376,6 @@ void __enter_scheduler(void)
if ( unlikely(prev == next) )
return;
cleanup_writable_pagetable(
prev, PTWR_CLEANUP_ACTIVE | PTWR_CLEANUP_INACTIVE);
perfc_incrc(sched_ctx);
#if defined(WAKE_HISTO)
Reference in new issue
xen-project/xen
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.

The note is not visible to the blocked user.