Linux Confidential Computing Development
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Rick P Edgecombe <rick.p.edgecombe@intel.com>
Cc: Xiaoyao Li <xiaoyao.li@intel.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	 "pbonzini@redhat.com" <pbonzini@redhat.com>,
	 "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
	"kas@kernel.org" <kas@kernel.org>,
	 "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	 "nik.borisov@suse.com" <nik.borisov@suse.com>
Subject: Re: [PATCH v4 0/9] KVM: TDX: Enable VM-DoS Prevention Features for TDX
Date: Fri, 21 Aug 2026 06:14:51 -0700	[thread overview]
Message-ID: <aohPS45Qc7erio4c@google.com> (raw)
In-Reply-To: <8f715ebf5cb0ef70803ca8c6ad462d9de7dfa8be.camel@intel.com>

On Wed, Aug 19, 2026, Rick P Edgecombe wrote:
> On Wed, 2026-08-19 at 16:03 -0700, Sean Christopherson wrote:
> > > To me this is not a valid reason. Sashiko is great, but we can't let false
> > > positives drive the patches. Given that the series is so big now, I'd think
> > > it would be better to leave 6 and 9 for follow up, so we can focus on the
> > > core thing.
> > 
> > Hmm, I disagree.  If the consolidation weren't here, I'd absolutely ask for
> > it. This is new feature enabling.  Yeah, it happens to be tagged for stable,
> > but at the end of the day, it's new feature enabling.  And it's standard
> > operation procedure to do cleanups and dedup code as part of new feature
> > enabling.
> > 
> > If anything patch 6 should be patch 1, but that's a minor detail I can sort
> > out when applying (assuming another version isn't required).
> 
> Ok. But you disagree with dropping the patch?

Dropping the patch.

> Or that avoiding sashiko reports of existing issues is an invalid reason to
> change the series?
> 
> I think it's good to discuss a bit how to handle sashiko scenarios.

Like we do any other code review: use common sense and follow established best
practices.  If a human reviewer pointed out an existing bug, we would analyze
the situation and make a judgment call as to whether it's better to send a
standalone fix or roll a fix into a new version of the series.  If we decided to
fix the issue separately, and then a human brought up the same pre-existing issue
in a future revision, we would point them at the fix or the previous discussion
(or if it was the same human, (politely?) tell them to go away).

The only differences is that Sashiko is noisier because is doesn't (yet?) remember
what feedback it gave in the past, often doesn't look at the patches later in the
series, and doesn't (yet?) respond to emails so telling Sashiko to shut up about a
particular pre-existing issue isn't effective.

But to be very explicit: don't include a patch *purely* to suppress Sashiko's
rediscovery of existing issues.

      reply	other threads:[~2026-08-21 13:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-19  9:48 [PATCH v4 0/9] KVM: TDX: Enable VM-DoS Prevention Features for TDX Xiaoyao Li
2026-08-19  9:48 ` [PATCH v4 1/9] KVM: TDX: Enable Notify VM exit Xiaoyao Li
2026-08-20  8:48   ` Binbin Wu
2026-08-19  9:48 ` [PATCH v4 2/9] KVM: TDX: Check if there is valid exit infos based on vp_enter_ret Xiaoyao Li
2026-08-19 16:39   ` Edgecombe, Rick P
2026-08-20  1:53     ` Xiaoyao Li
2026-08-20  9:11   ` Binbin Wu
2026-08-19  9:48 ` [PATCH v4 3/9] KVM: TDX: Set bits 31:16 to 0 for the synthesized Exit Reason Xiaoyao Li
2026-08-20  9:16   ` Binbin Wu
     [not found] ` <20260819094903.3060020-6-xiaoyao.li@intel.com>
2026-08-19 19:08   ` [PATCH v4 5/9] KVM: TDX: Update exit_reason on wait_for_sept_zap return Edgecombe, Rick P
2026-08-19 22:57 ` [PATCH v4 0/9] KVM: TDX: Enable VM-DoS Prevention Features for TDX Edgecombe, Rick P
2026-08-19 23:03   ` Sean Christopherson
2026-08-19 23:08     ` Edgecombe, Rick P
2026-08-21 13:14       ` Sean Christopherson [this message]

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=aohPS45Qc7erio4c@google.com \
    --to=seanjc@google.com \
    --cc=kas@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=xiaoyao.li@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox