From: Thomas Gleixner <tglx@linutronix.de>
To: David Woodhouse <dwmw2@infradead.org>, x86@kernel.org
Cc: iommu <iommu@lists.linux-foundation.org>,
kvm <kvm@vger.kernel.org>,
linux-hyperv@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()
Date: Wed, 07 Oct 2020 22:53:17 +0200 [thread overview]
Message-ID: <87tuv53ghu.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <7FA24FCF-E197-4502-BC89-0902E4053554@infradead.org>
On Wed, Oct 07 2020 at 17:11, David Woodhouse wrote:
> On 7 October 2020 16:57:36 BST, Thomas Gleixner <tglx@linutronix.de> wrote:
>>There is not lot's of nastiness.
>
> OK, but I think we do have to cope with the fact that the limit is
> dynamic, and a CPU might be added which widens the mask. I think
> that's fundamental and not x86-specific.
Yes, but it needs some thoughts vs. serialization against CPU hotplug.
The stability of that cpumask is architecture specific if the calling
context cannot serialize against CPU hotplug. The hot-unplug case is
less interesting because the mask does not shrink, it only get's wider.
That's why I want a callback instead of a pointer assignment and that
callback cannot return a pointer to something which can be modified
concurrently, it needs to update a caller provided mask so that the
result is at least consistent in itself.
It just occured to me that there is something which needs some more
thought vs. CPU hotunplug as well:
Right now we just check whether there are enough vectors available on
the remaining online CPUs so that the interrupts which have an
effective affinity directed to the outgoing CPU can be migrated away
(modulo the managed ones).
That check obviously needs to take the target CPU restrictions into
account to prevent that devices end up with no target at the end.
I bet there are some other interesting bits and pieces which need
some care...
Thanks,
tglx
next prev parent reply other threads:[~2020-10-07 20:53 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 15:28 [PATCH 0/13] Fix per-domain IRQ affinity, allow >255 CPUs on x86 without IRQ remapping David Woodhouse
2020-10-05 15:28 ` [PATCH 01/13] x86/apic: Use x2apic in guest kernels even with unusable CPUs David Woodhouse
2020-10-05 15:28 ` [PATCH 02/13] x86/msi: Only use high bits of MSI address for DMAR unit David Woodhouse
2020-10-06 20:45 ` Thomas Gleixner
2020-10-05 15:28 ` [PATCH 03/13] x86/ioapic: Handle Extended Destination ID field in RTE David Woodhouse
2020-10-05 15:28 ` [PATCH 04/13] x86/apic: Support 15 bits of APIC ID in IOAPIC/MSI where available David Woodhouse
2020-10-05 15:28 ` [PATCH 05/13] genirq: Prepare for default affinity to be passed to __irq_alloc_descs() David Woodhouse
2020-10-06 21:01 ` Thomas Gleixner
2020-10-06 21:07 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 06/13] genirq: Add default_affinity argument " David Woodhouse
2020-10-06 21:06 ` Thomas Gleixner
2020-10-05 15:28 ` [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs() David Woodhouse
2020-10-06 21:26 ` Thomas Gleixner
2020-10-07 7:19 ` David Woodhouse
2020-10-07 13:37 ` Thomas Gleixner
2020-10-07 14:10 ` David Woodhouse
2020-10-07 15:57 ` Thomas Gleixner
2020-10-07 16:11 ` David Woodhouse
2020-10-07 20:53 ` Thomas Gleixner [this message]
2020-10-08 7:21 ` David Woodhouse
2020-10-08 9:34 ` Thomas Gleixner
2020-10-08 11:10 ` David Woodhouse
2020-10-08 12:40 ` Thomas Gleixner
2020-10-09 7:54 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 08/13] genirq: Add irq_domain_set_affinity() David Woodhouse
2020-10-06 21:32 ` Thomas Gleixner
2020-10-07 7:22 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 09/13] x86/irq: Add x86_non_ir_cpumask David Woodhouse
2020-10-06 21:42 ` Thomas Gleixner
2020-10-07 7:25 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR David Woodhouse
2020-10-06 21:54 ` Thomas Gleixner
2020-10-07 7:48 ` David Woodhouse
2020-10-07 12:59 ` Thomas Gleixner
2020-10-07 13:08 ` David Woodhouse
2020-10-07 14:05 ` Thomas Gleixner
2020-10-07 14:23 ` David Woodhouse
2020-10-07 16:02 ` Thomas Gleixner
2020-10-07 16:15 ` David Woodhouse
2020-10-07 15:05 ` David Woodhouse
2020-10-07 15:25 ` Thomas Gleixner
2020-10-07 15:46 ` David Woodhouse
2020-10-07 17:23 ` Thomas Gleixner
2020-10-07 17:34 ` David Woodhouse
2020-10-05 15:28 ` [PATCH 11/13] x86/smp: Allow more than 255 CPUs even without interrupt remapping David Woodhouse
2020-10-05 15:28 ` [PATCH 12/13] iommu/irq_remapping: Kill most of hyperv-iommu.c now it's redundant David Woodhouse
2020-10-05 15:28 ` [PATCH 13/13] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID David Woodhouse
2020-10-07 8:14 ` Paolo Bonzini
2020-10-07 8:59 ` David Woodhouse
2020-10-07 11:15 ` Paolo Bonzini
2020-10-07 12:04 ` David Woodhouse
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=87tuv53ghu.fsf@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-hyperv@vger.kernel.org \
--cc=pbonzini@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).