Arch Linux User Repository

Here is 4.16.1-1.

• Has patches to compile under GCC12, entirely by disabling some error checks.
• The hvmloader patch has been brought in, fixing that problem.
• I dropped working on the OVMF fixes, since that's a separate project from Xen.
• I have tested it on exactly two systems, both of which run AMD processors. Error reports and patches welcome.

UPDATE 2022-05-18: I have one machine running a Ryzen 7 5700G with an Intel 82576 that crashes on iommu. I'm attempting to get help with the problem, but if anyone else has a problem I'd like to hear about it.

I get two errors when try to install this package. ==> Verifying source file signatures with gpg... xen-4.16.1.tar.gz ... FAILED (unknown public key 83FE14C957E82BD9) ==> ERROR: One or more PGP signatures could not be verified!

And after adding --skippgpcheck makepkg flag usage. ==> Starting prepare()... ==> Applying GCC 12.1 fixes... /home/<user_name>/aur/xen/PKGBUILD: line 172: patch: command not found ==> ERROR: A failure occurred in prepare(). Maybe, you need to add patch dependency.

If I want to install the xen-qemu-builtin package, I have to manually delete two files, which conflict with the xen package; then it can be installed without a conflict. Is this caused by the xen package?

[arthur@xen1 xen]$ sudo pacman -U xen-qemu-builtin-4.16.1-1-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for conflicting packages...

Packages (1) xen-qemu-builtin-4.16.1-1

Total Installed Size:  244.04 MiB

:: Proceed with installation? [Y/n] 
(1/1) checking keys in keyring                                                                                            [#########################################################################] 100%
(1/1) checking package integrity                                                                                          [#########################################################################] 100%
(1/1) loading package files                                                                                               [#########################################################################] 100%
(1/1) checking for file conflicts                                                                                         [#########################################################################] 100%
error: failed to commit transaction (conflicting files)
xen-qemu-builtin: /usr/lib/xen/bin/qemu-keymap exists in filesystem (owned by xen)
xen-qemu-builtin: /usr/lib/xen/libexec/vhost-user-gpu exists in filesystem (owned by xen)
[arthur@xen1 xen]$ sudo rm /usr/lib/xen/bin/qemu-keymap
[arthur@xen1 xen]$ sudo rm /usr/lib/xen/libexec/vhost-user-gpu
[arthur@xen1 xen]$ sudo pacman -U xen-qemu-builtin-4.16.1-1-x86_64.pkg.tar.xz

After last xen upgrade Im running into a strange error at bootup: none domain are up. Searching logs for a clue i found this:

May 31 11:08:16 bakaneko systemd[1]: Finished Xendomains - start and stop guests on boot and shutdown. May 31 11:08:16 bakaneko xendomains[369]: [done] May 31 11:08:16 bakaneko xendomains[369]: ! May 31 11:08:16 bakaneko xendomains[369]: An error occurred while creating domain new_moodle_eest1-vm.cfg: May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1064:domain_destroy_cb: Domain 4:Destruction of domain failed May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1137:domain_destroy_callback: Domain 4:Unable to destroy guest May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_domain.c:1183:libxl__destroy_domid: Domain 4:Non-existant domain May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_create.c:1289:initiate_domain_create: Domain 4:Unable to set disk defaults for disk 0 May 31 11:08:16 bakaneko xendomains[435]: libxl: error: libxl_device.c:399:libxl__device_disk_set_backend: Disk vdev=xvda failed to stat: /dev/mapper/VM_bakaneko_vg-new> May 31 11:08:16 bakaneko xendomains[369]: new_moodle_eest1-vm.cfg

Despite this if xendomains is manually restarted everything boots up normally. Another error is related to qemu-dom0 backend:

May 31 11:36:42 bakaneko systemd[1]: Starting qemu for xen dom0 disk backend... May 31 11:36:42 bakaneko systemd[1]: Started qemu for xen dom0 disk backend. May 31 11:36:42 bakaneko qemu-system-i386[964]: qemu-system-i386: -xen-domid 0: Option not supported for this target.

Also at system upgrade a question arise for qemu-desktop replacement for qemu (dont know its related or not) Any suggestion? Thanks!!

Here is 4.16.1-1.

• Has patches to compile under GCC12, entirely by disabling some error checks.
• The hvmloader patch has been brought in, fixing that problem.
• I dropped working on the OVMF fixes, since that's a separate project from Xen.
• I have tested it on exactly two systems, both of which run AMD processors. Error reports and patches welcome.

UPDATE 2022-05-18: I have one machine running a Ryzen 7 5700G with an Intel 82576 that crashes on iommu. I'm attempting to get help with the problem, but if anyone else has a problem I'd like to hear about it.

@Sven I have a 4.16.1-0 in my repo that compiles cleanly except for stubdom, mostly thanks to an OpenSUSE patch that sets a bunch exceptions here and there. Still looking into the stubdom bit before I update AUR.

Xen 4.16.0-3 doesn't seem to build with gcc 12.1.0

Hoping to get to it this week. Haven't had much time in front of a computer myriad of reasons.

@Refutationalist : any change of applying this patch to the PKGBUILD ?

@ArthurBorsboom Have a look at https://github.com/refutationalist/saur/pull/8 As long as this patch is not applied yet, you would have to help yourself.

I suspect I am overseeing something, but I can't find the hvmloader anymore in /usr/lib/xen/boot/hvmloader

Do I need to install a separate package? Am I missing a built/makepkg option?

Any pointers?

@milenus, this package does not build the qemu-xen-traditional device model, but this is needed if you want to use the mini-os-based qemu stubdom with device_model_stubdomain_override = 1. A qemu stubdom based on Linux is needed for use with the qemu-xen device model. As I have read, this will be part of Xen in the future. QubesOS already uses such stubdoms, but I haven't tried them yet. This package builds the VTPM stubdoms, which can be used to store LUKS keys, for example.

Actually in the last two commits there is no hvmloader after installing the compiled packages regardless of the build options, so I rolled back to 4.16.0-1.

@milenus: I don't actually use stubdom, so I'm not surprised they're working right. They're only in by request. I haven't set up a test for them, just hoping to get feedback. Patch will be welcome, otherwise it'll be a bit.

Hello @Refutationalist, I just read how cool are stub domains and decided to try them. Successfully compiled and installed all four xen*.zst packages. I included in the HVM file device_model_stubdomain_override = 1 but when I try to create the VM it fails because of missing hvmloader. Can you please share some info how you use it?

@Sven that's fixed now. I swear that was wrapped in an if statement at some point.

build_qemu=false makepkg -sc fails with rm: cannot remove '/home/skoehler/aur/xen/pkg/xen/usr/share/qemu-xen': No such file or directory

Hello! Here's 4.16.0-2.

As I mentioned earlier, qemu and stubdom, if built, now generate packages rather than being built into xen itself. As a reminder, if you need stubdom, you can pass build_stubdom=true to makepkg. Similarly, passing build_qemu=false will prevent the package from building qemu-xen.

I am working on that OVMF patch, and should have it in shortly.

The use of SDL requires the new dependency libxi, see https://github.com/libsdl-org/SDL/issues/4938

@Sven Take a look into the PKGBUILD file, you will find the answer there :)

Is there a way to build xen without qemu? I only have guests with paravirtualized hardware (pvh guests) and building qemu takes a lot of time and probably has a lot of dependencies.

OVMF from the edk2-ovmf package can no longer be used with Xen because Xen support has been removed from the x64 platform target. See my last post in arch linux forum: https://bbs.archlinux.org/viewtopic.php?id=269628

OVMF shipped with this Xen package cannot be built due to an upstream error. @Refutationalist, I have a working patch that I will email to you.

Btw, the specific platform target OvmfXen is supposed to be bootable in PVH type DomUs, but I couldn't get that to work.

@ska64 I don't work with windows very much at all, so needing TPM for win11 didn't occur to me. I've pushed the changes to AUR and I'll consider what I might do to improve stubdom.

Your updated package on Github works out of the box. Maybe you could surround the new ninja makedepends with apostrophes, but it compiles without that change.

I tested with and without build_stubdom=true, it compiles and runs. Qemu is built and running as well.

The stubdoms are needed for virtual TPMs. I want to use them to store a LUKS key. But maybe someone else needs them to start Windows?

I do not have 4.16 in yet, but I suspect a lot of people by now know that 4.16 is compiling cleanly without extra patches. I just haven't had a chance to test it, or heard of anyone else testing it, so I haven't pushed my changes. I do have a simply updated package in my repo (https://github.com/refutationalist/saur) if you're interested in testing.

So, still out of date officially, but if I can get some confirmations that it works, I can push it here and leaving dealing with stubdom when I get back.

Other notes:

1) I got a request to leave stubdom in. Maybe I could make it part of the split package config? Looking into that, but probably not. The age of the extfiles needed for stubdom is starting to worry me and conflating with the "secure" aspects of stubdom. Part of what moved me to subdomless PVH.

2) I'm not able to recreate the qemu conflicts.

3) If building QEMU, we now need ninja.

4) I'm going to be playing with a Honeycomb LX2, so I'm hoping to have a version of xen that runs under alarm. Building for arm is really different, however.

