On Mon, 12 Aug 2019 13:50:39 -0700, Sean Christopherson
<[email protected]> wrote:
> On Fri, Aug 09, 2019 at 07:00:19PM +0300, Adalbert Lazăr wrote:
> > From: Nicușor Cîțu <[email protected]>
> >
> > This would be used either if the introspection tool request it as a
> > reply to a KVMI_EVENT_PF event or to cope with instructions that cannot
> > be handled by the x86 emulator during the handling of a VMEXIT. In
> > these situations, all other vCPU-s are kicked and held, the EPT-based
> > protection is removed and the guest is single stepped by the vCPU that
> > triggered the initial VMEXIT. Upon completion the EPT-base protection
> > is reinstalled and all vCPU-s all allowed to return to the guest.
> >
> > This is a rather slow workaround that kicks in occasionally. In the
> > future, the most frequently single-stepped instructions should be added
> > to the emulator (usually, stores to and from memory - SSE/AVX).
> >
> > For the moment it works only on Intel.
> >
> > CC: Jim Mattson <[email protected]>
> > CC: Sean Christopherson <[email protected]>
> > CC: Joerg Roedel <[email protected]>
> > Signed-off-by: Nicușor Cîțu <[email protected]>
> > Co-developed-by: Mihai Donțu <[email protected]>
> > Signed-off-by: Mihai Donțu <[email protected]>
> > Co-developed-by: Adalbert Lazăr <[email protected]>
> > Signed-off-by: Adalbert Lazăr <[email protected]>
> > ---
> > arch/x86/include/asm/kvm_host.h | 3 +
> > arch/x86/kvm/kvmi.c | 47 ++++++++++-
> > arch/x86/kvm/svm.c | 5 ++
> > arch/x86/kvm/vmx/vmx.c | 17 ++++
> > arch/x86/kvm/x86.c | 19 +++++
> > include/linux/kvmi.h | 4 +
> > virt/kvm/kvmi.c | 145 +++++++++++++++++++++++++++++++-
> > virt/kvm/kvmi_int.h | 16 ++++
> > 8 files changed, 253 insertions(+), 3 deletions(-)
> >
[...] We'll do.
> > diff --git a/virt/kvm/kvmi_int.h b/virt/kvm/kvmi_int.h
> > index d7f9858d3e97..1550fe33ed48 100644
> > --- a/virt/kvm/kvmi_int.h
> > +++ b/virt/kvm/kvmi_int.h
> > @@ -126,6 +126,9 @@ struct kvmi_vcpu {
> > DECLARE_BITMAP(high, KVMI_NUM_MSR);
> > } msr_mask;
> >
> > + bool ss_owner;
>
> Why is single-stepping mutually exclusive across all vCPUs? Does that
> always have to be the case?
I never thought to single-step multiple vCPUs in the same time.
If one vCPU will relax the access to a guest page while a second one,
finishing single-stepping, restores the 'r--' flags, the first one
will get another page fault and relax the page access again. It might
be doable, but before starting single-stepping a vCPU we might replace
guest memory (as requested by the introspection tool) and we will have
to use a lock for this.
However, we would like to use alternate EPT views with single-step.
So, we might replace this patch.
> > + bool ss_requested;
> > +
> > struct list_head job_list;
> > spinlock_t job_lock;
> >
> > @@ -151,6 +154,15 @@ struct kvmi {
> > DECLARE_BITMAP(event_allow_mask, KVMI_NUM_EVENTS);
> > DECLARE_BITMAP(vm_ev_mask, KVMI_NUM_EVENTS);
> >
> > +#define SINGLE_STEP_MAX_DEPTH 8
> > + struct {
> > + gfn_t gfn;
> > + u8 old_access;
> > + u32 old_write_bitmap;
> > + } ss_context[SINGLE_STEP_MAX_DEPTH];
> > + u8 ss_level;
> > + atomic_t ss_active;
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
