May 2017 - openSUSE Virtual - openSUSE Mailing Lists

[opensuse-virtual] CONFIG_VIRTIO_MMIO, req'd (?) for Xen guest vif model == 'virtio-net' is UNSET in kernel-default config?
by PGNet Dev 28 May '17

28 May '17

I note @ https://wiki.xenproject.org/wiki/QEMU_Upstream#VirtIO (last modified on 9 February 2016) that VirtIO It's the PV drivers from KVM world. To use it for network, just use 'virtio-net' as a model: vif = [ 'model=virtio-net' ] You will need those kernel modules to use a VirtIO device virtio_mmio virtio_pci virtio_net But that egrep -i "virtio_mmio|virtio_pci|virtio_net" /boot/config-4.11.3-2.g7262353-default CONFIG_VIRTIO_NET=m CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_PCI_LEGACY=y # CONFIG_VIRTIO_MMIO is not set Is virtio_mmio no longer required for model=virtio-net usage? If it is, is there a reason for NOT currently enabling CONFIG_VIRTIO_MMIO in default kernel config? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

[opensuse-virtual] new "efi: Could not map UEFI random seed!" booting Xen 4.9.0 Dom0 + kernel 4.11.0-4 ?
by PGNet Dev 15 May '17

15 May '17

Booting Xen 4.9.0 on kernel-default 4.11.0-4, I currently see a non-fatal WARNING efi: Could not map UEFI random seed! ... (XEN) Xen version 4.9.0_04-493 (abuild(a)suse.de) (gcc (SUSE Linux) 4.8.5) debug=y Wed May 10 21:26:38 UTC 2017 (XEN) Latest ChangeSet: (XEN) Bootloader: EFI (XEN) Command line: dom0_mem=4096M,max:4096M dom0_max_vcpus=1 dom0_vcpus_pin=true cpuidle=1 c pufreq=xen vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps conso le_to_ring conring_size=64 reboot=acpi sched=credit2 clocksource=hpet iommu=verbose log_buf_l en=16M sched_debug apic_verbosity=verbose loglvl=warning guest_loglvl=none/warning (XEN) Xen image load base address: 0x8c200000 ... [ 0.000000] console [xenboot0] enabled [ 0.000000] NX (Execute Disable) protection: active [ 0.000000] efi: EFI v2.31 by American Megatrends [ 0.000000] efi: ESRT=0x9ef8d998 ACPI 2.0=0x9e819000 ACPI=0x9e819000 SMBIOS=0xf04c0 M PS=0xfd490 [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: CPU: 0 PID: 0 at ../mm/early_ioremap.c:137 __early_ioremap+0xf4/0x1b9 [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-4.gcb15206-default #1 [ 0.000000] Call Trace: [ 0.000000] dump_stack+0x5c/0x78 [ 0.000000] __warn+0xbe/0xe0 [ 0.000000] __early_ioremap+0xf4/0x1b9 [ 0.000000] efi_config_parse_tables+0x10d/0x1a7 [ 0.000000] ? __early_set_fixmap+0x8b/0x8e [ 0.000000] ? efi_config_init+0x71/0x93 [ 0.000000] ? efi_config_init+0x71/0x93 [ 0.000000] ? efi_init+0x35f/0x45d [ 0.000000] ? 0xffffffff81000000 [ 0.000000] ? setup_arch+0x471/0xcea [ 0.000000] ? printk+0x43/0x4b [ 0.000000] ? start_kernel+0x9d/0x43e [ 0.000000] ? xen_start_kernel+0x4de/0x4e8 [ 0.000000] ---[ end trace c06508679cc2dcf2 ]--- [ 0.000000] efi: Could not map UEFI random seed! [ 0.000000] efi: memattr: Unexpected EFI Memory Attributes table version -268402688 [ 0.000000] SMBIOS 2.7 present. [ 0.000000] DMI: Supermicro X10SAT/X10SAT, BIOS 3.0 05/26/2015 [ 0.000000] Hypervisor detected: Xen ... The notice is relatively new; tho can't tell you specifically when it appeared. The system *does* boot successfully, and *appears* to be functioning. Digging, I found Patchwork [1/2] efi: add support for seeding the RNG from a UEFI config table https://patchwork.kernel.org/patch/9364581/ Is this WARNING, in fact, related to that patch? Is the 'fix' for the warning the inclusion of that patch? Or, is there a kernel boot option needed? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 1

[opensuse-virtual] status/usage of multiboot2 in grub2 with Xen 4.9+?
by PGNet Dev 13 May '17

13 May '17

I have grub2 installed on an Opensuse Xen 4.9 Dom0 host, grub2-2.02-3.1.x86_64 grub2-i386-pc-2.02-3.1.x86_64 grub2-x86_64-efi-2.02-3.1.x86_64 grub2-x86_64-xen-2.02-3.1.x86_64 kernel-default-4.11.0-4.1.gcb15206.x86_64 xen-4.9.0_04-493.2.x86_64 xen-libs-4.9.0_04-493.2.x86_64 xen-tools-4.9.0_04-493.2.x86_64 reading @ https://wiki.xenproject.org/wiki/Xen_EFI, multiboot2 is supposedly supported ... Xen as gz binary ... Xen 4.9 and later implements both multiboot and multiboot2. ... with instructions to Inspect the grub.cfg. Make sure that it has 'multiboot2' and 'module2' for Xen Here, ls -al /boot/xen*gz -rw-r--r-- 1 root root 984K May 12 01:20 /boot/xen-4.9.0_04-493.gz lrwxrwxrwx 1 root root 19 May 12 09:31 /boot/xen-4.9.gz -> xen-4.9.0_04-493.gz lrwxrwxrwx 1 root root 19 May 12 09:31 /boot/xen-4.gz -> xen-4.9.0_04-493.gz -rw-r--r-- 1 root root 984K May 12 01:18 /boot/xen-dbg-4.9.0_04-493.gz lrwxrwxrwx 1 root root 23 May 12 09:31 /boot/xen-dbg-4.9.gz -> xen-dbg-4.9.0_04-493.gz lrwxrwxrwx 1 root root 23 May 12 09:31 /boot/xen-dbg-4.gz -> xen-dbg-4.9.0_04-493.gz lrwxrwxrwx 1 root root 23 May 12 09:31 /boot/xen-dbg.gz -> xen-dbg-4.9.0_04-493.gz lrwxrwxrwx 1 root root 19 May 12 09:32 /boot/xen.gz -> xen-4.9.0_04-493.gz but, grub.cfg still appears to use the chainloader mech, with no mention of "multiboot2" cat /boot/grub2/grub.cfg ... ### BEGIN /etc/grub.d/20_linux_xen ### menuentry 'OpenSUSE, with Xen hypervisor' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-4716053b-39da-4cc1-a7ce-72171b862357' { echo 'Loading Xen 4.9.0_04-493 with Linux 4.11.0-4.gcb15206-default ...' chainloader $cmdpath/xen-4.9.0_04-493.efi xen-4.9.0_04-493.efi /mapbs config.1 } submenu 'Advanced options for OpenSUSE (with Xen hypervisor)' $menuentry_id_option 'gnulinux-advanced-4716053b-39da-4cc1-a7ce-72171b862357' { submenu 'Xen hypervisor, version 4.9.0_04-493' $menuentry_id_option 'xen-hypervisor-4.9.0_04-493-4716053b-39da-4cc1-a7ce-72171b862357' { menuentry 'OpenSUSE, with Xen 4.9.0_04-493 and Linux 4.11.0-4.gcb15206-default' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-4.11.0-4.gcb15206-default-advanced-4716053b-39da-4cc1-a7ce-72171b862357' { echo 'Loading Xen 4.9.0_04-493 with Linux 4.11.0-4.gcb15206-default ...' chainloader $cmdpath/xen-4.9.0_04-493.efi xen-4.9.0_04-493.efi /mapbs config.2 } menuentry 'OpenSUSE, with Xen 4.9.0_04-493 and Linux 4.11.0-3.g39615a9-default' --class opensuse --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-4.11.0-3.g39615a9-default-advanced-4716053b-39da-4cc1-a7ce-72171b862357' { echo 'Loading Xen 4.9.0_04-493 with Linux 4.11.0-3.g39615a9-default ...' chainloader $cmdpath/xen-4.9.0_04-493.efi xen-4.9.0_04-493.efi /mapbs config.3 } } } ### END /etc/grub.d/20_linux_xen ### ... checking, the current grub appears to have multiboot2 modules installed ls -al {/usr/lib/grub2,/boot/grub2}/x86_64-efi/multiboot2* -rw-r--r-- 1 root root 25K May 12 08:52 /boot/grub2/x86_64-efi/multiboot2.mod -rw-r--r-- 1 root root 25K May 12 00:21 /usr/lib/grub2/x86_64-efi/multiboot2.mod -rw-r--r-- 1 root root 164K May 12 00:21 /usr/lib/grub2/x86_64-efi/multiboot2.module So it looks like the pieces are there ... What needs be done to enable the multiboot2 usage? Additional/different config on my part? Or, is support -- either from the grub2 or Xen sides -- not yet fully implemented? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

1 0

[opensuse-virtual] obs build of Xen 49 , w/ gcc7 -- "undefined reference to `__udivmoddi4'" ?
by PGNet Dev 04 May '17

04 May '17

I'm working on a home: build of Virtualization:Xen on OBS Atm, it's attempting to build with gcc7, for use with Kernel:stable, all for Leap 42.2 on x86_64 Currently, @OBS buils fails at https://build.opensuse.org/build/home:pgnd:Virtualization/openSUSE_Leap_42.… ... [ 200s] /home/abuild/rpmbuild/BUILD/xen-4.9.0-testing/stubdom/mini-os-x86_32-grub/mini-os.o: In function `_strtoll_r': [ 200s] /home/abuild/rpmbuild/BUILD/xen-4.9.0-testing/stubdom/newlib-x86_32/i686-xen-elf/newlib/libc/stdlib/../../../../../newlib-1.16.0/newlib/libc/stdlib/strtoll_r.c:110: undefined reference to `__udivmoddi4' ... I'm not yet sure if the problem's source, or my use of my own gcc7 build. While I'm DL'ing the project + sources locally to dig around for that symbol, anyone recognize this undef'd ref, and can suggest a solution? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 2