[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87fs0fuorx.ffs@tglx>
Date: Wed, 06 Dec 2023 20:14:26 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Jacob Pan <jacob.jun.pan@...ux.intel.com>,
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>
Cc: 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 Pan <jacob.jun.pan@...ux.intel.com>
Subject: Re: [PATCH RFC 09/13] x86/irq: Install posted MSI notification handler
On Sat, Nov 11 2023 at 20:16, Jacob Pan wrote:
> + /*
> + * Ideally, we should start from the high order bits set in the PIR
> + * since each bit represents a vector. Higher order bit position means
> + * the vector has higher priority. But external vectors are allocated
> + * based on availability not priority.
> + *
> + * EOI is included in the IRQ handlers call to apic_ack_irq, which
> + * allows higher priority system interrupt to get in between.
What? This does not make sense.
_IF_ we go there then
1) The EOI must be explicit in sysvec_posted_msi_notification()
2) Interrupt enabling must happen explicit at a dedicated place in
sysvec_posted_msi_notification()
You _CANNOT_ run all the device handlers with interrupts
enabled.
Please remove all traces of non-working wishful thinking from this series.
> + */
> + for_each_set_bit_from(vec, (unsigned long *)&pir_copy[0], 256)
Why does this need to check up to vector 255? The vector space does not
magially expand just because of posted interrupts, really. At least not
without major modifications to the vector management.
> + call_irq_handler(vec, regs);
> +
Stray newline.
> +}
Thanks,
tglx
Powered by blists - more mailing lists