On my system, the Xen 4.15.1-1 package fails to build. Any pointers ? GCC v11.1.0 ?

xentoollog_stubs.c:57: error: "Some_val" redefined [-Werror]
   57 | #define Some_val(v) Field(v,0)
      | 
In file included from /usr/lib/ocaml/caml/alloc.h:24,
                 from xentoollog_stubs.c:23:
/usr/lib/ocaml/caml/mlvalues.h:396: note: this is the location of the previous definition
  396 | #define Some_val(v) Field(v, 0)
      | 
cc1: all warnings being treated as errors
...
...
...
==> ERROR: A failure occurred in build().

I think it should conflict with qemu by default

error: failed to commit transaction (conflicting files)
xen: /usr/share/locale/bg/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/de_DE/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/fr_FR/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/hu/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/it/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/sv/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/tr/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
xen: /usr/share/locale/zh_CN/LC_MESSAGES/qemu.mo exists in filesystem (owned by qemu)
Errors occurred, no packages were upgraded.

Thank you for your commitment to this package. I never got the stubdom thing to work, but at some point I would like to try it again. So I would prefer if you keep the stubdom switch as it is implemented now.

Here's 4.15.1-1.

1) This one compiles cleanly on GCC11 et al., so there are currently no patches.

2) I'm well away from my usual haunts, so I'm only testing it on the Zen 2 machine I have with me, but it does boot and run HVM and PVH domUs.

3) We're expecting 4.16 around the end of the year, and so this is a reminder that when that's released, I'll be removing stubdom support as I was the only user.

4) I didn't know there was a Xen wiki page. I should update that at some point.

Hello! 4.15.0-3 is here. Here's an update:

1) The current GCC11 patch is updated for 4.15.0 and included here. It was in my github for a bit but I forgot to push it here. Whoops.

2) I've added the recent spate of XSA patches, but one had to be redone for our build environment. It is included.

3) mxca's fixes for EFI have been incorporated, but the directory is set to /boot by default, as I understand this is what is common.

4) On a personal note, my surgery went very well! I am still recovering, but things are looking good for me. Thank you for the well-wishes!

4.15.0-1 doesn't compile. Compilation stops with an error in line 729 of x86_emulate.c because of -Werror=stringop-overflow.

I assume that we see this error due to gcc 11. The command of mxca links to a patch for compiling with gcc 11.

Also, my best wishes go to Refutationalist. I hope the surgery goes well and you can return soon.

I came across this patch to get Xen building with GCC 11.

I also needed to make a few changes to support a system with split /efi and /boot (using XBOOTLDR). I ended up adding the make arguments BOOT_DIR=/boot EFI_DIR=/boot EFI_MOUNTPOINT=/efi. Technically that BOOT_DIR=/boot is redundant because it's the default, but I actually modified the package to set them as variables (e.g., _boot_dir=${boot_dir:-/boot}) and pass "${_common_make_flags[@]} to each make invocation.

EFI_DIR is where the xen.efi symlink farm gets installed along with the actual EFI image, so setting EFI_DIR=/boot looks weird but is the right thing to do on a SystemD bootctl-powered system using XBOOTLDR: the end result is that I don't need a hook to update the EFI system partition.

I also needed to refactor the symlink cleanup; specifically remove all the symlinks at the end after we've done both the multiboot and the EFI image relocations. Otherwise, if BOOT_DIR and EFI_DIR are the same thing you're gonna have a bad time.

I put my changes on github. Built it in a chroot with multilib-build, gonna go test it now.

Update: Works for me.

Thanks for your efforts. I wish you all the best with your surgery and a fast and painless recovery!

1) 4.15.0-1 adds zstd kernel support, so the hook for that is no longer needed, but I'm not sure if ever made it out of my personal repo.

2) The -no-pie problem in linking is present in 4.15, and there's an included patch for that. It is now the only patch needed to compile cleanly on Arch.

3) As promised, stubdom has moved from building by default to not building by default, as no one has spoken up about using it. If I continue maintaining the package, the plan is to remove it in the next major release.

4) I haven't done anything about the SDL2 deps.

5) Unless a co-maintainer is added, this is likely going to be the last release for a few months as I'm going in for surgery to have a brain tumor removed next month.

@juceda must set at top of PKGBUILD

Build Options

_build_stubdom=${build_stubdom:-false} _build_qemu=${build_qemu:-false}

@juceda: how to make the below modification on src/xen-4.14.1/tools/qemu-xen-build/config-host.mak file so that it is taken into account

@Guard - FYI that issue (unable to disambiguate: -no-pie) is caused by a recent binutils package: binutils-2.36-3-x86_64.pkg.tar.zst

If you downgrade it you'll be able to compile again (at least to bypass that point).

the flag is on: src/xen-4.14.1/tools/qemu-xen-build/config-host.mak changing LDFLAGS_NOPIE=-no-pie to LDFLAGS_NOPIE= will also fix the issue.

pkgbuild was successful after changing _build_stubdom and _build_qemu from "build_qemu/stubdom:-true" to "build_qemu/stubdom:-false"

"ld: Error: unable to disambiguate: -no-pie (did you mean --no-pie ?)"

happens every build, regardless of the source. perhaps I am missing a dependency? it fails to build afterwards.

SDL2 has the least dependencies when display output is needed for (pv)hvm domUs. I run xen on two Laptops and gpu passthrough is not an option. I patch the PKGBUILD and the built-in qemu myself. I can continue to do that. So for my sake the SDL2 support can be removed.

I think spice support is automatically enabled when the spice and spice-protocol packages are installed before makepkg runs. This probably also applies to GTK, VTE and other configuration switches. This could be an alternative to a toggle in PKGBUILD, but should be documented somewhere.

Thanks for your efforts :)

Hello!

In my personal repo I have an updated version of 4.14.1 with security patches and the changes suggested in the last couple weeks. With the new hook, it will boot recent kernels, but both the most recent linux and linux-lts kernels will not start any virtual machines. I'm trying to narrow down where the problem happens still, but what I know is that 5.4.88 works, and 5.4.94 doesn't. If you want to help me track down the problem, my repo is at https://github.com/refutationalist/saur

And now some future stuff where I need some feedback:

Stubdom: I'm now transitioning to using the package without stubdom support. In the comments, I think I was the only person who needed it. If that continues to be the case, I will begin to phase out stubdom starting with the next Xen release.

SDL2: The number of dependencies goes up significantly if one uses the built-in QEMU support, which is the default as the package in extra does not have xen support in it. Since I run Xen almost entirely on headless machines, I'd like to remove SDL2 support. Unless someone says otherwise, I'll have QEMU configured to not use sdl2, otherwise I'll have to turn it into a toggle.

libvirt, qemu, and getting the package into the repos: I've talked to a couple of TUs who are interested in getting the package into the repos, but not much has actually happened on that score. I could try to become a TU myself, but I do have a lot on my plate and I don't know that I have the brain space to handle that. Would it make more sense for me to just abandon the package and hope a TU picks it up? Some direction from someone who knows the political ins and outs of Arch Linux would be very helpful.

just a nitpick: in optdepends edk2-ovmf is misspelled

I am using libvirt with Xen.

Unfortunately the [Community] package libvirt does not have Xen support, since it depends on Xen to build and Xen is in the AUR.

https://bugs.archlinux.org/task/64800

Is there any chance to get this package in [Community]?

@refutationalist I've been using a hook to deal with the zstd kernel issue until support is complete.

xen-kernel.hook:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = linux

