[Qemu-commits] [qemu/qemu] 79a197: target/i386: kvm: Demand nested migration kernel c...

[Peter Maydell]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 79a197ab180e75838523c58973b1221ad7bf51eb
      
https://github.com/qemu/qemu/commit/79a197ab180e75838523c58973b1221ad7bf51eb
  Author: Liran Alon <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

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

  Log Message:
  -----------
  target/i386: kvm: Demand nested migration kernel capabilities only when vCPU 
may have enabled VMX

Previous to this change, a vCPU exposed with VMX running on a kernel
without KVM_CAP_NESTED_STATE or KVM_CAP_EXCEPTION_PAYLOAD resulted in
adding a migration blocker. This was because when the code was written
it was thought there is no way to reliably know if a vCPU is utilising
VMX or not at runtime. However, it turns out that this can be known to
some extent:

In order for a vCPU to enter VMX operation it must have CR4.VMXE set.
Since it was set, CR4.VMXE must remain set as long as the vCPU is in
VMX operation. This is because CR4.VMXE is one of the bits set
in MSR_IA32_VMX_CR4_FIXED1.
There is one exception to the above statement when vCPU enters SMM mode.
When a vCPU enters SMM mode, it temporarily exits VMX operation and
may also reset CR4.VMXE during execution in SMM mode.
When the vCPU exits SMM mode, vCPU state is restored to be in VMX operation
and CR4.VMXE is restored to its original state of being set.
Therefore, when the vCPU is not in SMM mode, we can infer whether
VMX is being used by examining CR4.VMXE. Otherwise, we cannot
know for certain but assume the worse that vCPU may utilise VMX.

Summaring all the above, a vCPU may have enabled VMX in case
CR4.VMXE is set or vCPU is in SMM mode.

Therefore, remove migration blocker and check before migration
(cpu_pre_save()) if the vCPU may have enabled VMX. If true, only then
require relevant kernel capabilities.

While at it, demand KVM_CAP_EXCEPTION_PAYLOAD only when the vCPU is in
guest-mode and there is a pending/injected exception. Otherwise, this
kernel capability is not required for proper migration.

Reviewed-by: Joao Martins <address@hidden>
Signed-off-by: Liran Alon <address@hidden>
Reviewed-by: Maran Wilson <address@hidden>
Tested-by: Maran Wilson <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 1e44f3ab71fb4291d266a264f7c207ae5c6d59b2
      
https://github.com/qemu/qemu/commit/1e44f3ab71fb4291d266a264f7c207ae5c6d59b2
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M target/i386/kvm.c
    M target/i386/machine.c

  Log Message:
  -----------
  target/i386: skip KVM_GET/SET_NESTED_STATE if VMX disabled, or for SVM

Do not allocate env->nested_state unless we later need to migrate the
nested virtualization state.

With this change, nested_state_needed() will return false if the
VMX flag is not included in the virtual machine.  KVM_GET/SET_NESTED_STATE
is also disabled for SVM which is safer (we know that at least the NPT
root and paging mode have to be saved/loaded), and thus the corresponding
subsection can go away as well.

Inspired by a patch from Liran Alon.

Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 12e1dc49395674960efec967ca4161428c08307a
      
https://github.com/qemu/qemu/commit/12e1dc49395674960efec967ca4161428c08307a
  Author: Paolo Bonzini <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M hw/scsi/vhost-scsi.c
    M hw/scsi/vhost-user-scsi.c
    M hw/scsi/virtio-scsi.c
    M include/hw/virtio/virtio-scsi.h

  Log Message:
  -----------
  virtio-scsi: remove unused argument to virtio_scsi_common_realize

The argument is not used and passing it clutters error propagation in the
callers.  So, get rid of it.

Reviewed-by: Stefan Hajnoczi <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 934443c37befc9e268f5c661cb9552a2ee572e19
      
https://github.com/qemu/qemu/commit/934443c37befc9e268f5c661cb9552a2ee572e19
  Author: Xie Yongji <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M hw/scsi/vhost-scsi.c

  Log Message:
  -----------
  vhost-scsi: Call virtio_scsi_common_unrealize() when device realize failed

This avoids memory leak when device hotplug is failed.

Signed-off-by: Xie Yongji <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 68fa7ca015dc8afb86e3aa51b31362f63048bd5c
      
https://github.com/qemu/qemu/commit/68fa7ca015dc8afb86e3aa51b31362f63048bd5c
  Author: Xie Yongji <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M hw/scsi/vhost-user-scsi.c

  Log Message:
  -----------
  vhost-user-scsi: Call virtio_scsi_common_unrealize() when device realize 
