On Fri, 2022-05-06 at 06:49 +, Tian, Kevin wrote:
> > From: Baolu Lu
> >
> > > --- a/include/linux/dmar.h
> > > +++ b/include/linux/dmar.h
> > > @@ -19,7 +19,7 @@
> > > struct acpi_dmar_header;
> > >
> > > #ifdef CONFIG_X86
> > > -# define DMAR_UNITS_SUPPORTEDMAX_IO_APICS
> > > +#
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
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)
>
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
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
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
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
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
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
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,
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.
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
. 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
>
>
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
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
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
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
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
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
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
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:
> > &
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
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
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
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
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.
> >
> >
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> >
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
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
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
1 - 100 of 276 matches
Mail list logo
