- openSUSE Virtual

[opensuse-virtual] Virtualization/qemu builds for Leap15.1 appear to need conditional to exclude "_static/language_data.js"
by PGNet Dev 06 May '19

06 May '19

Testing building of Virtualization/qemu for leap 15.1 in my OBS home: instance appears to FAIL, complaining about a missing "_static/language_data.js" It's simple enough to fix @, https://build.opensuse.org/package/view_file/home:pgnd:Virtualization:qemu/… just adding the leap15.1 condition, 1548 %endif %_docdir/%name/interop/_static/jquery.js - %if 0%{?sle_version} != 150000 + %if 0%{?sle_version} != 150000 && 0%{?sle_version} != 150100 %_docdir/%name/interop/_static/language_data.js %endif now builds OK https://download.opensuse.org/repositories/home:/pgnd:/Virtualization:/qemu… I'm not exactly clear why this gets excluded just for SLE/Leap 15.0 & 15.1 ... or why 'sle_version' makes sense here, and if/how the TW case should be dealt with; perhaps %if 0%{?suse_version} >= 1500 ? So wanted to get that clear b4 calling it a bug ... -- 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] How to correctly configure mitigation of CVE-2018-3646 'Foreshadow-NG (VMM)' on Xen Dom0 host?
by PGNet Dev 19 Apr '19

19 Apr '19

