All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Maxim Levitsky <mlevitsk@redhat.com>
Cc: kvm@vger.kernel.org, Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org,  Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org,  Ingo Molnar <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	 Joerg Roedel <joro@8bytes.org>,
	Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
	 Robin Murphy <robin.murphy@arm.com>,
	iommu@lists.linux.dev,  Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH v3 0/4] Allow AVIC's IPI virtualization to be optional
Date: Mon, 23 Sep 2024 02:29:55 -0700	[thread overview]
Message-ID: <ZvE06wB0JGWXGxpK@google.com> (raw)
In-Reply-To: <e5218efaceec20920166bd907416d6f88905558d.camel@redhat.com>

On Tue, Sep 10, 2024, Maxim Levitsky wrote:
> On Wed, 2023-10-04 at 16:14 +0300, Maxim Levitsky wrote:
> > У пн, 2023-10-02 у 12:21 -0700, Sean Christopherson пише:
> > > On Mon, Oct 02, 2023, Maxim Levitsky wrote:
> > > > Hi!
> > > > 
> > > > This patch allows AVIC's ICR emulation to be optional and thus allows
> > > > to workaround AVIC's errata #1235 by disabling this portion of the feature.
> > > > 
> > > > This is v3 of my patch series 'AVIC bugfixes and workarounds' including
> > > > review feedback.
> > > 
> > > Please respond to my idea[*] instead of sending more patches. 
> > 
> > Hi,
> > 
> > For the v2 of the patch I was already on the fence if to do it this way or to refactor
> > the code, and back when I posted it, I decided still to avoid the refactoring.
> > 
> > However, your idea of rewriting this patch, while it does change less lines of code,
> > is even less obvious and consequently required you to write even longer comment to 
> > justify it which is not a good sign.
> > 
> > In particular I don't want someone to find out later, and in the hard way that sometimes
> > real physid table is accessed, and sometimes a fake copy of it is.
> > 
> > So I decided to fix the root cause by not reading the physid table back,
> > which made the code cleaner, and even with the workaround the code 
> > IMHO is still simpler than it was before.
> > 
> > About the added 'vcpu->loaded' variable, I added it also because it is something that is 
> > long overdue to be added, I remember that in IPIv code there was also a need for this, 
> > and probalby more places in KVM can be refactored to take advantage of it,
> > instead of various hacks.
> > 
> > I did adopt your idea of using 'enable_ipiv', although I am still not 100% sure that this
> > is more readable than 'avic_zen2_workaround'.
> 
> Hi!
> 
> Sean, can you take another look at this patch series?

Ya, it might take a week or two, but it's on my todo list.

  reply	other threads:[~2024-09-23  9:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-02 11:57 [PATCH v3 0/4] Allow AVIC's IPI virtualization to be optional Maxim Levitsky
2023-10-02 11:57 ` [PATCH v3 1/4] KVM: Add per vCPU flag specifying that a vCPU is loaded Maxim Levitsky
2023-10-02 11:57 ` [PATCH v3 2/4] x86: KVM: AVIC: stop using 'is_running' bit in avic_vcpu_put() Maxim Levitsky
2023-10-02 11:57 ` [PATCH v3 3/4] x86: KVM: don't read physical ID table entry in avic_pi_update_irte() Maxim Levitsky
2023-10-02 11:57 ` [PATCH v3 4/4] x86: KVM: SVM: allow optionally to disable AVIC's IPI virtualization Maxim Levitsky
2023-10-02 19:21 ` [PATCH v3 0/4] Allow AVIC's IPI virtualization to be optional Sean Christopherson
2023-10-04 13:14   ` Maxim Levitsky
2024-09-10 20:13     ` Maxim Levitsky
2024-09-23  9:29       ` Sean Christopherson [this message]
2024-09-23 16:23         ` Maxim Levitsky
2024-10-22  0:55     ` Sean Christopherson
2024-10-22 19:00       ` Sean Christopherson
2024-11-22  3:34         ` Maxim Levitsky
2024-11-26  0:25           ` Sean Christopherson

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=ZvE06wB0JGWXGxpK@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux.dev \
    --cc=joro@8bytes.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=robin.murphy@arm.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=tglx@linutronix.de \
    --cc=will@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.