| Git Clone URL: | https://aur.archlinux.org/xen.git (read-only, click to copy) |
|---|---|
| Package Base: | xen |
| Description: | Xen hypervisor documentation and man pages |
| Upstream URL: | https://xenproject.org/ |
| Keywords: | hypervisor virtualization xen |
| Licenses: | GPL2 |
| Submitter: | sergej |
| Maintainer: | Refutationalist |
| Last Packager: | Refutationalist |
| Votes: | 185 |
| Popularity: | 0.46 |
| First Submitted: | 2009-11-09 11:22 (UTC) |
| Last Updated: | 2024-09-20 00:31 (UTC) |
@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:
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
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!
Pinned Comments
Refutationalist commented on 2024-12-06 01:37 (UTC)
Please Note: Per best-practices by upstream this package follows the git stable branch. Minor releases do not require a version bump and the PKGBUILD will provide the appropriate version number.
stubdom is still broken.