pool/xen
SHA256
2
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

- bnc#879425: handle cache=unsafe from libvirt to disable flush in qdisk

Browse Source 
libxl.add-option-to-disable-disk-cache-flushes-in-qdisk.patch
  qemu-xen-upstream-qdisk-cache-unsafe.patch

- libxl: introduce an option for disabling the non-O_DIRECT workaround
  recognize direct-io-safe in domU.cfg diskspec
  libxl.introduce-an-option-to-disable-the-non-O_DIRECT-workaround.patch
  

- fate#316071: add discard support for file backed storage (qdisk)
  update patch to allow more values in overloaded ->readwrite member

- bnc#826717 - VUL-0: CVE-2013-3495: XSA-59: xen: Intel VT-d
  Interrupt Remapping engines can be evaded by native NMI interrupts 
  537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch
  537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch
- Upstream patches from Jan
  53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch
  53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch
  537b5ede-move-domain-to-cpupool0-before-destroying-it.patch

- Update README.SuSE with information on the toolstack change

- fate#316071: add discard support for file backed storage (qdisk)
  update to recognize option discard/no-discard instead of discard=0,1
  to match upstream change

OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=316
This commit is contained in:
Charles Arnold 2014-05-29 22:55:47 +00:00 committed by Git OBS Bridge
parent 3c2f525a91
commit fb53ca5547
13 changed files with 807 additions and 135 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch Normal file
View File

@ -0,0 +1,31 @@
# Commit 99c03bc6a1f8c6722926d2db781ece045f9d09ae
# Date 2014-05-12 11:59:19 +0200
# Author Edmund H White <edmund.h.white@intel.com>
# Committer Jan Beulich <jbeulich@suse.com>
Nested VMX: load current_vmcs only when it exists
There may not have valid vmcs on current CPU. So only load it when it exists.
This original fixing is from Edmud <edmund.h.white@intel.com>.
Signed-off-by: Edmund H White <edmund.h.white@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -828,8 +828,12 @@ void virtual_vmcs_enter(void *vvmcs)
void virtual_vmcs_exit(void *vvmcs)
{
+ struct vmcs_struct *cur = this_cpu(current_vmcs);
+
__vmpclear(pfn_to_paddr(domain_page_map_to_mfn(vvmcs)));
- __vmptrld(virt_to_maddr(this_cpu(current_vmcs)));
+ if ( cur )
+ __vmptrld(virt_to_maddr(cur));
+
}
u64 virtual_vmcs_vmread(void *vvmcs, u32 vmcs_encoding)

26
53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch Normal file
View File

