Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: e346bcbf448543829cda7e58b9183343b1f7d0e2
https://github.com/qemu/qemu/commit/e346bcbf448543829cda7e58b9183343b1f7d0e2
Author: Yury Kotov <yury-ko...@yandex-team.ru>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M accel/kvm/kvm-all.c
Log Message:
-----------
kvm-all: Add/update fprintf's for kvm_*_ioeventfd_del
Signed-off-by: Yury Kotov <yury-ko...@yandex-team.ru>
Message-Id: <20190607090830.18807-1-yury-ko...@yandex-team.ru>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 6f38dca615286796df9a967117f3ce42b918c8db
https://github.com/qemu/qemu/commit/6f38dca615286796df9a967117f3ce42b918c8db
Author: Colin Xu <colin...@intel.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M cpus.c
M target/i386/hax-all.c
Log Message:
-----------
hax: Honor CPUState::halted
QEMU tracks whether a vcpu is halted using CPUState::halted. E.g.,
after initialization or reset, halted is 0 for the BSP (vcpu 0)
and 1 for the APs (vcpu 1, 2, ...). A halted vcpu should not be
handed to the hypervisor to run (e.g. hax_vcpu_run()).
Under HAXM, Android Emulator sometimes boots into a "vcpu shutdown
request" error while executing in SeaBIOS, with the HAXM driver
logging a guest triple fault in vcpu 1, 2, ... at RIP 0x3. That is
ultimately because the HAX accelerator asks HAXM to run those APs
when they are still in the halted state.
Normally, the vcpu thread for an AP will start by looping in
qemu_wait_io_event(), until the BSP kicks it via a pair of IPIs
(INIT followed by SIPI). But because the HAX accelerator does not
honor cpu->halted, it allows the AP vcpu thread to proceed to
hax_vcpu_run() as soon as it receives any kick, even if the kick
does not come from the BSP. It turns out that emulator has a
worker thread which periodically kicks every vcpu thread (possibly
to collect CPU usage data), and if one of these kicks comes before
those by the BSP, the AP will start execution from the wrong RIP,
resulting in the aforementioned SMP boot failure.
The solution is inspired by the KVM accelerator (credit to
Chuanxiao Dong <chuanxiao.d...@intel.com> for the pointer):
1. Get rid of questionable logic that unconditionally resets
cpu->halted before hax_vcpu_run(). Instead, only reset it at the
right moments (there are only a few "unhalt" events).
2. Add a check for cpu->halted before hax_vcpu_run().
Note that although the non-Unrestricted Guest (!ug_platform) code
path also forcibly resets cpu->halted, it is left untouched,
because only the UG code path supports SMP guests.
The patch is first merged to android emulator with Change-Id:
I9c5752cc737fd305d7eace1768ea12a07309d716
Cc: Yu Ning <yu.n...@intel.com>
Cc: Chuanxiao Dong <chuanxiao.d...@intel.com>
Signed-off-by: Colin Xu <colin...@intel.com>
Message-Id: <20190610021939.13669-1-colin...@intel.com>
Commit: 2d384d7c836142a1ce851442bd6fb8e03a72663a
https://github.com/qemu/qemu/commit/2d384d7c836142a1ce851442bd6fb8e03a72663a
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M hw/i386/pc.c
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/hyperv.c
M target/i386/kvm.c
M target/i386/machine.c
Log Message:
-----------
i386/kvm: convert hyperv enlightenments properties from bools to bits
Representing Hyper-V properties as bits will allow us to check features
and dependencies between them in a natural way.
Suggested-by: Roman Kagan <rka...@virtuozzo.com>
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-2-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 6760bd20027188092a0618c96f4da17a073c19d3
https://github.com/qemu/qemu/commit/6760bd20027188092a0618c96f4da17a073c19d3
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID
KVM now supports reporting supported Hyper-V features through CPUID
(KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be
the only way to announce new functionality and this has already happened
with Direct Mode stimers.
While we could just support KVM_GET_SUPPORTED_HV_CPUID for new features,
it seems to be beneficial to use it for all Hyper-V enlightenments when
possible. This way we can implement 'hv-all' pass-through mode giving the
guest all supported Hyper-V features even when QEMU knows nothing about
them.
Implementation-wise we create a new kvm_hyperv_properties structure
defining Hyper-V features, get_supported_hv_cpuid()/
get_supported_hv_cpuid_legacy() returning the supported CPUID set and
a bit over-engineered hv_cpuid_check_and_set() which we will also be
used to set cpu->hyperv_* properties for 'hv-all' mode.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-3-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 2344d22e502ddf8ace994f7241e72a2126986c45
https://github.com/qemu/qemu/commit/2344d22e502ddf8ace994f7241e72a2126986c45
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: move Hyper-V CPUID filling to hyperv_handle_properties()
Let's consolidate Hyper-V features handling in hyperv_handle_properties().
The change is necessary to support 'hv-passthrough' mode as we'll be just
copying CPUIDs from KVM instead of filling them in.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-4-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: fb19f72b774ce47cd26955ad61547bc3f7f02626
https://github.com/qemu/qemu/commit/fb19f72b774ce47cd26955ad61547bc3f7f02626
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
A docs/hyperv.txt
Log Message:
-----------
i386/kvm: document existing Hyper-V enlightenments
Currently, there is no doc describing hv-* CPU flags, people are
encouraged to get the information from Microsoft Hyper-V Top Level
Functional specification (TLFS). There is, however, a bit of QEMU
specifics.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-5-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: e48ddcc6ce13323087133f5922f8eb2fe516817b
https://github.com/qemu/qemu/commit/e48ddcc6ce13323087133f5922f8eb2fe516817b
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M docs/hyperv.txt
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: implement 'hv-passthrough' mode
In many case we just want to give Windows guests all currently supported
Hyper-V enlightenments and that's where this new mode may come handy. We
pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID.
hv_cpuid_check_and_set() is modified to also set cpu->hyperv_* flags as
we may want to check them later (and we actually do for hv_runtime,
hv_synic,...).
'hv-passthrough' is a development only feature, a migration blocker is
added to prevent issues while migrating between hosts with different
feature sets.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-6-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: c686193072a47032d83cb4e131dc49ae30f9e5d7
https://github.com/qemu/qemu/commit/c686193072a47032d83cb4e131dc49ae30f9e5d7
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: hv-stimer requires hv-time and hv-synic
Synthetic timers operate in hv-time time and Windows won't use these
without SynIC.
Add .dependencies field to kvm_hyperv_properties[] and a generic mechanism
to check dependencies between features.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-7-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: bd59fbdf4f4a5d91a5e85a2bae4655cc71d59987
https://github.com/qemu/qemu/commit/bd59fbdf4f4a5d91a5e85a2bae4655cc71d59987
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: hv-tlbflush/ipi require hv-vpindex
The corresponding hypercalls require using VP indexes.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-8-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 8caba36db5d70beb5353b5b5d28421b67275bcf0
https://github.com/qemu/qemu/commit/8caba36db5d70beb5353b5b5d28421b67275bcf0
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: hv-evmcs requires hv-vapic
Enlightened VMCS is enabled by writing to a field in VP assist page and
these require virtual APIC.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-9-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 128531d9e10908a08761ed1ce10e607985d172d7
https://github.com/qemu/qemu/commit/128531d9e10908a08761ed1ce10e607985d172d7
Author: Vitaly Kuznetsov <vkuzn...@redhat.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M docs/hyperv.txt
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/hyperv-proto.h
M target/i386/kvm.c
Log Message:
-----------
i386/kvm: add support for Direct Mode for Hyper-V synthetic timers
Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for
an interrupt instead of VMBus message). This new capability is only
announced in KVM_GET_SUPPORTED_HV_CPUID.
Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com>
Message-Id: <20190517141924.19024-10-vkuzn...@redhat.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 597360c0d8ebda9ca6f239db724a25bddec62b2f
https://github.com/qemu/qemu/commit/597360c0d8ebda9ca6f239db724a25bddec62b2f
Author: Xiaoyao Li <xiaoyao...@linux.intel.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/kvm.c
Log Message:
-----------
target/i386: define a new MSR based feature word - FEAT_CORE_CAPABILITY
MSR IA32_CORE_CAPABILITY is a feature-enumerating MSR, which only
enumerates the feature split lock detection (via bit 5) by now.
The existence of MSR IA32_CORE_CAPABILITY is enumerated by CPUID.7_0:EDX[30].
The latest kernel patches about them can be found here:
https://lkml.org/lkml/2019/4/24/1909
Signed-off-by: Xiaoyao Li <xiaoyao...@linux.intel.com>
Message-Id: <20190617153654.916-1-xiaoyao...@linux.intel.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 6b2341eeea43c00b8e266026cec84d57af1484dc
https://github.com/qemu/qemu/commit/6b2341eeea43c00b8e266026cec84d57af1484dc
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
target/i386: kvm: Delete VMX migration blocker on vCPU init failure
Commit d98f26073beb ("target/i386: kvm: add VMX migration blocker")
added migration blocker for vCPU exposed with Intel VMX because QEMU
doesn't yet contain code to support migration of nested virtualization
workloads.
However, that commit missed adding deletion of the migration blocker in
case init of vCPU failed. Similar to invtsc_mig_blocker. This commit fix
that issue.
Fixes: d98f26073beb ("target/i386: kvm: add VMX migration blocker")
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Message-Id: <20190619162140.133674-2-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: b1115c99919cf158bb859865f14c3198a0e6f679
https://github.com/qemu/qemu/commit/b1115c99919cf158bb859865f14c3198a0e6f679
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M accel/kvm/kvm-all.c
M include/sysemu/kvm.h
M target/arm/kvm32.c
M target/arm/kvm64.c
M target/i386/kvm.c
M target/mips/kvm.c
M target/ppc/kvm.c
M target/s390x/kvm.c
Log Message:
-----------
KVM: Introduce kvm_arch_destroy_vcpu()
Simiar to how kvm_init_vcpu() calls kvm_arch_init_vcpu() to perform
arch-dependent initialisation, introduce kvm_arch_destroy_vcpu()
to be called from kvm_destroy_vcpu() to perform arch-dependent
destruction.
This was added because some architectures (Such as i386)
currently do not free memory that it have allocated in
kvm_arch_init_vcpu().
Suggested-by: Maran Wilson <maran.wil...@oracle.com>
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Message-Id: <20190619162140.133674-3-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 37936ac70f6c20aec6f537349eb797fb98f9a99d
https://github.com/qemu/qemu/commit/37936ac70f6c20aec6f537349eb797fb98f9a99d
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
target/i386: kvm: Use symbolic constant for #DB/#BP exception constants
Reviewed-by: Nikita Leshenko <nikita.leshche...@oracle.com>
Reviewed-by: Krish Sadhukhan <krish.sadhuk...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Message-Id: <20190619162140.133674-4-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: bceeeef9e7544057659118688243260c390eceb9
https://github.com/qemu/qemu/commit/bceeeef9e7544057659118688243260c390eceb9
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
Log Message:
-----------
target/i386: kvm: Re-inject #DB to guest with updated DR6
If userspace (QEMU) debug guest, when #DB is raised in guest and
intercepted by KVM, KVM forwards information on #DB to userspace
instead of injecting #DB to guest.
While doing so, KVM don't update vCPU DR6 but instead report the #DB DR6
value to userspace for further handling.
See KVM's handle_exception() DB_VECTOR handler.
QEMU handler for this case is kvm_handle_debug(). This handler basically
checks if #DB is related to one of user set hardware breakpoints and if
not, it re-inject #DB into guest.
The re-injection is done by setting env->exception_injected to #DB which
will later be passed as events.exception.nr to KVM_SET_VCPU_EVENTS ioctl
by kvm_put_vcpu_events().
However, in case userspace re-injects #DB, KVM expects userspace to set
vCPU DR6 as reported to userspace when #DB was intercepted! Otherwise,
KVM_REQ_EVENT handler will inject #DB with wrong DR6 to guest.
Fix this issue by updating vCPU DR6 appropriately when re-inject #DB to
guest.
Reviewed-by: Nikita Leshenko <nikita.leshche...@oracle.com>
Reviewed-by: Krish Sadhukhan <krish.sadhuk...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Message-Id: <20190619162140.133674-5-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 18ab37ba1cee290923240744288dbee8be9355fb
https://github.com/qemu/qemu/commit/18ab37ba1cee290923240744288dbee8be9355fb
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/kvm.c
Log Message:
-----------
target/i386: kvm: Block migration for vCPUs exposed with nested virtualization
Commit d98f26073beb ("target/i386: kvm: add VMX migration blocker")
added a migration blocker for vCPU exposed with Intel VMX.
However, migration should also be blocked for vCPU exposed with
AMD SVM.
Both cases should be blocked because QEMU should extract additional
vCPU state from KVM that should be migrated as part of vCPU VMState.
E.g. Whether vCPU is running in guest-mode or host-mode.
Fixes: d98f26073beb ("target/i386: kvm: add VMX migration blocker")
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Message-Id: <20190619162140.133674-6-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 1d33bea4d013104f01d1c4badc4c670e55c16cca
https://github.com/qemu/qemu/commit/1d33bea4d013104f01d1c4badc4c670e55c16cca
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M linux-headers/asm-x86/kvm.h
Log Message:
-----------
linux-headers: sync with latest KVM headers from Linux 5.2
Improve the KVM_{GET,SET}_NESTED_STATE structs by detailing the format
of VMX nested state data in a struct.
In order to avoid changing the ioctl values of
KVM_{GET,SET}_NESTED_STATE, there is a need to preserve
sizeof(struct kvm_nested_state). This is done by defining the data
struct as "data.vmx[0]". It was the most elegant way I found to
preserve struct size while still keeping struct readable and easy to
maintain. It does have a misfortunate side-effect that now it has to be
accessed as "data.vmx[0]" rather than just "data.vmx".
Because we are already modifying these structs, I also modified the
following:
* Define the "format" field values as macros.
* Rename vmcs_pa to vmcs12_pa for better readability.
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Message-Id: <20190619162140.133674-7-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 6cfd7639329062797c04ec79adb1023a8ba2fcb4
https://github.com/qemu/qemu/commit/6cfd7639329062797c04ec79adb1023a8ba2fcb4
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M include/migration/vmstate.h
Log Message:
-----------
vmstate: Add support for kernel integer types
Reviewed-by: Nikita Leshenko <nikita.leshche...@oracle.com>
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Message-Id: <20190619162140.133674-8-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: ebbfef2f34cfc749c045a4569dedb4f748ec024a
https://github.com/qemu/qemu/commit/ebbfef2f34cfc749c045a4569dedb4f748ec024a
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M accel/kvm/kvm-all.c
M include/sysemu/kvm.h
M target/i386/cpu.h
M target/i386/kvm.c
M target/i386/machine.c
Log Message:
-----------
target/i386: kvm: Add support for save and restore nested state
Kernel commit 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
introduced new IOCTLs to extract and restore vCPU state related to
Intel VMX & AMD SVM.
Utilize these IOCTLs to add support for migration of VMs which are
running nested hypervisors.
Reviewed-by: Nikita Leshenko <nikita.leshche...@oracle.com>
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Tested-by: Maran Wilson <maran.wil...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Message-Id: <20190619162140.133674-9-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: fd13f23b8c95311eff74426921557eee592b0ed3
https://github.com/qemu/qemu/commit/fd13f23b8c95311eff74426921557eee592b0ed3
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/hvf/hvf.c
M target/i386/hvf/x86hvf.c
M target/i386/kvm.c
M target/i386/machine.c
Log Message:
-----------
target/i386: kvm: Add support for KVM_CAP_EXCEPTION_PAYLOAD
Kernel commit c4f55198c7c2 ("kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD")
introduced a new KVM capability which allows userspace to correctly
distinguish between pending and injected exceptions.
This distinguish is important in case of nested virtualization scenarios
because a L2 pending exception can still be intercepted by the L1 hypervisor
while a L2 injected exception cannot.
Furthermore, when an exception is attempted to be injected by QEMU,
QEMU should specify the exception payload (CR2 in case of #PF or
DR6 in case of #DB) instead of having the payload already delivered in
the respective vCPU register. Because in case exception is injected to
L2 guest and is intercepted by L1 hypervisor, then payload needs to be
reported to L1 intercept (VMExit handler) while still preserving
respective vCPU register unchanged.
This commit adds support for QEMU to properly utilise this new KVM
capability (KVM_CAP_EXCEPTION_PAYLOAD).
Reviewed-by: Nikita Leshenko <nikita.leshche...@oracle.com>
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Message-Id: <20190619162140.133674-10-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 12604092e26cdace44c901bc429e7e4c7c3e0cab
https://github.com/qemu/qemu/commit/12604092e26cdace44c901bc429e7e4c7c3e0cab
Author: Liran Alon <liran.a...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M target/i386/kvm.c
M target/i386/machine.c
Log Message:
-----------
target/i386: kvm: Add nested migration blocker only when kernel lacks
required capabilities
Previous commits have added support for migration of nested virtualization
workloads. This was done by utilising two new KVM capabilities:
KVM_CAP_NESTED_STATE and KVM_CAP_EXCEPTION_PAYLOAD. Both which are
required in order to correctly migrate such workloads.
Therefore, change code to add a migration blocker for vCPUs exposed with
Intel VMX or AMD SVM in case one of these kernel capabilities is
missing.
Signed-off-by: Liran Alon <liran.a...@oracle.com>
Reviewed-by: Maran Wilson <maran.wil...@oracle.com>
Message-Id: <20190619162140.133674-11-liran.a...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 1c598ab2b88571d8c75cfebbef09d4c1c675132c
https://github.com/qemu/qemu/commit/1c598ab2b88571d8c75cfebbef09d4c1c675132c
Author: Lidong Chen <lidong.c...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
sd: Fix out-of-bounds assertions
Due to an off-by-one error, the assert statements allow an
out-of-bound array access. This doesn't happen in practice,
but the static analyzer notices.
Signed-off-by: Lidong Chen <lidong.c...@oracle.com>
Reviewed-by: Liam Merwick <liam.merw...@oracle.com>
Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
Reviewed-by: Li Qiang <liq...@gmail.com>
Reviewed-by: Darren Kenny <darren.ke...@oracle.com>
Message-Id:
<6b19cb7359a10a6bedc3ea0fce22fed3ef93c102.1560806687.git.lidong.c...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 6512e34b0a500320da253c2397d4656b1bf84768
https://github.com/qemu/qemu/commit/6512e34b0a500320da253c2397d4656b1bf84768
Author: Lidong Chen <lidong.c...@oracle.com>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M util/main-loop.c
Log Message:
-----------
util/main-loop: Fix incorrect assertion
The check for poll_fds in g_assert() was incorrect. The correct assertion
should check "n_poll_fds + w->num <= ARRAY_SIZE(poll_fds)" because the
subsequent for-loop is doing access to poll_fds[n_poll_fds + i] where i
is in [0, w->num). This could happen with a very high number of file
descriptors and/or wait objects.
Signed-off-by: Lidong Chen <lidong.c...@oracle.com>
Suggested-by: Peter Maydell <peter.mayd...@linaro.org>
Suggested-by: Liam Merwick <liam.merw...@oracle.com>
Reviewed-by: Liran Alon <liran.a...@oracle.com>
Reviewed-by: Darren Kenny <darren.ke...@oracle.com>
Reviewed-by: Li Qiang <liq...@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com>
Message-Id:
<ded30967982811617ce7f0222d11228130c198b7.1560806687.git.lidong.c...@oracle.com>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 8e8cbed09ad9d577955691b4c061b61b602406d1
https://github.com/qemu/qemu/commit/8e8cbed09ad9d577955691b4c061b61b602406d1
Author: Greg Kurz <gr...@kaod.org>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M hw/core/machine.c
M hw/i386/pc.c
M hw/i386/pc_q35.c
M include/hw/boards.h
M include/hw/i386/pc.h
Log Message:
-----------
hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1
Commit c87759ce876a fixed a regression affecting pc-q35 machines by
introducing a new pc-q35-4.0.1 machine version to be used instead
of pc-q35-4.0. The only purpose was to revert the default behaviour
of not using split irqchip, but the change also introduced the usual
hw_compat and pc_compat bits, and wired them for pc-q35 only.
This raises questions when it comes to add new compat properties for
4.0* machine versions of any architecture. Where to add them ? In
4.0, 4.0.1 or both ? Error prone. Another possibility would be to teach
all other architectures about 4.0.1. This solution isn't satisfying,
especially since this is a pc-q35 specific issue.
It turns out that the split irqchip default is handled in the machine
option function and doesn't involve compat lists at all.
Drop all the 4.0.1 compat lists and use the 4.0 ones instead in the 4.0.1
machine option function.
Move the compat props that were added to the 4.0.1 since c87759ce876a to
4.0.
Even if only hw_compat_4_0_1 had an impact on other architectures,
drop pc_compat_4_0_1 as well for consistency.
Fixes: c87759ce876a "q35: Revert to kernel irqchip"
Suggested-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Signed-off-by: Greg Kurz <gr...@kaod.org>
Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Message-Id: <156051774276.244890.8660277280145466396.st...@bahia.lan>
Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
Commit: 68d7ff0cff0c4905802104843cf0100543b47314
https://github.com/qemu/qemu/commit/68d7ff0cff0c4905802104843cf0100543b47314
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2019-06-21 (Fri, 21 Jun 2019)
Changed paths:
M accel/kvm/kvm-all.c
M cpus.c
A docs/hyperv.txt
M hw/core/machine.c
M hw/i386/pc.c
M hw/i386/pc_q35.c
M hw/sd/sd.c
M include/hw/boards.h
M include/hw/i386/pc.h
M include/migration/vmstate.h
M include/sysemu/kvm.h
M linux-headers/asm-x86/kvm.h
M target/arm/kvm32.c
M target/arm/kvm64.c
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/hax-all.c
M target/i386/hvf/hvf.c
M target/i386/hvf/x86hvf.c
M target/i386/hyperv-proto.h
M target/i386/hyperv.c
M target/i386/kvm.c
M target/i386/machine.c
M target/mips/kvm.c
M target/ppc/kvm.c
M target/s390x/kvm.c
M util/main-loop.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging
* Nuke hw_compat_4_0_1 and pc_compat_4_0_1 (Greg)
* Static analysis fixes (Igor, Lidong)
* X86 Hyper-V CPUID improvements (Vitaly)
* X86 nested virt migration (Liran)
* New MSR-based features (Xiaoyao)
# gpg: Signature made Fri 21 Jun 2019 12:25:42 BST
# gpg: using RSA key BFFBD25F78C7AE83
# gpg: Good signature from "Paolo Bonzini <bonz...@gnu.org>" [full]
# gpg: aka "Paolo Bonzini <pbonz...@redhat.com>" [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: (25 commits)
hw: Nuke hw_compat_4_0_1 and pc_compat_4_0_1
util/main-loop: Fix incorrect assertion
sd: Fix out-of-bounds assertions
target/i386: kvm: Add nested migration blocker only when kernel lacks
required capabilities
target/i386: kvm: Add support for KVM_CAP_EXCEPTION_PAYLOAD
target/i386: kvm: Add support for save and restore nested state
vmstate: Add support for kernel integer types
linux-headers: sync with latest KVM headers from Linux 5.2
target/i386: kvm: Block migration for vCPUs exposed with nested virtualization
target/i386: kvm: Re-inject #DB to guest with updated DR6
target/i386: kvm: Use symbolic constant for #DB/#BP exception constants
KVM: Introduce kvm_arch_destroy_vcpu()
target/i386: kvm: Delete VMX migration blocker on vCPU init failure
target/i386: define a new MSR based feature word - FEAT_CORE_CAPABILITY
i386/kvm: add support for Direct Mode for Hyper-V synthetic timers
i386/kvm: hv-evmcs requires hv-vapic
i386/kvm: hv-tlbflush/ipi require hv-vpindex
i386/kvm: hv-stimer requires hv-time and hv-synic
i386/kvm: implement 'hv-passthrough' mode
i386/kvm: document existing Hyper-V enlightenments
...
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Compare: https://github.com/qemu/qemu/compare/33d609990621...68d7ff0cff0c
