Package Details: xen-stubdom 4.20.0-2

Git Clone URL: https://aur.archlinux.org/xen.git (read-only, click to copy)
Package Base: xen
Description: Xen hypervisor stubdom files
Upstream URL: https://xenproject.org/
Keywords: hypervisor virtualization xen
Licenses: GPL2
Submitter: sergej
Maintainer: Refutationalist
Last Packager: Refutationalist
Votes: 184
Popularity: 0.072649
First Submitted: 2009-11-09 11:22 (UTC)
Last Updated: 2025-03-13 08:19 (UTC)

Required by (3)

Sources (13)

Pinned Comments

Refutationalist commented on 2025-03-12 12:06 (UTC) (edited on 2025-03-13 08:23 (UTC) by Refutationalist)

We've moved to the newly-stable 4.20.0 branch. There are also other changes:

  • stubdom is fixed by disabling the vtmp and vtpmmgr components. This gets rid of a few source files and our remaining patches.
  • Debug files are only removed if the debug option is not set in makepkg.cfg (or the PKGBUILD itself)
  • pygrub has been removed
  • optdepends are adjusted for the upcoming xen-grub split package for the various Xen flavored builds.

If you're still using pygrub note that it is deprecated. The solution is to build PV grub instead, which used to be in AUR but is now missing. I am asking a couple questions on the mailing list, and I intend to put my current build of xen-grub (which supersedes xen-pvhgrub) on AUR as soon as possible. If you need to build it before that occurs, you can find it in my PKGBUILD repo.

EDIT: 4.20.0-2 adds support for the xen-edk2 package, which has a fixed UEFI for xen

Latest Comments

« First ‹ Previous 1 .. 88 89 90 91 92 93 94 95 96 97 98 .. 101 Next › Last »

Citral commented on 2012-03-10 13:54 (UTC)

Try creating guest with xl instead of xm.

<deleted-account> commented on 2012-02-22 02:21 (UTC)

Any one got it up and running? I get "Error: Device 0 (vif) could not be connected. Hotplug scripts not working.". Is it possible to Fix it without downgrade udev, mkinitcpio etc.? I compiled the patches given by aaronfitz to the source (thanks man), but now i'm stuck..

<deleted-account> commented on 2012-02-09 14:33 (UTC)

Hello, Can you please provide a link to the patch in plain text format? Pastebin, sprunge.us, something similar. Thanks.

miffe commented on 2012-01-30 23:42 (UTC)

Thanks aaronfitz, I hade exactly that problem and your fix worked!

aaronfitz commented on 2012-01-28 06:09 (UTC)