Following along at CVE-2018-3646 Common Vulnerabilities and Exposures https://www.suse.com/security/cve/CVE-2018-3646/ & Security Vulnerability: Spectre Variant 4 (Speculative Store Bypass) aka CVE-2018-3639. https://www.suse.com/support/kb/doc/?id=7022937 piecing together a number of other posts, and noting https://lists.opensuse.org/opensuse-security-announce/2018-12/msg00073.html An update that solves 9 vulnerabilities and has four fixes is now available. This update for xen fixes the following issues: Update to Xen 4.10.2 bug fix release (bsc#1027519). ... - CVE-2018-3646: Mitigations for VMM aspects of L1 Terminal Fault (XSA-273) (bsc#1091107) which references, Bug 1091107 - VUL-0: CVE-2018-3646: xen: L1 Terminal Fault -VMM (XSA-273) https://bugzilla.suse.com/show_bug.cgi?id=1091107 ==> Status: RESOLVED FIXED on uname -rm 5.0.7-lp150.5.g012b5f1-default x86_64 lsb_release -rd Description: openSUSE Leap 15.0 Release: 15.0 grep "model name" /proc/cpuinfo | head -n 1 model name : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz booting a Xen Dom0 host, dmesg | grep -i "xen version" [ 1.188399] Xen version: 4.12.0_09-lp150.640 (preserve-AD) In my grub cfg, GRUB_CMDLINE_LINUX_XEN_REPLACE="... spectre_v2=retpoline,generic spec_store_bypass_disable=on ..." GRUB_CMDLINE_XEN="... spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true smt=true ucode=scan ..." Updating microcode in Xen environments https://www.suse.com/support/kb/doc/?id=7022546 after grub re-config & mkinitrd, then reboot, per Updating microcode in Xen environments https://www.suse.com/support/kb/doc/?id=7022546 verifying, egrep "family|model|stepping" /proc/cpuinfo -m 4 cpu family : 6 model : 60 model name : Intel(R) Xeon(R) CPU E3-1220 v3 @ 3.10GHz stepping : 3 in hex, [cpu family]-[model]-[stepping] === 06-3C-03 rpm -qa | grep -i ucode-intel ucode-intel-20190312-lp150.3.1.x86_64 rpm -ql ucode-intel | grep -i 06-3C-03 /lib/firmware/intel-ucode/06-3c-03 lsinitrd /boot/initrd-5.0.7-lp150.5.g012b5f1-default Image: /boot/initrd-5.0.7-lp150.5.g012b5f1-default: 18M ======================================================================== Early CPIO image ======================================================================== drwxr-xr-x 3 root root 0 Apr 14 20:15 . -rw-r--r-- 1 root root 2 Apr 14 20:15 early_cpio drwxr-xr-x 3 root root 0 Apr 14 20:15 kernel drwxr-xr-x 3 root root 0 Apr 14 20:15 kernel/x86 drwxr-xr-x 2 root root 0 Apr 14 20:15 kernel/x86/microcode -rw-r--r-- 1 root root 23552 Apr 14 20:15 kernel/x86/microcode/GenuineIntel.bin ======================================================================== Version: dracut-044-lp150.14.27.1 grep -m1 microcode /proc/cpuinfo microcode : 0x25 in serial log (XEN) [00000027c847dc37] Xen version 4.12.0_09-lp150.640 (abuild(a)suse.de) (gcc (SUSE Linux) 8.3.1 20190305 [gcc-8-branch revi sion 269383]) debug=n Thu Apr 11 22:29:39 UTC 2019 (XEN) [00000027cb3e1267] Latest ChangeSet: (XEN) [00000027cbff3231] Bootloader: EFI (XEN) [00000027ccb72e3d] Command line: dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcpus=4 spec-ctrl=ssbd,l1d-flush=true pv-l1tf=dom0=true,domu=true smt=true com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sched=credit2 reboot=acpi ucode=scan log_buf_len=16M loglvl=warning guest_loglvl=none/warning noreboot=false iommu=verbose ... (XEN) [00000028c099c50b] Speculative mitigation facilities: (XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD (XEN) [00000028c2f57689] Compiled-in support: INDIRECT_THUNK SHADOW_PAGING (XEN) [00000028c445abaf] Xen settings: BTI-Thunk RETPOLINE, SPEC_CTRL: IBRS- SSBD+, Other: IBPB L1D_FLUSH (XEN) [00000028c61da08b] L1TF: believed vulnerable, maxphysaddr L1D 46, CPUID 39, Safe address 8000000000 (XEN) [00000028c7f67494] Support for HVM VMs: MSR_SPEC_CTRL RSB EAGER_FPU (XEN) [00000028c94630dc] Support for PV VMs: MSR_SPEC_CTRL RSB EAGER_FPU (XEN) [00000028ca92b21c] XPTI (64-bit PV only): Dom0 enabled, DomU enabled (with PCID) (XEN) [00000028cc1cfa07] PV L1TF shadowing: Dom0 enabled, DomU enabled then, cd /sys/devices/system/cpu/vulnerabilities/ for f in $(ls); do echo -e "\n$f"; cat $f; done l1tf Mitigation: PTE Inversion meltdown Unknown (XEN PV detected, hypervisor mitigation required) spec_store_bypass Mitigation: Speculative Store Bypass disabled spectre_v1 Mitigation: __user pointer sanitization spectre_v2 Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling BUT, checking with spectre-meltdown-checker.sh still returns "STATUS: VULNERABLE", ... CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault' * Information from the /sys interface: * This system is a host running an hypervisor: YES * Mitigation 1 (KVM) * EPT is disabled: N/A (the kvm_intel module is not loaded) * Mitigation 2 * L1D flush is supported by kernel: YES (found flush_l1d in kernel image) * L1D flush enabled: UNKNOWN (unrecognized mode) * Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower) * Hyper-Threading (SMT) is enabled: YES > STATUS: VULNERABLE (disable EPT or enabled L1D flushing to mitigate the vulnerability) ... Since I'm on Xen, 'Mitigation 1' isn't an option. Two things catch my attention: (1) L1D flush enabled: UNKNOWN (unrecognized mode) Not sure yet why I'm seeing UNKNOWN here, & (2) Hardware-backed L1D flush supported: NO even though (XEN) [00000028c19f6e50] Hardware features: IBRS/IBPB STIBP L1D_FLUSH SSBD ^^^^^^^^^ What's missing in my config to mitigate/remove the CVE-2018-3646 vulnerability? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 16

[opensuse-virtual] after leap 42.3 -> 15.0 upgrades, Xen/EFI servers' multiple services fail with "failed with result 'dependency'"
by PGNet Dev 04 Jun '18

04 Jun '18

