25 Apr, 2008
18 commits
-
The balloon driver allows memory to be dynamically added or removed from the domain,
in order to allow host memory to be balanced between multiple domains.This patch introduces the Xen balloon driver, though it currently only
allows a domain to be shrunk from its initial size (and re-grown back to
that size). A later patch will add the ability to grow a domain beyond
its initial size.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
This is a pair of Xen para-virtual frontend device drivers:
drivers/video/xen-fbfront.c provides a framebuffer, and
drivers/input/xen-kbdfront provides keyboard and mouse.The backends run in dom0 user space.
The two drivers are not in two separate patches, because the
intermediate step (one driver, not the other) is somewhat problematic:
the backend in dom0 needs both drivers, and will refuse to complete
device initialization unless they're both present.Signed-off-by: Markus Armbruster
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
When the xen block frontend driver is built as a module the module load
is only synchronous up to the point where the frontend and the backend
become connected rather than when the disk is added.This means that there can be a race on boot between loading the module and
loading the dm-* modules and doing the scan for LVM physical volumes (all
in the initrd). In the failure case the disk is not present until after the
scan for physical volumes is complete.Taken from:
http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/11483a00c017
Signed-off-by: Christian Limpach
Signed-off-by: Mark McLoughlin
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Frontends are expected to write their protocol ABI to xenstore. Since
the protocol ABI defaults to the backend's native ABI, things work
fine without that as long as the frontend's native ABI is identical to
the backend's native ABI. This is not the case for xen-blkfront
running 32-on-64, because its ABI differs between 32 and 64 bit, and
thus needs this fix.Based on http://xenbits.xensource.com/xen-unstable.hg?rev/c545932a18f3
and http://xenbits.xensource.com/xen-unstable.hg?rev/ffe52263b430 by
Gerd HoffmannSigned-off-by: Markus Armbruster
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
On xen/ia64 and xen/powerpc hypercall arguments are passed by pseudo
physical address (guest physical address) so that it's necessary to
convert from virtual address into pseudo physical address. The frame
work is called xencomm.
Import arch generic part of xencomm.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
split out x86 specific part from grant-table.c and
allow ia64/xen specific initialization.
ia64/xen grant table is based on pseudo physical address
(guest physical address) unlike x86/xen. On ia64 init_mm
doesn't map identity straight mapped area.
ia64/xen specific grant table initialization is necessary.Signed-off-by: Isaku Yamahata
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Don't use alloc_vm_area()/free_vm_area() directly, instead define
xen_alloc_vm_area()/xen_free_vm_area() and use them.alloc_vm_area()/free_vm_area() are used to allocate/free area which
are for grant table mapping. Xen/x86 grant table is based on virtual
address so that alloc_vm_area()/free_vm_area() are suitable.
On the other hand Xen/ia64 (and Xen/powerpc) grant table is based on
pseudo physical address (guest physical address) so that allocation
should be done differently.
The original version of xenified Linux/IA64 have its own
allocate_vm_area()/free_vm_area() definitions which don't allocate vm area
contradictory to those names.
Now vanilla Linux already has its definitions so that it's impossible
to have IA64 definitions of allocate_vm_area()/free_vm_area().
Instead introduce xen_allocate_vm_area()/xen_free_vm_area() and use them.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
The definitions in include/asm/xen/page.h are arch specific.
ia64/xen wants to define its own version. So move them to arch specific
directory and keep include/xen/page.h in order not to break compilation.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Define resend_irq_on_evtchn() which ia64/xen uses.
Although it isn't used by current x86/xen code, it's arch generic
so that put it into common code.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Remove x86 dependency in drivers/xen/events.c for ia64/xen support
introducing include/asm/xen/events.h.
Introduce xen_irqs_disabled() to hide regs->flags
Introduce xen_do_IRQ() to hide regs->orig_ax.
make enum ipi_vector definition arch specific. ia64/xen needs four vectors.
Add one rmb() because on ia64 xchg() isn't barrier.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
move arch/x86/xen/events.c undedr drivers/xen to share codes
with x86 and ia64. And minor adjustment to compile.
ia64/xen also uses events.cSigned-off-by: Yaozu (Eddie) Dong
Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Add xen handles realted definitions for xen vcpu which ia64/xen needs.
Pointer argumsnts for ia64/xen hypercall are passed in pseudo physical
address (guest physical address) so that it is required to convert
guest kernel virtual address into pseudo physical address.
The xen guest handle represents such arguments.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Add xen handles realted definitions for grant table which ia64/xen
needs.
Pointer argumsnts for ia64/xen hypercall are passed in pseudo physical
address (guest physical address) so that it is required to convert
guest kernel virtual address into pseudo physical address right before
issuing hypercall.
The xen guest handle represents such arguments.
Define necessary handles and helper functions.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Add xen VIRQ numbers defined for arch specific use.
ia64/xen domU uses VIRQ_ARCH_0 for virtual itc timer.
Although all those constants aren't used yet by ia64
at this moment, add all arch specific VIRQ numbers.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Add xen hypercall numbers defined for arch specific use.
ia64/xen domU uses __HYPERVISOR_arch_1 to manipulate paravirtualized
IOSAPIC. Although all those constants aren't used yet by IA64 at this
moment, add all arch specific hypercall numbers.Signed-off-by: Isaku Yamahata
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Xen's pte operations on mfns can be unified like the kernel's pfn operations.
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner -
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
30 Jan, 2008
1 commit
-
Make sure pte_t, whatever its definition, has a pte element with type
pteval_t. This allows common code to access it without needing to be
specifically parameterised on what pagetable mode we're compiling for.
For 32-bit, this means that pte_t becomes a union with "pte" and "{
pte_low, pte_high }" (PAE) or just "pte_low" (non-PAE).Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ingo Molnar
Signed-off-by: Thomas Gleixner
17 Oct, 2007
1 commit
-
The kernel's copy of struct vcpu_register_vcpu_info was out of date,
at best causing the hypercall to fail and the guest kernel to fall
back to the old mechanism, or worse, causing random memory corruption.[ Stable folks: applies to 2.6.23 ]
Signed-off-by: Jeremy Fitzhardinge
Cc: Stable Kernel
Cc: Morten =?utf-8?q?B=C3=B8geskov?=
Cc: Mark Williamson
27 Jul, 2007
1 commit
-
Fix:
linux/include/xen/page.h: In function mfn_pte:
linux/include/xen/page.h:149: error: __supported_pte_mask undeclared (first use in this function)
linux/include/xen/page.h:149: error: (Each undeclared identifier is reported only once
linux/include/xen/page.h:149: error: for each function it appears in.)Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
18 Jul, 2007
8 commits
-
An experimental patch for Xen allows guests to place their vcpu_info
structs anywhere. We try to use this to place the vcpu_info into the
PDA, which allows direct access.If this works, then switch to using direct access operations for
irq_enable, disable, save_fl and restore_fl.Signed-off-by: Jeremy Fitzhardinge
Cc: Chris Wright
Cc: Keir Fraser -
This communicates with the machine control software via a registry
residing in a controlling virtual machine. This allows dynamic
creation, destruction and modification of virtual device
configurations (network devices, block devices and CPUS, to name some
examples).[ Greg, would you mind giving this a review? Thanks -J ]
Signed-off-by: Ian Pratt
Signed-off-by: Christian Limpach
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Chris Wright
Cc: Greg KH -
Add Xen 'grant table' driver which allows granting of access to
selected local memory pages by other virtual machines and,
symmetrically, the mapping of remote memory pages which other virtual
machines have granted access to.This driver is a prerequisite for many of the Xen virtual device
drivers, which grant the 'device driver domain' restricted and
temporary access to only those memory pages that are currently
involved in I/O operations.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ian Pratt
Signed-off-by: Christian Limpach
Signed-off-by: Chris Wright -
Implement a Xen back-end for hvc console.
* * *
Add early printk support via hvc console, enable using
"earlyprintk=xen" on the kernel command line.From: Gerd Hoffmann
Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Chris Wright
Acked-by: Ingo Molnar
Acked-by: Olof Johansson -
This is a fairly straightforward Xen implementation of smp_ops.
Xen has its own IPI mechanisms, and has no dependency on any
APIC-based IPI. The smp_ops hooks and the flush_tlb_others pv_op
allow a Xen guest to avoid all APIC code in arch/i386 (the only apic
operation is a single apic_read for the apic version number).One subtle point which needs to be addressed is unpinning pagetables
when another cpu may have a lazy tlb reference to the pagetable. Xen
will not allow an in-use pagetable to be unpinned, so we must find any
other cpus with a reference to the pagetable and get them to shoot
down their references.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Chris Wright
Cc: Benjamin LaHaise
Cc: Ingo Molnar
Cc: Andi Kleen -
Xen implements interrupts in terms of event channels. Each guest
domain gets 1024 event channels which can be used for a variety of
purposes, such as Xen timer events, inter-domain events,
inter-processor events (IPI) or for real hardware IRQs.Within the kernel, we map the event channels to IRQs, and implement
the whole interrupt handling using a Xen irq_chip.Rather than setting NR_IRQ to 1024 under PARAVIRT in order to
accomodate Xen, we create a dynamic mapping between event channels and
IRQs. Ideally, Linux will eventually move towards dynamically
allocating per-irq structures, and we can use a 1:1 mapping between
event channels and irqs.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Chris Wright
Cc: Ingo Molnar
Cc: Eric W. Biederman -
This patch is a rollup of all the core pieces of the Xen
implementation, including:
- booting and setup
- pagetable setup
- privileged instructions
- segmentation
- interrupt flags
- upcalls
- multicall batchingBOOTING AND SETUP
The vmlinux image is decorated with ELF notes which tell the Xen
domain builder what the kernel's requirements are; the domain builder
then constructs the address space accordingly and starts the kernel.Xen has its own entrypoint for the kernel (contained in an ELF note).
The ELF notes are set up by xen-head.S, which is included into head.S.
In principle it could be linked separately, but it seems to provoke
lots of binutils bugs.Because the domain builder starts the kernel in a fairly sane state
(32-bit protected mode, paging enabled, flat segments set up), there's
not a lot of setup needed before starting the kernel proper. The main
steps are:
1. Install the Xen paravirt_ops, which is simply a matter of a
structure assignment.
2. Set init_mm to use the Xen-supplied pagetables (analogous to the
head.S generated pagetables in a native boot).
3. Reserve address space for Xen, since it takes a chunk at the top
of the address space for its own use.
4. Call start_kernel()PAGETABLE SETUP
Once we hit the main kernel boot sequence, it will end up calling back
via paravirt_ops to set up various pieces of Xen specific state. One
of the critical things which requires a bit of extra care is the
construction of the initial init_mm pagetable. Because Xen places
tight constraints on pagetables (an active pagetable must always be
valid, and must always be mapped read-only to the guest domain), we
need to be careful when constructing the new pagetable to keep these
constraints in mind. It turns out that the easiest way to do this is
use the initial Xen-provided pagetable as a template, and then just
insert new mappings for memory where a mapping doesn't already exist.This means that during pagetable setup, it uses a special version of
xen_set_pte which ignores any attempt to remap a read-only page as
read-write (since Xen will map its own initial pagetable as RO), but
lets other changes to the ptes happen, so that things like NX are set
properly.PRIVILEGED INSTRUCTIONS AND SEGMENTATION
When the kernel runs under Xen, it runs in ring 1 rather than ring 0.
This means that it is more privileged than user-mode in ring 3, but it
still can't run privileged instructions directly. Non-performance
critical instructions are dealt with by taking a privilege exception
and trapping into the hypervisor and emulating the instruction, but
more performance-critical instructions have their own specific
paravirt_ops. In many cases we can avoid having to do any hypercalls
for these instructions, or the Xen implementation is quite different
from the normal native version.The privileged instructions fall into the broad classes of:
Segmentation: setting up the GDT and the GDT entries, LDT,
TLS and so on. Xen doesn't allow the GDT to be directly
modified; all GDT updates are done via hypercalls where the new
entries can be validated. This is important because Xen uses
segment limits to prevent the guest kernel from damaging the
hypervisor itself.
Traps and exceptions: Xen uses a special format for trap entrypoints,
so when the kernel wants to set an IDT entry, it needs to be
converted to the form Xen expects. Xen sets int 0x80 up specially
so that the trap goes straight from userspace into the guest kernel
without going via the hypervisor. sysenter isn't supported.
Kernel stack: The esp0 entry is extracted from the tss and provided to
Xen.
TLB operations: the various TLB calls are mapped into corresponding
Xen hypercalls.
Control registers: all the control registers are privileged. The most
important is cr3, which points to the base of the current pagetable,
and we handle it specially.Another instruction we treat specially is CPUID, even though its not
privileged. We want to control what CPU features are visible to the
rest of the kernel, and so CPUID ends up going into a paravirt_op.
Xen implements this mainly to disable the ACPI and APIC subsystems.INTERRUPT FLAGS
Xen maintains its own separate flag for masking events, which is
contained within the per-cpu vcpu_info structure. Because the guest
kernel runs in ring 1 and not 0, the IF flag in EFLAGS is completely
ignored (and must be, because even if a guest domain disables
interrupts for itself, it can't disable them overall).(A note on terminology: "events" and interrupts are effectively
synonymous. However, rather than using an "enable flag", Xen uses a
"mask flag", which blocks event delivery when it is non-zero.)There are paravirt_ops for each of cli/sti/save_fl/restore_fl, which
are implemented to manage the Xen event mask state. The only thing
worth noting is that when events are unmasked, we need to explicitly
see if there's a pending event and call into the hypervisor to make
sure it gets delivered.UPCALLS
Xen needs a couple of upcall (or callback) functions to be implemented
by each guest. One is the event upcalls, which is how events
(interrupts, effectively) are delivered to the guests. The other is
the failsafe callback, which is used to report errors in either
reloading a segment register, or caused by iret. These are
implemented in i386/kernel/entry.S so they can jump into the normal
iret_exc path when necessary.MULTICALL BATCHING
Xen provides a multicall mechanism, which allows multiple hypercalls
to be issued at once in order to mitigate the cost of trapping into
the hypervisor. This is particularly useful for context switches,
since the 4-5 hypercalls they would normally need (reload cr3, update
TLS, maybe update LDT) can be reduced to one. This patch implements a
generic batching mechanism for hypercalls, which gets used in many
places in the Xen code.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Chris Wright
Cc: Ian Pratt
Cc: Christian Limpach
Cc: Adrian Bunk -
Add Xen interface header files. These are taken fairly directly from
the Xen tree, but somewhat rearranged to suit the kernel's conventions.Define macros and inline functions for doing hypercalls into the
hypervisor.Signed-off-by: Jeremy Fitzhardinge
Signed-off-by: Ian Pratt
Signed-off-by: Christian Limpach
Signed-off-by: Chris Wright