[Action]
Description = Pull ELF kernel to /boot
Depends = linux-headers
When = PostTransaction
Exec = /usr/bin/strip /usr/src/linux/vmlinux -o /boot/vmlinux

@Refutationalist, regarding the zstd support, it seems support for Dom0 is in progress.

https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg01060.html

I've tested this 4.14.1 on my older AMD box and my Xeon booting via EFI.

I'm in the middle of purging my need for the stubdom stuff, so I'm interested in hearing if people are using that at the moment. Also might have a co-maintainer shortly. Looking for input on how to handle zstd kernels.

4.14.1 has been out, and I'm working through it at the moment. Should hit my github repo in the next few days, and assuming it boots on my intel and AMD test systems, here shortly after.

@alaricljs -- the only real change between in the recent update was the inclusion of security patches from Xen. Might try pulling some of those out and see if that takes care of it for you. I'll see what I can test from here, but I'm not running any Windows VMs at the moment.

There was a patch update this morning, but I haven't looked at it closely yet. If it applies, there'll be a -5 soon.

@refutationalist - the -04 rev causes my Win VM to hang on boot (just the circular dot thing frozen on screen). The error in the vm log is:
qemu-system-i386: relocate_memory 4096 pages from GFN 40f000 to GFN f1000 failed: Bad address The version I was using prior to update was 4.14.0-1, I've rolled back.

Please replace the dependency sdl with sdl2 in your next version. SDL v1.2 is outdated and, as far as I can tell, is no longer supported by xen-4.14. Additionally libjpeg-turbo will be needed.

For the record, I almost universally use linux-lts on my servers, and that continues to work.

Also, when you update EFI, remember to copy the EFI kernel to /boot. That's not for you, that's for me, since I just spent an hour forgetting that.

EDIT: I will add a reminder in the next update. Maybe consider a hook, see how the kernels do it.

Updated to 4.14.0-4, added security patches, cmake fixes from cdchapman for stubdom building.

@alaricljs: that info would be better documented in the Wiki's Discussion page (or an update to the wiki if you have a procedure tested). Comments get lost into oblivion.

A partial (dom0 & PV) solution to the zstd compression issue that sticks to current kernels: https://gist.github.com/alaricljs/757d4b452335b187d7dff1b7e2c5808e

A Pacman hook that grabs the uncompressed kernel and puts it in /boot. Works on dom0 and PV guests (that's all that was tested, perhaps others work too).

Thanks to the previous comments I installed linux-lts and then sudo grub-mkconfig -o /boot/grub/grub.cfg it worked :) A new entry appeared on GRUB menu and now I booted to dom0 successfully.

Thank you for your tip @g8sqh!!!

I've posted this issue on forums some days ago (https://bbs.archlinux.org/viewtopic.php?id=260107), following the guidelines not to post questions etc here), but nobody answered.. ¬_¬

Please also note that Xen (4.14.0) no longer works with the standard Arch kernel (at least as dom-0)

Arch (at 5.9.1) compresses using zstd (CONFIG_KERNEL_ZSTD=1), and the ELF-reading code in Xen has a decompressor for xz (in xen/common/xz), but nothing for zstd

Message is elf-init: not an ELF binary and a (xen) kernel panic.

Until either Xen gains zstd, or Arch provides a kernel package using xz, you need an older kernel from the archive, or to build from source with CONFIG_KERNEL_XZ=1

Gotcha @eduncan911. Link: https://bbs.archlinux.org/viewtopic.php?id=259428

Everyone, please take this to the forums. Subscriptions to package notifications are just that: notifications about package updates, breaks, and news.

It's not a discussion, debugging, nor How To forum.

@skyzh Sorry for the flurry of comments; How do you actually apply that patch? I've done makepkg -o to just get the source files, I haven't done much manual makepkg work before.

@skyzh Got the same issue with GCC9 (can provide log snippets if need be), perhaps the patch you found is the only remedy at the moment.

@skyzh I'm getting the same problem, I'm going to attempt building with gcc9, which is in the community repo, then gcc8 if it still fails. I got nothing else better to do right now.

@Refutationalist It seems to be an issue related to gcc10. Here's the version info of my compiler.

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

I built Xen with makepkg -si.

@skyzh: How were you building when you triggered that message? I just built Xen on a brand new install and didn't manage to see that in the captured build output.

@ska67: For booting, I think the best way forward would be to update the wiki page with specific bootloader instructions, and then point to the wiki on install. We recently pulled out GRUB specific code, the direct EFI boot needs some changes that would make it longer than I think is useful in an install message, and there a lot of different boot methods being discussed in the comments here.

As far as QEMU goes, is there anything specific that needs to be added for Xen functionality? If we're just adding stuff to QEMU to use QEMU separate from Xen, I would not build QEMU inside this package, but modify the stock Arch qemu package to include Xen support.

Just a note that I see the recent comments, but I'm not in a position to work on them at the moment. I'll get to them ASAP.

Thanks for this AUR package! I tried to install this on latest archlinux, and the compiler reports

multiple definition of 'tpm version'

in several files.

I found that this can be solved with this patch from GitHub https://github.com/patchew-project/xen/commit/ac9d413015d3bcf1e8f31cda764590b3ee949bc1.patch

Hope this could help other users when using this AUR package.

Your PKGBUILD uses "build_qemu" as build option to enable or disable the integrated Xen version of upstream Qemu. The Xen configuration allows additional configuration options for building this upstream Qemu with --with-extra-qemuu-configure-args[="--ARG1 ..."]. Please allow such additional configuration options for "build_qemu", besides the options true and false.

I am using systemd-boot, after build and install I have to copy /usr/lib/efi/xen.efi and /etc/xen/efi-xen.cfg as xen.cfg to my esp (boot) partition. The names of xen.efi and xen.cfg must be equal. It would be great if a hint would be displayed during the installation on uefi systems using systemd-boot or efistub booting.

@jac299792458 Use "console=vga vga=text-80x25,keep" on the hypervisor command line and "console=hvc0 earlyprintk=xen" on the kernel command line if you do not have a serial console for hypervisor output.

I was able to get this to build and install successfully. However, I'm having the damnedest time getting it to boot on my Dell Precision 5550 laptop. I've tried using grub-xen-git (which boot regular Arch, same kernel, just fine), and I've tried directly booting Xen from UEFI.

In both cases, I see the Xen messages scroll by, the last one mentions relinquishing the VGA port, it blanks the screen and ... nothing. It just sits there.

I've removed and / or tweak the intel-ucode scanning with no change in behavior. Is there anything else I should try next to get some more actionable info? I've also added 'earlyprintk=xen' to the kernel cmdline for both via Grub->Xen and UEFI -> Xen ...

I've been having trouble getting this to compile. Is it possible that there's a missing dependency? Here's where the make errors out.

make[7]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc'
make[6]: *** [Makefile:582: all-recursive] Error 1
make[6]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib/libc'
make[5]: *** [Makefile:574: all-recursive] Error 1
make[5]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib'
make[4]: *** [Makefile:402: all] Error 2
make[4]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64/x86_64-xen-elf/newlib'
make[3]: *** [Makefile:8613: all-target-newlib] Error 2
make[3]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64'
make[2]: *** [Makefile:697: all] Error 2
make[2]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom/newlib-x86_64'
make[1]: *** [Makefile:100: cross-root-x86_64/x86_64-xen-elf/lib/libc.a] Error 2
make[1]: Leaving directory '/home/ephreal/builds/xen/src/xen-4.14.0/stubdom'
make: *** [Makefile:138: install-stubdom] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

@Refutationalist If you have it running, go ahead and do a package release for 4.14.0. Sorry I wasn't able to submit the GRUB bits before heading to the mountains for a family reunion this week. If you're game, we can do another package release with the updated GRUB once I get back to civilization.

I've got a 4.14.0-0 on my github that seems to be running well on my test machines, so if those grub changes are good to go, I can push to AUR.

@Reutationalist That's great and Github will work just fine. I'm in process with some other projects, but I will try to get those Grub changes to you by the end of the week.

@cman -- Yeah, the changes turned out to be pretty trivial and I've already got it compiling, will start testing shortly. I could use those GRUB changes as I'm GRUB-avoidant. If github is good, I've been using my PKGBUILD repo as a staging area, so you can get me the changes there, otherwise we'll figure it out.

Repo is: https://github.com/Refutationalist/saur

