Hello community,
here is the log from the commit of package xen for openSUSE:Factory checked in at 2014-06-01 18:58:23
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/xen (Old)
and /work/SRC/openSUSE:Factory/.xen.new (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen"
Changes:
--------
--- /work/SRC/openSUSE:Factory/xen/xen.changes 2014-05-15 21:31:30.000000000 +0200
+++ /work/SRC/openSUSE:Factory/.xen.new/xen.changes 2014-06-01 18:58:38.000000000 +0200
@@ -1,0 +2,44 @@
+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
+
+-------------------------------------------------------------------
New:
----
53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch
53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch
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
537b5ede-move-domain-to-cpupool0-before-destroying-it.patch
libxl.add-option-to-disable-disk-cache-flushes-in-qdisk.patch
libxl.introduce-an-option-to-disable-the-non-O_DIRECT-workaround.patch
qemu-xen-upstream-qdisk-cache-unsafe.patch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ xen.spec ++++++
--- /var/tmp/diff_new_pack.JjJzfv/_old 2014-06-01 18:58:40.000000000 +0200
+++ /var/tmp/diff_new_pack.JjJzfv/_new 2014-06-01 18:58:40.000000000 +0200
@@ -15,6 +15,7 @@
# Please submit bugfixes or comments via http://bugs.opensuse.org/
#
+
# needssslcertforbuild
Name: xen
@@ -153,7 +154,7 @@
%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 @@
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 @@
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 @@
%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 @@
%patch465 -p1
%patch466 -p1
%patch467 -p1
+%patch468 -p1
+%patch469 -p1
+%patch470 -p1
# Hypervisor and PV driver Patches
%patch501 -p1
%patch502 -p1
++++++ 53709b77-Nested-VMX-load-current_vmcs-only-when-it-exists.patch ++++++
# Commit 99c03bc6a1f8c6722926d2db781ece045f9d09ae
# Date 2014-05-12 11:59:19 +0200
# Author Edmund H White
# Committer Jan Beulich
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 .
Signed-off-by: Edmund H White
Signed-off-by: Yang Zhang
Acked-by: Kevin Tian
Reviewed-by: Andrew Cooper
--- 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)
++++++ 53732f4f-x86-MCE-bypass-uninitialized-vcpu-in-vMCE-injection.patch ++++++
# Commit a07084525c126c596326dc1442dd218f522f51b4
# Date 2014-05-14 10:54:39 +0200
# Author Kai Huang
# Committer Jan Beulich
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
Acked-by: Christoph Egger
--- 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) )
++++++ 537b5e50-VT-d-apply-quirks-at-device-setup-time-rather-than-only-at-boot.patch ++++++
# Commit 5786718fbaafbe47d72cc1512cd93de79b8fc2fa
# Date 2014-05-20 15:53:20 +0200
# Author Jan Beulich
# Committer Jan Beulich
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
Reviewed-by: Andrew Cooper
Acked-by: Xiantao Zhang
Acked-by: Yang Zhang
--- 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;
++++++ 537b5e79-VT-d-extend-error-report-masking-workaround-to-newer-chipsets.patch ++++++
# Commit 04734664eb20c3bf239e473af182bb7ab901d779
# Date 2014-05-20 15:54:01 +0200
# Author Jan Beulich
# Committer Jan Beulich
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
Reviewed-by: Andrew Cooper
Acked-by: Xiantao Zhang
Acked-by: Yang Zhang
--- 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) */
++++++ 537b5ede-move-domain-to-cpupool0-before-destroying-it.patch ++++++
# Commit bac6334b51d9bcfe57ecf4a4cb5288348fcf044a
# Date 2014-05-20 15:55:42 +0200
# Author Juergen Gross
# Committer Jan Beulich
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
Reviewed-by: Jan Beulich
Acked-by: George Dunlap
--- 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);
++++++ README.SuSE ++++++
--- /var/tmp/diff_new_pack.JjJzfv/_old 2014-06-01 18:58:41.000000000 +0200
+++ /var/tmp/diff_new_pack.JjJzfv/_new 2014-06-01 18:58:41.000000000 +0200
@@ -5,8 +5,8 @@
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 @@
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 @@
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 @@
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 @@
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.
-
-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.
+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.
+
+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 @@
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 @@
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 @@
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 the other xm commands by typing "xm help". Note that most xm
-commands must be done as root.
+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 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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
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...
http://www.novell.com/documentation/vmserver/.
@@ -540,10 +561,10 @@
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.
++++++ libxl.add-option-for-discard-support-to-xl-disk-conf.patch ++++++
--- /var/tmp/diff_new_pack.JjJzfv/_old 2014-06-01 18:58:41.000000000 +0200
+++ /var/tmp/diff_new_pack.JjJzfv/_new 2014-06-01 18:58:41.000000000 +0200
@@ -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
---
- 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 @@
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 @@
===================================================================
--- 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 @@
+ * 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 @@
}
+ 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 @@
===================================================================
--- 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 */
++++++ libxl.add-option-to-disable-disk-cache-flushes-in-qdisk.patch ++++++
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 */
++++++ libxl.introduce-an-option-to-disable-the-non-O_DIRECT-workaround.patch ++++++
xen-unstable commit 6ec48cf41b6656c98148380f39010063e62628c5
Frp,: Stefano Stabellini
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
Signed-off-by: Ian Jackson
Acked-by: Ian Campbell
Tested-by: Felipe Franciosi
---
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
++++++ qemu-xen-upstream-blkif-discard.patch ++++++
--- /var/tmp/diff_new_pack.JjJzfv/_old 2014-06-01 18:58:41.000000000 +0200
+++ /var/tmp/diff_new_pack.JjJzfv/_new 2014-06-01 18:58:41.000000000 +0200
@@ -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.
++++++ qemu-xen-upstream-qdisk-cache-unsafe.patch ++++++
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);
--
To unsubscribe, e-mail: opensuse-commit+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-commit+help@opensuse.org