@ -0,0 +1,26 @@
# Commit a07084525c126c596326dc1442dd218f522f51b4
# Date 2014-05-14 10:54:39 +0200
# Author Kai Huang <kai.huang@linux.intel.com>
# Committer Jan Beulich <jbeulich@suse.com>
x86/MCE: bypass uninitialized vcpu in vMCE injection
Dom0 may bring up less number of vCPUs than xen hypervisor actually created for
it, and in this case, on Intel platform, vMCE injection to dom0 will fail due to
injecting vMCE to uninitialized vcpu, and cause dom0 crash.
Signed-off-by: Kai Huang <kai.huang@linux.intel.com>
Acked-by: Christoph Egger <chegger@amazon.de>
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -357,6 +357,10 @@ int inject_vmce(struct domain *d, int vc
if ( vcpu != VMCE_INJECT_BROADCAST && vcpu != v->vcpu_id )
continue;
+ /* Don't inject to uninitialized VCPU. */
+ if ( !v->is_initialised )
+ continue;
+
if ( (has_hvm_container_domain(d) ||
guest_has_trap_callback(d, v->vcpu_id, TRAP_machine_check)) &&
!test_and_set_bool(v->mce_pending) )

83
537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch Normal file
View File

@ -0,0 +1,83 @@
# Commit 5786718fbaafbe47d72cc1512cd93de79b8fc2fa
# Date 2014-05-20 15:53:20 +0200
# Author Jan Beulich <jbeulich@suse.com>
# Committer Jan Beulich <jbeulich@suse.com>
VT-d: apply quirks at device setup time rather than only at boot
Accessing extended config space may not be possible at boot time, e.g.
when the memory space used by MMCFG is reserved only via ACPI tables,
but not in the E820/UEFI memory maps (which we need Dom0 to tell us
about). Consequently the change here still leaves the issue unaddressed
for systems where the extended config space remains inaccessible (due
to firmware bugs, i.e. not properly reserving the address space of
those regions).
With the respective messages now potentially getting logged more than
once, we ought to consider whether we should issue them only if we in
fact were required to do any masking (i.e. if the relevant mask bits
weren't already set).
This is CVE-2013-3495 / XSA-59.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
Acked-by: Yang Zhang <yang.z.zhang@intel.com>
--- a/xen/drivers/passthrough/vtd/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -99,7 +99,7 @@ void platform_quirks_init(void);
void vtd_ops_preamble_quirk(struct iommu* iommu);
void vtd_ops_postamble_quirk(struct iommu* iommu);
void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map);
-void pci_vtd_quirk(struct pci_dev *pdev);
+void pci_vtd_quirk(const struct pci_dev *);
int platform_supports_intremap(void);
int platform_supports_x2apic(void);
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1483,6 +1483,9 @@ static int domain_context_mapping(
break;
}
+ if ( !ret && devfn == pdev->devfn )
+ pci_vtd_quirk(pdev);
+
return ret;
}
@@ -1922,6 +1925,8 @@ static int intel_iommu_enable_device(str
struct acpi_drhd_unit *drhd = acpi_find_matched_drhd_unit(pdev);
int ret = drhd ? ats_device(pdev, drhd) : -ENODEV;
+ pci_vtd_quirk(pdev);
+
if ( ret <= 0 )
return ret;
@@ -1993,12 +1998,7 @@ static int intel_iommu_remove_device(u8
static int __init setup_dom0_device(u8 devfn, struct pci_dev *pdev)
{
- int err;
-
- err = domain_context_mapping(pdev->domain, devfn, pdev);
- if ( !err && devfn == pdev->devfn )
- pci_vtd_quirk(pdev);
- return err;
+ return domain_context_mapping(pdev->domain, devfn, pdev);
}
void clear_fault_bits(struct iommu *iommu)
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -385,7 +385,7 @@ void me_wifi_quirk(struct domain *domain
* - This can cause system failure upon non-fatal VT-d faults
* - Potential security issue if malicious guest trigger VT-d faults
*/
-void __init pci_vtd_quirk(struct pci_dev *pdev)
+void pci_vtd_quirk(const struct pci_dev *pdev)
{
int seg = pdev->seg;
int bus = pdev->bus;

57
537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch Normal file
View File

@ -0,0 +1,57 @@
# Commit 04734664eb20c3bf239e473af182bb7ab901d779
# Date 2014-05-20 15:54:01 +0200
# Author Jan Beulich <jbeulich@suse.com>
# Committer Jan Beulich <jbeulich@suse.com>
VT-d: extend error report masking workaround to newer chipsets
Add two more PCI IDs to the set that has been taken care of with a
different workaround long before XSA-59, and (for constency with the
newer workarounds) log a message here too.
Also move the function wide comment to the cases it applies to; this
should really have been done by d061d200 ("VT-d: suppress UR signaling
for server chipsets").
This is CVE-2013-3495 / XSA-59.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
Acked-by: Yang Zhang <yang.z.zhang@intel.com>
--- a/xen/drivers/passthrough/vtd/quirks.c
+++ b/xen/drivers/passthrough/vtd/quirks.c
@@ -379,12 +379,6 @@ void me_wifi_quirk(struct domain *domain
}
}
-/*
- * Mask reporting Intel VT-d faults to IOH core logic:
- * - Some platform escalates VT-d faults to platform errors
- * - This can cause system failure upon non-fatal VT-d faults
- * - Potential security issue if malicious guest trigger VT-d faults
- */
void pci_vtd_quirk(const struct pci_dev *pdev)
{
int seg = pdev->seg;
@@ -402,10 +396,20 @@ void pci_vtd_quirk(const struct pci_dev
switch ( pci_conf_read16(seg, bus, dev, func, PCI_DEVICE_ID) )
{
+ /*
+ * Mask reporting Intel VT-d faults to IOH core logic:
+ * - Some platform escalates VT-d faults to platform errors.
+ * - This can cause system failure upon non-fatal VT-d faults.
+ * - Potential security issue if malicious guest trigger VT-d faults.
+ */
+ case 0x0e28: /* Xeon-E5v2 (IvyBridge) */
case 0x342e: /* Tylersburg chipset (Nehalem / Westmere systems) */
+ case 0x3728: /* Xeon C5500/C3500 (JasperForest) */
case 0x3c28: /* Sandybridge */
val = pci_conf_read32(seg, bus, dev, func, 0x1AC);
pci_conf_write32(seg, bus, dev, func, 0x1AC, val | (1 << 31));
+ printk(XENLOG_INFO "Masked VT-d error signaling on %04x:%02x:%02x.%u\n",
+ seg, bus, dev, func);
break;
/* Tylersburg (EP)/Boxboro (MP) chipsets (NHM-EP/EX, WSM-EP/EX) */

53
537b5ede-move-domain-to-cpupool0-before-destroying-it.patch Normal file
View File

@ -0,0 +1,53 @@
# Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a
# Date 2014-05-20 15:55:42 +0200
# Author Juergen Gross <juergen.gross@ts.fujitsu.com>
# Committer Jan Beulich <jbeulich@suse.com>
move domain to cpupool0 before destroying it
Currently when a domain is destroyed it is removed from the domain_list
before all of it's resources, including the cpupool membership, are freed.
This can lead to a situation where the domain is still member of a cpupool
without for_each_domain_in_cpupool() (or even for_each_domain()) being
able to find it any more. This in turn can result in rejection of removing
the last cpu from a cpupool, because there seems to be still a domain in
the cpupool, even if it can't be found by scanning through all domains.
This situation can be avoided by moving the domain to be destroyed to
cpupool0 first and then remove it from this cpupool BEFORE deleting it from
the domain_list. As cpupool0 is always active and a domain without any cpupool
membership is implicitly regarded as belonging to cpupool0, this poses no
problem.
Signed-off-by: Juergen Gross <juergen.gross@ts.fujitsu.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -539,6 +539,8 @@ int domain_kill(struct domain *d)
BUG_ON(rc != -EAGAIN);
break;
}
+ if ( sched_move_domain(d, cpupool0) )
+ return -EAGAIN;
for_each_vcpu ( d, v )
unmap_vcpu_info(v);
d->is_dying = DOMDYING_dead;
@@ -721,8 +723,6 @@ static void complete_domain_destroy(stru
sched_destroy_domain(d);
- cpupool_rm_domain(d);
-
/* Free page used by xen oprofile buffer. */
#ifdef CONFIG_XENOPROF
free_xenoprof_pages(d);
@@ -770,6 +770,8 @@ void domain_destroy(struct domain *d)
if ( _atomic_read(old) != 0 )
return;
+ cpupool_rm_domain(d);
+
/* Delete from task list and task hashtable. */
TRACE_1D(TRC_SCHED_DOM_REM, d->domain_id);
spin_lock(&domlist_update_lock);

221
README.SuSE
View File

@ -5,8 +5,8 @@ This file contains SUSE-specific instructions and suggestions for using Xen.
For more in-depth documentation of using Xen on SUSE, consult the
virtualization chapter in the SLES or SUSE Linux manual, or read up-to-date
virtualization information, including a list of known issues, at
http://www.novell.com/documentation/vmserver/.
virtualization information, at
https://www.suse.com/documentation/sles11/singlehtml/book_xen/book_xen.html
For more complete documentation on Xen itself, please install one of the
xen-doc-* packages and read the documentation installed into
@ -30,13 +30,10 @@ If you want to install and manage VMs graphically, be sure to install a
graphical desktop environment like KDE or GNOME. The following optional
packages are needed to manage VMs graphically. Note that "Install Hypervisor
and Tools" installs all the packages below:
vm-install (Optional, to install VMs)
virt-install (Optional, to install VMs)
virt-manager (Optional, to manage VMs graphically)
virt-viewer (Optional, to view VMs outside virt-manager)
Additional packages:
nbd-client (Optional, to access virtual disks stored on NBD servers)
open-iscsi (Optional, to access virtual disks stored on iSCSI targets)
vm-install (Optional, to install VMs with xl only)
You then need to reboot your machine. Instead of booting a normal Linux
kernel, you will boot the Xen hypervisor and a slightly changed Linux kernel.
@ -66,7 +63,7 @@ domain 0 may sometimes be referred to as a dom0 kernel.
is unprivileged (that is, it cannot control other domains). A kernel used in
an unprivileged domain may be referred to as a domU kernel.
Novell documentation will use the more industry-standard term "virtual
SUSE documentation will use the more industry-standard term "virtual
machine", or "VM", rather than "domain" where possible. And to that end,
domain 0 will be called the "virtual machine server", since it essentially the
server on which the other VMs run. All other domains are simply "virtual
@ -110,25 +107,8 @@ If you installed Xen during the initial SUSE installation, or installed one
of the kernel-xen* packages later, a "XEN" option should exist in your Grub
bootloader. Select that to boot SUSE on top of Xen.
If you want to add additional entries, or modify the existing ones, you will
have to edit Grub yourself. All Xen entries in the Grub configuration file
(usually /boot/grub/menu.lst) look something like this:
title XEN
root (hd0,5)
kernel /xen.gz
module /vmlinuz-xen <parameters>
module /initrd-xen
Replace (hd0,5) with the partition that holds your /boot directory in
grub-speak, e.g., hda1 -> (hd0,0) and sda5 -> (hd2,4).
Normally, xen.gz requires no parameters. If you want to add parameters,
see below.
Replace "<parameters>" with the kernel parameters that you want to pass to
your kernel. These should be very similar, if not identical, to those passed
to a normal kernel that you boot on bare iron.
If you want to add additional entries, or modify the existing ones, you may
run the YaST2 Boot Loader program.
Once you have booted this configuration successfully, you are running Xen with
a privileged kernel on top of it.
@ -139,44 +119,40 @@ Xen Boot Parameters
Normally, xen.gz requires no parameters. However, in special cases (such as
debugging or a dedicated VM server) you may wish to pass it parameters.
Adding parameters to xen.gz can be done by editing the /etc/default/grub file.
Add the following line to this file; GRUB_CMDLINE_XEN="<parameters>". The
parameters may be valid options passed to xen.gz (the hypervisor). After
editing this file, you must run 'grub2-mkconfig -o /boot/grub2/grub.cfg' for
the changes to take effect and then reboot.
In particular in case of problems you may want to attach a serial terminal and
direct Xen to send its output not only to the screen, but also to that
terminal. In order to do so, add "console=vga,com<n> com<n>=<baud>" (without
the quotes and with <n> replaced by the serial port number - generally 1 or 2 -
and with <baud> replaced by the baud rate the serial terminal is configured
for) to the xen.gz line.
for) to the GRUB_CMDLINE_XEN line.
For a more complete discussion of possible parameters, see the user
documentation in the xen-doc-* packages.
Init scripts
------------
Before you can create additional VMs (or use any other xm command) xend must
be running. This init script is part of the xen-tools package, and it is
activated at installation time. You can (de)activate it using insserv. You
can also start it manually with "rcxend start".
The deprecated xendomains script is also shipped, but disabled by default. In
SLES 10 GA (xen 3.0.2) and older, this script allowed VMs to be started and
stopped automatically when the machine starts and stops. In SLES 10 SP1 (xen
3.0.4) and newer, the proper way to start and stop VMs automatically is to set
the "on_xend_start" and "on_xend_stop" settings in the VMs configuration.
(Deprecating xendomains was necessary because xend, not the configuration file
in /etc/xen/vm, is now the authoritative source for the VM's settings.)
Consult the online documentation for more information.
Creating a VM with vm-install
-----------------------------
The vm-install program (part of the vm-install package, and accessible
Creating a VM with virt-install
-------------------------------
The virt-install program (part of the virt-install package, and accessible
through YaST's Control Center) is the recommended method to create VMs. This
program handles creating both the VM's configuration file and disk(s). It can
help install any operating system, not just SUSE.
program handles creating both the VM's libvirt XML definition and disk(s).
It can help install any operating system, not just SUSE. Virt-install has both
a command line only mode and a graphical wizard mode that may be used to define
and start VM installations.
From the command line, run "vm-install". If the DISPLAY environment variable
is set and the supporting packages (python-gtk) are installed, a graphical
wizard will start. Otherwise, a text wizard will start.
Virt-install may be launched from the virt-manager VM management tool. After
starting virt-manager either from the YaST Control Center or by starting
it from the command line. The installation icon from the main virt-manager
screen may be selected to begin the virt-install installation wizard.
The use of virt-install or virt-manager requires the installation of the
libvirt packages and the libvirt daemon must be running on the host unless
you are managing a remote host.
Each VM needs to have its own root filesystem. The root filesystem can live
on a block device (e.g., a hard disk partition, or an LVM2 or EVMS volume) or
@ -193,6 +169,29 @@ boots. (See "Network Troubleshooting" below.) XenSource has been allocated a
range of MAC addresses with the OUI of 00-16-3E. By using MACs from this
range you can be sure they will not conflict with any physical adapters.
When the VM shuts down (because the installation -- or at least the first
stage of it -- is done), the wizard finalizes the VM's configuration and
restarts the VM.
The creation of VMs can be automated; read the virt-install man page for more
details. The installation of an OS within the VM can be automated if the OS
supports it.
Creating a VM with vm-install
-----------------------------
The vm-install program is also provided to create VMs. Like virt-install,
this optional program handles creating both the VM's Libvirt XML definition
and disk(s). It also creates a legacy configuration file for use with 'xl'.
It can help install any operating system, not just SUSE.
From the command line, run "vm-install". If the DISPLAY environment variable
is set and the supporting packages (python-gtk) are installed, a graphical
wizard will start. Otherwise, a text wizard will start. If vm-install is
started with the '--use-xl' flag, it will not require libvirt nor attempt
to communicate with libvirt when creating a VM and instead will only use the
'xl' toolstack to start VM installations.
Once you have the VM configured, click "OK". The wizard will now create a
configuration file for the VM, and create a disk image. The disk image will
exist in /var/lib/xen/images, and a corresponding config file will exist in
@ -210,7 +209,7 @@ supports it.
Creating a VM Manually
----------------------
If you create a VM manually (as opposed to using vm-install, which is the
If you create a VM manually (as opposed to using virt-install, which is the
recommended way), you will need to create a disk (or reuse an existing one)
and a configuration file.
@ -222,48 +221,68 @@ The kernel and ramdisk used to bootstrap the VM must match any kernel modules
that might be present in the VM's disk. It is possible to manually copy the
kernel and ramdisk from the VM's disk (for example, after updating the kernel
within that VM) to the VM server's filesystem. However, an easier (and less
error-prone) method is to use something called the "domUloader". Before a new
error-prone) method is to use something called the "pygrub". Before a new
VM is started, this loader automatically copies the kernel and ramdisk into
the VM server's filesystem, so that it can be used to bootstrap the new VM.
See /etc/xen/examples/xmexample.domUloader for an example.
Next, make a copy of one of the /etc/xen/examples/* files, and modify it to
suit your needs. For paravirtualized VMs, start with
/etc/xen/examples/xmexample1; for fully virtualized VMs, start with
/etc/xen/examples/xmexample.hvm. You'll need to change (at very least) the
"name" and "disk" parameters.
suit your needs. You'll need to change (at very least) the "name" and "disk"
parameters. See /etc/xen/examples/ for example configuration files.
Managing Virtual Machines
-------------------------
VMs can be managed from the command line or from virt-manager.
VMs can be managed from the command line using 'virsh' or from virt-manager.
Before a VM can be started, xend must be informed of it. vm-install will
automatically import new VM configurations into xend. However, if you copy a
VM from another machine, or manually create a VM configuration file, you will
need to import it into xend with a command like:
xm new my-vm
If your VM's configuration file is not located in /etc/xen/vm, you must
specify the full path. This imports the configuration into xend (and
therefore virt-manager becomes aware of it, also).
VMs created by virt-install or vm-install (without vm-install's --use-xl flag)
will automatically be defined in libvirt. VMs defined in libvirt may be managed
by virt-manager or from the command line using the 'virsh' command. However,
if you copy a VM from another machine and manually create a VM XML configuration
file, you will need to import it into libvirt with a command like:
virsh define <path to>/my-vm.xml
This imports the configuration into libvirt (and therefore virt-manager becomes
aware of it, also).
Now to start the VM:
xm start my-vm
or start it graphically from virt-manager.
virsh start my-vm
or start it from virt-manager's graphical menu.
Have a look at running sessions with "xm list". Note the ID of the newly
created VM. Attach to the VM's text console with "xm console <ID>" (replacing
ID with the VM's ID). Attaching to multiple VM consoles is most conveniently
done with the terminal multiplexer "screen".
Have a look at running sessions with "virsh list". Note the ID of the newly
created VM. Attach to the VM's text console with "virsh console <ID>"
(replacing ID with the VM's ID). Attaching to multiple VM consoles is most
conveniently done with the terminal multiplexer "screen".
Have a look at the other xm commands by typing "xm help". Note that most xm
commands must be done as root.
Have a look at the other virsh commands by typing "virsh help". Note that most
virsh commands must be done as root.
Changes in the Xen VM Management Toolstack
------------------------------------------
With SUSE Linux Enterprise Server 12, the way VMs are managed has changed
when compared with older SLES versions. Users familiar with the 'xm' command
and the xend management daemon will notice that these are absent. The xm/xend
toolstack has been replaced with the xl toolstack. The xl toolstack is
intended to remain backwards compatible with existing xm domain configuration
files. Most 'xm' commands can simply be replaced with 'xl'. One significant
difference is that xl does not support the concept of Managed Domains. The xl
command can only modifiy running VMs. Once the VM is shutdown, there is no
preserved state information other than what is saved in the configuration
file used to start the VM. In order to provide Managed Domains, users are
encouraged to use libvirt and it's tools to create and modify VMs. These
tools include the command line tool 'virsh' and the graphical tools
virt-manager and virt-install.
Warning: Using xl commands to modify libvirt managed domains will result in
errors when virsh or virt-manager is used. Please use only virsh or
virt-manager to manage libvirt managed domains. If you are not using libvirt
managed domains then using xl commands is the correct way to modify running
domains.
Using the Mouse via VNC in Fully Virtual Mode
---------------------------------------------
In a fully virtualized VM, the mouse may be emulated as a PS/2 mouse, USB
mouse, or USB tablet. The vm-install tool selects the best emulation that is
mouse, or USB tablet. The virt-install tool selects the best emulation that is
known to be automatically detected and supported by the operating system.
However, when accessing some fully virtualized operating systems via VNC, the
@ -302,13 +321,6 @@ Section "InputDevice"
EndSection
After making these changes, restart gpm and X.
To ensure the VM is emulating a USB tablet, add these lines to the
configuration file in /etc/xen/vm:
usb=1
usbdevice='tablet'
Then re-import the configuration into xend:
xm new my-vm
HVM Console in Fully Virtual Mode
---------------------------------
@ -411,10 +423,8 @@ compromised, all other domains are compromised as well.
To allow relocation of VMs (migration), the receiving machine listens on TCP
port 8002. You might want to put firewall rules in place in domain 0 to
restrict this to machines which you trust. You have some access control in
xend-config.sxp as well by tweaking the xend-relocation-hosts-allow
setting. Relocating VMs with sensitive data is not a good idea in untrusted
networks, since the data is not sent encrypted.
restrict this to machines which you trust. Relocating VMs with sensitive data
is not a good idea in untrusted networks, since the data is not sent encrypted.
The memory protections for the domUs are effective; so far no way to break out
of a virtual machine is known. A VM is an effective jail.
@ -457,7 +467,7 @@ that is reflected in the file's name.
Troubleshooting
---------------
First try to get Linux running on bare iron before trying with Xen.
First try to get Linux running on bare metal before trying with Xen.
Be sure your Xen hypervisor (xen) and VM kernels (kernel-xen) are compatible.
The hypervisor and domain 0 kernel are a matched set, and usually must be
@ -491,7 +501,7 @@ Grub configuration from something like this:
To something like this:
kernel (hd0,5)/xen-dbg.gz noreboot
After rebooting, the Xen hypervisor will write any error messages to the log
file (viewable with the "xm dmesg" command).
file (viewable with the "xl dmesg" command).
If problems persist, check if a newer version is available. Well-tested
versions will be shipped with SUSE and via YaST Online Update. More frequent
@ -502,10 +512,20 @@ versions will be shipped with SUSE and via YaST Online Update. More frequent
Upgrading the Host Operating System
-----------------------------------
When upgrading the host operating system from one major release to another
(for example, SLES 10 to SLES 11 or openSUSE 11.4 to openSUSE 12.1) or when
applying a service pack like SLES 11 SP2 to SLES 11 SP1 all running VMs must
(for example, SLES 11 to SLES 12 or openSUSE 12.3 to openSUSE 13.1) or when
applying a service pack like SLES 11 SP3 to SLES 11 SP2 all running VMs must
be shut down before the upgrade process is begun.
On versions of SLES 11 and openSUSE 12 you are using the xm/xend toolstack.
After upgrading to SLES 12 and newer openSUSE versions this toolstack will be
replaced with the xl toolstack. The xl toolstack does not support Managed
Domains. If you wish to continue using Managed Domains you must switch to
using libvirt and its command line interface 'virsh'. You may also use
virt-manager as a GUI interface to libvirt. After upgrading the host but
before you can begin using libvirt on VMs that were previously managed by
xm/xend, you must run a conversion tool called /usr/sbin/xen2libvirt for all
VMs. Run 'xen2libvirt -h' to see the syntax for using this tool.
Memory Ballooning in VMs
------------------------
@ -519,9 +539,10 @@ maxmem value may be increased. A reboot of the VM is required for this action
to take effect.
Known Issues
------------
For a list of known issues and work-arounds, see
Resources
---------
https://www.suse.com/documentation/sles11/singlehtml/book_xen/book_xen.html
http://doc.opensuse.org/products/draft/SLES/SLES-xen_sd_draft/cha.xen.basics.html
http://www.novell.com/documentation/vmserver/.
@ -540,10 +561,10 @@ Feedback
In case you have remarks about, problems with, ideas for, or praise for Xen,
please report it back to the xen-devel list:
xen-devel@lists.xensource.com
If you find issues with the packaging or setup done by Novell/SUSE, please
report it to:
http://www.suse.de/feedback/
If you find issues with the packaging or setup done by SUSE, please report
it through bugzilla:
https://bugzilla.novell.com
ENJOY!
Your Novell SUSE Team.
Your SUSE Team.

69
libxl.add-option-for-discard-support-to-xl-disk-conf.patch
View File

@ -1,55 +1,57 @@
References: FATE#316071
Subject: libxl: add option for discard support to xl disk configuration
Handle new option discard=on|off for disk configuration. It is supposed
to disable discard support if file based backing storage was
Handle new boolean option discard/no-discard for disk configuration. It
is supposed to disable discard support if file based backing storage was
intentionally created non-sparse to avoid fragmentation of the file.
The option is a boolean and intended for the backend driver. A new
boolean property "discard-enable" is written to the backend node. An
upcoming patch for qemu will make use of this property. The kernel
blkback driver may be updated as well to disable discard for phy based
backing storage.
The option intended for the backend driver. A new boolean property
"discard-enable" is written to the backend node. An upcoming patch for
qemu will make use of this property. The kernel blkback driver may be
updated as well to disable discard for phy based backing storage.
This change does not break ABI. Instead of adding a new member ->discard_enable
to struct libxl_device_disk the existing ->readwrite member is reused.
This change does not break ABI. Instead of adding a new member
discard_enable to struct libxl_device_disk the existing readwrite member
is reused.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
---
docs/misc/xl-disk-configuration.txt | 15 +++++++++++++++
docs/misc/xl-disk-configuration.txt | 17 +++++++++++++++++
tools/libxl/libxl.c | 2 ++
tools/libxl/libxl.h | 11 +++++++++++
tools/libxl/libxl.h | 12 ++++++++++++
tools/libxl/libxlu_disk.c | 3 +++
tools/libxl/libxlu_disk_i.h | 2 +-
tools/libxl/libxlu_disk_l.l | 4 ++++
6 files changed, 36 insertions(+), 1 deletion(-)
tools/libxl/libxlu_disk_l.l | 2 ++
6 files changed, 37 insertions(+), 1 deletion(-)
Index: xen-4.4.0-testing/docs/misc/xl-disk-configuration.txt
===================================================================
--- xen-4.4.0-testing.orig/docs/misc/xl-disk-configuration.txt
+++ xen-4.4.0-testing/docs/misc/xl-disk-configuration.txt
@@ -178,6 +178,21 @@ information to be interpreted by the exe
These scripts are normally called "block-<script>".
@@ -179,6 +179,23 @@ These scripts are normally called "block
+discard=<boolean>
+discard / no-discard
+---------------
+
+Description: Instruct backend to advertise discard support to frontend
+Supported values: on, off, 0, 1
+Description: Request backend to advertise discard support to frontend
+Supported values: discard
+ no-discard
+Mandatory: No
+Default value: on if, available for that backend typ
+Default value: discard
+
+This option is an advisory setting for the backend driver, depending of the
+value, to advertise discard support (TRIM, UNMAP) to the frontend. The real
+benefit of this option is to be able to force it off rather than on. It allows
+to disable "hole punching" for file based backends which were intentionally
+created non-sparse to avoid fragmentation of the file.
+An advisory setting for the backend driver, specifying whether, to
+advertise discard support (TRIM, UNMAP) to the frontend. The real
+benefit of this option is to be able to force it off rather than on. It
+can be used to disable "hole punching" for file based backends which
+were intentionally created non-sparse to avoid fragmentation of the
+file.
+
+
============================================
DEPRECATED PARAMETERS, PREFIXES AND SYNTAXES
============================================
Index: xen-4.4.0-testing/tools/libxl/libxl.c
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxl.c
@ -58,7 +60,7 @@ Index: xen-4.4.0-testing/tools/libxl/libxl.c
flexarray_append(back, disk->readwrite ? "w" : "r");
flexarray_append(back, "device-type");
flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+ if (disk->readwrite == LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC)
+ if ((disk->readwrite & ~LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK) == LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC)
+ flexarray_append_pair(back, "discard-enable", "0");
flexarray_append(front, "backend-id");
@ -67,7 +69,7 @@ Index: xen-4.4.0-testing/tools/libxl/libxl.h
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxl.h
+++ xen-4.4.0-testing/tools/libxl/libxl.h
@@ -95,6 +95,17 @@
@@ -95,6 +95,18 @@
#define LIBXL_HAVE_BUILDINFO_EVENT_CHANNELS 1
/*
@ -79,7 +81,8 @@ Index: xen-4.4.0-testing/tools/libxl/libxl.h
+ * readwrite == MAGIC: disk is readwrite, backend driver should not offer
+ * discard to the frontend driver.
+ */
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC 0xdcadU
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC 0x00000060U
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK 0xffffff0fU
+
+/*
* libxl ABI compatibility
@ -94,7 +97,7 @@ Index: xen-4.4.0-testing/tools/libxl/libxlu_disk.c
}
+ if (disk->readwrite && dpc.disable_discard)
+ disk->readwrite = LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC;
+ disk->readwrite = (disk->readwrite & LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK) | LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC;
+
if (!disk->vdev) {
xlu__disk_err(&dpc,0, "no vdev specified");
@ -116,14 +119,12 @@ Index: xen-4.4.0-testing/tools/libxl/libxlu_disk_l.l
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk_l.l
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk_l.l
@@ -173,6 +173,10 @@ backendtype=[^,]*,? { STRIP(','); setbac
@@ -173,6 +173,8 @@ backendtype=[^,]*,? { STRIP(','); setbac
vdev=[^,]*,? { STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); }
script=[^,]*,? { STRIP(','); SAVESTRING("script", script, FROMEQUALS); }
+discard=on,? { DPC->disable_discard = 0; }
+discard=1,? { DPC->disable_discard = 0; }
+discard=off,? { DPC->disable_discard = 1; }
+discard=0,? { DPC->disable_discard = 1; }
+discard,? { DPC->disable_discard = 0; }
+no-discard,? { DPC->disable_discard = 1; }
/* the target magic parameter, eats the rest of the string */

83
libxl.add-option-to-disable-disk-cache-flushes-in-qdisk.patch Normal file
View File

@ -0,0 +1,83 @@
https://bugzilla.novell.com/show_bug.cgi?id=879425
---
tools/libxl/libxl.c | 2 ++
tools/libxl/libxl.h | 12 ++++++++++++
tools/libxl/libxlu_disk.c | 2 ++
tools/libxl/libxlu_disk_i.h | 2 +-
tools/libxl/libxlu_disk_l.l | 1 +
5 files changed, 18 insertions(+), 1 deletion(-)
Index: xen-4.4.0-testing/tools/libxl/libxl.c
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxl.c
+++ xen-4.4.0-testing/tools/libxl/libxl.c
@@ -2484,6 +2484,8 @@ static void device_disk_add(libxl__egc *
flexarray_append_pair(back, "direct-io-safe", "1");
if ((disk->readwrite & ~LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK) == LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC)
flexarray_append_pair(back, "discard-enable", "0");
+ if ((disk->readwrite & ~LIBXL_HAVE_LIBXL_DEVICE_DISK_DISABLE_FLUSH_MASK) == LIBXL_HAVE_LIBXL_DEVICE_DISK_DISABLE_FLUSH_MAGIC)
+ flexarray_append_pair(back, "suse-diskcache-disable-flush", "1");
flexarray_append(front, "backend-id");
flexarray_append(front, libxl__sprintf(gc, "%d", disk->backend_domid));
Index: xen-4.4.0-testing/tools/libxl/libxl.h
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxl.h
+++ xen-4.4.0-testing/tools/libxl/libxl.h
@@ -118,6 +118,18 @@
#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK 0xffffff0fU
/*
+ * The libxl_device_disk has no way to indicate that cache=unsafe is
+ * supposed to be used. Provide this knob without breaking the ABI.
+ * This is done by overloading struct libxl_device_disk->readwrite:
+ * readwrite == 0: disk is readonly, no discard
+ * readwrite == 1: disk is readwrite, backend driver may enable discard
+ * readwrite == MAGIC: disk is readwrite, backend driver should ignore
+ * flush requests from the frontend driver.
+ */
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISABLE_FLUSH_MAGIC 0x00006000U
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DISABLE_FLUSH_MASK 0xffff0fffU
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
Index: xen-4.4.0-testing/tools/libxl/libxlu_disk.c
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk.c
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk.c
@@ -84,6 +84,8 @@ int xlu_disk_parse(XLU_Config *cfg,
disk->readwrite = (disk->readwrite & LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MASK) | LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MAGIC;
if (disk->readwrite && dpc.disable_discard)
disk->readwrite = (disk->readwrite & LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK) | LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC;
+ if (disk->readwrite && dpc.suse_diskcache_disable_flush)
+ disk->readwrite = (disk->readwrite & LIBXL_HAVE_LIBXL_DEVICE_DISK_DISABLE_FLUSH_MASK) | LIBXL_HAVE_LIBXL_DEVICE_DISK_DISABLE_FLUSH_MAGIC;
if (!disk->vdev) {
xlu__disk_err(&dpc,0, "no vdev specified");
Index: xen-4.4.0-testing/tools/libxl/libxlu_disk_i.h
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk_i.h
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk_i.h
@@ -10,7 +10,7 @@ typedef struct {
void *scanner;
YY_BUFFER_STATE buf;
libxl_device_disk *disk;
- int access_set, direct_io_safe, disable_discard, had_depr_prefix;
+ int access_set, suse_diskcache_disable_flush, direct_io_safe, disable_discard, had_depr_prefix;
const char *spec;
} DiskParseContext;
Index: xen-4.4.0-testing/tools/libxl/libxlu_disk_l.l
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk_l.l
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk_l.l
@@ -176,6 +176,7 @@ script=[^,]*,? { STRIP(','); SAVESTRING(
direct-io-safe,? { DPC->direct_io_safe = 1; }
discard,? { DPC->disable_discard = 0; }
no-discard,? { DPC->disable_discard = 1; }
+suse-diskcache-disable-flush,? { DPC->suse_diskcache_disable_flush = 1; }
/* the target magic parameter, eats the rest of the string */

203
libxl.introduce-an-option-to-disable-the-non-O_DIRECT-workaround.patch Normal file
View File

@ -0,0 +1,203 @@
xen-unstable commit 6ec48cf41b6656c98148380f39010063e62628c5
Frp,: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Wed Apr 30 16:06:24 2014 +0100
Subject: libxl: introduce an option for disabling the non-O_DIRECT workaround
Document and implement a new option that permits disk backends which
would otherwise have to avoid O_DIRECT (because of the network memory
lifetime bug) to use it anyway. This is:
direct-io-safe in the xl domain disk config specification
direct_io_safe in the libxl disk API
direct-io-safe in the backend xenstore interface
Add a reference to xen/include/public/io/blkif.h in
docs/misc/vbd-interface.txt.
This change does not break ABI. Instead of adding a new member
direct_io_safe to struct libxl_device_disk the existing readwrite member
is reused.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Felipe Franciosi <felipe@paradoxo.org>
---
docs/misc/vbd-interface.txt | 6 +++++
docs/misc/xl-disk-configuration.txt | 38 ++++++++++++++++++++++++++++++++++++
tools/libxl/libxl.c | 2 +
tools/libxl/libxl.h | 11 ++++++++++
tools/libxl/libxlu_disk.c | 2 +
tools/libxl/libxlu_disk_i.h | 2 -
tools/libxl/libxlu_disk_l.l | 1
xen/include/public/io/blkif.h | 22 ++++++++++++++++++++
8 files changed, 83 insertions(+), 1 deletion(-)
Index: xen-4.4.0-testing/docs/misc/vbd-interface.txt
===================================================================
--- xen-4.4.0-testing.orig/docs/misc/vbd-interface.txt
+++ xen-4.4.0-testing/docs/misc/vbd-interface.txt
@@ -125,3 +125,9 @@ because they directly map the bottom 8 b
directly to the Linux guest's device number and throw away the rest;
they can crash due to minor number clashes. With these guests, the
workaround is not to supply problematic combinations of devices.
+
+
+Other frontend and backend options
+----------------------------------
+
+See xen/include/public/io/blkif.h for the full list of options.
Index: xen-4.4.0-testing/docs/misc/xl-disk-configuration.txt
===================================================================
--- xen-4.4.0-testing.orig/docs/misc/xl-disk-configuration.txt
+++ xen-4.4.0-testing/docs/misc/xl-disk-configuration.txt
@@ -178,6 +178,44 @@ information to be interpreted by the exe
These scripts are normally called "block-<script>".
+direct-io-safe
+--------------
+
+Description: Disables non-O_DIRECT workaround
+Supported values: absent, present
+Mandatory: No
+Default value: absent (workaround may be enabled)
+
+There is a memory lifetime bug in some driver domain (dom0) kernels
+which can cause crashes when using O_DIRECT. The bug occurs due to a
+mismatch between the backend-visible lifetime of pages used for the
+Xen PV network protocol and that expected by the backend kernel's
+networking subsystem. This can cause crashes when using certain
+backends with certain underlying storage.
+
+See:
+ http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
+
+For this reason, (this version of) the Xen libxl toolstack disables
+O_DIRECT when using the qemu-based Xen PV backend ("qdisk").
+
+However, this workaround has performance and scaling implications, and
+it is only necessary if the underlying device is a network filesystem.
+If the underlying device is not, then it is good to disable it; that
+is what this option is for.
+
+This option simply requests that the workaround be disabled. (However,
+not all backends versions which use the workaround understand this
+option, so this is on a best effort basis.)
+
+It's important to note that if you are storing the VM disk on a
+network filesystem or a network block device (NFS or ISCSI) it might
+not be safe to use this option. Otherwise specifying it is safe and
+can give better performances.
+
+If in the future the bug is fixed properly this option will then be
+silently ignored.
+
discard / no-discard
---------------
Index: xen-4.4.0-testing/tools/libxl/libxl.c
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxl.c
+++ xen-4.4.0-testing/tools/libxl/libxl.c
@@ -2480,6 +2480,8 @@ static void device_disk_add(libxl__egc *
flexarray_append(back, disk->readwrite ? "w" : "r");
flexarray_append(back, "device-type");
flexarray_append(back, disk->is_cdrom ? "cdrom" : "disk");
+ if ((disk->readwrite & ~LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MASK) == LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MAGIC)
+ flexarray_append_pair(back, "direct-io-safe", "1");
if ((disk->readwrite & ~LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK) == LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC)
flexarray_append_pair(back, "discard-enable", "0");
Index: xen-4.4.0-testing/tools/libxl/libxl.h
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxl.h
+++ xen-4.4.0-testing/tools/libxl/libxl.h
@@ -95,6 +95,17 @@
#define LIBXL_HAVE_BUILDINFO_EVENT_CHANNELS 1
/*
+ * The libxl_device_disk lacks some "cache" field, enabling directio
+ * is supported without breaking the ABI. This is done by overloading
+ * struct libxl_device_disk->readwrite:
+ * readwrite == 0: disk is readonly, no directio
+ * readwrite == 1: disk is readwrite, backend driver may enable directio
+ * readwrite == MAGIC: disk is readwrite, backend driver should use direct IO
+ */
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MAGIC 0x00000600U
+#define LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MASK 0xfffff0ffU
+
+/*
* The libxl_device_disk lacks discard_enable field, disabling discard
* is supported without breaking the ABI. This is done by overloading
* struct libxl_device_disk->readwrite:
Index: xen-4.4.0-testing/tools/libxl/libxlu_disk.c
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk.c
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk.c
@@ -80,6 +80,8 @@ int xlu_disk_parse(XLU_Config *cfg,
disk->format = LIBXL_DISK_FORMAT_EMPTY;
}
+ if (disk->readwrite && dpc.direct_io_safe)
+ disk->readwrite = (disk->readwrite & LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MASK) | LIBXL_HAVE_LIBXL_DEVICE_DISK_DIRECT_IO_SAFE_MAGIC;
if (disk->readwrite && dpc.disable_discard)
disk->readwrite = (disk->readwrite & LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MASK) | LIBXL_HAVE_LIBXL_DEVICE_DISK_DISCARD_DISABLE_MAGIC;
Index: xen-4.4.0-testing/tools/libxl/libxlu_disk_i.h
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk_i.h
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk_i.h
@@ -10,7 +10,7 @@ typedef struct {
void *scanner;
YY_BUFFER_STATE buf;
libxl_device_disk *disk;
- int access_set, disable_discard, had_depr_prefix;
+ int access_set, direct_io_safe, disable_discard, had_depr_prefix;
const char *spec;
} DiskParseContext;
Index: xen-4.4.0-testing/tools/libxl/libxlu_disk_l.l
===================================================================
--- xen-4.4.0-testing.orig/tools/libxl/libxlu_disk_l.l
+++ xen-4.4.0-testing/tools/libxl/libxlu_disk_l.l
@@ -173,6 +173,7 @@ backendtype=[^,]*,? { STRIP(','); setbac
vdev=[^,]*,? { STRIP(','); SAVESTRING("vdev", vdev, FROMEQUALS); }
script=[^,]*,? { STRIP(','); SAVESTRING("script", script, FROMEQUALS); }
+direct-io-safe,? { DPC->direct_io_safe = 1; }
discard,? { DPC->disable_discard = 0; }
no-discard,? { DPC->disable_discard = 1; }
Index: xen-4.4.0-testing/xen/include/public/io/blkif.h
===================================================================
--- xen-4.4.0-testing.orig/xen/include/public/io/blkif.h
+++ xen-4.4.0-testing/xen/include/public/io/blkif.h
@@ -97,6 +97,28 @@
*
* The type of the backing device/object.
*
+ *
+ * direct-io-safe
+ * Values: 0/1 (boolean)
+ * Default Value: 0
+ *
+ * The underlying storage is not affected by the direct IO memory
+ * lifetime bug. See:
+ * http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
+ *
+ * Therefore this option gives the backend permission to use
+ * O_DIRECT, notwithstanding that bug.
+ *
+ * That is, if this option is enabled, use of O_DIRECT is safe,
+ * in circumstances where we would normally have avoided it as a
+ * workaround for that bug. This option is not relevant for all
+ * backends, and even not necessarily supported for those for
+ * which it is relevant. A backend which knows that it is not
+ * affected by the bug can ignore this option.
+ *
+ * This option doesn't require a backend to use O_DIRECT, so it
+ * should not be used to try to control the caching behaviour.
+ *
*--------------------------------- Features ---------------------------------
*
* feature-barrier

1
qemu-xen-upstream-blkif-discard.patch
View File

@ -1,5 +1,6 @@
References: FATE#316071
Subject: qemu-upstream: add discard support for xen_disk
Git-commit: f31352041bdde436c3f6d07e1525a42e48dec215
Implement discard support for xen_disk. It makes use of the existing
discard code in qemu.

52
qemu-xen-upstream-qdisk-cache-unsafe.patch Normal file
View File

@ -0,0 +1,52 @@
https://bugzilla.novell.com/show_bug.cgi?id=879425
---
tools/qemu-xen-dir-remote/hw/block/xen_disk.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Index: xen-4.4.0-testing/tools/qemu-xen-dir-remote/hw/block/xen_disk.c
===================================================================
--- xen-4.4.0-testing.orig/tools/qemu-xen-dir-remote/hw/block/xen_disk.c
+++ xen-4.4.0-testing/tools/qemu-xen-dir-remote/hw/block/xen_disk.c
@@ -113,6 +113,7 @@ struct XenBlkDev {
int requests_inflight;
int requests_finished;
+ gboolean cache_unsafe;
/* Persistent grants extension */
gboolean feature_discard;
gboolean feature_persistent;
@@ -725,6 +726,16 @@ static void blk_parse_discard(struct Xen
xenstore_write_be_int(&blkdev->xendev, "feature-discard", 1);
}
+static void blk_parse_cache_unsafe(struct XenBlkDev *blkdev)
+{
+ int enable;
+
+ blkdev->cache_unsafe = false;
+
+ if (xenstore_read_be_int(&blkdev->xendev, "suse-diskcache-disable-flush", &enable) == 0)
+ blkdev->cache_unsafe = !!enable;
+}
+
static int blk_init(struct XenDevice *xendev)
{
struct XenBlkDev *blkdev = container_of(xendev, struct XenBlkDev, xendev);
@@ -793,6 +804,7 @@ static int blk_init(struct XenDevice *xe
xenstore_write_be_int(&blkdev->xendev, "info", info);
blk_parse_discard(blkdev);
+ blk_parse_cache_unsafe(blkdev);
g_free(directiosafe);
return 0;
@@ -832,6 +844,9 @@ static int blk_connect(struct XenDevice
if (blkdev->feature_discard)
qflags |= BDRV_O_UNMAP;
+ if (blkdev->cache_unsafe)
+ qflags |= BDRV_O_NO_FLUSH;
+
/* init qemu block driver */
index = (blkdev->xendev.dev - 202 * 256) / 16;
blkdev->dinfo = drive_get(IF_XEN, 0, index);

44
xen.changes
View File

@ -1,3 +1,47 @@
-------------------------------------------------------------------
Tue May 27 16:54:13 CEST 2014 - ohering@suse.de
- bnc#879425: handle cache=unsafe from libvirt to disable flush in qdisk
libxl.add-option-to-disable-disk-cache-flushes-in-qdisk.patch
qemu-xen-upstream-qdisk-cache-unsafe.patch
-------------------------------------------------------------------
Tue May 27 16:50:22 CEST 2014 - ohering@suse.de
- libxl: introduce an option for disabling the non-O_DIRECT workaround
recognize direct-io-safe in domU.cfg diskspec
libxl.introduce-an-option-to-disable-the-non-O_DIRECT-workaround.patch
-------------------------------------------------------------------
Tue May 27 16:44:06 CEST 2014 - ohering@suse.de
- fate#316071: add discard support for file backed storage (qdisk)
update patch to allow more values in overloaded ->readwrite member
-------------------------------------------------------------------
Tue May 27 08:03:51 MDT 2014 - carnold@suse.com
- bnc#826717 - VUL-0: CVE-2013-3495: XSA-59: xen: Intel VT-d
Interrupt Remapping engines can be evaded by native NMI interrupts
537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch
537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch
- Upstream patches from Jan
53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch
53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch
537b5ede-move-domain-to-cpupool0-before-destroying-it.patch
-------------------------------------------------------------------
Tue May 20 16:34:37 MDT 2014 - carnold@suse.com
- Update README.SuSE with information on the toolstack change
-------------------------------------------------------------------
Fri May 16 10:27:04 CEST 2014 - ohering@suse.de
- fate#316071: add discard support for file backed storage (qdisk)
update to recognize option discard/no-discard instead of discard=0,1
to match upstream change
-------------------------------------------------------------------
Mon May 12 18:00:14 CEST 2014 - ohering@suse.de

19
xen.spec
View File

@ -15,6 +15,7 @@
# Please submit bugfixes or comments via http://bugs.opensuse.org/
#
# needssslcertforbuild
Name: xen
@ -153,7 +154,7 @@ BuildRequires: xorg-x11-util-devel
%endif
%endif
Version: 4.4.0_18
Version: 4.4.0_20
Release: 0
PreReq: %insserv_prereq %fillup_prereq
Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel)
@ -249,6 +250,11 @@ Patch34: 535e31bc-x86-HVM-correct-the-SMEP-logic-for-HVM_CR0_GUEST_RESERV
Patch35: 535fa503-x86-HVM-restrict-HVMOP_set_mem_type.patch
Patch36: 53636978-hvm_set_ioreq_page-releases-wrong-page-in-error-path.patch
Patch37: 53636ebf-x86-fix-guest-CPUID-handling.patch
Patch38: 53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch
Patch39: 53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch
Patch40: 537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch
Patch41: 537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch
Patch42: 537b5ede-move-domain-to-cpupool0-before-destroying-it.patch
# Upstream qemu
Patch250: VNC-Support-for-ExtendedKeyEvent-client-message.patch
Patch251: 0001-net-move-the-tap-buffer-into-TAPState.patch
@ -372,6 +378,9 @@ Patch464: set-mtu-from-bridge-for-tap-interface.patch
Patch465: libxl.add-option-for-discard-support-to-xl-disk-conf.patch
Patch466: aarch64-rename-PSR_MODE_ELxx-to-match-linux-headers.patch
Patch467: xl-check-for-libvirt-managed-domain.patch
Patch468: libxl.introduce-an-option-to-disable-the-non-O_DIRECT-workaround.patch
Patch469: libxl.add-option-to-disable-disk-cache-flushes-in-qdisk.patch
Patch470: qemu-xen-upstream-qdisk-cache-unsafe.patch
# Hypervisor and PV driver Patches
Patch501: x86-ioapic-ack-default.patch
Patch502: x86-cpufreq-report.patch
@ -646,6 +655,11 @@ Authors:
%patch35 -p1
%patch36 -p1
%patch37 -p1
%patch38 -p1
%patch39 -p1
%patch40 -p1
%patch41 -p1
%patch42 -p1
# Upstream qemu patches
%patch250 -p1
%patch251 -p1
@ -768,6 +782,9 @@ Authors:
%patch465 -p1
%patch466 -p1
%patch467 -p1
%patch468 -p1
%patch469 -p1
%patch470 -p1
# Hypervisor and PV driver Patches
%patch501 -p1
%patch502 -p1