bwlp/qemu.git/accel/kvm, branch spice_video_codecs

i386: add notify VM exit support

2022-10-11T07:36:00+00:00

There are cases that malicious virtual machine can cause CPU stuck (due to event windows don't open up), e.g., infinite loop in microcode when nested #AC (CVE-2015-5307). No event window means no event (NMI, SMI and IRQ) can be delivered. It leads the CPU to be unavailable to host or other VMs. Notify VM exit is introduced to mitigate such kind of attacks, which will generate a VM exit if no event window occurs in VM non-root mode for a specified amount of time (notify window). A new KVM capability KVM_CAP_X86_NOTIFY_VMEXIT is exposed to user space so that the user can query the capability and set the expected notify window when creating VMs. The format of the argument when enabling this capability is as follows: Bit 63:32 - notify window specified in qemu command Bit 31:0 - some flags (e.g. KVM_X86_NOTIFY_VMEXIT_ENABLED is set to enable the feature.) Users can configure the feature by a new (x86 only) accel property: qemu -accel kvm,notify-vmexit=run|internal-error|disable,notify-window=n The default option of notify-vmexit is run, which will enable the capability and do nothing if the exit happens. The internal-error option raises a KVM internal error if it happens. The disable option does not enable the capability. The default value of notify-window is 0. It is valid only when notify-vmexit is not disabled. The valid range of notify-window is non-negative. It is even safe to set it to zero since there's an internal hardware threshold to be added to ensure no false positive. Because a notify VM exit may happen with VM_CONTEXT_INVALID set in exit qualification (no cases are anticipated that would set this bit), which means VM context is corrupted. It would be reflected in the flags of KVM_EXIT_NOTIFY exit. If KVM_NOTIFY_CONTEXT_INVALID bit is set, raise a KVM internal error unconditionally. Acked-by: Peter Xu Signed-off-by: Chenyi Qiang Message-Id: <20220929072014.20705-5-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini

kvm: expose struct KVMState

2022-10-11T07:36:00+00:00

Expose struct KVMState out of kvm-all.c so that the field of struct KVMState can be accessed when defining target-specific accelerator properties. Signed-off-by: Chenyi Qiang Message-Id: <20220929072014.20705-4-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini

kvm: allow target-specific accelerator properties

2022-10-10T07:23:16+00:00

Several hypervisor capabilities in KVM are target-specific. When exposed to QEMU users as accelerator properties (i.e. -accel kvm,prop=value), they should not be available for all targets. Add a hook for targets to add their own properties to -accel kvm, for now no such property is defined. Signed-off-by: Paolo Bonzini Message-Id: <20220929072014.20705-3-chenyi.qiang@intel.com> Signed-off-by: Paolo Bonzini

accel/kvm: move kvm_update_guest_debug to inline stub

2022-10-06T10:53:41+00:00

Signed-off-by: Alex Bennée Message-Id: <20220929114231.583801-47-alex.bennee@linaro.org>

gdbstub: move guest debug support check to ops

2022-10-06T10:53:41+00:00

This removes the final hard coding of kvm_enabled() in gdbstub and moves the check to an AccelOps. Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Alex Bennée Reviewed-by: Mads Ynddal Message-Id: <20220929114231.583801-46-alex.bennee@linaro.org>

gdbstub: move breakpoint logic to accel ops

2022-10-06T10:53:41+00:00

As HW virtualization requires specific support to handle breakpoints lets push out special casing out of the core gdbstub code and into AccelOpsClass. This will make it easier to add other accelerator support and reduces some of the stub shenanigans. Reviewed-by: Richard Henderson Signed-off-by: Alex Bennée Reviewed-by: Mads Ynddal Message-Id: <20220929114231.583801-45-alex.bennee@linaro.org>

gdbstub: move sstep flags probing into AccelClass

2022-10-06T10:53:41+00:00

The support of single-stepping is very much dependent on support from the accelerator we are using. To avoid special casing in gdbstub move the probing out to an AccelClass function so future accelerators can put their code there. Reviewed-by: Richard Henderson Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Alex Bennée Reviewed-by: Mads Ynddal Message-Id: <20220929114231.583801-44-alex.bennee@linaro.org>

kvm: fix memory leak on failure to read stats descriptors

2022-09-18T07:17:40+00:00

Reported by Coverity as CID 1490142. Since the size is constant and the lifetime is the same as the StatsDescriptors struct, embed the struct directly instead of using a separate allocation. Suggested-by: Richard Henderson Signed-off-by: Paolo Bonzini

KVM: use store-release to mark dirty pages as harvested

2022-09-18T07:17:40+00:00

The following scenario can happen if QEMU sets more RESET flags while the KVM_RESET_DIRTY_RINGS ioctl is ongoing on another host CPU: CPU0 CPU1 CPU2 ------------------------ ------------------ ------------------------ fill gfn0 store-rel flags for gfn0 fill gfn1 store-rel flags for gfn1 load-acq flags for gfn0 set RESET for gfn0 load-acq flags for gfn1 set RESET for gfn1 do ioctl! -----------> ioctl(RESET_RINGS) fill gfn2 store-rel flags for gfn2 load-acq flags for gfn2 set RESET for gfn2 process gfn0 process gfn1 process gfn2 do ioctl! etc. The three load-acquire in CPU0 synchronize with the three store-release in CPU2, but CPU0 and CPU1 are only synchronized up to gfn1 and CPU1 may miss gfn2's fields other than flags. The kernel must be able to cope with invalid values of the fields, and userspace *will* invoke the ioctl once more. However, once the RESET flag is cleared on gfn2, it is lost forever, therefore in the above scenario CPU1 must read the correct value of gfn2's fields. Therefore RESET must be set with a store-release, that will synchronize with KVM's load-acquire in CPU1. Cc: Gavin Shan Reviewed-by: Peter Xu Reviewed-by: Philippe Mathieu-Daudé Signed-off-by: Paolo Bonzini

KVM: dirty ring: add missing memory barrier

2022-09-01T06:37:04+00:00

The KVM_DIRTY_GFN_F_DIRTY flag ensures that the entry is valid. If the read of the fields are not ordered after the read of the flag, QEMU might see stale values. Cc: Gavin Shan Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Peter Xu Signed-off-by: Paolo Bonzini