Re: [PATCH 2/3] iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled

2021-03-17 Thread David Woodhouse
On 17 March 2021 13:32:35 GMT, Joerg Roedel wrote: >On Wed, Mar 17, 2021 at 11:47:11AM +0000, David Woodhouse wrote: >> If you've already moved the Stoney Ridge check out of the way, >there's >> no real reason why you can't just set >init_state=IOMMU_CMDLINE_DISA

Re: [PATCH 2/3] iommu/amd: Don't call early_amd_iommu_init() when AMD IOMMU is disabled

2021-03-17 Thread David Woodhouse
On Wed, 2021-03-17 at 10:10 +0100, Joerg Roedel wrote: > diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c > index 3280e6f5b720..61dae1800b7f 100644 > --- a/drivers/iommu/amd/init.c > +++ b/drivers/iommu/amd/init.c > @@ -2919,12 +2919,12 @@ static int __init state_next(void) >

[PATCH] iommu/amd: Don't initialise remapping irqdomain if IOMMU is disabled

2021-03-15 Thread David Woodhouse
From: David Woodhouse When the IOMMU is disabled, the driver still enumerates and initialises the hardware in order to turn it off. Because IRQ remapping setup is done early, the irqdomain is set up opportunistically. In commit b34f10c2dc59 ("iommu/amd: Stop irq_remapping_select() matching

Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths

2021-01-20 Thread David Woodhouse
On Wed, 2021-01-20 at 18:04 +0100, Greg KH wrote: > I tried applying these to 5.4, 4.19, and 4.14, and they all fail to > build: > > drivers/iommu/dmar.c: In function ‘free_iommu’: > drivers/iommu/dmar.c:1140:35: error: ‘struct intel_iommu’ has no member named > ‘drhd’ > 1140 | if

Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths

2021-01-20 Thread David Woodhouse
On Wed, 2021-01-20 at 13:06 +0100, Greg KH wrote: > On Wed, Jan 20, 2021 at 09:42:43AM +0000, David Woodhouse wrote: > > On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote: > > > From: David Woodhouse > > > > > > Instead of bailing out compl

Re: [PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths

2021-01-20 Thread David Woodhouse
On Thu, 2020-09-24 at 15:08 +0100, David Woodhouse wrote: > From: David Woodhouse > > Instead of bailing out completely, such a unit can still be used for > interrupt remapping. > > Signed-off-by: David Woodhouse Could we have this for stable too please, along with the

[PATCH] iommu/amd: Stop irq_remapping_select() matching when remapping is disabled

2021-01-04 Thread David Woodhouse
From: David Woodhouse The AMD IOMMU initialisation registers the IRQ remapping domain for each IOMMU before doing the final sanity check that every I/OAPIC is covered. This means that the AMD irq_remapping_select() function gets invoked even when IRQ remapping has been disabled, eventually

[PATCH] iommu/amd: Set iommu->int_enabled consistently when interrupts are set up

2021-01-04 Thread David Woodhouse
From: David Woodhouse When I made the INTCAPXT support stop gratuitously pretending to be MSI, I missed the fact that iommu_setup_msi() also sets the ->int_enabled flag. I missed this in the iommu_setup_intcapxt() code path, which means that a resume from suspend will try to allocate the

Re: [EXTERNAL] PROBLEM: commit f36a74b9345a leads to not booting system with AMD 2990WX

2021-01-04 Thread David Woodhouse
On Tue, 2021-01-05 at 00:05 +0100, Johnathan Smithinovic wrote: > commit f36a74b9345a leads to not booting system with AMD 2990WX > > > When trying to boot 5.11-rc2 as usual the messages of the bootloader stay on > my > screen and not much appears to happen (fans run a bit slower than in GRUB,

Re: Interrupts enabled after amd_iommu_resume+0x0/0x40

2021-01-04 Thread David Woodhouse
On Tue, 2021-01-05 at 00:23 +0100, Borislav Petkov wrote: > On Mon, Jan 04, 2021 at 02:22:50PM +0100, Borislav Petkov wrote: > > Hi folks, > > > > syscore_resume() doesn't like when the AMD iommu driver enables > > interrupts in its ->resume hook when I resume the box from suspend to > > RAM. > >

[PATCH] iommu/vt-d: Don't read VCCAP register unless it exists

2020-11-26 Thread David Woodhouse
From: David Woodhouse My virtual IOMMU implementation is whining that the guest is reading a register that doesn't exist. Only read the VCCAP_REG if the corresponding capability is set in ECAP_REG to indicate that it actually exists. Fixes: 3375303e8287 ("iommu/vt-d: Add custom allo

Re: [PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers

2020-11-10 Thread David Woodhouse
On Tue, 2020-11-10 at 01:31 -0500, Qian Cai wrote: > On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote: > > From: Thomas Gleixner > > > > 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling > > the trigger type (edge/level) and the ac

Re: [PATCH v3 17/35] x86/pci/xen: Use msi_msg shadow structs

2020-10-25 Thread David Woodhouse
On Sun, 2020-10-25 at 09:49 +, David Laight wrote: > Just looking at a random one of these patches... > > Does the compiler manage to optimise that reasonably? > Or does it generate a lot of shifts and masks as each > bitfield is set? > > The code generation for bitfields is often a lot

Re: [PATCH v3 00/35] Fix x2apic enablement and allow more CPUs, clean up I/OAPIC and MSI bitfields

2020-10-25 Thread David Woodhouse
On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote: > Fix the conditions for enabling x2apic on guests without interrupt > remapping, and support 15-bit Extended Destination ID to allow 32768 > CPUs without IR on hypervisors that support it. > > Make the I/OAPIC code g

[PATCH v3 26/35] iommu/hyper-v: Implement select() method on remapping irqdomain

2020-10-24 Thread David Woodhouse
From: David Woodhouse Preparatory for removing irq_remapping_get_irq_domain() Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- drivers/iommu/hyperv-iommu.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv

[PATCH v3 10/35] x86/hpet: Move MSI support into hpet.c

2020-10-24 Thread David Woodhouse
From: David Woodhouse This isn't really dependent on PCI MSI; it's just generic MSI which is now supported by the generic x86_vector_domain. Move the HPET MSI support back into hpet.c with the rest of the HPET support. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- arch

[PATCH v3 21/35] x86/ioapic: Generate RTE directly from parent irqchip's MSI message

2020-10-24 Thread David Woodhouse
From: David Woodhouse The I/O-APIC generates an MSI cycle with address/data bits taken from its Redirection Table Entry in some combination which used to make sense, but now is just a bunch of bits which get passed through in some seemingly arbitrary order. Instead of making IRQ remapping

[PATCH v3 29/35] x86: Kill all traces of irq_remapping_get_irq_domain()

2020-10-24 Thread David Woodhouse
From: David Woodhouse All users are converted to use the fwspec based parent domain lookup. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/hw_irq.h| 2 -- arch/x86/include/asm/irq_remapping.h | 9 drivers/iommu/amd/iommu.c

[PATCH v3 20/35] x86/ioapic: Cleanup IO/APIC route entry structs

2020-10-24 Thread David Woodhouse
Signed-off-by: David Woodhouse --- arch/x86/include/asm/io_apic.h | 78 ++- arch/x86/kernel/apic/io_apic.c | 144 +--- drivers/iommu/amd/iommu.c | 8 +- drivers/iommu/hyperv-iommu.c| 4 +- drivers/iommu/intel/irq_remapping.c

[PATCH v3 13/35] iommu/intel: Use msi_msg shadow structs

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner Use the bitfields in the x86 shadow struct to compose the MSI message. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- drivers/iommu/intel/irq_remapping.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git

[PATCH v3 24/35] iommu/amd: Implement select() method on remapping irqdomain

2020-10-24 Thread David Woodhouse
From: David Woodhouse Preparatory change to remove irq_remapping_get_irq_domain(). Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- drivers/iommu/amd/iommu.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu

[PATCH v3 19/35] x86/io_apic: Cleanup trigger/polarity helpers

2020-10-24 Thread David Woodhouse
of 'trigger' and 'polarity' is opaque and confusing at best. Rename them to 'is_level' and 'active_low' and make them boolean in various structs so it's entirely clear what the meaning is. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/include/asm/hw_irq.h | 6

[PATCH v3 27/35] x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-24 Thread David Woodhouse
From: David Woodhouse All possible parent domains have a select method now. Make use of it. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- arch/x86/kernel/hpet.c | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel

[PATCH v3 08/35] x86/apic: Cleanup destination mode

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner apic::irq_dest_mode is actually a boolean, but defined as u32 and named in a way which does not explain what it means. Make it a boolean and rename it to 'dest_mode_logical' Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/include/asm/apic.h

[PATCH v3 16/35] x86/kvm: Use msi_msg shadow structs

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner Use the bitfields in the x86 shadow structs instead of decomposing the 32bit value with macros. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/kvm/irq_comm.c | 31 +-- 1 file changed, 13 insertions(+), 18 deletions

[PATCH v3 30/35] iommu/vt-d: Simplify intel_irq_remapping_select()

2020-10-24 Thread David Woodhouse
From: David Woodhouse Now that the old get_irq_domain() method has gone, consolidate on just the map_XXX_to_iommu() functions. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- drivers/iommu/intel/irq_remapping.c | 19 +++ 1 file changed, 7 insertions(+), 12

[PATCH v3 34/35] x86/kvm: Reserve KVM_FEATURE_MSI_EXT_DEST_ID

2020-10-24 Thread David Woodhouse
From: David Woodhouse No functional change; just reserve the feature bit for now so that VMMs can start to implement it. This will allow the host to indicate that MSI emulation supports 15-bit destination IDs, allowing up to 32768 CPUs without interrupt remapping. cf. https

[PATCH v3 25/35] iommu/vt-d: Implement select() method on remapping irqdomain

2020-10-24 Thread David Woodhouse
From: David Woodhouse Preparatory for removing irq_remapping_get_irq_domain() Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- drivers/iommu/intel/irq_remapping.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/iommu/intel/irq_remapping.c b

[PATCH v3 11/35] genirq/msi: Allow shadow declarations of msi_msg::$member

2020-10-24 Thread David Woodhouse
representation for each member of msi_msg. Provide empty defaults for each and stick them into an union. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- include/asm-generic/msi.h | 4 include/linux/msi.h | 46 +++ 2 files changed, 46

[PATCH v3 33/35] iommu/hyper-v: Disable IRQ pseudo-remapping if 15 bit APIC IDs are available

2020-10-24 Thread David Woodhouse
From: David Woodhouse If the 15-bit APIC ID support is present in emulated MSI then there's no need for the pseudo-remapping support. Signed-off-by: David Woodhouse --- drivers/iommu/hyperv-iommu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iommu/hyperv-iommu.c b/drivers

[PATCH v3 05/35] x86/apic: Cleanup delivery mode defines

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner The enum ioapic_irq_destination_types and the enumerated constants starting with 'dest_' are gross misnomers because they describe the delivery mode. Rename then enum and the constants so they actually make sense. Signed-off-by: Thomas Gleixner Signed-off-by: David

[PATCH v3 22/35] genirq/irqdomain: Implement get_name() method on irqchip fwnodes

2020-10-24 Thread David Woodhouse
From: David Woodhouse Prerequesite to make x86 more irqdomain compliant. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- kernel/irq/irqdomain.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c

[PATCH v3 18/35] x86/msi: Remove msidef.h

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner Nothing uses the macro maze anymore. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/include/asm/msidef.h | 57 --- 1 file changed, 57 deletions(-) delete mode 100644 arch/x86/include/asm/msidef.h diff --git

[PATCH v3 00/35] Fix x2apic enablement and allow more CPUs, clean up I/OAPIC and MSI bitfields

2020-10-24 Thread David Woodhouse
parent irqchip's MSI messages. • Clean up HPET MSI support into hpet.c now that we can. David Woodhouse (19): x86/apic: Fix x2apic enablement without interrupt remapping x86/msi: Only use high bits of MSI address for DMAR unit x86/apic: Always provide irq_compose_msi_msg() method

[PATCH v3 12/35] x86/msi: Provide msi message shadow structs

2020-10-24 Thread David Woodhouse
not all to be a union] Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/include/asm/msi.h | 49 + arch/x86/kernel/apic/apic.c | 35 ++ 2 files changed, 68 insertions(+), 16 deletions(-) diff --git a/arch/x86

[PATCH v3 02/35] x86/msi: Only use high bits of MSI address for DMAR unit

2020-10-24 Thread David Woodhouse
From: David Woodhouse 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

[PATCH v3 03/35] x86/apic/uv: Fix inconsistent destination mode

2020-10-24 Thread David Woodhouse
-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/kernel/apic/x2apic_uv_x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c b/arch/x86/kernel/apic/x2apic_uv_x.c index 714233cee0b5..9ade9e6a95ff 100644 --- a/arch/x86/kernel/apic

[PATCH v3 06/35] x86/apic: Replace pointless apic::dest_logical usage

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner All these functions are only used for logical destination mode. So reading the destination mode mask from the apic structure is a pointless exercise. Just hand in the proper constant: APIC_DEST_LOGICAL. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse

[PATCH v3 17/35] x86/pci/xen: Use msi_msg shadow structs

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner Use the msi_msg shadow structs and compose the message with named bitfields instead of the unreadable macro maze. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/pci/xen.c | 26 +++--- 1 file changed, 11 insertions(+), 15

[PATCH v3 28/35] x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-24 Thread David Woodhouse
From: David Woodhouse All possible parent domains have a select method now. Make use of it. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/io_apic.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/arch

[PATCH v3 31/35] x86/ioapic: Handle Extended Destination ID field in RTE

2020-10-24 Thread David Woodhouse
From: David Woodhouse Bits 63-48 of the I/OAPIC Redirection Table Entry map directly to bits 19-4 of the address used in the resulting MSI cycle. Historically, the x86 MSI format only used the top 8 of those 16 bits as the destination APIC ID, and the "Extended Destination ID" in t

[PATCH v3 32/35] x86/apic: Support 15 bits of APIC ID in MSI where available

2020-10-24 Thread David Woodhouse
From: David Woodhouse Some hypervisors can allow the guest to use the Extended Destination ID field in the MSI address to address up to 32768 CPUs. This applies to all downstream devices which generate MSI cycles, including HPET, I/OAPIC and PCI MSI. HPET and PCI MSI use the same

[PATCH v3 14/35] iommu/amd: Use msi_msg shadow structs

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner Get rid of the macro mess and use the shadow structs for the x86 specific MSI message format. Convert the intcapxt setup to use named bitfields as well while touching it anyway. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- drivers/iommu/amd/init.c

[PATCH v3 07/35] x86/apic: Get rid of apic::dest_logical

2020-10-24 Thread David Woodhouse
. This will be cleaned up in a subsequent change. Remove apic::dest_logical and fixup the remaining users. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/include/asm/apic.h | 2 -- arch/x86/kernel/apic/apic.c | 2 +- arch/x86/kernel/apic/apic_flat_64.c

[PATCH v3 04/35] x86/devicetree: Fix the ioapic interrupt type table

2020-10-24 Thread David Woodhouse
the type information for consistency sake. No functional change. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- arch/x86/kernel/devicetree.c | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/arch/x86/kernel/devicetree.c b

[PATCH v3 01/35] x86/apic: Fix x2apic enablement without interrupt remapping

2020-10-24 Thread David Woodhouse
From: David Woodhouse Currently, Linux as a hypervisor guest will enable x2apic only if there are no CPUs present at boot time with an APIC ID above 255. Hotplugging a CPU later with a higher APIC ID would result in a CPU which cannot be targeted by external interrupts. Add a filter

[PATCH v3 15/35] PCI: vmd: Use msi_msg shadow structs

2020-10-24 Thread David Woodhouse
From: Thomas Gleixner Use the x86 shadow structs in msi_msg instead of the macros. Signed-off-by: Thomas Gleixner Signed-off-by: David Woodhouse --- drivers/pci/controller/vmd.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/pci/controller/vmd.c b

[PATCH v3 09/35] x86/apic: Always provide irq_compose_msi_msg() method for vector domain

2020-10-24 Thread David Woodhouse
From: David Woodhouse This shouldn't be dependent on PCI_MSI. HPET and I/O-APIC can deliver interrupts through MSI without having any PCI in the system at all. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/apic.h | 8 +++- arch/x86/kernel/apic

[PATCH v3 23/35] x86/apic: Add select() method on vector irqdomain

2020-10-24 Thread David Woodhouse
From: David Woodhouse This will be used to select the irqdomain for I/O-APIC and HPET. Signed-off-by: David Woodhouse Signed-off-by: Thomas Gleixner --- arch/x86/include/asm/irqdomain.h | 3 +++ arch/x86/kernel/apic/vector.c| 43 2 files changed, 46

[PATCH v3 35/35] x86/kvm: Enable 15-bit extension when KVM_FEATURE_MSI_EXT_DEST_ID detected

2020-10-24 Thread David Woodhouse
From: David Woodhouse This allows the host to indicate that MSI emulation supports 15-bit destination IDs, allowing up to 32768 CPUs without interrupt remapping. cf. https://patchwork.kernel.org/patch/11816693/ for qemu Signed-off-by: David Woodhouse Acked-by: Paolo Bonzini --- arch/x86

Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built

2020-10-17 Thread David Woodhouse
On Wed, 2020-10-14 at 14:57 +0200, Joerg Roedel wrote: > On Wed, Oct 14, 2020 at 03:25:08PM +0800, Lu Baolu wrote: > > I suppose Joerg will pick this up. I guess you don't need to resend it > > unless Joerg asks you to do. > > Yes, will pick this up soon, no need to re-send. Please could it, and

Re: [PATCH next] iommu: intel: don't dereference iommu_device if IOMMU_API is not built

2020-10-13 Thread David Woodhouse
ly handle DMAR units with no > supported address widths") > Signed-off-by: Bartosz Golaszewski Oops, apologies for that. Thanks for fixing it. Acked-by: David Woodhouse smime.p7s Description: S/MIME cryptographic signature ___ iommu ma

[PATCH 6/9] x86/hpet: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- arch/x86/kernel/hpet.c | 23 +-- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index 3b8b12769f3b..fb7736ca7b5b 100644 --- a/arch/x86/kernel/hpet.c

[PATCH 4/9] iommu/vt-d: Implement select() method on remapping irqdomain

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- drivers/iommu/intel/irq_remapping.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/iommu/intel/irq_remapping.c b/drivers/iommu/intel/irq_remapping.c index 511dfb4884bc..40c2fec122b8 100644 --- a/drivers/iommu

[PATCH 0/9] Remove irq_remapping_get_irq_domain()

2020-10-13 Thread David Woodhouse
s at https://patchwork.kernel.org/project/kvm/list/?series=362037 https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/ext_dest_id David Woodhouse (9): genirq/irqdomain: Implement get_name() method on irqchip fwnodes x86/apic: Add select() method on vector irqdomain iommu/amd: Implem

[PATCH 7/9] x86/ioapic: Use irq_find_matching_fwspec() to find remapping irqdomain

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- arch/x86/kernel/apic/io_apic.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index ca2da19d5c55..73cacc92c3bb 100644

[PATCH 1/9] genirq/irqdomain: Implement get_name() method on irqchip fwnodes

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- kernel/irq/irqdomain.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index 76cd7ebd1178..6440f97c412e 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq

[PATCH 5/9] iommu/hyper-v: Implement select() method on remapping irqdomain

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- drivers/iommu/hyperv-iommu.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/iommu/hyperv-iommu.c b/drivers/iommu/hyperv-iommu.c index 37dd485a5640..6a8966fbc3bd 100644 --- a/drivers/iommu/hyperv-iommu.c +++ b

[PATCH 9/9] iommu/vt-d: Simplify intel_irq_remapping_select()

2020-10-13 Thread David Woodhouse
From: David Woodhouse Now that the old get_irq_domain() method has gone, we can consolidate on just the map_XXX_to_iommu() functions. Signed-off-by: David Woodhouse --- drivers/iommu/intel/irq_remapping.c | 19 +++ 1 file changed, 7 insertions(+), 12 deletions(-) diff --git

[PATCH 3/9] iommu/amd: Implement select() method on remapping irqdomain

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- drivers/iommu/amd/iommu.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 13d0a8f42d56..7ecebc5d255f 100644 --- a/drivers/iommu/amd/iommu.c +++ b

[PATCH 8/9] x86: Kill all traces of irq_remapping_get_irq_domain()

2020-10-13 Thread David Woodhouse
From: David Woodhouse Signed-off-by: David Woodhouse --- arch/x86/include/asm/hw_irq.h| 2 -- arch/x86/include/asm/irq_remapping.h | 9 drivers/iommu/amd/iommu.c| 34 drivers/iommu/hyperv-iommu.c | 9 drivers/iommu

[PATCH 2/9] x86/apic: Add select() method on vector irqdomain

2020-10-13 Thread David Woodhouse
From: David Woodhouse This will be used to select the irqdomain for I/OAPIC and HPET. Signed-off-by: David Woodhouse --- arch/x86/include/asm/irqdomain.h | 3 +++ arch/x86/kernel/apic/vector.c| 43 2 files changed, 46 insertions(+) diff --git a/arch/x86

Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-09 Thread David Woodhouse
On Thu, 2020-10-08 at 14:40 +0200, Thomas Gleixner wrote: > Subject: x86/iommu: Make interrupt remapping more robust > From: Thomas Gleixner > Date: Thu, 08 Oct 2020 14:09:44 +0200 > > Needs to be split into pieces and cover PCI proper. Right now PCI gets a > NULL pointer assigned which makes it

Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-08 Thread David Woodhouse
On Thu, 2020-10-08 at 11:34 +0200, Thomas Gleixner wrote: > The overall conclusion for this is: > > 1) X2APIC support on bare metal w/o irq remapping is not going to > happen unless you: > > - added support in multi-queue devices which utilize managed > interrupts > >

Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-08 Thread David Woodhouse
On Wed, 2020-10-07 at 17:57 +0200, Thomas Gleixner wrote: > TLDR & HTF; > > Multiqueue devices want to have at max 1 queue per CPU or if the device > has less queues than CPUs they want the queues to have a fixed > association to a set of CPUs. > > At setup time this is established considering

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 19:23 +0200, Thomas Gleixner wrote: > > It so happens that in Linux, we don't really architect the software > > like that. So each of the PCI MSI domain, HPET, and IOAPIC have their > > *own* message composer which has the same limits and composes basically > > the same

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On 7 October 2020 17:02:59 BST, Thomas Gleixner wrote: >On Wed, Oct 07 2020 at 15:23, David Woodhouse wrote: >> On Wed, 2020-10-07 at 16:05 +0200, Thomas Gleixner wrote: >>> On Wed, Oct 07 2020 at 14:08, David Woodhouse wrote: >>> > On 7 October 2020 13:59:0

Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-07 Thread David Woodhouse
On 7 October 2020 16:57:36 BST, Thomas Gleixner wrote: >On Wed, Oct 07 2020 at 15:10, David Woodhouse wrote: >> On Wed, 2020-10-07 at 15:37 +0200, Thomas Gleixner wrote: >>> What is preventing you to change the function signature? But handing >>> down ir

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 17:25 +0200, Thomas Gleixner wrote: > It's clearly how the hardware works. MSI has a message store of some > sorts and if the entry is enabled then the MSI chip (in PCI or > elsewhere) will send exactly the message which is in that message > store. It knows absolutely nothing

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 16:05 +0200, Thomas Gleixner wrote: > > > The information has to property of the relevant irq domains and the > > > hierarchy allows you nicely to retrieve it from there instead of > > > sprinkling this all over the place. > > > > No. This is not a property of the parent

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 16:05 +0200, Thomas Gleixner wrote: > On Wed, Oct 07 2020 at 14:08, David Woodhouse wrote: > > On 7 October 2020 13:59:00 BST, Thomas Gleixner wrote: > > > On Wed, Oct 07 2020 at 08:48, David Woodhouse wrote: > > > > To fix *that* case, we r

Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 15:37 +0200, Thomas Gleixner wrote: > On Wed, Oct 07 2020 at 08:19, David Woodhouse wrote: > > On Tue, 2020-10-06 at 23:26 +0200, Thomas Gleixner wrote: > > > On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote: > > &

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On 7 October 2020 13:59:00 BST, Thomas Gleixner wrote: >On Wed, Oct 07 2020 at 08:48, David Woodhouse wrote: >> On Tue, 2020-10-06 at 23:54 +0200, Thomas Gleixner wrote: >>> On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote: >> This is the case I called

Re: [PATCH 13/13] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 13:15 +0200, Paolo Bonzini wrote: > On 07/10/20 10:59, David Woodhouse wrote: > > Yeah, I was expecting the per-irqdomain affinity support to take a few > > iterations. But this part, still sticking with the current behaviour of > > only allowing CPUs

Re: [PATCH 13/13] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

2020-10-07 Thread David Woodhouse
On Wed, 2020-10-07 at 10:14 +0200, Paolo Bonzini wrote: > Looks like the rest of the series needs some more work, but anyway: > > Acked-by: Paolo Bonzini Thanks. Yeah, I was expecting the per-irqdomain affinity support to take a few iterations. But this part, still sticking with the current

Re: [PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-07 Thread David Woodhouse
On Tue, 2020-10-06 at 23:54 +0200, Thomas Gleixner wrote: > On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote: > > > From: David Woodhouse > > > > When interrupt remapping isn't enabled, only the first 255 CPUs can > > No, only CPUs with an APICid < 255

Re: [PATCH 09/13] x86/irq: Add x86_non_ir_cpumask

2020-10-07 Thread David Woodhouse
On Tue, 2020-10-06 at 23:42 +0200, Thomas Gleixner wrote: > On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote: > > From: David Woodhouse > > > > This is the mask of CPUs to which IRQs can be delivered without > > interrupt > > remapping. > > > >

Re: [PATCH 08/13] genirq: Add irq_domain_set_affinity()

2020-10-07 Thread David Woodhouse
On Tue, 2020-10-06 at 23:32 +0200, Thomas Gleixner wrote: > What the heck? Why does this need a setter function which is exported? > So that random driver writers can fiddle with it? > > The affinity mask restriction of an irq domain is already known when the > domain is created. It's exported

Re: [PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-07 Thread David Woodhouse
On Tue, 2020-10-06 at 23:26 +0200, Thomas Gleixner wrote: > On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote: > > From: David Woodhouse > > > > This is the maximum possible set of CPUs which can be used. Use it > > to calculate the default affinity reque

Re: [PATCH 05/13] genirq: Prepare for default affinity to be passed to __irq_alloc_descs()

2020-10-06 Thread David Woodhouse
On 6 October 2020 22:01:18 BST, Thomas Gleixner wrote: >On Mon, Oct 05 2020 at 16:28, David Woodhouse wrote: >> >> #else /* CONFIG_SMP */ >> >> +#define irq_default_affinity (NULL) > >... > >> static int alloc_descs(unsig

[PATCH 05/13] genirq: Prepare for default affinity to be passed to __irq_alloc_descs()

2020-10-05 Thread David Woodhouse
From: David Woodhouse Instead of plugging in irq_default_affinity at the lowest level in desc_smp_init() if the caller didn't specify an affinity for this specific IRQ in its array, allow the default affinity to be passed down from __irq_alloc_descs() instead. This is in preparation for irq

[PATCH 04/13] x86/apic: Support 15 bits of APIC ID in IOAPIC/MSI where available

2020-10-05 Thread David Woodhouse
From: David Woodhouse Some hypervisors can allow the guest to use the Extended Destination ID field in the IOAPIC RTE and MSI address to address up to 32768 CPUs. Signed-off-by: David Woodhouse --- arch/x86/include/asm/mpspec.h | 1 + arch/x86/include/asm/x86_init.h | 2 ++ arch/x86

[PATCH 12/13] iommu/irq_remapping: Kill most of hyperv-iommu.c now it's redundant

2020-10-05 Thread David Woodhouse
From: David Woodhouse It took me a while to realise that this "IRQ remapping" driver exists not to actually remap interrupts, but to return -EINVAL if anyone ever tries to set the affinity to a set of CPUs which can't be reached *without* remapping. Having fixed the core IRQ d

[PATCH 13/13] x86/kvm: Add KVM_FEATURE_MSI_EXT_DEST_ID

2020-10-05 Thread David Woodhouse
From: David Woodhouse This allows the host to indicate that IOAPIC and MSI emulation supports 15-bit destination IDs, allowing up to 32Ki CPUs without remapping. Signed-off-by: David Woodhouse --- Documentation/virt/kvm/cpuid.rst | 4 arch/x86/include/uapi/asm/kvm_para.h | 1 + arch

[PATCH 01/13] x86/apic: Use x2apic in guest kernels even with unusable CPUs.

2020-10-05 Thread David Woodhouse
From: David Woodhouse If the BIOS has enabled x2apic mode, then leave it enabled and don't fall back to xapic just because some CPUs can't be targeted. Previously, if there are CPUs with APIC IDs > 255, the kernel will disable x2apic and fall back to xapic. And then not use the additional C

[PATCH 11/13] x86/smp: Allow more than 255 CPUs even without interrupt remapping

2020-10-05 Thread David Woodhouse
From: David Woodhouse Now that external interrupt affinity can be limited to the range of CPUs that can be reached through legacy IOAPIC RTEs and MSI, it is possible to use additional CPUs. Signed-off-by: David Woodhouse --- arch/x86/kernel/apic/apic.c | 2 -- 1 file changed, 2 deletions

[PATCH 07/13] irqdomain: Add max_affinity argument to irq_domain_alloc_descs()

2020-10-05 Thread David Woodhouse
From: David Woodhouse This is the maximum possible set of CPUs which can be used. Use it to calculate the default affinity requested from __irq_alloc_descs() by first attempting to find the intersection with irq_default_affinity, or falling back to using just the max_affinity if the intersection

[PATCH 08/13] genirq: Add irq_domain_set_affinity()

2020-10-05 Thread David Woodhouse
From: David Woodhouse This allows a maximal affinity to be set, for IRQ domains which cannot target all CPUs in the system. Signed-off-by: David Woodhouse --- include/linux/irqdomain.h | 4 kernel/irq/irqdomain.c| 28 ++-- kernel/irq/manage.c | 19

[PATCH 02/13] x86/msi: Only use high bits of MSI address for DMAR unit

2020-10-05 Thread David Woodhouse
From: David Woodhouse 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

[PATCH 09/13] x86/irq: Add x86_non_ir_cpumask

2020-10-05 Thread David Woodhouse
From: David Woodhouse This is the mask of CPUs to which IRQs can be delivered without interrupt remapping. Signed-off-by: David Woodhouse --- arch/x86/include/asm/mpspec.h | 1 + arch/x86/kernel/apic/apic.c| 12 arch/x86/kernel/apic/io_apic.c | 2 ++ 3 files changed, 15

[PATCH 06/13] genirq: Add default_affinity argument to __irq_alloc_descs()

2020-10-05 Thread David Woodhouse
From: David Woodhouse It already takes an array of affinities for each individual irq being allocated but that's awkward to allocate and populate in the case where they're all the same and inherited from the irqdomain, so pass the default in separately as a simple cpumask. Signed-off-by: David

[PATCH 03/13] x86/ioapic: Handle Extended Destination ID field in RTE

2020-10-05 Thread David Woodhouse
From: David Woodhouse The IOAPIC Redirection Table Entries contain an 8-bit Extended Destination ID field which maps to bits 11-4 of the MSI address. The lowest bit is used to indicate remappable format, when interrupt remapping is in use. A hypervisor can use the other 7 bits to permit guests

[PATCH 0/13] Fix per-domain IRQ affinity, allow >255 CPUs on x86 without IRQ remapping

2020-10-05 Thread David Woodhouse
11-5 without even needing to use remapping. David Woodhouse (13): x86/apic: Use x2apic in guest kernels even with unusable CPUs. x86/msi: Only use high bits of MSI address for DMAR unit x86/ioapic: Handle Extended Destination ID field in RTE x86/apic: Support 15 bits of APIC

[PATCH 10/13] x86/irq: Limit IOAPIC and MSI domains' affinity without IR

2020-10-05 Thread David Woodhouse
From: David Woodhouse When interrupt remapping isn't enabled, only the first 255 CPUs can receive external interrupts. Set the appropriate max affinity for the IOAPIC and MSI IRQ domains accordingly. This also fixes the case where interrupt remapping is enabled but some devices are not within

[PATCH] iommu/vt-d: gracefully handle DMAR units with no supported address widths

2020-09-24 Thread David Woodhouse
From: David Woodhouse Instead of bailing out completely, such a unit can still be used for interrupt remapping. Signed-off-by: David Woodhouse --- drivers/iommu/intel/dmar.c | 46 +- 1 file changed, 31 insertions(+), 15 deletions(-) diff --git a/drivers

Re: [PATCH 0/4] PCI, iommu: Factor 'untrusted' check for ATS enablement

2020-05-18 Thread David Woodhouse
On Fri, 2020-05-15 at 10:19 -0700, Raj, Ashok wrote: > Hi Christoph > > On Fri, May 15, 2020 at 08:43:51AM -0700, Christoph Hellwig wrote: > > Can you please lift the untrusted flag into struct device? It really > > isn't a PCI specific concept, and we should not have code poking into > >

Re: [PATCH] swiotlb: Allow swiotlb to live at pre-defined address

2020-03-26 Thread David Woodhouse
On Thu, 2020-03-26 at 18:11 +0100, Alexander Graf wrote: > I'm with you on that sentiment, but in the environment I'm currently > looking at, we have neither DT nor ACPI: The kernel gets purely > configured via kernel command line. For other unenumerable artifacts on > the system, such as

Re: [PATCH 0/5] iommu/vt-d: Consolidate various cache flush ops

2019-12-03 Thread David Woodhouse
On Fri, 2019-11-22 at 11:04 +0800, Lu Baolu wrote: > Intel VT-d 3.0 introduces more caches and interfaces for software to > flush when it runs in the scalable mode. Currently various cache flush > helpers are scattered around. This consolidates them by putting them in > the existing iommu_flush

Re: [PATCH] intel-iommu: Turn off translations at shutdown

2019-11-08 Thread David Woodhouse
On Fri, 2019-11-08 at 08:47 +, Zeng, Jason wrote: > > -Original Message- > > From: David Woodhouse > > Sent: Friday, November 8, 2019 3:54 PM > > To: Deepa Dinamani ; j...@8bytes.org; linux- > > ker...@vger.kernel.org > > Cc: iommu@lists.linux-fo

Re: [PATCH] intel-iommu: Turn off translations at shutdown

2019-11-07 Thread David Woodhouse
On Thu, 2019-11-07 at 12:59 -0800, Deepa Dinamani wrote: > The intel-iommu driver assumes that the iommu state is > cleaned up at the start of the new kernel. > But, when we try to kexec boot something other than the > Linux kernel, the cleanup cannot be relied upon. > Hence, cleanup before we go

  1   2   3   >