Package Details: xen 4.19.1pre-1

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Open-source type-1 or baremetal hypervisor
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.63
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2024-09-20 00:31 (UTC)

Dependencies (63)

Sources (7)

Pinned Comments

Refutationalist commented on 2024-05-22 22:08 (UTC) (edited on 2024-05-23 00:07 (UTC) by Refutationalist)

As of now (2024-22-05) Xen with stubdom doesn't build because of a problem in the imported code. Been this way for about two weeks. Anyone else seeing this behavior?

Also, there is a lot of work happening on Xen in my development repo, thanks to @Serus. Check it out at: https://github.com/refutationalist/saur

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 101 Next › Last »

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.

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 .. 101 Next › Last »