mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Daniel Kiper
9841d94c95
Introduction of Linux Kernel git commit ceefccc93932b920a8ec6f35f596db05202a12fe (x86: default CONFIG_PHYSICAL_START and CONFIG_PHYSICAL_ALIGN to 16 MB) revealed deeply hidden bug in pv-grub. During kernel load stage dom->p2m_host[] list has been incorrectly initialized. At the beginning of kernel load stage dom->p2m_host[] list is populated with current PFN->MFN layout. Later during memory allocation (memory is allocated page by page in kexec_allocate()) page order is changed to establish linear layout in new domain. It is done by exchanging subsequent MFNs with newly allocated MFNs. dom->p2m_host[] list is indexed by currently requested PFN (it is incremented from 0) and PFN of newly allocated paged. If PFN of newly allocated page is less than currently requested PFN then earlier allocated MFN is overwritten which leads to domain crash later. This patch corrects that issue. If PFN of newly allocated page is less then currently requested PFN then relevant PFN/MFN pair is properly calculated and usual exchange occurs later. Signed-off-by: Daniel Kiper <dkiper@net-space.pl> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
IOEMU stubdom
=============
This boosts HVM performance by putting ioemu in its own lightweight domain.
General Configuration
=====================
Due to a race between the creation of the IOEMU stubdomain itself and allocation
of video memory for the HVM domain, you need to avoid the need for ballooning,
by using the hypervisor dom0_mem= option for instance.
There is a sample configuration set in xmexample.hvm-stubdom
In your HVM config "hvmconfig" use stubdom-dm as dm script:
device_model = 'stubdom-dm'
To run
======
mkdir -p /exports/usr/share/xen/qemu
ln -s /usr/share/xen/qemu/keymaps /exports/usr/share/xen/qemu
mkdir -p /exports/var/lib
ln -s /var/lib/xen /exports/var/lib
/usr/sbin/fs-backend &
xm create hvmconfig
PV-GRUB
=======
This replaces pygrub to boot domU images safely: it runs the regular grub
inside the created domain itself and uses regular domU facilities to read the
disk / fetch files from network etc. ; it eventually loads the PV kernel and
chain-boots it.
Configuration
=============
In your PV config,
- use pv-grub.gz as kernel:
kernel = "pv-grub.gz"
- set the path to menu.lst, as seen from the domU, in extra:
extra = "(hd0,0)/boot/grub/menu.lst"
or you can provide the content of a menu.lst stored in dom0 by passing it as a
ramdisk:
ramdisk = "/boot/domU-1-menu.lst"
or you can also use a tftp path (dhcp will be automatically performed):
extra = "(nd)/somepath/menu.lst"
or you can set it in option 150 of your dhcp server and leave extra and ramdisk
empty (dhcp will be automatically performed)
Limitations
===========
- You can not boot a 64bit kernel with a 32bit-compiled PV-GRUB and vice-versa.
To cross-compile a 32bit PV-GRUB,
export XEN_TARGET_ARCH=x86_32
- bootsplash is supported, but the ioemu backend does not yet support restart
for use by the booted kernel.
- PV-GRUB doesn't support virtualized partitions. For instance:
disk = [ 'phy:hda7,hda7,w' ]
will be seen by PV-GRUB as (hd0), not (hd0,6), since GRUB will not see any
partition table.
Your own stubdom
================
By running
cd stubdom/
make c-stubdom
or
cd stubdom/
make caml-stubdom
you can compile examples of C or caml stub domain kernels. You can use these
and the relevant Makefile rules as basis to build your own stub domain kernel.
Available libraries are libc, libxc, libxs, zlib and libpci.