failed

This avoids memory leak when device hotplug is failed.

Signed-off-by: Xie Yongji <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 1849f297f5952ea60ddfd39fe02ce21cba6aa4d8
      
https://github.com/qemu/qemu/commit/1849f297f5952ea60ddfd39fe02ce21cba6aa4d8
  Author: Shin'ichiro Kawasaki <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M hw/scsi/scsi-generic.c

  Log Message:
  -----------
  scsi-generic: Check sense key before request snooping and patching

When READ CAPACITY command completes, scsi_read_complete() function
snoops the command result and updates SCSIDevice members blocksize and
max_lba . However, this update is executed even when READ CAPACITY
command indicates an error in sense data. This causes unexpected
blocksize update with zero value for SCSI devices without
READ CAPACITY(10) command support and eventually results in a divide
by zero. An emulated device by TCMU-runner is an example of a device
that doesn't support READ CAPACITY(10) command.

To avoid the unexpected update, add sense key check in
scsi_read_complete() function. The function already checks the sense key
for VPD Block Limits emulation. Do the scsi_parse_sense_buf() call for
all requests rather than just for VPD Block Limits emulation, so that
blocksize and max_lba are only updated if READ CAPACITY returns zero
sense key.

Signed-off-by: Shin'ichiro Kawasaki <address@hidden>
[Extend the check to all requests, not just READ CAPACITY]
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 2f950b1e449818ec69ce70a19270f1a039350c2e
      
https://github.com/qemu/qemu/commit/2f950b1e449818ec69ce70a19270f1a039350c2e
  Author: Wei Yang <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M tests/test-bitmap.c

  Log Message:
  -----------
  test-bitmap: add test for bitmap_set

Add a test for bitmap_set. There are three cases:

  * Both start and end is BITS_PER_LONG aligned
  * Only start is BITS_PER_LONG aligned
  * Only end is BITS_PER_LONG aligned

Signed-off-by: Wei Yang <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Peter Xu <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 8072aae3770aed5ed1274a3d6b83a94672c6181a
      
https://github.com/qemu/qemu/commit/8072aae3770aed5ed1274a3d6b83a94672c6181a
  Author: Alexey Kardashevskiy <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M accel/kvm/kvm-all.c
    M include/sysemu/accel.h
    M memory.c

  Log Message:
  -----------
  hmp: Print if memory section is registered with an accelerator

This adds an accelerator name to the "into mtree -f" to tell the user if
a particular memory section is registered with the accelerator;
the primary user for this is KVM and such information is useful
for debugging purposes.

This adds a has_memory() callback to the accelerator class allowing any
accelerator to have a label in that memory tree dump.

Since memory sections are passed to memory listeners and get registered
in accelerators (rather than memory regions), this only prints new labels
for flatviews attached to the system address space.

An example:
 Root memory region: system
  0000000000000000-0000002fffffffff (prio 0, ram): /objects/mem0 kvm
  0000003000000000-0000005fffffffff (prio 0, ram): /objects/mem1 kvm
  0000200000000020-000020000000003f (prio 1, i/o): virtio-pci
  0000200080000000-000020008000003f (prio 0, i/o): capabilities

Signed-off-by: Alexey Kardashevskiy <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 3bf5de5240525a52a88deb3e864646763157e2ba
      
https://github.com/qemu/qemu/commit/3bf5de5240525a52a88deb3e864646763157e2ba
  Author: Nicholas Piggin <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M vl.c

  Log Message:
  -----------
  qmp: don't emit the RESET event on wakeup

