That finds us the fix as:

commit 120eee7d1fdb2eba15766cfff7b9bcdc902690b4
Author: Eduardo Habkost <ehabk...@redhat.com>
Date:   Tue Jun 17 17:31:53 2014 -0300

    target-i386: Set migratable=yes by default on "host" CPU mooel
    
    Having only migratable flags reported by default on the "host" CPU model
    is safer for the following reasons:
    
     * Existing users may expect "-cpu host" to be migration-safe, if they
       take care of always using compatible host CPUs, host kernels, and
       QEMU versions.
     * Users who don't care aboug migration and want to enable all features
       supported by the host kernel can simply change their setup to use
       migratable=no.
    
    Without this change, people using "-cpu host" will stop being able to
    migrate, because now "invtsc" is getting enabled by default.
    
    We are not setting migratable=yes by default on all X86CPU subclasses,
    because users should be able to get non-migratable features enabled if
    they ask for them explicitly.
    
    Reviewed-by: Marcelo Tosatti <mtosa...@redhat.com>
    Signed-off-by: Eduardo Habkost <ehabk...@redhat.com>
    Signed-off-by: Andreas Färber <afaer...@suse.de>


Which is interesting, because that just is a flip in a default setting of qemu.
Maybe the interaction that qemu 2.5 and kernel 4.4 (remember it does not occur 
with 3.13 kernel) comes down to a user accessible switch?

If we are running as "host-passthrough" (which we do) this change means
it does no more pass "all" flags. Instead only flags considered
"migratable" are passed to the guest.

In qemu 2.0 this differentiation didn't even exist (the infrastructure
for it was added in qemu 2.1).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829555

Title:
  nested virtualization w/first level trusty guests has odd MDS behavior

Status in linux package in Ubuntu:
  Confirmed
Status in qemu package in Ubuntu:
  Confirmed

Bug description:
  When nested kvm virtualization is used (with host-passthrough), if the
  first level guest is a trusty vm, odd behavior is seen in the second
  level guest:

    host os:
    disco/5.0.0-15.16-generic/qemu 1:3.1+dfsg-2ubuntu3.1
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
       Mitigation: Clear CPU buffers; SMT vulnerable

    1st level vm:
    trusty/4.4.0-148.174~14.04.1-generic/qemu 2.0.0+dfsg-2ubuntu1.46
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
      Mitigation: Clear CPU buffers; SMT Host state unknown

    2nd level vm:
    bionic/4.15.0-50.54-generic
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
      Not affected

  This behavior is not seen when the first level guest is a xenial or
  bionic vm (same bare metal hardware):

    1st level vm:
    bionic/4.15.0-50.54-generic/qemu 1:2.11+dfsg-1ubuntu7.13
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
      Mitigation: Clear CPU buffers; SMT Host state unknown

    2nd level vm:
    bionic/4.15.0-50.54-generic
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
      Mitigation: Clear CPU buffers; SMT Host state unknown

  and:

    1st level vm:
    xenial/4.4.0-148.174-generic/qemu 1:2.5+dfsg-5ubuntu10.39
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
      Mitigation: Clear CPU buffers; SMT Host state unknown

    2nd level vm:
    bionic/4.15.0-50.54-generic
    contents of /sys/devices/system/cpu/vulnerabilities/mds:
      Mitigation: Clear CPU buffers; SMT Host state unknown

  It's not clear whether this is an issue with linux/kvm or qemu in trusty.
  --- 
  ApportVersion: 2.14.1-0ubuntu3.29
  Architecture: amd64
  AudioDevicesInUse:
   USER        PID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu     2239 F.... pulseaudio
  DistroRelease: Ubuntu 14.04
  HibernationDevice: RESUME=UUID=4fa9460d-7ed4-49db-8e22-86a5107d0062
  InstallationDate: Installed on 2019-02-14 (92 days ago)
  InstallationMedia: Ubuntu 14.04.5 LTS "Trusty Tahr" - Release amd64 (20160803)
  Lsusb:
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd 
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  Package: qemu 2.0.0+dfsg-2ubuntu1.46
  PackageArchitecture: amd64
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 qxldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-148-generic 
root=UUID=9a35107e-83fa-4010-81e1-235a4ea14fe6 ro quiet splash vt.handoff=7
  ProcVersionSignature: User Name 4.4.0-148.174~14.04.1-generic 4.4.177
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-148-generic N/A
   linux-backports-modules-4.4.0-148-generic  N/A
   linux-firmware                             1.127.24
  RfKill:
   
  Tags:  trusty trusty
  Uname: Linux 4.4.0-148-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip libvirtd lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: 1.12.0-1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-bionic
  dmi.modalias: 
dmi:bvnSeaBIOS:bvr1.12.0-1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-bionic:cvnQEMU:ct1:cvrpc-i440fx-bionic:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-bionic
  dmi.sys.vendor: QEMU

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829555/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to