Package Base Details: xen

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Keywords: hypervisor virtualization xen
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 186
Popularity: 0.71
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-01-19 23:00 (UTC)

Latest Comments

1 2 3 4 5 6 .. 11 Next › Last »

daurnimator commented on 2024-01-22 05:27 (UTC)

FYI I plan on moving parts of xen to [extra] soon. Not all functionality of this AUR package will be retained, and you will likely have to e.g. have stubdom parts as their own AUR package xen-stubdom or similar

lapuglisi commented on 2023-09-12 00:43 (UTC) (edited on 2023-09-12 00:45 (UTC) by lapuglisi)

@Refutationalist

We need to change the file 'add-stubdom-fuxes.patch' to contain a new line, so it looks like this:

diff -Naur orig.xen-4.16.1/stubdom/Makefile xen-4.16.1/stubdom/Makefile
--- orig.xen-4.16.1/stubdom/Makefile    2022-05-16 09:41:38.409898784 -0700
+++ xen-4.16.1/stubdom/Makefile 2022-05-16 09:43:31.891076356 -0700
@@ -241,6 +241,7 @@
    patch -d $@ -p1 < vtpm_extern.patch
    patch -d $@ -p1 < vtpm-microsecond-duration.patch
    patch -d $@ -p1 < vtpm-command-duration.patch
+   patch -d $@ -p1 < vtpm-gcc12-fixes.patch
    patch -d $@ -p1 < vtpm-tpm_bn_t-addr.patch
    mkdir $@/build
    cd $@/build; CC=${CC} $(CMAKE) .. -DCMAKE_C_FLAGS:STRING="-std=c99 -DTPM_NO_EXTERN $(TARGET_CPPFLAGS) $(TARGET_CFLAGS) -Wno-declaration-after-statement"
    touch $@

Add line patch -d $@ -p1 < vtpm-tpm_bn_t-addr.patch right after + patch -d $@ -p1 < vtpm-gcc12-fixes.patch to match the contents of src/xen/stubdom/Makefile (the target file for the patch).

Refutationalist commented on 2023-07-11 22:05 (UTC)

Most recent change removes OCaml, as it was supposed to be doing that anyway. Building issues are gone.

lapuglisi commented on 2023-07-03 14:04 (UTC)

For those of you facing the issue below:

xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c:36:1: note: each undeclared identifier is reported only once for each function it appears in 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_progress’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c:140:9: note: in expansion of macro ‘CAMLdone’ 140 | CAMLdone; | ^~~~~~~~

One workaround is to add the option '--disable-ocamltools' to the './configure' command line in the 'build' function inside PKGBUILD.

Finebread commented on 2023-06-19 18:00 (UTC)

I experience a same problem like manueljben posted here. During installation I get the same error. I tried older Xen version and I got the same error. I tried to change caml_local_roots to caml_local_roots_ptr, didn't work out.

manueljben commented on 2023-06-13 17:11 (UTC) (edited on 2023-06-13 17:11 (UTC) by manueljben)

