All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Maxim Levitsky <mlevitsk@redhat.com>,
	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: Wed, 17 Mar 2021 10:20:36 +0100	[thread overview]
Message-ID: <d94f9c87-9609-4e7f-04d0-546d27671e51@siemens.com> (raw)
In-Reply-To: <YFDqSisnoWD5wVdP@google.com>

On 16.03.21 18:26, Sean Christopherson wrote:
> On Tue, Mar 16, 2021, Jan Kiszka wrote:
>> On 16.03.21 17:50, Sean Christopherson wrote:
>>> 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.
> 
> But are any other sources of interrupts a chronic problem?  I 100% agree that

If you are debugging a problem, you are not interested in seening
problems of the debugger, only real ones of your target. IOW: Yes, they
are, even if less likely - for idle VMs.

> this would not be a robust solution, but neither is blocking events in KVM.  At
> least with this approach, the blast radius is somewhat contained.
> 
>> Would quickly become a mess.
> 
> Maybe, but it'd be Qemu's mess ;-)
> 

Nope, it would spread to KVM as well, as indicated above.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

  reply	other threads:[~2021-03-17  9:26 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 [this message]
2021-03-16 18:02                         ` Maxim Levitsky
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=d94f9c87-9609-4e7f-04d0-546d27671e51@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.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=mlevitsk@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.