All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	kvm@vger.kernel.org, Vitaly Kuznetsov <vkuznets@redhat.com>,
	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>, Jan Kiszka <jan.kiszka@siemens.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.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>, Borislav Petkov <bp@suse.de>
Subject: Re: [PATCH 3/3] KVM: SVM: allow to intercept all exceptions for debug
Date: Thu, 18 Mar 2021 17:22:01 +0000	[thread overview]
Message-ID: <YFOMOV/u69LEpnh8@google.com> (raw)
In-Reply-To: <7169229dde171c8e10fb276ff8e1a869af99b39d.camel@redhat.com>

On Thu, Mar 18, 2021, Maxim Levitsky wrote:
> On Thu, 2021-03-18 at 16:35 +0000, Sean Christopherson wrote:
> > Skipping SEV-ES guests should not be difficult; KVM could probably even
> > print a message stating that the debug hook is being ignored.  One thought would
> > be to snapshot debug_intercept_exceptions at VM creation, and simply zero it out
> > for incompatible guests.  That would also allow changing debug_intercept_exceptions
> > without reloading KVM, which IMO would be very convenient.
> > 
> So all right I'll disable this for SEV-ES. 

Belated thought.  KVM doesn't know a guest will be an SEV-ES guest until
sev_es_guest_init(), and KVM currently doesn't prevent creating vCPUs before
KVM_SEV_ES_INIT.  But, I'm 99% confident that's a KVM bug.  For your purposes,
I think you can assume kvm->arch.debug_intercept_exceptions will _not_ change
after vCPU creation.

> The idea to change the debug_intercept_exceptions on the fly is also a good idea,
> I will implement it in next version of the patches.

Can you also move the module param to x86?  It doesn't need to be wired up for
VMX right away, but it makes sense to do it at some point, and ideally folks
won't have to update their scripts when that happens.

  reply	other threads:[~2021-03-18 17:22 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
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 [this message]
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=YFOMOV/u69LEpnh8@google.com \
    --to=seanjc@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=bp@suse.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=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.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.