Hi @Refutationalist, thanks for the great package. I have compiled this package with 4.14.0, and can confirm that most, but not all, of the gcc patches are no longer needed. I've also rebased the grub script on what is in the latest Archlinux package, plus added support to the script for cpu microcode updates and xsm, if present.

I, too, am not too conversant with aur, so I don't know whether a standard way exists to do that (other than with git, of course), but I'm happy to contribute patchsets if you would like if you tell me how you want them.

@linuxninja - Yeah, my package is still requiring qemu-xen from my personal repo, something that I'll be fixing in the next update.

I'm also looking at 4.14.0, which is not compiling but looks to have some of the same problems as 4.13.1 did. I'll try to have something ASAP, depending on complexity and my workload.

I was able to build with the changes to the source that I noted, however, I am unable to start a HVM VM with the new build options in this PKGBUILD. I had to revert to the old PKGBUILD and go back to Xen 4.13.0.

source = https://src.fedoraproject.org/rpms/xen/raw/master/f/xen.gcc10.fixes.patch https://src.fedoraproject.org/rpms/xen/raw/master/f/xen.ocaml.4.10.patch

Needs to be changed to

source = https://src.fedoraproject.org/rpms/xen/raw/f32/f/xen.gcc10.fixes.patch https://src.fedoraproject.org/rpms/xen/raw/f32/f/xen.ocaml.4.10.patch

in the PKGBUILD. The f32 tag reflects the files the PKGBUILD has been using up to this point. The Master branch has moved on to Xen 4.14.0 and has removed the ocaml patch and the gcc10 patch is no longer the same file.

Ok, so it turns out I'm actually blind. Removing --with-system-qemu from the build function does the deed. Makes me think there should be an optdepends or depends on qemu if you're going that route so that it's slightly more obvious.

So how do I get a functional HVM with this release? (4.13.1-4) There's no /usr/lib/xen/bin/qemu-dm but I don't see anything obvious in the PKGBUILD as to why.

WANTED: Maintainer or co-maintainer.

I've written a lot of PKGBUILDs for my own purposes, but I'm not that conversant with AUR itself other than using it. I'm also going to be hip deep in work over the next few months and might miss stuff.

Okay, I've added the disable flag for qemut, and at least allowed the package to disable stubdom if people don't want it. I've also split out the docs package, as before. This package is currently at parity with what's in my git.

Next, I'd like to take a closer look at qemu before I willy-nilly push qemu-xen to AUR.

@JohnTh:

The minimal-components builds were never useful to me without modification, which is another reason why my personal repo is the way it is. But my build wasn't going to be on AUR, so I suppose I should revisit that. I invariably need stubdom, so I pulled out the optional check. Other stuff I can probably get rid of, qemut in particular.

I'm not familiar with what the community decisions were. I can review the comments, but that wasn't my initial aim and I took over the package as I seemed to have inadvertently caused a problem. Would it make more sense if you or someone else took over the package? I'm open to that.

Otherwise, I'm going to look into fixing what I have outstanding and updating the package sometime next week.

@JohnTh qemu requires the Xen headers to compile Xen support, so unless you can get this into an arch repository, it will be unlikely our qemu maintainers will want to build the Xen tools themselves.

I would prefer such headers/compilation to be a separate package, so to keep this one lean. Much like the kernel headers are available in an addition package.

It is much easier to support a minimal-components build:

Do we need?: - qemut (--disable-qemu-traditional) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=configure;hb=staging - stubdom (--disable-stubdom) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=configure;hb=staging - ipxe (only used with qemut rombios / with-system-ipxe exists, but only aur ipxe package) https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/firmware/Makefile;h=809a5fd0255e19b15abda6daf891ed1f5e63e9ad;hb=staging

qemu requires the Xen headers to compile Xen support, so unless you can get this into an arch repository, it will be unlikely our qemu maintainers will want to build the Xen tools themselves.

Most of these have been covered deeper in these comments: https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100

My minimal Xen staging tee build seems to be compiling fine without any extra patches, but it is way too messy to use: https://gitlab.com/archlinux-packages-johnth/xen/-/blob/xen-git/PKGBUILD

Thanks FFY00 and Ref.

Thank you for your work, FFY00.

I'm currently out in the woods with limited internet. I'll be back sometime next week, at which point I'll clean up outstanding changes in my repo and push it to AUR. I didn't care about the docs package, but I can re-add that.

I'll also talk to the QEMU maintainers about adding the configure arg for Xen to QEMU, and seeing what they're doing upstream about GCC and python changes. I'll also likely push my PVH kernel to AUR.

@FFY00: The package I'm working on is very much based on your work and is intended as an interim solution while you are doing things properly. I tried to make that clear in my notes. If I have given any other impression, it is not intended and I apologize.

I had a personal itch to scratch and I shared my work. I wasn't figuring on much of anything beyond that, so the formatting changes didn't really matter to me very much. You're welcome to use what I've done or dismiss it entirely.

There were several things that blocked me from updating the package, you should be able to find the discussion below. If you think you are able to do it package the new version properly, please show me a PKGBUILD and I'll disown.

@Refutationalist Unfortunately, it's difficult to diff your changes against this PKGBUILD because of all the formatting changes. Do you plan on rebasing your changes on top of this pkg, or do you consider your work to be a hard fork at this point?

Here is the minimal diff I came up with on top of this PKGBUILD to get 4.13.1 building with latest GCC (& drop the python2 dep): https://github.com/sl4mmy/docker-aur-xen/blob/master/aur-xen_PKGBUILD.patch. The two patches for GCC 10 compile fixes can be found here: https://github.com/sl4mmy/docker-aur-xen/blob/master/gcc-10-fixes.patch, and here: https://github.com/sl4mmy/docker-aur-xen/blob/master/gcc-10-ipxe-fixes.patch.

It would be great if we could get this pkg updated to 4.13.1, including all of your additional improvements (stubdom, rundir, firmware hooks, etc.).

@ntegan: that's good to hear. I'll probably want to look at changing the GRUB scripts then to look for xen.gz instead of a versioned file.

My justification is that I use either syslinux or direct EFI boot, and having to change my settings on every revision is suboptimal. Also, since other kernels aren't versioned in the repos, it seemed a bit more Arch-like to me.

In the meantime, since I first posted I've made a couple of bugfixes. I moved ipxe out of _stubdom_sources as it's not for stubdom, set rundir, and then added a hook to extract firmware from intel-ucode so xen EFI can use it. I'm working on an AMD hook.

Thanks for the updated PKGBUILD, @Refutationalist.

Only thing I had to change for GRUB to generate the menu entry was to move my /boot/xen.gz to /boot/xen-4.13.1.gz, to match what the grub menu entry generator was looking for.

I found that the gcc upgrade to 10 broke my compile, too. The only reason I needed to compile is that nettle upgraded and requires xen to be recompiled, but I could only get xen 4.13.0 to compile, not 4.13.1. I downgraded gcc back to the last version of 9 and was able to recompile for the newer version of nettle.

I'm still on kernel 5.5.13-arch2 as it was the latest I could get HVM networking to work (I run OPNSense as a HVM).

My server motherboard doesn't have UEFI, so I'm only doing BIOS boot with Grub2.

Thanks for the repo. I will certainly check it out!

Oh, also, I haven't tested the grub bits at all since, as I don't use it.

Most recent upgrade of one of my dom0s broke this package for me. Also, recompiling from this package or any other PKGBUILD failed under GCC 10.1. I decided to look into it as I needed this machine up and running.

While I was looking for solutions, I noticed that there was a tarball for 4.13.1 available. I found some patches for GCC 10 via Fedora, but there were other simple changes needed for 10.1. It was trial and error, "make it go" hacking rather than anything robust, but it does compile and run.

It's a kitbash of a couple PKGBUILDs with some changes to simplify things. It's available here: https://github.com/refutationalist/saur/tree/master/xen

I've tested it on exactly one system: the one I needed to run. It's successfully booted Arch in PV and OpenBSD in HVM. Haven't tested PVH yet, but that's next. At this point, I thought more eyes were better.

Elsewhere in the repo is a version of qemu from the repos that has been modified to include xen, if that's needed.

I've been testing different kernels with dom0 under Xen. I found that kernel 5.6.0 does not work, but 5.5.13-arch2-1 does. I will be looking through the other kernel versions and comparing the kernel compile configs to determine if something changed.

Kernel 5.5.13-arch2-a as a dom0 under Xen 4.13.0 is working, so far.