@miffe: This may interest you. Not sure if you've run into this issue or not. I was having issues creating a HVM under the x86_64 dom0 I started with. After some digging, it was due to some improper behavior in Xen 4.1 which is patched in xen-unstable. xm list would show dom0, but xm create would cause xend to crash, causing the xm create to fail saying the connection was refused to xend. After this, xm list would show a Domain-Unnamed which was useless. The revisions which fix this issue in xen-unstable are 24341, 24344, and 24345. At first I struggled to get xen-unstable to compile correctly, but was unsuccessful because of an incompatible libyajl. I modified this PKGBUILD to apply those 3 patches and rebooted (losing my reference where I found the revision numbers in the process) and now xend is no longer crashing! Windows just finished installing in my new HVM and is now booted up to its brand new desktop. @revellion: Are you still active? If so, would you consider adding this to a revision of this package? If not, I'll wait a couple days and see if I can figure out how to push it up myself. [aaron@myhost 41newpatch]$ diff -au ../orig41/ . Only in .: 24341.patch Only in .: 24344.patch Only in .: 24345.patch diff -au ../orig41/PKGBUILD ./PKGBUILD --- ../orig41/PKGBUILD 2011-10-22 10:26:27.000000000 -0500 +++ ./PKGBUILD 2012-01-28 00:04:43.252295563 -0600 @@ -2,7 +2,7 @@ #Contributor WaxyMouthfeel pkgname=xen pkgver=4.1.2 -pkgrel=1 +pkgrel=2 pkgdesc="Xen 4 (hypervisor and tools)" arch=(i686 x86_64) url="http://xen.org/" @@ -20,7 +20,10 @@ 09_xen xen.patch archinit.patch - dom0_xz_decompression.patch) + dom0_xz_decompression.patch + 24341.patch + 24344.patch + 24345.patch) build() { @@ -30,6 +33,9 @@ patch -p1 -i ../xen.patch patch -p1 -i ../archinit.patch patch -p1 -i ../dom0_xz_decompression.patch + patch -p1 -i ../24341.patch + patch -p1 -i ../24344.patch + patch -p1 -i ../24345.patch unset CFLAGS LDFLAGS @@ -86,4 +92,7 @@ '1eb1de5675e4499018a37c3a5de973fe' 'f149bae1a6b420e49c51b9f3a74338a4' '7a1ed81ecc828037724bb3280058c9fc' - '4aebccf16b578ed97aa8bab945011f35') + '4aebccf16b578ed97aa8bab945011f35' + 'b561220323e84359d98cd51ba8063aad' + '3a3a9ba7324ce52b13f1e450c9ed2585' + '95a220076aec53764ca71aacb02f856d') [aaron@myhost 41newpatch]$ cat 24341.patch diff -r 3f815406feb2 -r 60d4e257d04b xen/arch/x86/x86_64/mmconfig_64.c --- a/xen/arch/x86/x86_64/mmconfig_64.c Mon Nov 28 13:37:17 2011 +0100 +++ b/xen/arch/x86/x86_64/mmconfig_64.c Fri Dec 02 09:05:26 2011 +0100 @@ -23,7 +23,7 @@ char __iomem *virt; }; static struct mmcfg_virt *pci_mmcfg_virt; -static int __initdata mmcfg_pci_segment_shift; +static unsigned int mmcfg_pci_segment_shift; static char __iomem *get_virt(unsigned int seg, unsigned bus) { [aaron@myhost 41newpatch]$ cat 24344.patch diff -r 109b99239b21 -r 72f4e4cb7440 tools/libxc/xc_cpuid_x86.c --- a/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:07:52 2011 -0800 +++ b/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:31:14 2011 -0800 @@ -43,23 +43,23 @@ static void cpuid(const unsigned int *input, unsigned int *regs) { unsigned int count = (input[1] == XEN_CPUID_INPUT_UNUSED) ? 0 : input[1]; +#ifdef __i386__ + /* Use the stack to avoid reg constraint failures with some gcc flags */ asm ( -#ifdef __i386__ "push %%ebx; push %%edx\n\t" -#else - "push %%rbx; push %%rdx\n\t" -#endif "cpuid\n\t" "mov %%ebx,4(%4)\n\t" "mov %%edx,12(%4)\n\t" -#ifdef __i386__ "pop %%edx; pop %%ebx\n\t" + : "=a" (regs[0]), "=c" (regs[2]) + : "0" (input[0]), "1" (count), "S" (_regs) + : "memory" ); #else - "pop %%rdx; pop %%rbx\n\t" + asm ( + "cpuid" + : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3]) + : "0" (input[0]), "2" (count) ); #endif - : "=a" (regs[0]), "=c" (regs[2]) - : "0" (input[0]), "1" (count), "S" (regs) - : "memory" ); } /* Get the manufacturer brand name of the host processor. */ diff -r 109b99239b21 -r 72f4e4cb7440 tools/misc/xen-detect.c --- a/tools/misc/xen-detect.c Fri Dec 02 06:07:52 2011 -0800 +++ b/tools/misc/xen-detect.c Fri Dec 02 06:31:14 2011 -0800 @@ -35,18 +35,21 @@ static void cpuid(uint32_t idx, uint32_t *regs, int pv_context) { +#ifdef __i386__ + /* Use the stack to avoid reg constraint failures with some gcc flags */ asm volatile ( -#ifdef __i386__ -#define R(x) "%%e"#x"x" -#else -#define R(x) "%%r"#x"x" -#endif - "push "R(a)"; push "R(b)"; push "R(c)"; push "R(d)"\n\t" + "push %%eax; push %%ebx; push %%ecx; push %%edx\n\t" "test %1,%1 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t" "mov %%eax,(%2); mov %%ebx,4(%2)\n\t" "mov %%ecx,8(%2); mov %%edx,12(%2)\n\t" - "pop "R(d)"; pop "R(c)"; pop "R(b)"; pop "R(a)"\n\t" + "pop %%edx; pop %%ecx; pop %%ebx; pop %%eax\n\t" : : "a" (idx), "c" (pv_context), "S" (regs) : "memory" ); +#else + asm volatile ( + "test %5,%5 ; jz 1f ; ud2a ; .ascii \"xen\" ; 1: cpuid\n\t" + : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3]) + : "0" (idx), "1" (pv_context), "2" (0) ); +#endif } static int check_for_xen(int pv_context) [aaron@myhost 41newpatch]$ cat 24345.patch diff -r 72f4e4cb7440 -r 491c3ebf1d37 tools/libxc/xc_cpuid_x86.c --- a/tools/libxc/xc_cpuid_x86.c Fri Dec 02 06:31:14 2011 -0800 +++ b/tools/libxc/xc_cpuid_x86.c Fri Dec 02 08:40:02 2011 -0800 @@ -52,7 +52,7 @@ "mov %%edx,12(%4)\n\t" "pop %%edx; pop %%ebx\n\t" : "=a" (regs[0]), "=c" (regs[2]) - : "0" (input[0]), "1" (count), "S" (_regs) + : "0" (input[0]), "1" (count), "S" (regs) : "memory" ); #else asm (

aaronfitz commented on 2012-01-28 00:57 (UTC)

@miffe: Thanks, that worked. For the interested, I did some digging on why--it's a bug with libc attempting to use AVX instructions which are not valid unless XSAVE is enabled. Arch has a fix in glibc-2.15-4 in [testing]: https://bugs.archlinux.org/task/27828

miffe commented on 2012-01-27 10:54 (UTC)

@aaronfitz: I figured it out, you need to add xsave=1 to the xen commandline.

aaronfitz commented on 2012-01-27 05:14 (UTC)

I'm getting the exact same error as miffe. New to Xen so I'm sure I just missed something along the way...

tritron commented on 2012-01-22 06:11 (UTC)

Well it looks like xl is looking in wrong place for xenstored.pid libxl: error: libxl.c:56:libxl_ctx_init Is xenstore daemon running? failed to stat /var/run/xenstored.pid: No such file or directory src/xen-4.1.2/tools/libxl/libxl_internal.h needs to be patched /var/run/xenstored.pid needs to be changed to /run/daemons/xenstored.pid