Upgrading working OpenSUSE leap42.3 / Xen servers (5, atm) to leap15.0, after upgrade lsb_release -rd Description: openSUSE Leap 15.0 Release: 15.0 uname -rm 4.16.12-lp150.2.g39c7522-default x86_64 rpm -qa | egrep -i "xen|qemu|efi" | sort efibootmgr-14-lp150.2.2.x86_64 efivar-devel-31-lp150.1.11.x86_64 grub2-x86_64-efi-2.02-lp150.35.1.x86_64 grub2-x86_64-xen-2.02-lp150.35.1.x86_64 libefivar1-31-lp150.1.11.x86_64 qemu-2.12.0-lp150.453.1.x86_64 qemu-arm-2.12.0-lp150.453.1.x86_64 qemu-block-curl-2.12.0-lp150.453.1.x86_64 qemu-block-dmg-2.12.0-lp150.453.1.x86_64 qemu-extra-2.12.0-lp150.453.1.x86_64 qemu-ipxe-1.0.0-lp150.453.1.noarch qemu-ksm-2.12.0-lp150.453.1.x86_64 qemu-kvm-2.12.0-lp150.453.1.x86_64 qemu-lang-2.12.0-lp150.453.1.x86_64 qemu-linux-user-2.12.0-lp150.453.1.x86_64 qemu-ovmf-x86_64-2018+git1525854636.13e3f8c03339-lp150.75.1.noarch qemu-seabios-1.11.1-lp150.453.1.noarch qemu-sgabios-8-lp150.453.1.noarch qemu-tools-2.12.0-lp150.453.1.x86_64 qemu-vgabios-1.11.1-lp150.453.1.noarch qemu-x86-2.12.0-lp150.453.1.x86_64 xen-4.10.1_02-lp150.576.1.x86_64 xen-libs-4.10.1_02-lp150.576.1.x86_64 xen-tools-4.10.1_02-lp150.576.1.x86_64 No notable version changes, just the switch to lp150 packages. serial output @ boot ... Booting `OpenSUSE, with Xen hypervisor'Booting `OpenSUSE, with Xen hypervisor' Loading Xen 4.10.1_02-lp150.576 with Linux 4.16.12-lp150.2.g39c7522-default ...Loading Xen 4.10.1_02-lp150.576 with Linux 4.16.12-lp150.2.g39c7522-default ... /EndEntire /EndEntire file path: file path: /ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor (cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: /HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 ]]/HD(2,1000,96000,3d7310980ce0754c ,2,2)/HD(2,1000,96000,3d7310980ce0754c,2,2)/File(\efi\opensuse) /File(\efi\opensuse)/File(xen-4.10.1_02-lp150.576.efi)/File(xen-4.10.1_02-lp150.576.efi)/EndEntire /EndEntire Xen 4.10.1_02-lp150.576 (c/s ) EFI loader Using configuration file 'xen-4.10.1_02-lp150.576.cfg' vmlinuz-4.16.12-lp150.2.g39c7522-default: 0x000000008b917000-0x000000008c073da8 initrd-4.16.12-lp150.2.g39c7522-default: 0x000000008a856000-0x000000008b916e60 0x0000:0x00:0x19.0x0: ROM: 0x10000 bytes at 0x928b9018 0x0000:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x928b0018 0x0000:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x92894018 __ __ \ \/ /___ _ __ \ // _ \ '_ \ / \ __/ | | | /_/\_\___|_| |_| _ _ _ ___ _ ___ ____ _ _ ____ ___ ____ _____ __ | || | / |/ _ \ / | / _ \___ \ | |_ __ / | ___| / _ \ | ___|___ / /_ | || |_ | | | | || | | | | |__) |__| | '_ \| |___ \| | | ||___ \ / / '_ \ |__ _|| | |_| || | | |_| / __/|__| | |_) | |___) | |_| | ___) |/ /| (_) | |_|(_)_|\___(_)_|___\___/_____| |_| .__/|_|____/ \___(_)____//_/ \___/ |_____| |_| (XEN) Xen version 4.10.1_02-lp150.576 (abuild(a)suse.de) (gcc (SUSE Linux) 8.1.1 20180523 [gcc-8-branch revision 260570]) debug=n Fri May 18 14:03:46 UTC 2018 (XEN) Latest ChangeSet: (XEN) Console output is synchronous. (XEN) Bootloader: EFI (XEN) Command line: dom0_mem=4016M,max:4096M bootscrub=false dom0_max_vcpus=4 vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps console_to_ring conring_size=64 sc hed=credit2 reboot=acpi log_buf_len=16M loglvl=all guest_loglvl=all noreboot=false sync_console=true sched_debug iommu=verbose apic_verbosity=verbose ... dmesg ... [ 0.000000] Hypervisor detected: Xen PV ... But checking, xl list Name ID Mem VCPUs State Time(s) (null) 0 4016 4 r----- 329.6 Xenstore 1 31 1 -b---- 0.0 and dmesg | grep -i xen [ 0.000000] Command line: root=/dev/mapper/VG0 softlevel=xen rd.shell rd.debug=0 rd.udev.log_priority=info rd.auto=1 dolvm lvmwait=/dev/mapper/VG0 root=/dev/mapper/VG0 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand clocksource=xen net.ifnames=1 biosdevname=0 plymouth.enable=0 apparmor=0 pcie_aspm=off mce=off fsck.mode=skip fsck.repair=preen nomodeset nouveau.modeset=1 showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=info systemd.log_target=kmsg earlyprintk=xen,keep [ 0.000000] Xen: [mem 0x0000000000000000-0x0000000000007fff] reserved ... [ 0.000000] Xen: [mem 0x000000016f2a8000-0x000000085dffffff] unusable [ 0.000000] Hypervisor detected: Xen PV [ 0.000000] Kernel/User page tables isolation: disabled on XEN PV. [ 0.000000] Setting APIC routing to Xen PV. [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.10.1_02-lp150.576 (preserve-AD) [ 0.000000] xen: PV spinlocks enabled [ 0.000000] Kernel command line: root=/dev/mapper/VG0 softlevel=xen rd.shell rd.debug=0 rd.udev.log_priority=info rd.auto=1 dolvm lvmwait=/dev/mapper/VG0 root=/dev/mapper/VG0 rootfstype=ext4 rootflags=journal_checksum noresume video=vesa:off video=efifb:1024x768 video=HDMI-A-1:1920x1080@60 xencons=xvc console=tty0 console=hvc0 elevator=deadline cpuidle cpufreq=xen:ondemand clocksource=xen net.ifnames=1 biosdevname=0 plymouth.enable=0 apparmor=0 pcie_aspm=off mce=off fsck.mode=skip fsck.repair=preen nomodeset nouveau.modeset=1 showopts noquiet log_buf_len=10M print_fatal_signals=1 systemd.log_level=info systemd.log_target=kmsg earlyprintk=xen,keep [ 0.004000] xen:events: Using FIFO-based ABI [ 0.004000] xen: --> pirq=1 -> irq=1 (gsi=1) ... [ 0.004000] xen: --> pirq=15 -> irq=15 (gsi=15) [ 0.004000] clocksource: xen: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [ 0.004000] Xen: using vcpuop timer interface [ 0.004000] installing Xen timer for CPU 0 [ 0.192039] installing Xen timer for CPU 1 [ 0.232038] installing Xen timer for CPU 2 [ 0.272060] installing Xen timer for CPU 3 [ 0.360014] xen:grant_table: Grant tables using version 1 layout [ 0.464199] xen: registering gsi 9 triggering 0 polarity 0 ... [ 21.864462] xen: registering gsi 17 triggering 0 polarity 1 [ 27.472745] xen:xen_evtchn: Event-channel device installed [ 27.753699] xen_pciback: backend is vpci [ 27.820997] xen_acpi_processor: Uploading Xen processor PM info [ 59.589179] xen: registering gsi 19 triggering 0 polarity 1 [ 117.961068] systemd[1]: xenstored.service: Start operation timed out. Terminating. [ 117.961491] systemd[1]: Failed to start The Xen xenstore. [ 117.961541] systemd[1]: Dependency failed for Xendomains - start and stop guests on boot and shutdown. [ 117.961563] systemd[1]: xendomains.service: Job xendomains.service/start failed with result 'dependency'. [ 117.961577] systemd[1]: Dependency failed for qemu for xen dom0 disk backend. [ 117.961590] systemd[1]: Dependency failed for xencommons. [ 117.961605] systemd[1]: xencommons.service: Job xencommons.service/start failed with result 'dependency'. [ 117.961624] systemd[1]: xen-qemu-dom0-disk-backend.service: Job xen-qemu-dom0-disk-backend.service/start failed with result 'dependency'. [ 117.961628] systemd[1]: Dependency failed for Xenconsoled - handles logging from guest consoles and hypervisor. [ 117.961643] systemd[1]: xenconsoled.service: Job xenconsoled.service/start failed with result 'dependency'. systemctl status -l xen-qemu-dom0-disk-backend.service ● xen-qemu-dom0-disk-backend.service - qemu for xen dom0 disk backend Loaded: loaded (/usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service; enabled; vendor preset: disabled) Active: inactive (dead) systemctl list-unit-files | grep -i xen home-xen.mount generated proc-xen.mount static var-lib-xenstored.mount static xen-dom0-modules.service disabled xen-init-dom0.service enabled xen-qemu-dom0-disk-backend.service enabled xen-watchdog.service disabled xencommons.service enabled xenconsoled.service enabled xendomains.service enabled xenstored.service enabled cat /usr/lib/systemd/system/xen-qemu-dom0-disk-backend.service [Unit] Description=qemu for xen dom0 disk backend Requires=proc-xen.mount xenstored.service After=proc-xen.mount xenstored.service xenconsoled.service Before=xendomains.service libvirtd.service libvirt-guests.service RefuseManualStop=true ConditionPathExists=/proc/xen/capabilities [Service] Type=simple PIDFile=/var/run/xen/qemu-dom0.pid ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities ExecStartPre=/bin/mkdir -p /var/run/xen ExecStart=/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 [Install] WantedBy=multi-user.target systemctl status -l xenstored.service ● xenstored.service - The Xen xenstore Loaded: loaded (/usr/lib/systemd/system/xenstored.service; enabled; vendor preset: disabled) Active: failed (Result: timeout) since Wed 2018-05-30 10:37:08 PDT; 10min ago Main PID: 1391 (code=exited, status=0/SUCCESS) May 30 10:35:39 xserver launch-xenstore[1391]: Starting /usr/lib/xen/boot/xenstore-stubdom.gz... Not sure yet -- is this a new bug, or a config change, issue? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 6

