Package Base Details: xen

Git Clone URL: (read-only, click to copy)
Keywords: hypervisor virtualization xen
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 185
Popularity: 0.156360
First Submitted: 2009-11-09 11:22
Last Updated: 2021-09-28 23:24

Packages (2)

Pinned Comments

Refutationalist commented on 2021-09-28 23:27

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.

Latest Comments

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

linuxninja commented on 2020-07-29 06:44

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.

linuxninja commented on 2020-07-29 03:08

source =

Needs to be changed to

source =

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.

alaricljs commented on 2020-07-21 21:14

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.

alaricljs commented on 2020-07-21 16:43

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.

Refutationalist commented on 2020-07-20 18:55

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.

Refutationalist commented on 2020-07-20 18:49

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.

Refutationalist commented on 2020-07-10 05:16


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.

eduncan911 commented on 2020-07-01 10:57

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

JohnTh commented on 2020-06-30 22:46

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

Do we need?: - qemut (--disable-qemu-traditional);a=blob;f=configure;hb=staging - stubdom (--disable-stubdom);a=blob;f=configure;hb=staging - ipxe (only used with qemut rombios / with-system-ipxe exists, but only aur ipxe package);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:

My minimal Xen staging tee build seems to be compiling fine without any extra patches, but it is way too messy to use:

Thanks FFY00 and Ref.

Refutationalist commented on 2020-06-30 21:07

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.