[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240213113142.6b7459e1@jacob-builder>
Date: Tue, 13 Feb 2024 11:31:42 -0800
From: Jacob Pan <jacob.jun.pan@...ux.intel.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>, X86 Kernel <x86@...nel.org>,
iommu@...ts.linux.dev, Lu Baolu <baolu.lu@...ux.intel.com>,
kvm@...r.kernel.org, Dave Hansen <dave.hansen@...el.com>, Joerg Roedel
<joro@...tes.org>, "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov
<bp@...en8.de>, Ingo Molnar <mingo@...hat.com>, Raj Ashok
<ashok.raj@...el.com>, "Tian, Kevin" <kevin.tian@...el.com>,
maz@...nel.org, peterz@...radead.org, seanjc@...gle.com, Robin Murphy
<robin.murphy@....com>, jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH RFC 12/13] iommu/vt-d: Add a helper to retrieve PID
address
Hi Thomas,
On Tue, 13 Feb 2024 09:21:47 +0100, Thomas Gleixner <tglx@...utronix.de>
wrote:
> > Here the parent APIC chip does apic_set_affinity() which will set up
> > effective mask before posted MSI affinity change.
> >
> > Maybe I missed some cases?
>
> The function is only used in intel_ir_reconfigure_irte_posted() in the
> next patch, but it's generally available. So I asked that question
> because if it's called in some other context then it's going to be not
> guaranteed.
>
> That also begs the question why this function exists in the first
> place. This really can be part of intel_ir_reconfigure_irte_posted(),
> which makes it clear what the context is, no?
Make sense, will fold it in next time.
Thanks,
Jacob
Powered by blists - more mailing lists