[opensuse-virtual] XEN
by suse＠a-domani.nl 04 Jun '18

04 Jun '18

Hi all, I've a couple of old VM-hosting machines (XEN), that I finally wanted to get up-to-dade, and with the release of leap15, that seemed a good opportunity. So, after a fresh installation (no! upgrade), system initially booted fine, with the default desktop kernel. However, when I boot with the XEN hypervisor, it crashes beyond anything I've seen for a long long time. And I date back to the time of the 1.2 kernels; (and SuSE since 6.3) Not even REISUB worked anymore, only pulling the powerplug can revive, but only into desktop-mode As this 'leap' is pretty young, and things might have slipped through Q&A, I presumed it would be fixed shortly, hence I reverted to 42.3. But to my dismay: exactly the same! I ditched the idea of having full disk encryption, (and no other fancy stuff installed): still the same. Having the behavior six** installation times in a row is beyond coincidence. ** both lead 15.0 and 42.3: verified sha256 checksum Installed from thumb-drive 60GB Volume Group 10GB lvm holding root partition 5GB lvm holding swap server-installation (text-mode) plus following groups: XEN, NW-admin, Print-server, Mail-server, web-server,Internet-GW, DHCP/DNS-server Installed with online repo's enabled, finally zypper lu; zypper up When was such a XEN set-up working properly? How far do I have to go back? Or does one needs nowadays a full KDE/Gnome-desktop to have XEN working? Kind regards, Hans. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 5

