Improve xen packages and hvm domUs support

[Fantu]

I report also here some useful informations to improve xen packages and hvm domUs support with xen 4.4 that I already reported on debian bugtracker:

"
I advice maintainers for fast and easy improve hvm domUs support on xen
debian packages when the xen 4.4 will be packaged to specifying seabios
and qemu binary of debian packages from configure, see these patches for
details:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=5c7cbadaccca8dbb47f2c42ab1b5a8afac9275e3
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=906677d6411c3dc579e07967d0137a12392ff314
Already tested and working with debian packages of qemu and seabios.
Also the use of new ./configure ... --enable-qemu-traditional=no can be
useful to disable qemu traditional without debian patches.
Is possible to specify ovmf binary for experimental uefi hvm support:
http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=6b2029c9a1f6b4cd7585fd537d45233f8dde14b7
but in that case ovmf package should be updated at least to commit
447d264115c476142f884af0be287622cd244423 for good xen support.
Probably can be good also to put qemu-system-x86 package as dependency
instead of recommended.
"

Tell me if there are other important things that you would into upstream to improve the implementation of xen into the distributions that are not already been made and if I have time I'll try to make them.

I also did a large test with upstream qemu and qdisk instead qemu traditional with blktap2 and I saw generic hvm beckmark increase up to 40-60% and disks performance with qdisks and recent upstream qemu increased by several times, above all in writing operations.

I think it is better to inform as much as possible to drop xend already deprecated many xen versions ago and will be removed in xen 4.5.

I also think it is better to use more qemu upstream and report any problems,
The traditional qemu is now less supported, more difficult to maintain, and some new features are only supported by qemu upstream and will not be implemented in the traditional.

I hope this information is helpful and sorry for my bad english.

[Stefan Bader (smb)]

Supporting flexible locations of qemu and alternate location for the ovmf BIOS would allow to get rid of patches. So sounds useful. Note that the 14.04 (Trusty) release of Ubuntu (as well as the 13.10 (Saucy) release) were not using the Xen version of qemu for xl but the generic upstream qemu (compiled with Xen support).

To push deprecation of xend in 14.04, xl was made the default toolstack. In order to not completely break users of xend it still ships with xend support and this will not get removed in the 14.04 release. This could be something to try in the next release. If Xen-4.5 is ready by then its gone anyway and in case we stick with 4.4 we could stop using --with-xend. Probably depending on upstream to decide whether the old device-model should go, too.

Blktap(2) is not installed by default. It has been a bunch of separate packages for a while. The default is to use upmstream qemu. Not sure whether qdisk refers to a specific interface. Normally IDE is specified and blkfront is used after unplug.

[Fantu (fantonifabio)]

Thanks for your reply.
I not tried xen trusty package for now but only a fast watch on debian folder of packages source.
seabios and upstream qemu is not specified on configure for what I saw (./configure --enable-xend --prefix=/usr) and I think should be done to have seabios and upstream qemu without adding distro patches (I saw at least 3 patches about them), same for ovmf if you will add it (but actual ovmf trusty package seems too old for good xen support, if I remember correctly the patch for a decent xen support are ovmf upstream from the beginning of February).
About xend if you already shown that it is deprecated and will be removed okay, on xen 4.5 (on development) xend has already been removed.
About disks part from a fast watch seems ok but I have not tried it yet I do not have the certainty.

[Fantu (fantonifabio)]

