Re: [Xen-devel] FAILED/MISSING cstate/cpufreq/cpupower support with Xen 4.13 + kernel 5.4.14; withOUT xen/hypervisor, WORKS. bug or config?

2020-01-29 Thread PGNet Dev
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?

2020-01-28 Thread PGNet Dev
( 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.

2020-01-15 Thread PGNet Dev
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.

2020-01-15 Thread PGNet Dev
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.

2020-01-15 Thread PGNet Dev
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

2019-05-27 Thread PGNet Dev

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

2019-05-24 Thread PGNet Dev
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

2019-04-20 Thread PGNet Dev
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

2019-04-17 Thread PGNet Dev
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

2019-04-17 Thread PGNet Dev

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

2019-04-15 Thread PGNet Dev
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]