No problem getting Xen 4.13.0 compiled and running. Had to change one configure option...

Any updates on getting the version moved up? This package is now a couple of versions behind upstream... current Xen version is 4.13.0

I was able to get 4.12.2 to build without issue.

Upgraded to the latest kernel, 5.6.10, and it broke networking for Xen HVM (opnsense). Downgraded the kernel back to 5.5.8 and things work, again. Not sure which kernel version is the last one that works since I haven't upgraded each release.

Just failed to build like that:

makepkg -cCsfir
==> Making package: xen 4.12.1-1 (Sun 12 Apr 2020 10:23:19 PM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
resolving dependencies...
looking for conflicting packages...

...

==> Retrieving sources...
  -> Found xen-4.12.1.tar.gz
  -> Found xen-4.12.1.tar.gz.sig
  -> Found ipxe-git.tar.gz
  -> Found grub-mkconfig-helper
  -> Found efi-xen.cfg
  -> Found grub.conf
  -> Found xen.conf
  -> Found tmpfiles.conf
==> Validating source files with sha256sums...
    xen-4.12.1.tar.gz ... Passed
    xen-4.12.1.tar.gz.sig ... Skipped
    ipxe-git.tar.gz ... Passed
    grub-mkconfig-helper ... Passed
    efi-xen.cfg ... Passed
    grub.conf ... Passed
    xen.conf ... Passed
    tmpfiles.conf ... Passed
==> Verifying source file signatures with gpg...
    xen-4.12.1.tar.gz ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Extracting xen-4.12.1.tar.gz with bsdtar
==> Starting prepare()...
  -> Copying downloaded files...
  -> Applying XSA patches...
  -> Applying tools patches (qemu-xen-traditional)...
  -> Applying tools patches (qemu-xen)...
  -> Applying misc compile fixes...
  -> Fixing installation paths...
==> Sources are ready.
==> Removing installed dependencies...
checking dependencies...
:: brltty optionally requires ocaml: OCaml support
:: graphviz optionally requires ocaml: ocaml bindings

...

 CC       xentoollog_stubs.o
xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage':
xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
   93 |  value *func = caml_named_value(xtl->vmessage_cb) ;
      |                ^~~~~~~~~~~~~~~~
xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress':
xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  123 |  value *func = caml_named_value(xtl->progress_cb) ;
      |                ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
...
==> ERROR: A failure occurred in build().
    Aborting...
...

Not sure if we not need to install the xen /boot/xen-$version.config, we do not have a Arch linux /boot/config-vmlinuz, which is where one GRUB 20_linux_xen issue comes from: GRUB upstream bug: 20_linux_xen does not work if no kernel config file

xen-$version.efi may still be wanted by some, and GRUB should not add this as a multiboot2 option: GRUB upstream bug: 20_linux_xen also creates garbage entries for xenconfig and xenefi

Xen installs the /usr/lib/modules-load.d/xen.conf file. It also contains (historic) module names that do not exist in our distribution. systemd-modules-load.service will exit with failure for these nonexistant modules, but boot does continue. see:pacman -Ql linux | grep -E 'xen-' https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100#comment-622244

Ah, thanks.

My second GRUB patch null config filename we could workaround by installing: /boot/config-${linux pkgbase} with CONFIG_XEN_DOM0=y in a pacman hook? But this is only appropriate to booting Xen with GRUB on Arch. I will open bug upstream and pursue it there as well.

Thanks! Please post a link when you do :)

Hey FF,

Great to see progress.

modules-load.d/xen.conf

Xen installs the /usr/lib/modules-load.d/xen.conf file. It also contains (historic) module names that do not exist in our distribution. systemd-modules-load.service will exit with failure for these nonexistant modules, but boot does continue. see:pacman -Ql linux | grep -E 'xen-' https://aur.archlinux.org/pkgbase/xen/?O=0&PP=100#comment-622244

GRUB helper fixes upstream

Yes, will try for GRUB helper upstream changes.

Should not need my first GRUB patch -vmlinuz-*, +vmlinuz anymore, as it looks like mkinitcpio installs kernel as vmlinuz-${pkgbase} now I use dracut, so I cannot check this on system. https://git.archlinux.org/mkinitcpio.git/tree/libalpm/scripts/mkinitcpio-install

My second GRUB patch null config filename we could workaround by installing: /boot/config-${linux pkgbase} with CONFIG_XEN_DOM0=y in a pacman hook? But this is only appropriate to booting Xen with GRUB on Arch I will open bug upstream and pursue it there as well.

Cheers

I think we should work on fixing the issue in the upstream (so, grub) and backport the patch to the grub package. Do you want to do it? Since you wrote the patches.

The two last patches that is. For the first we should open a bug report for grub package.

Hey, sorry for the delay catching up.

ovmf typo in your PKGBUILD optdepends and Xen configure option Package has /etc/init.d/ files

Fixed (locally).

Maybe some sort of install message about: - booting Xen & enabling services? (Xen gets booted before linux dom0) - fixing dom0 memory in the bootloader Xen hypervisor config

Will add before moving to the repos.

Worth cleanup of usr/lib/modules-load.d/xen.conf to avoid modules load errors: I used this in prepare(). find tools -iname 'configure*' -exec sed -i -E -e '/^LINUX_BACKEND_MODULES="$/,/^"$/{/"/b;/^xen-/!d;s/scsibk/scsiback/;};' {} \;

Can you explain exactly what is the issue here?

GRUB helper for loading the Xen dom0: It might be better to fix the Arch grub package with a patch so that 20_linux_xen works for arch kernel? My old changes linked. Need retesting. - vmlinuz- - don't fail on no /boot/config file - ignore xen files grub cannot boot

I think we should work on fixing the issue in the upstream (so, grub) and backport the patch to the grub package.

Do you want to do it? Since you wrote the patches.

Hey FF,

Have not yet had a chance to install and test, but looking over it again:

• ovmf typo in your PKGBUILD optdepends and Xen configure option
• Package has /etc/init.d/ files
• Maybe some sort of install message about:
• booting Xen & enabling services? (Xen gets booted before linux dom0)
• fixing dom0 memory in the bootloader Xen hypervisor config

• Worth cleanup of usr/lib/modules-load.d/xen.conf to avoid modules load errors: I used this in prepare(). find tools -iname 'configure*' -exec sed -i -E -e '/^LINUX_BACKEND_MODULES="$/,/^"$/{/"/b;/^xen-/!d;s/scsibk/scsiback/;};' {} \;

• GRUB helper for loading the Xen dom0: It might be better to fix the Arch grub package with a patch so that 20_linux_xen works for arch kernel? My old changes linked. Need retesting.

• vmlinuz-
• don't fail on no /boot/config file
• ignore xen files grub cannot boot

Cheers

I think I fixed everything in the PKGBUILD[1]. Both the updated xen package and a qemu package built with --enable-xen are available in my repo[2]. Could you guys please try it and let me know if there are still are any issues?

Regarding the bootloader, the pvgrub helper is packaged but it is broken. This is an upstream issue, I am going to contact them. Basically, in Python 3.8 the descriptor flags for native modules are checked when the module is imported, as opposed to when a certain method is called. This causes the xen.lowlevel.xc to fail to import. This should be a quick fix from the upstream, I had a look but couldn't find the culprit (the python error message could be a little more verbose :P).

Also, if you want UEFI support you will need the ovfm package from [testing].

[1] https://paste.xinu.at/mbZ/ [2] https://pkgbuild.com/~ffy00/repo/

Hi FF, With my own built and installed Xen git master:

The OVMF package in Arch [testing] now includes OVMF.fd, and that boots for me. I tested a boot to EFI BIOS & linux had populated /sys/firmware/efi/efivars/

Tested with: domU.cfg options

bios = "ovmf"
bios_path_override = "/usr/share/ovmf/x64/OVMF.fd"

I cannot use the current Arch system QEMU:

tail /var/log/xen/qemu-dm-*.log
qemu-system-x86_64: -xen-domid 11: Option not supported for this target

Tested with: domU.cfg options

device_model_version = "qemu-xen"
device_model_override = "/usr/bin/qemu-system-x86_64"

To use Arch system QEMU would require some changes in the Arch qemu package. At least makedep xen for the header files, and compiled with --enable-xen, and possibly --enable-xen-pci-passthrough Then check qemu still functions without the xen headers, or split these headers from the xen package and depend on them in qemu? https://packages.debian.org/sid/amd64/libxen-dev/filelist

