All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	x86@kernel.org,  stable@vger.kernel.org
Subject: Re: [PATCH 2/4] selftests: kvm: replace numbered sync points with actions
Date: Thu, 8 Jan 2026 12:26:22 -0800	[thread overview]
Message-ID: <aWAS7iCLgJHd_GgZ@google.com> (raw)
In-Reply-To: <CABgObfZSchPMdqSvvVPgy9s5-TkHHZpLPHNYSsK-YHRye0SAaw@mail.gmail.com>

On Wed, Jan 07, 2026, Paolo Bonzini wrote:
> On Tue, Jan 6, 2026 at 1:02 AM Sean Christopherson <seanjc@google.com> wrote:
> > > @@ -244,6 +254,7 @@ int main(int argc, char *argv[])
> > >       memset(addr_gva2hva(vm, xstate), 0, PAGE_SIZE * DIV_ROUND_UP(XSAVE_SIZE, PAGE_SIZE));
> > >       vcpu_args_set(vcpu, 3, amx_cfg, tiledata, xstate);
> > >
> > > +     int iter = 0;
> >
> > If we want to retain "tracing" of guest syncs, I vote to provide the information
> > from the guest, otherwise I'll end up counting GUEST_SYNC() calls on my fingers
> > (and run out of fingers) :-D.
> 
> I had a similar idea, but I was too lazy to implement it because for a
> very linear test such as this one, "12n" in vi does wonders...
> 
> > E.g. if we wrap all GUEST_SYNC() calls in a macro, we can print the line number
> > without having to hardcode sync point numbers.
> 
> ... but there are actually better reasons than laziness and linearity
> to keep the simple "iter++".
> 
> First, while using line numbers has the advantage of zero maintenance,
> the disadvantage is that they change all the time as you're debugging.
> So you are left slightly puzzled if the number changed because the
> test passed or because of the extra debugging code you added.

True.  I'm good with the current patch.

> Second, the iteration number is probably more useful to identify the
> places at which the VM was reentered (which are where the iteration
> number changes), than to identify the specific GUEST_SYNC that failed;
> from that perspective there's not much difference between line
> numbers, manually-numbered sync points, or incrementing a counter in
> main().

  reply	other threads:[~2026-01-08 20:26 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-01  9:05 [PATCH v2 0/4] x86, fpu/kvm: fix crash with AMX Paolo Bonzini
2026-01-01  9:05 ` [PATCH 1/4] x86/fpu: Clear XSTATE_BV[i] in save state whenever XFD[i]=1 Paolo Bonzini
2026-01-03  2:06   ` Yao Yuan
2026-01-05 17:31     ` Sean Christopherson
2026-01-06  5:25       ` Yao Yuan
2026-01-06  0:54   ` Jim Mattson
2026-01-06  1:17     ` Sean Christopherson
2026-01-06 17:56       ` Jim Mattson
2026-01-15 16:07         ` Dave Hansen
2026-01-15 16:12           ` Paolo Bonzini
2026-01-15 16:27             ` Dave Hansen
2026-01-07  0:28   ` Chang S. Bae
2026-01-07 22:33     ` Paolo Bonzini
2026-01-08  3:06   ` Binbin Wu
2026-01-08 16:26     ` Paolo Bonzini
2026-01-15 15:54   ` Dave Hansen
2026-01-15 16:22     ` Paolo Bonzini
2026-01-15 18:19       ` Dave Hansen
2026-01-15 18:26         ` Paolo Bonzini
2026-01-15 23:43         ` Chang S. Bae
2026-01-01  9:05 ` [PATCH 2/4] selftests: kvm: replace numbered sync points with actions Paolo Bonzini
2026-01-06  0:02   ` Sean Christopherson
2026-01-07 22:28     ` Paolo Bonzini
2026-01-08 20:26       ` Sean Christopherson [this message]
2026-01-01  9:05 ` [PATCH 3/4] selftests: kvm: try getting XFD and XSAVE state out of sync Paolo Bonzini
2026-01-01  9:05 ` [PATCH 4/4] selftests: kvm: Verify TILELOADD actually #NM faults when XFD[18]=1 Paolo Bonzini
2026-01-06  1:18 ` [PATCH v2 0/4] x86, fpu/kvm: fix crash with AMX Sean Christopherson
2026-01-15 12:22 ` Borislav Petkov
2026-01-15 13:49   ` Paolo Bonzini
2026-01-15 16:39     ` Sean Christopherson
2026-01-15 17:05       ` Borislav Petkov
2026-01-15 17:12         ` Sean Christopherson
2026-01-16 12:22 ` Borislav Petkov
2026-01-21 11:35   ` Paolo Bonzini
2026-01-22 11:12     ` Borislav Petkov
2026-01-22 12:00       ` Paolo Bonzini
2026-01-23 13:23         ` 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=aWAS7iCLgJHd_GgZ@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    --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.