Re: [Xen-devel] FAILED/MISSING cstate/cpufreq/cpupower support with Xen 4.13 + kernel 5.4.14; withOUT xen/hypervisor, WORKS. bug or config?
with xen cmd line opts reduced to options=dom0_max_vcpus=4 dom0_mem=4016M,max:4096M loglvl=all guest_loglvl=all noreboot=false sync_console=true sched_debug iommu=verbose apic_verbosity=verbose still no freq data/control and, xl dmesg (XEN) 92118000 - 9213c000 (usable) (XEN) 9213c000 - 921e (reserved) (XEN) 921e - 921ea000 (usable) (XEN) 921ea000 - 92438000 (reserved) (XEN) 92438000 - 9243a000 (usable) (XEN) 9243a000 - 9243f000 (reserved) (XEN) 9243f000 - 92441000 (usable) (XEN) 92441000 - 92448000 (reserved) (XEN) 92448000 - 9244a000 (usable) (XEN) 9244a000 - 92451000 (reserved) (XEN) 92451000 - 92454000 (usable) (XEN) 92454000 - 92467000 (reserved) (XEN) 92467000 - 9246a000 (usable) (XEN) 9246a000 - 92565000 (reserved) (XEN) 92565000 - 92568000 (usable) (XEN) 92568000 - 926a8000 (reserved) (XEN) 926a8000 - 926ab000 (usable) (XEN) 926ab000 - 926e7000 (reserved) (XEN) 926e7000 - 926e9000 (usable) (XEN) 926e9000 - 926ee000 (reserved) (XEN) 926ee000 - 926ef000 (usable) (XEN) 926ef000 - 9e024000 (reserved) (XEN) 9e024000 - 9e2ba000 (usable) (XEN) 9e2ba000 - 9e6c9000 (reserved) (XEN) 9e6c9000 - 9e716000 (usable) (XEN) 9e716000 - 9e849000 (ACPI NVS) (XEN) 9e849000 - 9f00 (reserved) (XEN) f000 - f800 (reserved) (XEN) fec0 - fec01000 (reserved) (XEN) fed0 - fed04000 (reserved) (XEN) fed1c000 - fed2 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) ff00 - 0001 (reserved) (XEN) 0001 - 00085e00 (usable) (XEN) ACPI: XSDT 9E81A088, 008C (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: FACP 9E8282D0, 010C (r5 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: DSDT 9E81A1A8, E121 (r2 SUPERM SMCI--MB0 INTL 20120711) (XEN) ACPI: FACS 9E848F80, 0040 (XEN) ACPI: APIC 9E8283E0, 0072 (r3 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: FPDT 9E828458, 0044 (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: FIDT 9E8284A0, 009C (r1 SUPERM SMCI--MB 1072009 AMI 10013) (XEN) ACPI: SSDT 9E828540, 0C7D (r2 Ther_R Ther_Rvp 1000 INTL 20120711) (XEN) ACPI: SSDT 9E8291C0, 0539 (r2 PmRef Cpu0Ist 3000 INTL 20051117) (XEN) ACPI: SSDT 9E829700, 0B74 (r2 CpuRef CpuSsdt 3000 INTL 20051117) (XEN) ACPI: MCFG 9E82A278, 003C (r1 SUPERM SMCI--MB 1072009 MSFT 97) (XEN) ACPI: HPET 9E82A2B8, 0038 (r1 SUPERM SMCI--MB 1072009 AMI. 5) (XEN) ACPI: SSDT 9E82A688, 57F6 (r2 SaSsdt SaSsdt 3000 INTL 20120711) (XEN) ACPI: ASF! 9E82FE80, 00A5 (r32 INTEL HCG1 TFSM F4240) (XEN) ACPI: DMAR 9E82FF28, 0080 (r1 INTEL BDW 1 INTL 1) (XEN) System RAM: 32493MB (33273104kB) (XEN) No NUMA configuration found (XEN) Faking a node at -00085e00 (XEN) Domain heap initialised (XEN) vesafb: framebuffer at 0xd100, mapped to 0x82c000201000, using 1920k, total 1920k (XEN) vesafb: mode is 800x600x32, linelength=3200, font 8x8 (XEN) vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0 (XEN) CPU Vendor: Intel, Family 6 (0x6), Model 60 (0x3c), Stepping 3 (raw 000306c3) (XEN) SMBIOS 2.7 present. (XEN) DMI 2.7 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x1808 (32 bits) (XEN) ACPI: v5 SLEEP INFO: control[0:0], status[0:0] (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1804,1:0], pm1x_evt[1:1800,1:0] (XEN) ACPI: 32/64X FACS address mismatch in FADT - 9e848f80/, using 32 (XEN) ACPI: wakeup_vec[9e848f8c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x04] enabled) (XEN) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x06] enabled) (XEN) ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x08] address[0xfec0] gsi_base[0])
[Xen-devel] FAILED/MISSING cstate/cpufreq/cpupower support with Xen 4.13 + kernel 5.4.14; withOUT xen/hypervisor, WORKS. bug or config?
( posted this already to xen-users, and @ distro list; advised to bring it here ) I'm running linux kernel lsb_release -rd Description:openSUSE Leap 15.1 Release:15.1 uname -rm 5.4.14-25.g170524c-default x86_64 dmesg | grep DMI: [0.00] DMI: Supermicro X10SAT/X10SAT, BIOS 3.0 05/26/2015 cat /proc/cpuinfo | grep "model name" | head -n 1 model name : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz BIOS *is* setup for max cstate support. Xeon E3-1220 does support intel_pstate driver. WITH Xen/hypervisor, I've *NO* cpufreq/scaling support. withOUT Xen/hypervisor, works as expected. Testing first, (1) boot, NO XEN pstate driver's init'd dmesg | egrep -i "intel_pstate" [6.132964] intel_pstate: Intel P-state driver initializing pstate/cstate info cat /sys/module/intel_idle/parameters/max_cstate 9 cd /sys/devices/system/cpu/cpu0/cpuidle for state in state{0..9} do echo c-$state `cat $state/name` `cat $state/latency` done c-state0 POLL 0 c-state1 C1 2 c-state2 C1E 10 c-state3 C3 33 c-state4 C6 133 c-state5 C7s 166 cat: state6/name: No such file or directory cat: state6/latency: No such file or directory c-state6 cat: state7/name: No such file or directory cat: state7/latency: No such file or directory c-state7 cat: state8/name: No such file or directory cat: state8/latency: No such file or directory c-state8 cat: state9/name: No such file or directory cat: state9/latency: No such file or directory c-state9 cpufreq scaling info's available, cpupower frequency-info analyzing CPU 0: driver: intel_pstate CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: Cannot determine or is not supported. hardware limits: 800 MHz - 3.50 GHz available cpufreq governors: performance powersave current policy: frequency should be within 800 MHz and 3.50 GHz. The governor "powersave" may decide which speed to use within this range. current CPU frequency: Unable to call hardware current CPU frequency: 799 MHz (asserted by call to kernel) boost state support: Supported: yes Active: yes & scaling IS in effect, cat /proc/cpuinfo | grep MHz cpu MHz : 798.106 cpu MHz : 798.129 cpu MHz : 798.964 cpu MHz : 798.154 (2) boot, WITH Xen 4.13 rpm -qa | grep -i xen | sort grub2-x86_64-xen-2.04-lp151.6.5.noarch xen-4.13.0_04-lp151.688.2.x86_64 xen-libs-4.13.0_04-lp151.688.2.x86_64 xen-tools-4.13.0_04-lp151.688.2.x86_64 Xen cmd line includes, grep options= /boot/grub2/xen-4.13.0_04-lp151.688.cfg [config.1] options=dom0=pvh dom0-iommu=map-reserved dom0_mem=4016M,max:4096M dom0_max_vcpus=4 cpufreq=xen cpuidle ucode=scan ... cstate info IS available xenpm start 5 Timeout set to 5 seconds Start sampling, waiting for CTRL-C or SIGINT or SIGALARM signal ... Elapsed time (ms): 5000 CPU0: Residency(ms) Avg Res(ms) C019 ( 0.40%)0.03 C10 ( 0.00%)0.00 C20 ( 0.00%)0.00 C31 ( 0.02%)0.22 C41 ( 0.02%)0.59 C54978(99.56%)8.07 Avg freq -302378336 KHz CPU1: Residency(ms) Avg Res(ms) C03 ( 0.08%)0.03 C10 ( 0.00%)0.00 C20 ( 0.00%)0.00 C30 ( 0.00%)0.00 C40 ( 0.00%)0.00 C54996(99.92%)35.94 Avg freq -302378336 KHz CPU2: Residency(ms) Avg Res(ms) C05000(100.00%) 5000.27 C10 ( 0.00%)0.00 C20 ( 0.00%)0.00
Re: [Xen-devel] xen 4.13 + kernel 5.4.11 'APIC Error ... FATAL PAGE FAULT' on reboot? non-Xen reboot's ok.
On 1/15/20 9:21 AM, Andrew Cooper wrote: > That is the command line for dom0 which is a VM. You need the Xen > hypervisor command line. thx. done. > You'll need to edit xen-4.13.0_04-lp151.688.cfg which will be somewhere > on the ESP (wherever that is mounted in an openSUSE system). verifying, cat /boot/efi/EFI/opensuse/xen-4.13.0_04-lp151.688.cfg [global] [config.1] options=dom0=pvh ... reboot=a kernel=... now, on restart, ... [ OK ] Reached target Shutdown. [ 137.682171] watchdog: watchdog0: watchdog did not stop! [ 139.373683] watchdog: watchdog0: watchdog did not stop! dracut Warning: Killing all remaining processes mdadm: stopped /dev/md4 mdadm: stopped /dev/md3 mdadm: stopped /dev/md2 mdadm: stopped /dev/md1 mdadm: stopped /dev/md0 Rebooting. [ 144.908520] reboot: Restarting system (XEN) [2020-01-15 17:38:25] Hardware Dom0 shutdown: rebooting machine (XEN) [2020-01-15 17:38:25] APIC error on CPU0: 40(00) (XEN) [2020-01-15 17:38:25] Resetting with ACPI MEMORY or I/O RESET_REG. and reboot proceeds ... the error's still there, but without the trace/noise ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] xen 4.13 + kernel 5.4.11 'APIC Error ... FATAL PAGE FAULT' on reboot? non-Xen reboot's ok.
hi On 1/15/20 9:10 AM, Andrew Cooper wrote: >> Is this a known/fixable issue? > > The APIC errors aren't fatal. They need looking into and addressing in > due course. > > The real crash is EFI firmware falling over a NULL pointer which is > wildly known issue. Fixing it requires following the Linux approach > which is to not use EFI reboot unless absolutely necessary. > > You can work around it with reboot=a on the command line, but actually > fixing this in Xen is probably never going to happen because I've lost > interest in trying to arguing that default behaviour like the above is a > bad thing which we should code around. currently, here, cat /proc/cmdline root=/dev/mapper/VG0-ROOT softlevel=xen rd.shell mds=full l1tf=flush rd.debug=0 rd.udev.log_priority=debug rd.auto=1 dolvm lvmwait=/dev/mapper/VG0-ROOT root=/dev/mapper/VG0-ROOT rootfstype=ext4 rootflags=journal_checksum noresume nomodeset nouveau.modeset=1 video=vesa:off video=efifb:1024x768 xencons=xvc console=tty0 console=hvc0 pcie_aspm=off mce=off fsck.mode=skip fsck.repair=preen reboot=acpi clocksource=xen intel_iommu=on apparmor=0 plymouth.enable=0 scsi_mod.use_blk_mq=1 elevator=mq-deadline cpuidle cpufreq=xen:ondemand net.ifnames=1 biosdevname=0 showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=info systemd.log_target=kmsg earlyprintk=xen,keep audit=0 note the reboot=acpi already there. something else I'm missing, perhaps? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] xen 4.13 + kernel 5.4.11 'APIC Error ... FATAL PAGE FAULT' on reboot? non-Xen reboot's ok.
dev @distro suggested I post this here ... I've a recently upgraded Xen & Kernel on lsb_release -rd Description:openSUSE Leap 15.1 Release:15.1 Atm, I'm running Xen 4.13.0_04 server, on EFI hardware + Intel Xeon E3 CPU, with kernel 5.4.11-24.g2d02eb4-default It boots as always, with no issue Welcome to GRUB! Please press t to show the boot menu on this console Xen 4.13.0_04-lp151.688 (c/s ) EFI loader Using configuration file 'xen-4.13.0_04-lp151.688.cfg' vmlinuz-5.4.11-24.g2d02eb4-default: 0x8b7c-0x8c04efb8 initrd-5.4.11-24.g2d02eb4-default: 0x8a4a5000-0x8b7bfe28 0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x928a9018 0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x928a0018 0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x92885018 __ __ \ \/ /___ _ __ \ // _ \ '_ \ / \ __/ | | | /_/\_\___|_| |_| _ __ _ ___ ___ _ _ _ _ _ _____ ___ | || | / |___ / / _ \ / _ \| || || |_ __ / | ___|/ | / /_ ( _ ) ( _ ) | || |_ | | |_ \| | | | | | | | || |_ __| | '_ \| |___ \| || '_ \ / _ \ / _ \ |__ _|| |___) | |_| | | |_| |__ _|__| | |_) | |___) | || (_) | (_) | (_) | |_|(_)_|(_)___/___\___/ |_||_| .__/|_|/|_(_)___/ \___/ \___/ |_| |_| (XEN) [0026c8dc8909] Xen version 4.13.0_04-lp151.688 (abu...@suse.de) (gcc (SUSE Linux) 9.2.1 20200109 [gcc-9-branch revi sion 280039]) debug=n Wed Jan 8 11:43:04 UTC 2020 (XEN) [0026cbd609dc] Latest ChangeSet: (XEN) [0026cc9505ea] Bootloader: EFI (XEN) [0026cd46f20f] Command line: dom0=pvh dom0-iommu=map-reserved dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcp us=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 ucode=scan log_buf_len=16M loglvl=warning guest_loglvl=none/warning noreboot=false iommu=verbose sync_console=false ... on exec of cmdline shutdown from shell, shutdown -r now the system DOES reboot, but first throws an APIC error -- only if running Xen, reboot with no-hypervisor has not probs 1st step, here's the current, relevant _log_ trace ... [ OK ] Reached target Shutdown. [ 343.932856] watchdog: watchdog0: watchdog did not stop! [ 346.871303] watchdog: watchdog0: watchdog did not stop! dracut Warning: Killing all remaining processes mdadm: stopped /dev/md4 mdadm: stopped /dev/md3 mdadm: stopped /dev/md2 mdadm: stopped /dev/md1 mdadm: stopped /dev/md0 Rebooting. [ 352.396918] reboot: Restarting system (XEN) [2020-01-15 15:01:26] Hardware Dom0 shutdown: rebooting machine (XEN) [2020-01-15 15:01:26] APIC error on CPU0: 40(00) (XEN) [2020-01-15 15:01:26] [ Xen-4.13.0_04-lp151.688 x86_64 debug=n Not tainted ] (XEN) [2020-01-15 15:01:26] CPU:0 (XEN) [2020-01-15 15:01:26] RIP:e008:[<>] (XEN) [2020-01-15 15:01:26] RFLAGS: 00010202 CONTEXT: hypervisor (XEN) [2020-01-15 15:01:26] rax: 0286 rbx: rcx: (XEN) [2020-01-15 15:01:26] rdx: 9e5ca7a0 rsi: rdi: (XEN) [2020-01-15 15:01:26] rbp: rsp: 83008ca2fa48 r8: 83008ca2fa90 (XEN) [2020-01-15 15:01:26] r9: 83008ca2fa80 r10: r11: (XEN) [2020-01-15 15:01:26] r12: r13: 83008ca2fb00 r14: 83008ca2 (XEN) [2020-01-15 15:01:26] r15: cr0: 80050033 cr4: 001526e0 (XEN) [2020-01-15 15:01:26] cr3: 0008492ed000 cr2: eef3f286 (XEN) [2020-01-15 15:01:26] fsb: gsb: gss: (XEN) [2020-01-15 15:01:26] ds: es: fs: gs: ss: cs: e008 (XEN) [2020-01-15 15:01:26] Xen code around <> () [fault on access]: (XEN) [2020-01-15 15:01:26] -- -- -- -- -- -- -- -- <00> 80 00 f0 f3 ee 00 f0 c3 e2 00 f0 f3 ee 00 f0 (XEN) [2020-01-15 15:01:26] Xen stack trace from rsp=83008ca2fa48: (XEN) [2020-01-15 15:01:26]9e5ca3c9 82d08036681f 82d08036682b (XEN) [2020-01-15 15:01:26] 83008ca2fa88 001526e0 (XEN) [2020-01-15 15:01:26]82d0802758cd
Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
Let's clarify this a bit: a very useful & clear reply -- if that's all in the docs/wiki already, I managed to miss it! thx! ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 successfully boots in PVH mode (dom0=pvh ...), with efi vars available so that efibootmgr functions, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4015 4 r- 847.6 Xenstore 131 1 -b 0.0 dmesg | grep -i pvh [0.181973] Booting paravirtualized kernel on Xen PVH efibootmgr BootCurrent: Timeout: 1 seconds BootOrder: ,0002,0003 Boot* xensvr HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0002* UEFI OS HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO Boot0003* UEFI: Built-in EFI Shell VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO From https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/ I understand that PVH Dom0 *removes* qemu dependency, "PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems PVH combines the best of PV and HVM mode to simplify the interface between operating systems with Xen Project Support and the Xen Project Hypervisor and to reduce the attack surface of Xen Project Software. PVH guests are lightweight HVM guests that use hardware virtualization support for memory and privileged instructions. PVH does not require QEMU. Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 million lines of QEMU code from Xen Project’s computing base shrinking the attack surface of Xen Project based systems." Checking, qemu is still resident, ps ax | grep qemu 1895 ?Sl 0:00 /usr/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile /var/run/xen/qemu-dom0.pid Is this still expected? If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64? If not, is there some additional config required to disable its use here? ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
On 4/18/19 5:52 AM, Roger Pau Monné wrote: >> Given some of the build 'fun' I've been having today, I'll take a closer >> look at the patched kernel build in the morning -- to make doubly sure I >> actually built correctly. finally! got that cleaned up. > OK, that patch seemed to fix the issue for me, and I managed to get > efibootmgr to display the firmware data from a PVH dom0. > > Can you provide the full serial output of Xen plus Linux booting with > dom0=pvh and the patch below applied? > > Note that this is the previously provided patch with added debug > messages. with your latest patch applied, packages available from https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/kernel-source?expand=0 it appears to boot OK -- with EFI tools correctly functioning. serial output includes, ... (XEN) [0027b5faa36d] Bootloader: EFI (XEN) [0027b6afda74] Command line: dom0=pvh dom0-iommu=map-reserved dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcp ... [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490 ... [3.780634] Registered efivars operations ... [6.903746] EFI Variables Facility v0.08 2004-May-17 ... [6.992034] Couldn't get size: 0x800e [6.997132] MODSIGN: Couldn't get UEFI db list [7.002052] Couldn't get size: 0x800e [7.007148] Couldn't get UEFI MokListRT [7.011379] Couldn't get size: 0x800e [7.016438] Couldn't get UEFI dbx list ... xen's up, uname -rm 5.0.8-21.g4835ec0-default x86_64 xl list NameID Mem VCPUs State Time(s) Domain-0 0 4015 4 r- 117.1 Xenstore 131 1 -b 0.0 as are efi tools efibootmgr -V version 17 efibootmgr -v BootCurrent: Timeout: 1 seconds BootOrder: ,0002,0003 Boot* openSUSE-XSVR HD(2,GPT,981...)/File(\EFI\OPENSUSE\GRUBX64.EFI) Boot0002* UEFI OS HD(2,GPT,981...)/File(\EFI\BOOT\BOOTX64.EFI)..BO Boot0003* UEFI: Built-in EFI Shell VenMedia(502...)..BO assuming nothing's changed, other than logging, in your recent patch, the problem in my last attempt was due to the kernel build mess on my end; likely equal portions of buildsystem challenges and pebkac. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
On 4/17/19 8:30 PM, PGNet Dev wrote: > Thx. > > not ignoring you -- opensuse kernel build system is having a hissy-fit > atm; builds are failing. :-/ > > if I can't get it to behave a build a nice pkg for me, I'll work on a > manual spin. With a pkg instance of your-patched kernel 5.0.8, https://build.opensuse.org/build/home:pgnd:Kernel:stable/openSUSE_Leap_15.0/x86_64/kernel-source/_log ... [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.suse/vfio-type1-limit-dma-mappings-per-container >>> [ 79s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i >>> /home/abuild/rpmbuild/BUILD/kernel-source-5.0.8/patches.addon/xen-pvh-uefi.patch [ 79s] ++ find . -name .gitignore ... and Dom=pvh enabled, ... Xen 4.12.0_10-lp150.647 (c/s ) EFI loader Using configuration file 'xen-4.12.0_10-lp150.647.cfg' vmlinuz-5.0.8-lp150.2.g8b88553-default: 0x8b899000-0x8c068db8 initrd-5.0.8-lp150.2.g8b88553-default: 0x8a72-0x8b898618 ... (XEN) [0027c63c1674] Xen version 4.12.0_10-lp150.647 ... (XEN) [0027caa3ad80] Command line: dom0=pvh dom0-iommu=map-reserved ... ... it boots OK, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4015 4 r- 62.1 Xenstore 131 1 -b 0.0 but still efibootmgr -v EFI variables are not supported on this system. error trace: Given some of the build 'fun' I've been having today, I'll take a closer look at the patched kernel build in the morning -- to make doubly sure I actually built correctly. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
Thx. not ignoring you -- opensuse kernel build system is having a hissy-fit atm; builds are failing. :-/ if I can't get it to behave a build a nice pkg for me, I'll work on a manual spin. On 4/17/19 5:05 AM, Roger Pau Monné wrote: On Tue, Apr 16, 2019 at 12:50:43PM +0200, Roger Pau Monné wrote: Adding the Linux Xen maintainers, in case they can provide some insight. On Mon, Apr 15, 2019 at 03:27:43PM -0700, PGNet Dev wrote: ref: from chat in #xen [08:53] pgnd: would be good to send an email so we can keep track of this in a more formal way. I've got Xen PV Dom0 booted on a Linux UEFI box dmesg | grep -i "xen version" [1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD) uname -rm 5.0.7-lp150.5.g012b5f1-default x86_64 lsb_release -rd Description:openSUSE Leap 15.0 Release:15.0 rpm -qa | grep -i qemu | egrep "seabios|u-3" qemu-seabios-1.12.0-lp150.513.13.noarch qemu-3.1.0-lp150.513.13.x86_64 rpm -qa | grep -i ovmf ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64 qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64 rpm -qa | grep grub2 |egrep "xen|efi" grub2-x86_64-efi-2.02-lp150.64.10.noarch grub2-x86_64-xen-2.02-lp150.64.10.noarch & rpm -qa | grep -i efi | grep git | sort efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64 efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64 libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64 note these^^ EFI* tools -- src from efi master branch, pkgs available here, https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr -- were needed, as distro packaged versions' were old/problematic ... With this^^ config, all's well serial boot log ... [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490 [0.00] SMBIOS 2.7 present. [0.00] Hypervisor detected: Xen PV [0.00] Xen version 4.12. ... at shell prompt, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4016 4 r-5949.6 Xenstore 131 1 -b 0.2 efibootmgr -v BootCurrent: Timeout: 1 seconds BootOrder: Boot* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi) dp: 04 01 2a ... 04 00 enabling PVH Dom0, adding to grub configs, GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..." GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..." then mkinitrd & grub reconfig, serial boot log Xen 4.12.0_09-lp150.640 (c/s ) EFI loader ... (XEN) [0027dcded44e] Bootloader: EFI ... Using configuration file 'xen-4.12.0_09-lp150.640.cfg' ... [0.00] BIOS-e820: [mem 0x0001-0x00016a2acfff] usable [0.00] BIOS-e820: [mem 0x00016a2ad000-0x00085dff] unusable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] Hypervisor detected: Xen HVM [0.00] Xen version 4.12. ... Note, there is NO "efi: ..." log content, as in the prior, PV mode example. at shell prompt, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4015 4 r- 563.0 Xenstore 131 1 -b 0.0 but, in this Dom0=pvh mode, efibootmgr -v EFI variables are not supported on this system. So boot works as expected, it's just interaction with the EFI firmware by dom0 that seems to be broken. I'm currently setting up a Linux EFI box to test this, thanks for the report. I've managed to reproduce this, and have a patch for the Linux kernel for you to try. If you can give it a try and report back whether
[Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot
ref: from chat in #xen [08:53] pgnd: would be good to send an email so we can keep track of this in a more formal way. I've got Xen PV Dom0 booted on a Linux UEFI box dmesg | grep -i "xen version" [1.185996] Xen version: 4.12.0_09-lp150.640 (preserve-AD) uname -rm 5.0.7-lp150.5.g012b5f1-default x86_64 lsb_release -rd Description:openSUSE Leap 15.0 Release:15.0 rpm -qa | grep -i qemu | egrep "seabios|u-3" qemu-seabios-1.12.0-lp150.513.13.noarch qemu-3.1.0-lp150.513.13.x86_64 rpm -qa | grep -i ovmf ovmf-tools-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64 qemu-ovmf-x86_64-2019+git1552059899.89910a39dcfd-lp150.100.3.noarch ovmf-2019+git1552059899.89910a39dcfd-lp150.100.3.x86_64 rpm -qa | grep grub2 |egrep "xen|efi" grub2-x86_64-efi-2.02-lp150.64.10.noarch grub2-x86_64-xen-2.02-lp150.64.10.noarch & rpm -qa | grep -i efi | grep git | sort efibootmgr-999.git.20190306.438ba96-lp150.7.22.x86_64 efivar-devel-999.git.20190305.836461e-lp150.6.21.x86_64 libefivar1-999.git.20190305.836461e-lp150.6.21.x86_64 note these^^ EFI* tools -- src from efi master branch, pkgs available here, https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efivar https://build.opensuse.org/package/show/home:pgnd:Kernel:stable/efibootmgr -- were needed, as distro packaged versions' were old/problematic ... With this^^ config, all's well serial boot log ... [0.00] efi: EFI v2.31 by American Megatrends [0.00] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 MPS=0xfd490 [0.00] SMBIOS 2.7 present. [0.00] Hypervisor detected: Xen PV [0.00] Xen version 4.12. ... at shell prompt, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4016 4 r-5949.6 Xenstore 131 1 -b 0.2 efibootmgr -v BootCurrent: Timeout: 1 seconds BootOrder: Boot* openSUSE-pgnXEN HD(2,GPT,98026223-f11d-3c68-8d30-3f9856c8c21e,0x1000,0x96000)/File(\EFI\opensuse\grubx64.efi) dp: 04 01 2a ... 04 00 enabling PVH Dom0, adding to grub configs, GRUB_CMDLINE_LINUX_XEN_REPLACE="... intel_iommu=on ..." GRUB_CMDLINE_XEN="... dom0=pvh dom0-iommu=map-reserved ..." then mkinitrd & grub reconfig, serial boot log Xen 4.12.0_09-lp150.640 (c/s ) EFI loader ... (XEN) [0027dcded44e] Bootloader: EFI ... Using configuration file 'xen-4.12.0_09-lp150.640.cfg' ... [0.00] BIOS-e820: [mem 0x0001-0x00016a2acfff] usable [0.00] BIOS-e820: [mem 0x00016a2ad000-0x00085dff] unusable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.7 present. [0.00] Hypervisor detected: Xen HVM [0.00] Xen version 4.12. ... Note, there is NO "efi: ..." log content, as in the prior, PV mode example. at shell prompt, xl list NameID Mem VCPUs State Time(s) Domain-0 0 4015 4 r- 563.0 Xenstore 131 1 -b 0.0 but, in this Dom0=pvh mode, efibootmgr -v EFI variables are not supported on this system. checking mount | grep -i efi systemd-1 on /boot/efi type autofs (rw,relatime,fd=54,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21340) /dev/sde2 on /boot/efi type vfat (rw,relatime,fmask=0002,dmask=0002,allow_utime=0020,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro,x-systemd.automount) tree /boot/efi/ /boot/efi/ ├── [root4096] EFI │ ├── [root4096] BOOT │ │ └── [root 142848] BOOTX64.EFI │ └── [root4096] opensuse │ ├── [root 142848] grubx64.efi │ ├── [root 532] grub.xen-files │ ├── [root18318448]