From: David Woodhouse <dwmw2@infradead.org> To: 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: [PATCH 02/13] x86/msi: Only use high bits of MSI address for DMAR unit Date: Mon, 5 Oct 2020 16:28:45 +0100 Message-ID: <20201005152856.974112-2-dwmw2@infradead.org> (raw) In-Reply-To: <20201005152856.974112-1-dwmw2@infradead.org> From: David Woodhouse <dwmw@amazon.co.uk> The Intel IOMMU has an MSI-like configuration for its interrupt, but it isn't really MSI. So it gets to abuse the high 32 bits of the address, and puts the high 24 bits of the extended APIC ID there. This isn't something that can be used in the general case for real MSIs, since external devices using the high bits of the address would be performing writes to actual memory space above 4GiB, not targeted at the APIC. Factor the hack out and allow it only to be used when appropriate, adding a WARN_ON_ONCE() if other MSIs are targeted at an unreachable APIC ID. That should never happen since the legacy MSI messages are not supposed to be used with Interrupt Remapping enabled. The x2apic_enabled() check isn't needed because we won't bring up CPUs with higher APIC IDs unless x2apic is enabled anyway. Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> --- arch/x86/kernel/apic/msi.c | 34 ++++++++++++++++++++++++++++------ 1 file changed, 28 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c index 6313f0a05db7..356f8acf4927 100644 --- a/arch/x86/kernel/apic/msi.c +++ b/arch/x86/kernel/apic/msi.c @@ -23,13 +23,10 @@ struct irq_domain *x86_pci_msi_default_domain __ro_after_init; -static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg) +static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg, int dmar) { msg->address_hi = MSI_ADDR_BASE_HI; - if (x2apic_enabled()) - msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid); - msg->address_lo = MSI_ADDR_BASE_LO | ((apic->irq_dest_mode == 0) ? @@ -43,18 +40,42 @@ static void __irq_msi_compose_msg(struct irq_cfg *cfg, struct msi_msg *msg) MSI_DATA_LEVEL_ASSERT | MSI_DATA_DELIVERY_FIXED | MSI_DATA_VECTOR(cfg->vector); + + /* + * Only the IOMMU itself can use the trick of putting destination + * APIC ID into the high bits of the address. Anything else would + * just be writing to memory if it tried that, and needs IR to + * address APICs above 255. + */ + if (dmar) + msg->address_hi |= MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid); + else + WARN_ON_ONCE(MSI_ADDR_EXT_DEST_ID(cfg->dest_apicid)); } void x86_vector_msi_compose_msg(struct irq_data *data, struct msi_msg *msg) { - __irq_msi_compose_msg(irqd_cfg(data), msg); + __irq_msi_compose_msg(irqd_cfg(data), msg, 0); } +/* + * The Intel IOMMU (ab)uses the high bits of the MSI address to contain the + * high bits of the destination APIC ID. This can't be done in the general + * case for MSIs as it would be targeting real memory above 4GiB not the + * APIC. + */ +static void dmar_msi_compose_msg(struct irq_data *data, struct msi_msg *msg) +{ + __irq_msi_compose_msg(irqd_cfg(data), msg, 1); + + + +} static void irq_msi_update_msg(struct irq_data *irqd, struct irq_cfg *cfg) { struct msi_msg msg[2] = { [1] = { }, }; - __irq_msi_compose_msg(cfg, msg); + __irq_msi_compose_msg(cfg, msg, 0); irq_data_get_irq_chip(irqd)->irq_write_msi_msg(irqd, msg); } @@ -288,6 +309,7 @@ static struct irq_chip dmar_msi_controller = { .irq_ack = irq_chip_ack_parent, .irq_set_affinity = msi_domain_set_affinity, .irq_retrigger = irq_chip_retrigger_hierarchy, + .irq_compose_msi_msg = dmar_msi_compose_msg, .irq_write_msi_msg = dmar_msi_write_msg, .flags = IRQCHIP_SKIP_SET_WAKE, }; -- 2.26.2
next prev parent reply index 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 ` David Woodhouse [this message] 2020-10-06 20:45 ` [PATCH 02/13] x86/msi: Only use high bits of MSI address for DMAR unit 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 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=20201005152856.974112-2-dwmw2@infradead.org \ --to=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
Linux-HyperV Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-hyperv/0 linux-hyperv/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-hyperv linux-hyperv/ https://lore.kernel.org/linux-hyperv \ linux-hyperv@vger.kernel.org public-inbox-index linux-hyperv Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-hyperv AGPL code for this site: git clone https://public-inbox.org/public-inbox.git