Received-SPF: pass (google.com: domain of linux-kernel+bounces-63100-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
From: Thomas Gleixner <tglx@linutronix.de>
To: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: LKML <linux-kernel@vger.kernel.org>, X86 Kernel <x86@kernel.org>,
 iommu@lists.linux.dev, Lu Baolu <baolu.lu@linux.intel.com>,
 kvm@vger.kernel.org, Dave Hansen <dave.hansen@intel.com>, Joerg Roedel
 <joro@8bytes.org>, "H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov
 <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>, Raj Ashok
 <ashok.raj@intel.com>, "Tian, Kevin" <kevin.tian@intel.com>,
 maz@kernel.org, peterz@infradead.org, seanjc@google.com, Robin Murphy
 <robin.murphy@arm.com>, jacob.jun.pan@linux.intel.com
Subject: Re: [PATCH RFC 12/13] iommu/vt-d: Add a helper to retrieve PID address
In-Reply-To: <20240126153047.5e42e5d0@jacob-builder>
References: <20231112041643.2868316-1-jacob.jun.pan@linux.intel.com>
 <20231112041643.2868316-13-jacob.jun.pan@linux.intel.com>
 <874jgvuls0.ffs@tglx> <20240126153047.5e42e5d0@jacob-builder>
Date: Tue, 13 Feb 2024 09:21:47 +0100
Message-ID: <87le7oixk4.ffs@tglx>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On Fri, Jan 26 2024 at 15:30, Jacob Pan wrote:
> On Wed, 06 Dec 2023 21:19:11 +0100, Thomas Gleixner <tglx@linutronix.de>
> wrote:
>> > +static u64 get_pi_desc_addr(struct irq_data *irqd)
>> > +{
>> > +	int cpu =
>> > cpumask_first(irq_data_get_effective_affinity_mask(irqd));  
>> 
>> The effective affinity mask is magically correct when this is called?
>> 
> My understanding is that remappable device MSIs have the following
> hierarchy,e.g.

SNIP

> 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?

Thanks,

        tglx