Commit 1405819637f53 ("qmp: don't emit the RESET event on wakeup from
S3") changed system wakeup to avoid calling qapi_event_send_reset.
Commit 76ed4b18debfe ("s390/ipl: fix ipl with -no-reboot") appears to
have inadvertently broken that logic.

Acked-by: Cornelia Huck <address@hidden>
Signed-off-by: Nicholas Piggin <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 21e709aa071d301f154f137bffaaa19fe11e88bb
      
https://github.com/qemu/qemu/commit/21e709aa071d301f154f137bffaaa19fe11e88bb
  Author: Marc-André Lureau <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M configure

  Log Message:
  -----------
  build-sys: do no support modules on Windows

Our module system does not support Windows, because it relies on
resolving symbols from the main executable.

If there is enough interest in supporting modules on Windows, we could
generate an import library for the executable and link with it:
https://stackoverflow.com/questions/15454968/dll-plugin-that-uses-functions-defined-in-the-main-executable

However, there is a small chicken egg problem, since the executable
link and exports extra symbols needed by the library...

Signed-off-by: Marc-André Lureau <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 2924ab02c28ce8d32da144a6ae8bfc5a8d7e072b
      
https://github.com/qemu/qemu/commit/2924ab02c28ce8d32da144a6ae8bfc5a8d7e072b
  Author: Denis V. Lunev <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  i386: indicate that 'pconfig' feature was removed intentionally

pconfig feature was added in 5131dc433df and removed in 712f807e196.
This patch mark this feature as known to QEMU and removed by
intentinally. This follows the convention of 9ccb9784b57 and f1a23522b03
dealing with 'osxsave' and 'ospke'.

Signed-off-by: Denis V. Lunev <address@hidden>
CC: Paolo Bonzini <address@hidden>
CC: Richard Henderson <address@hidden>
CC: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: d4b976c0a81dc625ccd05e2b3075f353170669d4
      
https://github.com/qemu/qemu/commit/d4b976c0a81dc625ccd05e2b3075f353170669d4
  Author: Jiri Slaby <address@hidden>
  Date:   2019-07-19 (Fri, 19 Jul 2019)

  Changed paths:
    M target/i386/sev.c

  Log Message:
  -----------
  target/i386: sev: fix failed message typos

In these multiline messages, there were typos. Fix them -- add a missing
space and remove a superfluous apostrophe.

Inspired by Tom's patch.

Signed-off-by: Jiri Slaby <address@hidden>
Cc: Paolo Bonzini <address@hidden>
Cc: Richard Henderson <address@hidden>
Cc: Eduardo Habkost <address@hidden>
Cc: address@hidden
Cc: Brijesh Singh <address@hidden>
Cc: Tom Lendacky <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Paolo Bonzini <address@hidden>


  Commit: 9d2e1fcd14c2bae5be1992214a03c0ddff714c80
      
https://github.com/qemu/qemu/commit/9d2e1fcd14c2bae5be1992214a03c0ddff714c80
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-22 (Mon, 22 Jul 2019)

  Changed paths:
    M accel/kvm/kvm-all.c
    M configure
    M hw/scsi/scsi-generic.c
    M hw/scsi/vhost-scsi.c
    M hw/scsi/vhost-user-scsi.c
    M hw/scsi/virtio-scsi.c
    M include/hw/virtio/virtio-scsi.h
    M include/sysemu/accel.h
    M memory.c
    M target/i386/cpu.c
    M target/i386/cpu.h
    M target/i386/kvm.c
    M target/i386/kvm_i386.h
    M target/i386/machine.c
    M target/i386/sev.c
    M tests/test-bitmap.c
    M vl.c

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging

Mostly bugfixes, plus a patch to mark accelerator MemoryRegions in "info
mtree" that has been lingering for too long.

# gpg: Signature made Fri 19 Jul 2019 22:45:46 BST
# gpg:                using RSA key F13338574B662389866C7682BFFBD25F78C7AE83
# gpg:                issuer "address@hidden"
# gpg: Good signature from "Paolo Bonzini <address@hidden>" [full]
# gpg:                 aka "Paolo Bonzini <address@hidden>" [full]
# Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4  E2F7 7E15 100C CD36 69B1
#      Subkey fingerprint: F133 3857 4B66 2389 866C  7682 BFFB D25F 78C7 AE83

* remotes/bonzini/tags/for-upstream:
  target/i386: sev: fix failed message typos
  i386: indicate that 'pconfig' feature was removed intentionally
  build-sys: do no support modules on Windows
  qmp: don't emit the RESET event on wakeup
  hmp: Print if memory section is registered with an accelerator
  test-bitmap: add test for bitmap_set
  scsi-generic: Check sense key before request snooping and patching
  vhost-user-scsi: Call virtio_scsi_common_unrealize() when device realize 
failed
  vhost-scsi: Call virtio_scsi_common_unrealize() when device realize failed
  virtio-scsi: remove unused argument to virtio_scsi_common_realize
  target/i386: skip KVM_GET/SET_NESTED_STATE if VMX disabled, or for SVM
  target/i386: kvm: Demand nested migration kernel capabilities only when vCPU 
may have enabled VMX

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


Compare: https://github.com/qemu/qemu/compare/b9e02bb3f981...9d2e1fcd14c2