Re: [opensuse-virtual] Re: [opensuse] where has independent_wallclock gone ?
by Jan Beulich 05 Feb '18

05 Feb '18

>>> On 05.02.18 at 12:56, <per(a)opensuse.org> wrote: > Jan Beulich wrote: >>>>> On 05.02.18 at 12:24, <per(a)opensuse.org> wrote: >>> I was just playing around with Leap15 as a guest and wanted to run >>> ntp, >>> but couldn't find the wallclock setting. I thought it might mean it >>> is no longer necessary to run ntp, i.e. that the guest would sync to >>> dom0. Are you saying that there is no need to set >>> independent_wallclock when running ntp in a DomU ? >> >> Generally you should turn on independent wall clock in a DomU if >> and only if you mean to run NTP within the guest. > > Right. How do I turn on independent wall clock in e.g. Leap423 or > Leap15 ? Why do you want to turn on something that's already on? You can't turn it _off_. Jan -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 1

Re: [opensuse-virtual] Re: [opensuse] where has independent_wallclock gone ?
by Jan Beulich 05 Feb '18

05 Feb '18

>>> On 05.02.18 at 12:24, <per(a)opensuse.org> wrote: > I was just playing around with Leap15 as a guest and wanted to run ntp, > but couldn't find the wallclock setting. I thought it might mean it is > no longer necessary to run ntp, i.e. that the guest would sync to dom0. > Are you saying that there is no need to set independent_wallclock when > running ntp in a DomU ? Generally you should turn on independent wall clock in a DomU if and only if you mean to run NTP within the guest. Jan -- 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] Re: [opensuse] where has independent_wallclock gone ?
by Per Jessen 05 Feb '18