If you want to move this packaging planning somewhere else, let us know.

Cheers

Hi FFY00,

Other things that could be improved in your PKGBUILD, you can use Arch Linux's SeaBIOS, with:

./configure --with-system-seabios=/usr/share/qemu/bios-256k.bin

For backup=(), this is probably the list of configuration file:

etc/default/xencommons
etc/default/xendomains
etc/xen/cpupool
etc/xen/xl.conf
etc/xen/scripts/*

Cheers.

It almost builds. It builds, but then fails when packaging here: mv "${pkgdir}/usr/lib64/efi/xen".efi "${pkgdir}/boot". The folder .../lib64 doesn't exist, and xen.efi isn't built. I don't have any idea why. After all the build works (after using the patched PKGBUILD). Can somebody explain why the xen.efi binaries aren't built? Tried to understand the makefiles, ..I guess some precondition isn't met but I have no fing idea.

It builds fine (is valgrind necessary? quite a large dependency).

Got this when trying to install: https://gist.github.com/invisiblek/01920f2b63f37e7d0d317ae549c9de00 It's due to an empty /usr/lib64 dir in the package which is residual from the mv of efi in package() function. Add an rmdir "$pkgdir"/usr/lib64/ after the mv on line 97 and it installs fine.

Your PKGBUILD does not include a grub helper like this one does, so creating a grub config would have to be done manually or something after installation. I'm not sure the best way to handle that situation (for an official build you probably need to handle more than just grub as the user's bootloader?).

FF,

I have not yet tried your package, just had a quick look over it.

It has been years since I tried to use Arch system qemu and ovmf (typo in your optdepends), and it would be delightful to find these just worked now...

When I did:

• Xen could not use OVMF's code.fd and vars.fd separately. It would be very simple to split Arch's OVMF package to ship the unified file in another package. The Arch bug has been ignored for years https://bugs.archlinux.org/task/58635

• QEMU seems to need to be built with Xen headers in place for Xen backend support Debian installs libxen-dev before building QEMU https://salsa.debian.org/qemu-team/qemu/-/blob/debian-unstable/debian/control-in https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/control Xen uses --enable-xen for the in-tree copy https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/Makefile;h=c10946e3b15a5a14aa83e4bbfda759b3681692de;hb=HEAD#l241

It would be great to see this tested and packaged. Cheers

Hey guys. I have been working on a PKGBUILD but haven't been able to test it.

https://paste.xinu.at/6PR/

Can anyone see if there are any issues? If everything is fine we can go ahead and move it to the official repos.

This commit fixes the current build issue: http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=368375d7360a38c27de8e0276498bdd29e9e8a03

Sadly that commit hasn't been backported to the 4.12 branch, so it has to be patched during makepkg. I suppose you could also downgrade your ocaml to something before 4.09 and things would work again too...but that seems foolish.

Possible solutions here:

1. Fix up the current 4.12.1 build like so: https://github.com/invisiblek/xen-aur/commits/4.12.1-2

2. Step one plus update to 4.12.2 while we're at it: https://github.com/invisiblek/xen-aur/commits/4.12.2-1

3. Move to 4.13.0: https://github.com/invisiblek/xen-aur/commits/4.13.0-1

All three do require this minor patch to remove a now deprecated flag in qemu: https://github.com/invisiblek/xen-aur/commit/168fbdaa33265c4902ebfd5e8def892b0c2c14ca

I'll be testing with my 4.13.0-1 branch for now.

I see FFY00 mentioned official repos a couple months ago, unsure the status on that as of yet. Maybe I'll ping them on irc one of these days and see where that whole thing is at.

For now at least we can have working builds again :)

Getting the same error as @schweratlet, installing with pikaur.

@mbroemme I'm getting the same error when trying to install (installing with yay -S xen. though I hope it doesn't make a difference.

make -C xentoollog install make[8]: Entering directory '/home/shogoro/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog' python2 genlevels.py _xtl_levels.mli.in _xtl_levels.ml.in _xtl_levels.inc MLDEP MLC xentoollog.cmo MLA xentoollog.cma CC xentoollog_stubs.o xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage': xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 93 | value func = caml_named_value(xtl->vmessage_cb) ; | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress': xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] 123 | value func = caml_named_value(xtl->progress_cb) ; | ^~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors )

It leaves a whole bunch of directories and then.

make[1]: [Makefile:74: install] Error 2 make[1]: Leaving directory '/home/shogoro/.cache/yay/xen/src/xen-4.12.1/tools' make: [Makefile:127: install-tools] Error 2 ==> ERROR: A failure occurred in build(). Aborting... Error making: xen

Is this in any way my fault? Any advice? I have installed Xen successfully before, more specifically twice 4-5 months ago both on a fresh install. This is the first time I'm encountering such an error. I've tried it several times.

@FFY00 oh please do!

In regards to CIS, this is the only package remaining that we use outside of the official repos.

Hey, I want to move this to the official repos. Are you ok with that?

@mbroemme - do you plan on dropping the python2 dependency in favor of python? Also, would you be willing to consider switching the brltty dependency to the brltty-minimal available in AUR?

Thanks in advance!

4.13.0 is available, will built and merge all changes requested in the comments in the next few days.

I have spent many hours the last days trying to get a VM running with UEFI (ovmf), but Xen keeps crashing (visible by "xl dmesg").

It is related to the used Arch ovmf package in combination with the Xen configure parameter in PKGBUILD

--with-system-ovmf=/usr/share/ovmf/x64/OVMF_CODE.fd

After removing this parameter, Xen uses its 'native' ovmf binary provided by

/usr/lib/xen/boot/ovmf.bin

and not the one from the arch ovmf package provided by

/usr/share/ovmf/x64/OVMF_CODE.fd /usr/share/ovmf/x64/OVMF_VARS.fd

Would you mind to either (for now) remove the ovmf configure parameter and/or solve the cause of the crashing Xen with the Arch ovmf package?

I ran into the same libiscsi.so.8 problem. Re-compiling Xen and re-installing resolved the issue.

Hi sometroubles with xen when compile the package see below make[4]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools/ocaml' make[3]: [/tmp/trizen-geh/xen/src/xen-4.12.1/tools/../tools/Rules.mk:251: subdir-install-ocaml] Error 2 make[3]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools' make[2]: [/tmp/trizen-geh/xen/src/xen-4.12.1/tools/../tools/Rules.mk:246: subdirs-install] Error 2 make[2]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools' make[1]: [Makefile:74: install] Error 2 make[1]: Leaving directory '/tmp/trizen-geh/xen/src/xen-4.12.1/tools' make: [Makefile:127: install-tools] Error 2 ==> ERREUR : Une erreur s’est produite dans build(). Abandon… :: Unable to build xen - makepkg exited with code: 4

Post upgrade, xen cannot start Windows HVM since libiscsi got upgraded. Can you make that dependency build-time version specific?

[2019-11-15T12:09:35-0500] [ALPM] upgraded libiscsi (1.18.0-1 -> 1.19.0-1)

/usr/lib/libiscsi.so.9

/usr/lib/xen/bin/qemu-system-i386: error while loading shared libraries: libiscsi.so.8: cannot open shared object file: No such file or directory

I had to add this line to the PKGBUILD file:

Compile fixes.

• sed 's/CFLAGS += -fPIC -Werror -I$(shell ocamlc -where)/CFLAGS += -fPIC -I$(shell ocamlc -where)/' -i tools/ocaml/common.make

Details are here: https://bbs.archlinux.org/viewtopic.php?id=249954

I am getting this error when trying to compile:

make[8]: Entering directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/mmap'
 MLDEP    
 MLI      xenmmap.cmi
 MLC      xenmmap.cmo
 MLA      xenmmap.cma
 CC       xenmmap_stubs.o
 MKLIB    libxenmmap_stubs.a
 MLOPT    xenmmap.cmx
 MLA      xenmmap.cmxa
sed 's/@VERSION@/4.1/g' < META.in >META.new && mv -f META.new META
mkdir -p /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml
ocamlfind remove -destdir /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml xenmmap
ocamlfind: [WARNING] No such file: /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/META
ocamlfind install -destdir /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml -ldconf ignore xenmmap META xenmmap.cmi xenmmap.cma xenmmap.cmxa *.a *.so *.cmx
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cmx
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/dllxenmmap_stubs.so
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.a
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/libxenmmap_stubs.a
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cmxa
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cma
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/xenmmap.cmi
Installed /home/roberts/.cache/yay/xen/src/xen-4.12.1/dist/install/usr/lib/ocaml/xenmmap/META
make[8]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/mmap'
make[7]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make[7]: Entering directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make -C xentoollog install
make[8]: Entering directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog'
python2 genlevels.py _xtl_levels.mli.in _xtl_levels.ml.in _xtl_levels.inc
 MLDEP    
 MLC      xentoollog.cmo
 MLA      xentoollog.cma
 CC       xentoollog_stubs.o
xentoollog_stubs.c: In function 'stub_xtl_ocaml_vmessage':
xentoollog_stubs.c:93:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
   93 |  value *func = caml_named_value(xtl->vmessage_cb) ;
      |                ^~~~~~~~~~~~~~~~
xentoollog_stubs.c: In function 'stub_xtl_ocaml_progress':
xentoollog_stubs.c:123:16: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  123 |  value *func = caml_named_value(xtl->progress_cb) ;
      |                ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[8]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog/../../Makefile.rules:37: xentoollog_stubs.o] Error 1
make[8]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/xentoollog'
make[7]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/../../../tools/Rules.mk:251: subdir-install-xentoollog] Error 2
make[7]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make[6]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs/../../../tools/Rules.mk:246: subdirs-install] Error 2
make[6]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/libs'
make[5]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/../../tools/Rules.mk:251: subdir-install-libs] Error 2
make[5]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml'
make[4]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml/../../tools/Rules.mk:246: subdirs-install] Error 2
make[4]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/ocaml'
make[3]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/../tools/Rules.mk:251: subdir-install-ocaml] Error 2
make[3]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools'
make[2]: *** [/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools/../tools/Rules.mk:246: subdirs-install] Error 2
make[2]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools'
make[1]: *** [Makefile:74: install] Error 2
make[1]: Leaving directory '/home/roberts/.cache/yay/xen/src/xen-4.12.1/tools'
make: *** [Makefile:127: install-tools] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
Error making: xen

@mbroemme First of thanks for getting it working with gcc-9!

Secondly I'm running into the following compile issue: .cache/yay/xen/src/xen-4.12.1/tools/qemu-xen/include/disas/capstone.h:6:10: fatal error: capstone.h: No such file or directory 6 | #include <capstone.h>

I have capstone installed; and /usr/include/capstone/capstone.h exists. Any chance of a suggestion, Also should capstone be listed as a dependency?

Package is updated to Xen 4.12.1, ipxe package as well, supporting compilation with gcc-9.

@dhlk thanks for it, added !debug

fresh install of arch

attempted to install xen - failed

removed gcc v9, installed gcc-8

symlinked gcc -> gcc-8

re-tried install of xen - failed

/usr/bin/env: 'python': No such file or directory

So, looks like a dependency on python isn't configured properly? python2 is installed...

Installed python (python v3)

re-tried install of xen - failed

ERROR: "cc" either does not exist or does not work

make: Entering directory '/home/user/.cache/yay/xen/src/xen-4.12.0/tools/qemu-xen-build'

make: *** No rule to make target 'all'. Stop.

Not sure how deep this rabbit hole goes. Really don't want to go back to Debian...

"error: taking address of packed member of ..."
Same issue here to build Xen 4.12 w/ kernel 5.1.15, gcc 9.1.0
Solved by downgrading to package gcc8

It seems to not compile at all using the latest GCC (9.1.0, just got out of testing today). I get way too many instances of -Werror=address-of-packed-member.

It's a known bug and afaik has been fixed in xen's git repo for a while now. Might be wise to incorporate the patch into the PKGBUILD until it gets merged into a proper release?

EDIT: I should add that this happens even when adding "--disable-werror" to the config params and "!debug" to the options à la dhlk's commment.

EDIT2: Even the latest, bleeding edge staging versions of xen and ipxe do not compile under GCC 9. I'm sure it'll be fixed in a few days or so, but the official Xen 4.13 release probably won't be coming for a while. If it ends up getting fixed and anyone is interested, I can create a xen-git package.

the http://google.com

For anyone else (and my future self) who forgot they enabled debug in makepkg.conf, debug CFLAGS break xen's builds.

Error looks something like this:

<command-line>: error: "__OBJECT_FILE__" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
<command-line>: error: "__OBJECT_LABEL__" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
Makefile:69: recipe for target 'compat/callback.i' failed

Fix requires removing debug in the PKGBUILD:

-options=(!buildflags !strip)
+options=(!buildflags !strip !debug)

Works like a charm, Thank you.

@ArthurBorsboom: thank you! i'll have an AMD system to test it out on soon.

instead of flooding these comments with discussions, let's keep it in recent forum topic here:

https://bbs.archlinux.org/viewtopic.php?pid=1814467

In short, there's another way that we can ask the author of the intel-ucode package to resolve (posted in the link above).

I have found a solution in the past (and am still using) another way of loading the (AMD) microcode in Xen.

In essence:

• Create a symlink from /lib/firmware/amd-ucode/microcode_amd_fam15h.bin -> /boot/microcode_amd_fam15h.bin
• Edit the /etc/xen/grub.conf and add " ucode=-1"

• Manually update the file /etc/grub.d/09_xen by adding the following two lines (note that these lines differ a little bit from the forum post

  echo 'Loading AMD Microcode' module2 ${REAL_DIR}/microcode_amd_fam15h.bin

• rebuild grub conf file: grub-mkconfig -o /boot/grub/grub.cfg

• reboot

I have described it more accurately in this forum post, where you have to replace the word module (outdated) with module2.

https://bbs.archlinux.org/viewtopic.php?id=191828

So, no kernel panic while loading multiple ramdisks.

Does this help you to find a persistent solution?

EDIT: Created a bbs topic for discussion: https://bbs.archlinux.org/viewtopic.php?pid=1814467

Intel (and perhaps AMD, can't test that yet) microcode patching.

Problem:

xen.cfg for Xen EFI cannot use the intel-ucode.img microcode binary produced by the intel-ucode system package. Attempting to specify multiple ramdisk lines panics the kernel (Xen EFI only reads the first line); and, specifying multiple imgs on the single ramdisk line is invalid by Xen EFI and just exits the boot.

Resolution:

Create a "patched" initramfs-linux.img file:

# cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/intel-ucode_initramfs-linux.img

And then change xen.cfg to use this new patched ramdisk.

You can verify the fix with:

$ sudo xl dmesg | grep microcode
(XEN) microcode: CPU0 updated from revision 0x28 to 0x32, date = 2018-05-11
(XEN) microcode: CPU2 updated from revision 0x28 to 0x32, date = 2018-05-11

The bbs discussion above is to figure out the best place to capture this information.

I confirm the error message reported by sniper7kills: "free(): invalid pointer".

To generate the error I went to tools/firmware/hvmloader and ran make while using the latest version of acpica

make -C ../../libacpi  ACPI_BUILD_DIR=/storage/xen/src/xen-4.11.0/tools/firmware/hvmloader DSDT_FILES="dsdt_anycpu.c dsdt_15cpu.c dsdt_anycpu_qemu_xen.c"
make[1]: Entering directory '/storage/xen/src/xen-4.11.0/tools/libacpi'
gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -DCONFIG_X86 -I/storage/xen/src/xen-4.11.0/tools/libacpi/../../tools/include -D__XEN_TOOLS__ -o /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/mk_dsdt mk_dsdt.c
# Remove last bracket
awk 'NR > 1 {print s} {s=$0}' dsdt.asl > /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp
cat dsdt_acpi_info.asl >> /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp
/storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/mk_dsdt --debug=n --maxcpu any  >> /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp
mv -f /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl.tmp /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl
iasl -vs -p /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.tmp -tc /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.asl
free(): invalid pointer
make[1]: *** [Makefile:78: /storage/xen/src/xen-4.11.0/tools/firmware/hvmloader/dsdt_anycpu.c] Aborted (core dumped)
make[1]: Leaving directory '/storage/xen/src/xen-4.11.0/tools/libacpi'
make: *** [Makefile:72: acpi] Error 2

Unlikely that this is a xen issue; but building fails when using the latest acpica package.

It was something to do with the hvmloader and unable to call free() due to an invalid pointer.

Downgrading acpica to version 20180629 allows the package to compile.

Once I recompile xen to fix my libiscsi issue, I'll upgrade acpica again to try and provide more information.

Orphaned package removal routine* breaks this package. Please fix your depends/makedepends so that they are accurate.

*https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Removing_unused_packages_.28orphans.29

Thanks!

4.11.0 is available and I will test it till next week and update PKGBUILD

@mbroemme: No problem, thanks for reply and for your work on xen package. Have an awesome weekend!

@k96hkh: I believe xen 4.11.0 will come out in the next 2 weeks. Is it okay to wait this 2 weeks and I will update the PKGBUILD as soon as 4.11.0 is out.

I'm afraid I got stuck with same error as "Anonym" and "tendermonster", any idea what I can do to get xen to build? I guess I could build from 4.11-rcX like "tendermonster" but I would prefer to use the AUR package. Cheers!

My lil story on installing xen from aur:

i got the same error what "Anonym commented on 2018-06-21 15:01" got. Then i tried to compile xen myself from gitrepo but failed with save error. I tries fixing it my editing countless c++ files, but at the end i gave up when i encountered "util.o: In function hvmloader_acpi_build_tables': util.c:(.text+0x183e): undefined reference todsdt_anycpu_qemu_xen' util.c:(.text+0x1b52): undefined reference to dsdt_anycpu' util.c:(.text+0x1b65): undefined reference todsdt_15cpu' ovmf.o: In function ovmf_acpi_build_tables': ovmf.c:(.text+0xf8): undefined reference todsdt_anycpu_qemu_xen' seabios.o: In function seabios_acpi_build_tables': seabios.c:(.text+0x25a): undefined reference todsdt_anycpu_qemu_xen' rombios.o: In function rombios_acpi_build_tables': rombios.c:(.text+0x68): undefined reference todsdt_anycpu' rombios.c:(.text+0x7e): undefined reference to `dsdt_15cpu' " errors. I have no idea what really causes it(Makefile in tools/firmware/hvmloader?)

After that I just compiled the more uptodate "i guess" 4.11-rcX from https://github.com/xen-project/xen and all just worked fine.

Just install all required packaged "make gcc lib32-gcc-libs lib32-fakeroot lib32-libltdl seabios patch autoconf pkgconf linux-headers zlib python python-pip python-lxml xorg-server haskell-uuid yajl libaio glib2 bridge-utils bison flex acpica cmake markdown figlet bin86 dev86 python2 python-pip fig2dev wget pandoc patch" and configure; make; install

Just to be on the safe side use python2 and gcc7 also link then to gcc and python with ln -s /usr/bin/python2 /usr/bin/python and ls -s /usr/bin/gcc-7 /usr/bin/gcc

It would ne cool if anyone would notify me if the problem resolves on xen 4.10.1

Much thx and have a sunny day :)

@anon This commit updates the makefile for newer versions of iasl: https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=858dbaaeda33b05c1ac80aea0ba9a03924e09005

when compiling dsdt_anycpu.c, I get the following error dsdt_anycpu.c:7495:28: Error：‘dsdt_anycpu’ undeclared here (not in a function); did you mean ‘dsdt_anycpu_len’? int dsdt_anycpu_len=sizeof(dsdt_anycpu); ^~~~~~~~~~~ dsdt_anycpu_len

@daniel_shub AFAIK, this is a new feature in GCC 8, which will be an error if -Werror is used. If you need the build ASAP, then you can downgrade your GCC.

I am building in a clean chroot. I get the following error;

xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation] strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN);

It looks like there may be a patch for it https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg11468.html

@virtualdxs: I've fixed OVMF system path, also added XSA-258 and glibc-2.27 compilation fix.

Regarding build failure, it looks like there was a previosuly applied patch in the src/ directory. Did you do rm -R src/ pkg/ before trying another compilation?

Here's the patch output: https://pastebin.com/VyPBun68

Also xsa253-xsa254-diff-release410-comet1.1.patch is failing. Build succeeds without it.

I could've sworn this was fixed months ago, but the compile options are wrong.

    --enable-ovmf \
    --with-system-ovmf \
    --with-system-seabios=/usr/share/qemu/bios-256k.bin \

Notice the --with-system-ovmf doesn't have a path. So Xen tries to access the file yes when looking for an EFI bios.

@mbroemme

xencommons: afaik I did not modified anything in xencommons https://pastebin.com/fjL3aRXw

xenstored.log:

...
Xen Storage Daemon, version 1.0
Xen Storage Daemon, version 1.0
Xen Storage Daemon, version 1.0
[20170612T07:40:10.883Z|error|xenstored] closing socket connection: write error: Broken pipe
Xen Storage Daemon, version 1.0
Xen Storage Daemon, version 1.0
...

@barathon: Do you have anything in /var/log/xen/xenstored.log Could you please post a link to your /etc/conf.d/xencommons

Nope, its still not working.

$ systemctl status xenstored
● xenstored.service - The Xen xenstore
   Loaded: loaded (/usr/lib/systemd/system/xenstored.service; enabled; vendor preset: disabled)
   Active: failed (Result: protocol) since Fri 2018-04-13 06:08:24 CEST; 10h ago
  Process: 493 ExecStart=/etc/xen/scripts/launch-xenstore (code=exited, status=0/SUCCESS)
  Process: 484 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 493 (code=exited, status=0/SUCCESS)
$
$ pacman -Qi xen
Version         : 4.10.0-4
Provides        : xen-4.10.0
Installed Size  : 63.92 MiB
Build Date      : Thu 12 Apr 2018 09:29:46 AM CEST
Install Date    : Thu 12 Apr 2018 09:30:24 AM CEST

@mbroemme: Sure. But I can restart the machine only tomorrow.

@jsteel: I've fixed the dependencies and aligned them between qemu-xen and qemu-xen-traditional.

@ianu/@dhlk: Fixed it as well and also applied and enabled all patches up to XSA-256.

@baratharon: Could you please retry with latest PKGBUILD from AUR?

xen-qemu-dom0-disk-backend.service fails, libepoxy is needed: /usr/lib/xen/bin/qemu-system-i386: error while loading shared libraries: libepoxy.so.0: cannot open shared object file: No such file or directory

This change should fix it

    # XSA patches (Last checked: XSA-253)
    'bba1abb5e4368421de29385e37f8477bf3534d3ba3ff7e2aae9c9d3da53f1393'
-   '5276d63e3b2ffc5217981e7b683c28d75b81793af8d2ffc75566db39aaabbaef'
+   'fa8cd07b85a8ff29cba8d891f12f9be4b173dd91a58404aabbf49c3f83152af9'

Looks like the checksum on xsa254-diff-release410-comet1.1.patch is incorrect.

Today I upgraded from 4.8 to 4.10, and I got this (no more information is available, so I don't know what should I do; also, google has no any usable info):

 xenstored.service - The Xen xenstore
   Loaded: loaded (/usr/lib/systemd/system/xenstored.service; enabled; vendor preset: disabled)
   Active: failed (Result: protocol) since Wed 2018-02-28 10:23:45 CET; 2min 6s ago
  Process: 506 ExecStart=/etc/xen/scripts/launch-xenstore (code=exited, status=0/SUCCESS)
  Process: 485 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 506 (code=exited, status=0/SUCCESS)

If your guest cannot see disks, make sure you have the xen-blkfront module loaded in your guest. You can use a serial port on the dom0 to get the full Xen log. I have a 4.10 PKGBUILD here: https://gitlab.com/archlinux-packages-johnth/xen

@mbroemme if you happen to have a git repo or PKGBUILD for 4.10 I'd love to give it a try; for some reason I'm having issues with linux install disks not detecting the HDD on any VM I try to setup and also been getting some errors after xen boots prior to the kernel but haven't been able to capture them at all.

Hoping that 4.10 resolves these for me.

@das_j: According to the wiki 4.10 was released. If you want I can also take it over and continue to maintain it.

@ezequiel.ezb: Import key via 'gpg --recv-keys 83FE14C957E82BD9' and retry build

All dependencies install correctly, however, I get this error afterwards:

==> Verifying source file signatures with gpg... xen-4.9.0.tar.gz ... FAILED (unknown public key 83FE14C957E82BD9) ==> ERROR: One or more PGP signatures could not be verified! makepkg -si 21.93s user 5.66s system 5% cpu 9:01.31 total