Ah... I think that probably is also good put qemu-system-x86 as dipendency since is default for "disks on file" also on pv domUs.
Is used also for vnc (and spice basic support if my patch will be accepted on xen 4.5) on pv domUs.
Then using the 4.4 xl seem to me a few cases where it is not used, but I could be wrong not knowing the actual xen use cases, not to mention that I fear that xend and qemu traditional is still too used even if obsolete :(

[Stefan Bader (smb)]

qemu-system-x86 is on the recommends list which will pull in upstream qemu. Right now the build of Xen modifies the source in a way to look for qemu-system-i386 on the path provided by qemu. This also causes seabios to be used. ovmf would need testing. Ovmf was not really looked at. So for the next release you could file a bug against edk2 which looks to be the source package that provides ovmf.
I would try to make everything use/depend on the same generic parts. I would prefer if we can more and more get rid of any qemu part being built as part of Xen and rather rely on the common qemu package there. As long as qemu-xen-traditional needs to be supported we need to keep that in Xen but long term it should go.

[Fantu (fantonifabio)]

Sorry for my bad english.
I not understand if you mean right.
About seabios, upstream qemu and ovmf from distro package I mean simply for example:
for seabios ./configure ... --with-system-seabios=/usr/share/seabios/bios.bin and remove tools-firmware-seabios-packaged patch.
About ovmf is better not use it until the package will be updated.
Seabios and ovmf are still build in hvmloader and need xen packages to be rebuild for update them (same of actual patches), qemu instead not need xen rebuild but will automatic use new version on qemu package update.
for upstream qemu ./configure ... --with-system-qemu=/usr/bin/qemu-system-i386 (if I remember good) and remove ubuntu-qemu-disable-qemu-upstream and ubuntu-qemu-upstream-location patches.

For example I use debian for develop and testing, I used Seabios from debian packages many times, also recently, and qemu from debian package instead compile it months ago latest time, but also with qemu 2.0 final should be ok, I recently tested it with xen 4.4 and xen-unstable (4.5).

[Fantu (fantonifabio)]

I saw now the test I did with qemu from debian packages and I always use /usr/bin/qemu-system-x86_64, since xen not use emulated cpu _64 or not should not be different but probably is different for spice-server that if I remember good have problem on 32 bit.

[Stefan Bader (smb)]

So we talk about different sides. Debian has not, yet packaged up Xen-4.4 (there was a post to Debian today asking how we can change that), I did package Xen-4.4 for Ubuntu Trusty (14.04). That does a lot of the things you were suggesting. Maybe not all in a way that will be ok with Debian. I will try to work together with whoever does the Debian side (if that person wants me to).
Otherwise (if Debian would have been quicker in picking up 4.4) normally Ubuntu picks the Debian version and I would try to keep the differences at a minimum. But sometimes there is no way around doing some things different.

[Fantu (fantonifabio)]

Recently on xen 4.5 staging git were added some tool's flags patches, I do not have time to check the ubuntu patches but in the TODO for 4.5 maybe you should also mark to check about them that perhaps other ubuntu patches can be removed.
Same thing also about a patch serie for tools prefix:
http://lists.xen.org/archives/html/xen-devel/2014-04/msg03240.html
Almost certainly be accepted and perhaps that allow you to remove some other ubuntu patches.
Also might be useful to point out some fixes or improvements required on upstream in the xen-devel instead of having to do and maintain dozens of patches in all the distros on things that can be corrected or improved without problems upstream.

I hope this information is helpful and sorry for my bad english.

[Fantu (fantonifabio)]

I can not find the updated repository of packages xen in ubuntu.
Someone is making improvements?
If not, if I have enough time I start to make some public and patches.

Thanks for any reply.

[Fantu (fantonifabio)]

I did some small improments:
  * Build with distro's seabios with xen configure instead patch.
  * Use seabios 256k build instead the 128k one, because in the 128k the
    xen support will be disabled in future.
  * Use distro's upstream qemu with xen configure instead patches.
  * Removed patches no more needed:
    - debian/patches/tools-firmware-seabios-packaged.diff
    - debian/patches/ubuntu-qemu-disable-qemu-upstream.diff
    - debian/patches/ubuntu-qemu-upstream-location.patch
  * Refreshed patches:
    - debian/patches/config-etherboot.diff
    - debian/patches/tools-firmware-etherboot-packaged.diff
    - debian/patches/ubuntu-tools-armhf-without-ocaml.patch

I did only build test and not xen use test but should be working.

Full changes are available here:
https://github.com/Fantu/pkg-xen

[Fantu (fantonifabio)]

Changes tested and working:
http://lists.xen.org/archives/html/xen-users/2014-05/msg00187.html

I did also xendomain init and default update but need to be tested:
https://github.com/Fantu/pkg-xen/commit/6f0ef68441c2c8e20e7170df25821baa8b03515d

[Fantu (fantonifabio)]

Seabios package from version 1.7.5-1 removes the xen support in 128k build, than the seabios build change to 256k is needed for future build on utopic:
http://changelogs.ubuntu.com/changelogs/pool/main/s/seabios/seabios_1.7.5-1/changelog

[Stefan Bader (smb)]

Hi Fantu, sorry for the delay but I was busy with other things. And I cannot promise how quickly I can look into your improvements. In the end I would prefer to have things the same in Debian and Ubuntu but unfortunately this might be difficult. So it might happen that we have to keep things more recent in Ubuntu. Again, I will have a look, though it might be taking a bit more time.

[Fantu (fantonifabio)]

Also xendomains init update tested (on debian sid) and working.
Can be used also on ubuntu with cherry-pick of:
https://github.com/Fantu/pkg-xen/commit/6f0ef68441c2c8e20e7170df25821baa8b03515d
https://github.com/Fantu/pkg-xen/commit/0b7bda2d553655c345f09f9814aae43bccec6130

[James Dingwall (a-james-launchpad)]

I have built the xen sources from wily with the following patch to enable HVM guest UEFI support:

diff -ur xen-4.5.0.orig/debian/control xen-4.5.0/debian/control
--- xen-4.5.0.orig/debian/control 2015-02-24 18:14:03.000000000 +0000
+++ xen-4.5.0/debian/control 2015-04-11 19:25:28.360151702 +0100
@@ -5,7 +5,7 @@
 XSBC-Original-Maintainer: Debian Xen Team <email address hidden>
 Uploaders: Guido Trotter <email address hidden>, Bastian Blank <email address hidden>
 Standards-Version: 3.9.4
-Build-Depends: autotools-dev, debhelper (>> 9), dpkg-dev (>= 1.16.0~), lsb-release, python-dev, bcc [i386 amd64], gcc-multilib [i386 amd64], e2fslibs-dev, iasl [i386 amd64], seabios (>= 1.7.4-2~) [i386 amd64], libaio-dev, libfdt-dev [armhf arm64], libglib2.0-dev, liblzma-dev, libncurses5-dev, libyajl-dev, libssl-dev, pkg-config, uuid-dev, zlib1g-dev
+Build-Depends: autotools-dev, debhelper (>> 9), dpkg-dev (>= 1.16.0~), lsb-release, python-dev, bcc [i386 amd64], gcc-multilib [i386 amd64], e2fslibs-dev, iasl [i386 amd64], seabios (>= 1.7.4-2~) [i386 amd64], libaio-dev, libfdt-dev [armhf arm64], libglib2.0-dev, liblzma-dev, libncurses5-dev, libyajl-dev, libssl-dev, pkg-config, uuid-dev, zlib1g-dev, ovmf
 XS-Python-Version: current

 Package: libxen-4.5
diff -ur xen-4.5.0.orig/debian/rules.real xen-4.5.0/debian/rules.real
--- xen-4.5.0.orig/debian/rules.real 2015-01-22 10:44:54.000000000 +0000
+++ xen-4.5.0/debian/rules.real 2015-04-11 19:00:20.676151702 +0100
@@ -57,6 +57,7 @@
  cp -al $(SOURCE_FILES) $(DIR)
  cp --remove-destination /usr/share/misc/config.guess /usr/share/misc/config.sub $(DIR)
  cd $(DIR); \
+ GIT=/bin/false \
   WGET=/bin/false \
   ./configure \
    --disable-docs --disable-stubdom --disable-xen \
@@ -72,7 +73,8 @@
    --disable-ocamltools \
    --disable-qemu-traditional --disable-rombios \
    --with-system-qemu=/usr/bin/qemu-system-i386 \
- --with-system-seabios=/usr/share/seabios/bios-256k.bin
+ --with-system-seabios=/usr/share/seabios/bios-256k.bin \
+ --with-system-ovmf=/usr/share/ovmf/OVMF.fd --enable-ovmf
  @$(stamp)

 $(STAMPS_DIR)/build-docs: DIR=$(BUILD_DIR)/build-docs

This introduces a new dependency on the ovmf package.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stefan Bader (smb)]

Thanks James, unfortunately its the build-dependency on edk2/ovmf which prevents me from picking this right now (ovmf is multiverse and at least xen source is main).
And really sorry Fantu, this cycle I had no time at all to do realistic improvements to the packaging at all. The only thing I am getting to is pulling in the latest stable (4.5.1). For 16.04 I hope to spend more time as this also should make the jump to 4.6 hopefully.