05 Feb '18

Per Jessen wrote: > I have a xen guest running leap15 beta - whilst playing with chrony > and ntp, I noticed that independent_wallclock appears to have gone > away? > > It would normally reside here: /proc/sys/xen/ > > I don't see it in Leap15 nor in Leap423. The source file is arch/x86/kernel/time-xen.c It was still present in Leap421, kernel 4.1.39, but with leap422, kernel 4.4.27, it's gone. I know the xen patches are no longer needed, everything is in the kernel, but I cannot find anything that tells me what to do about independent_wallclock ? > It is not needed anymore? I can see my leap15 guest has lost two > second already, out of sync with dom0. A Leap423 guest is also losing time. (no NTP). -- Per Jessen, Zürich (-0.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

3 2

[opensuse-virtual] Deprecate / Remove SDL support from QEMU packages going forward
by Bruce Rogers 17 Nov '17

17 Nov '17

All, We've had a request to remove our SDL dependency in QEMU for SLE15 due to packaging issues. Since QEMU is as single sourced as much as possible, this has a bearing on what gets packaged for Tumbleweed and Leap 15 as well. It was about 5 few years ago that QEMU switched the default graphical library from SDL to GTK, but we continued to build SDL support in (-display sdl...), I don't really see any problem with removing our support for SDL in future QEMU packages, since for the most part this is a complete duplication of functionality. Although each has slightly different windowing characteristics, I hope anyone used to using SDL will not have an issue switching to use the GTK interface. I will propose that for openSUSE (Tumbleweed and Leap 15) we consider SDL support in the QEMU packages deprecated, allowing for a time period of adjustment and an opportunity to evaluate any feedback. My hope is that it won't disrupt any users of QEMU, or at least only require minor adjustments and we can remove it before Leap 15 is released. If you will be badly impacted by this change, please speak up, and we'll re-evaluate this decision based on that feedback. Thanks, Bruce Rogers

1 0

[opensuse-virtual] Booting Debian9 installer as Xen VM guest in UEFI mode requires *dis*abling SecureBoot. How, in TianoCore setup?
by PGNet Dev 19 Oct '17

19 Oct '17

I've got an OpenSUSE Leap 42.3 Xen Host, with kernel-default-4.13.6-3.1.ga8d2202.x86_64 grub2-x86_64-xen-2.02-13.2.x86_64 qemu-ovmf-x86_64-2017+git1505340320.5afa5b8159-63.1.noarch ovmf-2017+git1505340320.5afa5b8159-63.1.x86_64 ovmf-tools-2017+git1505340320.5afa5b8159-63.1.x86_64 xen-4.9.0_50-535.6.x86_64 xen-libs-4.9.0_50-535.6.x86_64 xen-tools-4.9.0_50-535.6.x86_64 I'm attempting to boot the Debian9 installer as a UEFI Xen Guest. When I launch the guest, for Debian9 -- unlike Ubuntu & OpenSUSE guests -- it drops to EFI Shell. @ #debian irc suggests that SecureBoot is *not* supported, and that it needs to be toggled off. When I enter TianoCore config -> "Secure Boot Configuration", it's currently setup: Current Secure Boot State Enabled Attempt Secure Boot [ ] Secure Boot Mode <Standard Mode> There appears to be no option to toggle the Boot State. How do I boot this guest, with SecureBoot *DISABLED*? &/or, is there some other magic required for booting Debian9 in UEFI on OpenSUSE Xen Host? -- To unsubscribe, e-mail: opensuse-virtual+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-virtual+owner(a)opensuse.org

2 3

[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