All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>,
	Sean Christopherson <seanjc@google.com>
Cc: kvm list <kvm@vger.kernel.org>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Wanpeng Li <wanpengli@tencent.com>,
	Kieran Bingham <kbingham@kernel.org>,
	Jessica Yu <jeyu@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Joerg Roedel <joro@8bytes.org>,
	Jim Mattson <jmattson@google.com>, Borislav Petkov <bp@alien8.de>,
	Stefano Garzarella <sgarzare@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping
Date: Tue, 16 Mar 2021 20:02:07 +0200	[thread overview]
Message-ID: <f6c6eee97772264eff62a8c1dafa325c82173d64.camel@redhat.com> (raw)
In-Reply-To: <31c0bba9-0399-1f15-a59b-a8f035e366e8@siemens.com>

On Tue, 2021-03-16 at 18:01 +0100, Jan Kiszka wrote:
> On 16.03.21 17:50, Sean Christopherson wrote:
> > On Tue, Mar 16, 2021, Maxim Levitsky wrote:
> > > On Tue, 2021-03-16 at 16:31 +0100, Jan Kiszka wrote:
> > > > Back then, when I was hacking on the gdb-stub and KVM support, the
> > > > monitor trap flag was not yet broadly available, but the idea to once
> > > > use it was already there. Now it can be considered broadly available,
> > > > but it would still require some changes to get it in.
> > > > 
> > > > Unfortunately, we don't have such thing with SVM, even recent versions,
> > > > right? So, a proper way of avoiding diverting event injections while we
> > > > are having the guest in an "incorrect" state should definitely be the goal.
> > > Yes, I am not aware of anything like monitor trap on SVM.
> > > 
> > > > Given that KVM knows whether TF originates solely from guest debugging
> > > > or was (also) injected by the guest, we should be able to identify the
> > > > cases where your approach is best to apply. And that without any extra
> > > > control knob that everyone will only forget to set.
> > > Well I think that the downside of this patch is that the user might actually
> > > want to single step into an interrupt handler, and this patch makes it a bit
> > > more complicated, and changes the default behavior.
> > 
> > Yes.  And, as is, this also blocks NMIs and SMIs.  I suspect it also doesn't
> > prevent weirdness if the guest is running in L2, since IRQs for L1 will cause
> > exits from L2 during nested_ops->check_events().
> > 
> > > I have no objections though to use this patch as is, or at least make this
> > > the new default with a new flag to override this.
> > 
> > That's less bad, but IMO still violates the principle of least surprise, e.g.
> > someone that is single-stepping a guest and is expecting an IRQ to fire will be
> > all kinds of confused if they see all the proper IRR, ISR, EFLAGS.IF, etc...
> > settings, but no interrupt.
> 
> From my practical experience with debugging guests via single step,
> seeing an interrupt in that case is everything but handy and generally
> also not expected (though logical, I agree). IOW: When there is a knob
> for it, it will remain off in 99% of the time.
> 
> But I see the point of having some control, in an ideal world also an
> indication that there are pending events, permitting the user to decide
> what to do. But I suspect the gdb frontend and protocol does not easily
> permit that.

Qemu gdbstub actually does have control over suppression of the interrupts
over a single step and it is even enabled by default:

https://qemu.readthedocs.io/en/latest/system/gdb.html
(advanced debug options)

However it is currently only implemented in TCG (software emulator) mode 
and not in KVM mode (I can argue that this is a qemu bug).

So my plan was to add a new kvm guest debug flag KVM_GUESTDBG_BLOCKEVENTS,
and let qemu enable it when its 'NOIRQ' mode is enabled (it is by default).

However due to the discussion in this thread about the leakage of the RFLAGS.TF,
I wonder if kvm should by default suppress events and have something like
KVM_GUESTDBG_SSTEP_ALLOW_EVENTS to override this and wire 
that to qemu's NOIRQ=false case.

This will allow older qemu to work correctly and new qemu will be able to choose
the old less ideal behavior.

> 
> > > Sean Christopherson, what do you think?
> > 
> > Rather than block all events in KVM, what about having QEMU "pause" the timer?
> > E.g. save MSR_TSC_DEADLINE and APIC_TMICT (or inspect the guest to find out
> > which flavor it's using), clear them to zero, then restore both when
> > single-stepping is disabled.  I think that will work?
> > 
> 
> No one can stop the clock, and timers are only one source of interrupts.
> Plus they do not all come from QEMU, some also from KVM or in-kernel
> sources directly. Would quickly become a mess.

This, plus as we see, even changing with RFLAGS.TF leaks it.
Changing things like MSR_TSC_DEADLINE will also make it visible to the guest,
sooner or later and is a mess that I rather not get into.

It is _possible_ to disable timer interrupts 'out of band', but that is messy too
if done from userspace. For example, what if the timer interrupt is already pending
in local apic, when qemu decides to single step?

Also with gdbstub the user doesn't have to stop all vcpus (there is a non-stop mode),
in which only some vcpus are stopped which is actually a very cool feature,
and of course running vcpus can raise events.

Also interrupts can indeed come from things like vhost.

Best regards,
	Maxim Levitsky


> Jan
> 



  parent reply	other threads:[~2021-03-16 18:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 22:10 [PATCH 0/3] KVM: my debug patch queue Maxim Levitsky
2021-03-15 22:10 ` [PATCH 1/3] scripts/gdb: rework lx-symbols gdb script Maxim Levitsky
2021-03-16 13:38   ` Jan Kiszka
2021-03-16 14:12     ` Maxim Levitsky
2021-03-15 22:10 ` [PATCH 2/3] KVM: x86: guest debug: don't inject interrupts while single stepping Maxim Levitsky
2021-03-15 23:37   ` Sean Christopherson
2021-03-16  9:16     ` Jan Kiszka
2021-03-16 10:59       ` Maxim Levitsky
2021-03-16 11:27         ` Jan Kiszka
2021-03-16 12:34           ` Maxim Levitsky
2021-03-16 13:46             ` Jan Kiszka
2021-03-16 14:34               ` Maxim Levitsky
2021-03-16 15:31                 ` Jan Kiszka
     [not found]                   ` <e2cd978e357155dbab21a523bb8981973bd10da7.camel@redhat.com>
2021-03-16 15:56                     ` Jan Kiszka
2021-03-16 16:50                     ` Sean Christopherson
2021-03-16 17:01                       ` Jan Kiszka
2021-03-16 17:26                         ` Sean Christopherson
2021-03-17  9:20                           ` Jan Kiszka
2021-03-16 18:02                         ` Maxim Levitsky [this message]
2021-03-18 16:02                           ` Jan Kiszka
2021-03-18 12:21             ` Jan Kiszka
2021-03-16 10:55     ` Maxim Levitsky
2021-03-15 22:10 ` [PATCH 3/3] KVM: SVM: allow to intercept all exceptions for debug Maxim Levitsky
2021-03-16  8:32   ` Joerg Roedel
2021-03-16 10:51     ` Maxim Levitsky
2021-03-18  9:19       ` Joerg Roedel
2021-03-18  9:24         ` Maxim Levitsky
2021-03-18 15:47           ` Joerg Roedel
2021-03-18 16:35             ` Sean Christopherson
2021-03-18 16:41               ` Maxim Levitsky
2021-03-18 17:22                 ` Sean Christopherson
2021-03-16  8:34   ` Borislav Petkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f6c6eee97772264eff62a8c1dafa325c82173d64.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jan.kiszka@siemens.com \
    --cc=jeyu@kernel.org \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kbingham@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=sgarzare@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.