[Qemu-commits] [qemu/qemu] a2b107: i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: a2b107dbbd342ff2077aa5af705efaf68c375459
      
https://github.com/qemu/qemu/commit/a2b107dbbd342ff2077aa5af705efaf68c375459
  Author: Vitaly Kuznetsov <address@hidden>
  Date:   2019-01-14 (Mon, 14 Jan 2019)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h
    M target/i386/kvm.c

  Log Message:
  -----------
  i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and 
HV_CPUID_NESTED_FEATURES.EAX as feature words

It was found that QMP users of QEMU (e.g. libvirt) may need
HV_CPUID_ENLIGHTMENT_INFO.EAX/HV_CPUID_NESTED_FEATURES.EAX information. In
particular, 'hv_tlbflush' and 'hv_evmcs' enlightenments are only exposed in
HV_CPUID_ENLIGHTMENT_INFO.EAX.

HV_CPUID_NESTED_FEATURES.EAX is exposed for two reasons: convenience
(we don't need to export it from hyperv_handle_properties() and as
future-proof for Enlightened MSR-Bitmap, PV EPT invalidation and
direct virtual flush features.

Signed-off-by: Vitaly Kuznetsov <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Roman Kagan <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>


  Commit: 483c6ad426dbab72d912fe4793d7d558671aa727
      
https://github.com/qemu/qemu/commit/483c6ad426dbab72d912fe4793d7d558671aa727
  Author: Borislav Petkov <address@hidden>
  Date:   2019-01-14 (Mon, 14 Jan 2019)

  Changed paths:
    M hw/i386/pc.c
    M qemu-doc.texi
    M target/i386/cpu.c

  Log Message:
  -----------
  target-i386: Reenable RDTSCP support on Opteron_G[345] CPU models CPU models

The missing functionality was added ~3 years ago with the Linux commit

  46896c73c1a4 ("KVM: svm: add support for RDTSCP")

so reenable RDTSCP support on those CPU models.

Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
(the real hardware doesn't have it. K8 got RDTSCP support with the NPT
models, i.e., models >= 0x40).

Document the host's minimum required kernel version, while at it.

Signed-off-by: Borislav Petkov <address@hidden>
Message-ID: <address@hidden>
[ehabkost: moved compat properties code to pc.c]
Signed-off-by: Eduardo Habkost <address@hidden>


  Commit: ecb85fe48cacb2f8740186e81f2f38a2e02bd963
      
https://github.com/qemu/qemu/commit/ecb85fe48cacb2f8740186e81f2f38a2e02bd963
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-01-14 (Mon, 14 Jan 2019)

  Changed paths:
    M hw/i386/pc.c
    M target/i386/cpu.c

  Log Message:
  -----------
  target/i386: Disable MPX support on named CPU models

MPX support is being phased out by Intel; GCC has dropped it, Linux
is also going to do that.  Even though KVM will have special code
to support MPX after the kernel proper stops enabling it in XCR0,
we probably also want to deprecate that in a few years.  As a start,
do not enable it by default for any named CPU model starting with
the 4.0 machine types; this include Skylake, Icelake and Cascadelake.

Signed-off-by: Paolo Bonzini <address@hidden>
Message-Id: <address@hidden>
Reviewed-by:   Wainer dos Santos Moschetta <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>


  Commit: 258fe08bd341d2e230676228307294e41f33002c
      
https://github.com/qemu/qemu/commit/258fe08bd341d2e230676228307294e41f33002c
  Author: Eduardo Habkost <address@hidden>
  Date:   2019-01-14 (Mon, 14 Jan 2019)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  x86: host-phys-bits-limit option

Some downstream distributions of QEMU set host-phys-bits=on by
default.  This worked very well for most use cases, because
phys-bits really didn't have huge consequences. The only
difference was on the CPUID data seen by guests, and on the
handling of reserved bits.

This changed in KVM commit 855feb673640 ("KVM: MMU: Add 5 level
EPT & Shadow page table support").  Now choosing a large
phys-bits value for a VM has bigger impact: it will make KVM use
5-level EPT even when it's not really necessary.  This means
using the host phys-bits value may not be the best choice.

Management software could address this problem by manually
configuring phys-bits depending on the size of the VM and the
amount of MMIO address space required for hotplug.  But this is
not trivial to implement.

However, there's another workaround that would work for most
cases: keep using the host phys-bits value, but only if it's
smaller than 48.  This patch makes this possible by introducing a
new "-cpu" option: "host-phys-bits-limit".  Management software
or users can make sure they will always use 4-level EPT using:
"host-phys-bits=on,host-phys-bits-limit=48".

This behavior is still not enabled by default because QEMU
doesn't enable host-phys-bits=on by default.  But users,
management software, or downstream distributions may choose to
change their defaults using the new option.

Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
[ehabkost: removed test code while some issues are addressed]
Signed-off-by: Eduardo Habkost <address@hidden>


  Commit: abd5fc4c862d033a989552914149f01c9476bb16
      
https://github.com/qemu/qemu/commit/abd5fc4c862d033a989552914149f01c9476bb16
  Author: Vitaly Kuznetsov <address@hidden>
  Date:   2019-01-14 (Mon, 14 Jan 2019)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386/kvm: add a comment explaining why .feat_names are commented out for 
Hyper-V feature bits

Hyper-V .feat_names are, unlike hardware features, commented out and it is
not obvious why we do that. Document the current status quo.

Signed-off-by: Vitaly Kuznetsov <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>


  Commit: 89bd861c2b470e3fb45596945509079c72af3ac2
      
https://github.com/qemu/qemu/commit/89bd861c2b470e3fb45596945509079c72af3ac2
  Author: Peter Maydell <address@hidden>
  Date:   2019-01-14 (Mon, 14 Jan 2019)

  Changed paths:
    M hw/i386/pc.c
    M qemu-doc.texi
    M target/i386/cpu.c
    M target/i386/cpu.h
    M target/i386/kvm.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' 
into staging

x86 queue, 2019-01-14

* Reenable RDTSCP support on Opteron_G[345] CPU models CPU models
  (Borislav Petkov)
* host-phys-bits-limit option for better control of 5-level EPT
  (Eduardo Habkost)
* Disable MPX support on named CPU models (Paolo Bonzini)
* expose HV_CPUID_ENLIGHTMENT_INFO.EAX and HV_CPUID_NESTED_FEATURES.EAX
  as feature words (Vitaly Kuznetsov)

# gpg: Signature made Mon 14 Jan 2019 14:33:55 GMT
# gpg:                using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <address@hidden>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost/tags/x86-next-pull-request:
  i386/kvm: add a comment explaining why .feat_names are commented out for 
Hyper-V feature bits
  x86: host-phys-bits-limit option
  target/i386: Disable MPX support on named CPU models
  target-i386: Reenable RDTSCP support on Opteron_G[345] CPU models CPU models
  i386/kvm: expose HV_CPUID_ENLIGHTMENT_INFO.EAX and 
HV_CPUID_NESTED_FEATURES.EAX as feature words

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/c9d18c1c150c...89bd861c2b47
      **NOTE:** This service has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.