new problem arised to me today... :-(

xentoollog_stubs.c: In function ‘stub_xtl_ocaml_vmessage’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c:36:1: note: each undeclared identifier is reported only once for each function it appears in 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~
xentoollog_stubs.c:114:9: note: in expansion of macro ‘CAMLdone’ 114 | CAMLdone;
| ^~~~~~~~
xentoollog_stubs.c: In function ‘stub_xtl_ocaml_progress’: xentoollog_stubs.c:36:1: error: ‘caml_local_roots’ undeclared (first use in this function); did you mean ‘caml_local_roots_ptr’? 36 | caml_local_roots = caml__frame; \ | ^~~~~~~~~~~~~~~~ xentoollog_stubs.c:140:9: note: in expansion of macro ‘CAMLdone’ 140 | CAMLdone; | ^~~~~~~~

Refutationalist commented on 2023-05-15 03:12 (UTC)

personal update: It's going to be a bit before I can really look at these changes as I've had hand surgery and typing is not recommended at the moment. Feel free to keep submitting patches here or PRs at my github and I'll update the package itself as soon as I can.

Serus commented on 2023-05-06 16:30 (UTC)

I observed the code and it seems to be a false positive in GCC. I wrote a little patch that silences the warning:

From a033f9c535e41140a3138edbb0d6a89be0e80564 Mon Sep 17 00:00:00 2001
From: Xen Arch <user@xen-arch>
Date: Sat, 6 May 2023 17:58:47 +0200
Subject: [PATCH] Silence false positive use after free warning

---
 tools/libs/guest/xg_offline_page.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/libs/guest/xg_offline_page.c b/tools/libs/guest/xg_offline_page.c
index ccd0299f0f..96f197a801 100644
--- a/tools/libs/guest/xg_offline_page.c
+++ b/tools/libs/guest/xg_offline_page.c
@@ -182,9 +182,11 @@ static int backup_ptes(xen_pfn_t table_mfn, int offset,
     if (backup->max == backup->cur)
     {
         void *orig = backup->entries;
+       // silence false positive warning
+       void *orig2 = orig;

         backup->entries = realloc(
-            orig, backup->max * 2 * sizeof(struct pte_backup_entry));
+            orig2, backup->max * 2 * sizeof(struct pte_backup_entry));

         if (backup->entries == NULL)
         {
--
2.40.1

Simply save it as a .patch file, and drop it in the same folder as the PKGBUILD. Run sha512sum on it and put the patch file in the _patches list and the sha512 sum in the _patch_sums list.

Sven commented on 2023-05-06 11:56 (UTC)

xen fails to build with gcc 13.1.1 with -Werror=use-after-free error. Can we disable -Werror? New gcc versions typically bring new warnings. I respect the decision by the xen devs to treat them as errors. It keeps the code base clean. But it's not really convenient for us users.

Refutationalist commented on 2023-04-24 00:14 (UTC) (edited on 2023-04-24 00:14 (UTC) by Refutationalist)

in short:

  • the guidance comes from the documentation with XSAs and correspondence. example: https://xenbits.xen.org/xsa/advisory-429.html

  • though by following the stable branch a lot of these patches already get included

  • this pkgbuild has buildtime options, which obviates reproducable builds. at some future date those will be gone

  • yay compatibility is not a concern of mine at the moment, and it's in "considered harmful" territory for me regarding servers

  • you can see what my future plans are at my repo, but in short i do plan on doing most of what you're asking: https://github.com/refutationalist/saur

sorry for the terse response, typing is a bit diffucult for me at the moment

Sven commented on 2023-04-23 23:45 (UTC)

@Refutationalist Can you provide a link to upstream's requested best practices?

I have checked the stable-4.17 branch. The release of 4.17.0 was 4 months ago. Since then, the branch has been updated periodically. In result, everytime I build this package, I will end up with a different commit/version of xen. Please understand that this comes to me as a surprise. On Gentoo, authors typically offered some sort to of *-git package that would always give you the latest version from git. I'm not quite sure if such packages exist in AUR. But please indicate in the name of the package, that it's not building a release but always the latest from a certain branch.

At some point, the version reported by pkgver() was 4.17.0. Currently, it is 4.17.1pre. pkgver() has reported this string for a while now and it will continue to do so until upstream changes it to 4.17.1rc or 4.17.1 (release). So it's basically impossible to tell which xen-*.pkg.tar.zst is newer or older. This seems like a nightmare for us users to me. I would like to persuade you to include the date and (optionally) even the git commit hash in the output of pkgver().

If you had a binary repo, you could only push out updates to users if the version number actually changes (actually it needs to increase!). So what pkgver() currently does is insufficient for the purpose of your binary repo and it's also a hassle for us users who use the AUR.

The current PKGBUILD is also incompatible with package managers like yay. Yay will only pick up an update if the pkgver variable in PKGBUILD changes. The pkgver() function is ignored in this context.

Also, some users may prefer repeatable builds. With the current PKGBUILD, it's not trivial to repeat a previous build. It's quite a hassle to find the commit id of a previously built binary package and to patch the PKGBUILD to repeat that build.

Sorry for that much criticism. I appreciate your contribution. I currently rely on your work for my Arch-based dom0.

Refutationalist commented on 2023-04-23 22:26 (UTC)

@Sven: The package is built using upstream's requested best practices, particularly in regards to security. Since this way does not have the PKGBUILD strictly following point releases, it made sense to follow guidelines so we know what package we're building: https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_function

That said, my ability to do package maintenance is limited at the moment. It'll be a few weeks before I can do more work on the package, at which point I'm planning on implementing some build automation so I can have more rigorous testing and-- hopefully-- a binary repo.

Sven commented on 2023-04-23 21:49 (UTC)

Sorry for posting so many messages. Please don't simply fetch the stable-4.17 branch. Please fetch a release tag, such as RELEASE-4.17.0.

Found that makepkg automatically updates the pkgver variable in PKGBUILD, if the pkgver() function exists. I would under the impression that this was not a package always fetching the latest from git. I expected this package to fetch the specified version (4.17.0) from git.

Sven commented on 2023-04-23 21:41 (UTC)

Why does running makepkg on this package modify the PKGBUILD file? I'm alarmed. That shouldn't happen. To be more specific, it changes the pkgver inside PKGBUILD from 4.17.0 to 4.17.1pre. I'd really like to build xen 4.17.0.

Sven commented on 2023-04-23 21:30 (UTC)

It seems like man-db is a missing build dep. Without man-db being installed, makepkg fails with some file not found error.

ArthurBorsboom commented on 2022-12-19 20:31 (UTC)

The Xen package upgrade 4.16.3 > 4.17.0 worked without any issues. Thanks for the work.

ArthurBorsboom commented on 2022-11-15 10:46 (UTC)

Thanks for the nice work.

Do you think it is possible to make xen-docs a separate package as well and mark it as optional ? I dislike the 70+ haskell dependencies just for pandoc/xen-docs, which I do not use/need.

Refutationalist commented on 2022-11-15 02:32 (UTC)

@vibrion are you having the same problem with the new package? might be worth taking up with the xen-users mailing list.

Refutationalist commented on 2022-11-15 02:32 (UTC) (edited on 2022-11-16 00:13 (UTC) by Refutationalist)

Important: QEMU is now it's own package. See xen-qemu.

Here's my updated Xen, which now tracks git stable, as suggested by the Xen security team. For more information about the build, check my PKGBUILD git repo: https://github.com/refutationalist/saur

xen-pvhgrub, a method for booting kernels inside a PVH domain will be in AUR as soon as it lets me. I'm going to be looking into a package repo for now.

EDIT: xen-pvhgrub is now available in AUR.

vibrion commented on 2022-11-07 12:47 (UTC)

Hi I'm having two strange problems (unrelated?) with two different servers.On an old IBM3100 M4 server latest xen qemuless version is working fine but for some reason limits the memory to only 8Gb (it has 24Gb). Booting directly to kernel without xen, memory is properly detected. Passing mem=24G to xen.cfg doesnt reflect any change On the other hand on a Huawei server im stuck on kernel 5.19.11 cause trying to scale up this version it wont boot (errors trying to mount root). Again booting without xen it works fine (even with latest 6.xx version) Thanks in advance! Martin

ArthurBorsboom commented on 2022-11-03 19:37 (UTC)

Xen 4.16.2 has been officially released.

https://xenproject.org/downloads/xen-project-archives/xen-project-4-16-series/xen-project-4-16-2/

@Refutationalist, thanks for your efforts.

Refutationalist commented on 2022-11-01 22:24 (UTC)

@ArthurBorsboom I'm blocking on a rather sizeable patchset for {o,}xenstored at the moment, but once I get xen compiling again I'll look directly at that. Once I have those things tackled, I'll merge that branch in and update AUR officially.

Tracking updates to qemu is a bigger job than I expected and I'm going to have to implement some infrastructure and automation if I'm going to keep track. This will likely culminate in a publicly available repo.

ArthurBorsboom commented on 2022-10-19 10:03 (UTC)

"xen-qemuless-again/xen" builts and boots (although the Dom0 VM is not all the way stable, but I guess that is package unrelated).

"xen-qemuless-again/xen-qemu" does not built. The error is related to the libbpf. My system has libbpf v1.0.1.

/home/arthur/Downloads/saur-xen-qemuless-again/xen-qemu/src/build/../qemu-7.0.0/ebpf/ebpf_rss.c:52: undefined reference to `bpf_program__set_socket_filter'
collect2: error: ld returned 1 exit status
[2582/2620] Compiling C object tests/qtest/virtio-net-failover.p/virtio-net-failover.c.o
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

Refutationalist commented on 2022-10-19 02:20 (UTC)

My solution was to break qemu out of the package and build it to Xen spec from upstream. My work is in this branch: https://github.com/refutationalist/saur/tree/xen-qemuless-again

This tree also moves to the Xen repo rather than using tarballs as that's what the XSAs really want, but I'm not sure if I should pin to the branch or a specific commit or what. There's also a GRUB2 in that branch that will let you boot kernels inside a PVH domU.

When I merge this branch back in I'm probably going to start looking into setting up a repo with my builds on it. It would solve many issues in other projects, and might simplify things for a lot of folks here.

ArthurBorsboom commented on 2022-10-17 09:11 (UTC)

I have reported the Xen building issue upstream.

https://lists.xenproject.org/archives/html/xen-devel/2022-10/msg00816.html

If I understood it correct, two possible solutions are:

  • Update qemu in the Xen build
  • Use qemu of Arch Linux, which must have been build with Xen support.

Hopefully this is helpful in fixing the package.

ArthurBorsboom commented on 2022-10-13 12:31 (UTC) (edited on 2022-10-17 07:47 (UTC) by ArthurBorsboom)

Xen doesn't build anymore. I believe it is caused by the missing function 'bpf_program__set_socket_filter' of libbpf. Before this function was deprecated and now it has been removed (v1.0.1).

A downgrade to libbpf v0.8.1 fixes the Xen build problem. I recall vaguely that the downgrade of libbpg lead to qemu issues.

/bin/ld: libcommon.fa.p/ebpf_ebpf_rss.c.o: in function `ebpf_rss_load':
/home/arthur/.cache/yay/xen/src/xen-4.16.1/tools/qemu-xen-build/../qemu-xen/ebpf/ebpf_rss.c:52: undefined reference to `bpf_program__set_socket_filter'
collect2: error: ld returned 1 exit status
...
...
...
ninja: build stopped: subcommand failed.
make: *** [Makefile:156: run-ninja] Error 1
make: Leaving directory '/home/arthur/.cache/yay/xen/src/xen-4.16.1/tools/qemu-xen-build'
make[3]: *** [Makefile:212: subdir-all-qemu-xen-dir] Error 2
make[3]: Leaving directory '/home/arthur/.cache/yay/xen/src/xen-4.16.1/tools'
make[2]: *** [/home/arthur/.cache/yay/xen/src/xen-4.16.1/tools/../tools/Rules.mk:161: subdirs-install] Error 2
make[2]: Leaving directory '/home/arthur/.cache/yay/xen/src/xen-4.16.1/tools'
make[1]: *** [Makefile:66: install] Error 2
make[1]: Leaving directory '/home/arthur/.cache/yay/xen/src/xen-4.16.1/tools'
make: *** [Makefile:140: install-tools] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: xen

ArthurBorsboom commented on 2022-10-09 19:56 (UTC)

I am not 100% sure, but Xen 4.16.2 might have been released, just not explicitly through the web interface.

https://downloads.xenproject.org/release/xen/4.16.2/

Also, while debugging a compilation problem, it seems that the newer version of dependency libbpf (1.0 vs 0.8) does not play nice with Xen 4.16.x

Refutationalist commented on 2022-08-28 09:26 (UTC) (edited on 2022-08-28 12:02 (UTC) by Refutationalist)

Xen 4.16.2 should be out soon, but I'm changing some of the ways this package compiles. First, the XSA patches always suggest that they be applied not to the tarball but to stable branch. I'd been meaning to do it for a while, but the retbleed patchset was the final nail in the tarball coffin.

There is a problem, however. Xen's builtin QEMU doesn't build properly at the moment, which is precisely the problem earlier packagers had to contend with. We really should see about separating that out, since it's a build-within-a-build.

So with that, plus a couple other issues-- how to version this and whether or not I should pin the PKGBUILD to a specific commit-- you can check out what I'm working on in my PKGBUILD repo: https://github.com/refutationalist/saur

EDIT: in a branch on that repo, I've removed QEMU building from the xen package entirely, and now have a xen-qemu package that builds QEMU fairly closely to how Xen itself builds it, so it shouldn't conflict with an existing QEMU installation. I'm thinking this may be the way to go for now, just in case there's some future push to get Xen into the repos and therefore use Arch's included qemu.

ska67 commented on 2022-08-14 14:02 (UTC)

@Refutationalist During package creation, Qemu configuration detects needed options, two additional files can be created: /usr/lib/xen/bin/qemu-keymap /usr/lib/xen/libexec/vhost-user-gpu

These two files should also be removed when assembling the xen package, but only if they are present.

Refutationalist commented on 2022-07-26 09:30 (UTC)

@straybit & @FringeLunatic

I've been working on this on and off. Can either of you try building Xen in a clean chroot to see if you get the same conflict? My packages don't create a qemu-keymap at all, and I do not build my packages on my workstation.

straybit commented on 2022-07-08 14:40 (UTC) (edited on 2022-07-08 14:40 (UTC) by straybit)

Like ArthurBorsboom and FringeLunatic I also get a conflicting file error:

Packages (3) xen-4.16.1-1  xen-docs-4.16.1-1  xen-qemu-builtin-4.16.1-1
...
error: failed to commit transaction (conflicting files)
/usr/lib/xen/bin/qemu-keymap exists in both 'xen' and 'xen-qemu-builtin'
Errors occurred, no packages were upgraded.
==> WARNING: Failed to install built package(s).

FringeLunatic commented on 2022-07-03 01:34 (UTC) (edited on 2022-07-03 14:00 (UTC) by FringeLunatic)

Like ArthurBorsboom, I get a conflicting file error:

error: failed to commit transaction (conflicting files)
/usr/lib/xen/bin/qemu-keymap exists in both 'xen' and 'xen-qemu-builtin'
Errors occurred, no packages were upgraded.
==> WARNING: Failed to install built package(s).
==> Cleaning up...

Any way to fix this conflict without removing "qemu-keymap?" I believe this is a bug because both "xen" and "xen-qemu-builtin" own "qemu-keymap." I don't want to report it as such if there's something obvious I'm missing but I've found nothing about it until a user reported it here.

Refutationalist commented on 2022-07-02 19:39 (UTC)

@Shapito You need to add the PGP key to your keyring to verify the signature, and patch is part of base-devel, which is always assumed.

Shapito commented on 2022-07-02 09:48 (UTC)

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.

ArthurBorsboom commented on 2022-06-12 08:04 (UTC) (edited on 2022-06-12 08:05 (UTC) by ArthurBorsboom)

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

vibrion commented on 2022-05-31 14:43 (UTC) (edited on 2022-05-31 14:48 (UTC) by vibrion)

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!!

Refutationalist commented on 2022-05-16 19:07 (UTC) (edited on 2022-05-18 22:19 (UTC) by Refutationalist)

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.

Refutationalist commented on 2022-05-13 08:32 (UTC)

@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.

Sven commented on 2022-05-12 21:45 (UTC)

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

Refutationalist commented on 2022-04-20 21:59 (UTC)

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

ArthurBorsboom commented on 2022-04-14 07:05 (UTC)

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

ska67 commented on 2022-04-13 22:22 (UTC)

@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.

ArthurBorsboom commented on 2022-04-13 13:00 (UTC)

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?

ska67 commented on 2022-02-19 12:36 (UTC)

@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.

milenus commented on 2022-02-18 09:33 (UTC)

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.

Refutationalist commented on 2022-02-17 22:55 (UTC)

@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.

milenus commented on 2022-02-17 12:22 (UTC)

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?

Refutationalist commented on 2022-02-15 18:49 (UTC)

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

Sven commented on 2022-02-13 09:44 (UTC)

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

Refutationalist commented on 2022-02-06 14:16 (UTC)

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.

ska67 commented on 2022-01-30 16:58 (UTC)

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 :)

Sven commented on 2022-01-03 00:01 (UTC)

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.

ska67 commented on 2022-01-02 14:19 (UTC) (edited on 2022-01-02 14:21 (UTC) by ska67)

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.

Refutationalist commented on 2021-12-28 17:47 (UTC) (edited on 2021-12-28 17:47 (UTC) by Refutationalist)

@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.

ska67 commented on 2021-12-28 16:20 (UTC)

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?

Refutationalist commented on 2021-12-26 19:29 (UTC) (edited on 2021-12-26 19:32 (UTC) by Refutationalist)

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.

ArthurBorsboom commented on 2021-10-24 09:33 (UTC)

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().

micwoj92 commented on 2021-10-13 19:02 (UTC)

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.

ska67 commented on 2021-09-29 22:20 (UTC)

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.

Refutationalist commented on 2021-09-28 23:27 (UTC) (edited on 2021-09-28 23:28 (UTC) by Refutationalist)

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.

Refutationalist commented on 2021-08-28 07:28 (UTC) (edited on 2021-08-28 07:29 (UTC) by Refutationalist)

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!

Sven commented on 2021-08-09 19:10 (UTC) (edited on 2021-08-14 22:14 (UTC) by Sven)

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.

mxca commented on 2021-05-27 14:32 (UTC) (edited on 2021-05-27 21:42 (UTC) by mxca)

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.

ArthurBorsboom commented on 2021-04-15 10:03 (UTC)

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

Refutationalist commented on 2021-04-15 09:56 (UTC)

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.

vibrion commented on 2021-04-13 22:01 (UTC)

@juceda must set at top of PKGBUILD

Build Options

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

tec14 commented on 2021-03-25 17:16 (UTC) (edited on 2021-03-25 17:28 (UTC) by tec14)

@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

juceda commented on 2021-02-20 21:48 (UTC)

@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.

Guard commented on 2021-02-11 05:11 (UTC) (edited on 2021-02-11 05:12 (UTC) by Guard)

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

Guard commented on 2021-02-11 00:11 (UTC) (edited on 2021-02-11 03:15 (UTC) by Guard)

"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.

ska67 commented on 2021-02-07 14:58 (UTC)

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 :)

Refutationalist commented on 2021-02-03 19:23 (UTC)

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.

ilstam commented on 2021-01-31 23:18 (UTC)

just a nitpick: in optdepends edk2-ovmf is misspelled

ArthurBorsboom commented on 2021-01-31 11:36 (UTC)

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]?

alaricljs commented on 2021-01-27 20:12 (UTC) (edited on 2021-01-27 20:15 (UTC) by alaricljs)

@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

ArthurBorsboom commented on 2021-01-17 13:04 (UTC)

@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

Refutationalist commented on 2021-01-12 21:05 (UTC)

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.

Refutationalist commented on 2020-12-22 11:29 (UTC) (edited on 2020-12-22 11:29 (UTC) by Refutationalist)

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.

Refutationalist commented on 2020-11-24 18:20 (UTC)

@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.

alaricljs commented on 2020-11-22 22:46 (UTC)

@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.

ska67 commented on 2020-11-22 14:47 (UTC)

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.

Refutationalist commented on 2020-11-21 21:23 (UTC) (edited on 2020-11-21 21:24 (UTC) by Refutationalist)

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.

Refutationalist commented on 2020-11-11 00:40 (UTC)

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

eduncan911 commented on 2020-11-09 16:28 (UTC)

@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.

alaricljs commented on 2020-11-09 16:11 (UTC)

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).

kapcom01 commented on 2020-11-06 09:04 (UTC)

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.

manueljben commented on 2020-10-26 15:07 (UTC) (edited on 2020-10-26 15:09 (UTC) by manueljben)

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.. ¬_¬

g8sqh commented on 2020-10-23 11:00 (UTC)

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

ccook13 commented on 2020-09-29 17:28 (UTC)

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

eduncan911 commented on 2020-09-27 23:24 (UTC)

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.

ccook13 commented on 2020-09-27 18:27 (UTC)

@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.

ccook13 commented on 2020-09-27 06:53 (UTC)

@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.

ccook13 commented on 2020-09-27 06:01 (UTC)

@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.

skyzh commented on 2020-09-27 02:45 (UTC)

@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.

Refutationalist commented on 2020-09-27 02:42 (UTC)

@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.

Refutationalist commented on 2020-09-14 04:52 (UTC)

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.

skyzh commented on 2020-09-14 04:49 (UTC)

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.

ska67 commented on 2020-09-12 10:51 (UTC)

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.