search for: waiting_for_reply

...+ return ivcpu->reply_waiting; > +} > + Do you actually need this function? It seems to me that everywhere you call it you already have an ivcpu, so you can just access the field. Also, "reply_waiting" means "there is a reply that is waiting". What you mean is "waiting_for_reply". The overall structure of the jobs code is confusing. The same function kvm_run_jobs_and_wait is an infinite loop before and gets a "break" later. It is also not clear why kvmi_job_wait is called through a job. Can you have instead just kvm_run_jobs in KVM_REQ_INTROSPECTION, and...

...+struct kvmi_vcpu_reply { + int error; + int action; + u32 seq; + void *data; + size_t size; +}; + struct kvmi_job { struct list_head link; void *ctx; @@ -25,6 +33,9 @@ struct kvm_vcpu_introspection { spinlock_t job_lock; atomic_t pause_requests; + + struct kvmi_vcpu_reply reply; + bool waiting_for_reply; }; struct kvm_introspection { diff --git a/include/uapi/linux/kvmi.h b/include/uapi/linux/kvmi.h index 54a788c1c204..2eb1e5b20d53 100644 --- a/include/uapi/linux/kvmi.h +++ b/include/uapi/linux/kvmi.h @@ -15,6 +15,7 @@ enum { }; enum { + KVMI_EVENT_REPLY = 0, KVMI_EVENT...

...for consistency with the vCPU events. diff --git a/include/linux/kvmi_host.h b/include/linux/kvmi_host.h index 49e68777a390..da621d83cd94 100644 --- a/include/linux/kvmi_host.h +++ b/include/linux/kvmi_host.h @@ -36,6 +36,8 @@ struct kvm_vcpu_introspection { struct kvmi_vcpu_reply reply; bool waiting_for_reply; + + DECLARE_BITMAP(ev_mask, KVMI_NUM_EVENTS); }; struct kvm_introspection { diff --git a/include/uapi/linux/kvmi.h b/include/uapi/linux/kvmi.h index 2eb1e5b20d53..745503fb7378 100644 --- a/include/uapi/linux/kvmi.h +++ b/include/uapi/linux/kvmi.h @@ -18,16 +18,17 @@ enum { KVMI_EVENT_REPLY...

...vmi.c b/virt/kvm/introspection/kvmi.c index 10d59061fa82..b798eeab6618 100644 --- a/virt/kvm/introspection/kvmi.c +++ b/virt/kvm/introspection/kvmi.c @@ -361,6 +361,9 @@ static void kvmi_job_release_vcpu(struct kvm_vcpu *vcpu, void *ctx) atomic_set(&vcpui->pause_requests, 0); vcpui->waiting_for_reply = false; + + if (vcpui->singlestep.loop) + kvmi_arch_stop_singlestep(vcpu); } static void kvmi_release_vcpus(struct kvm *kvm) @@ -1003,6 +1006,9 @@ bool kvmi_enter_guest(struct kvm_vcpu *vcpu) if (!kvmi) return true; + if (VCPUI(vcpu)->singlestep.loop) + kvmi_arch_start_singleste...

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VMs (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VMs (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place

The KVM introspection subsystem provides a facility for applications running on the host or in a separate VM, to control the execution of other VM-s (pause, resume, shutdown), query the state of the vCPUs (GPRs, MSRs etc.), alter the page access bits in the shadow page tables (only for the hardware backed ones, eg. Intel's EPT) and receive notifications when events of interest have taken place