> From: Lu Baolu
> Sent: Thursday, August 27, 2020 12:25 PM
>
> The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
> General
> Description) that:
>
> If multiple control fields in this register need to be modified, software
> must serialize the modifications through multiple
On Wed, 2020-08-26 at 16:56 +0800, Miles Chen wrote:
> In previous discussion [1] and [2], we found that it is risky to
> use max_pfn or totalram_pages to tell if 4GB mode is enabled.
>
> Check 4GB mode by reading infracfg register, remove the usage
> of the un-exported symbol max_pfn.
>
> This
The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG General
Description) that:
If multiple control fields in this register need to be modified, software
must serialize the modifications through multiple writes to this register.
However, in irq_remapping.c, modifications of IRE and
Hi Kevin,
On 8/26/20 1:29 PM, Tian, Kevin wrote:
From: Lu Baolu
Sent: Wednesday, August 26, 2020 10:58 AM
The VT-d spec requires (10.4.4 Global Command Register, GCMD_REG
General
Description) that:
If multiple control fields in this register need to be modified, software
must serialize the
Hello,
I had a similiar panic when booting an ARM VM with kernel v5.9-rc1. git
bisect identified following bad commit. After reverting the bad commit,
the VM boot ok. Maybe we should look into the following commit.
d323bb44e4d23802eb25d13de1f93f2335bd60d0 is the first bad commit
commit
On Wed, 26 Aug 2020 20:47:38 +0100,
Thomas Gleixner wrote:
>
> On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote:
> > On Wed, 26 Aug 2020 12:16:57 +0100,
> > Thomas Gleixner wrote:
> >> /**
> >> - * msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain
> >> associated tp @dev
>
On Wed, 26 Aug 2020 22:19:56 +0100,
Thomas Gleixner wrote:
>
> On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote:
> > On Wed, 26 Aug 2020 12:16:32 +0100,
> > Thomas Gleixner wrote:
> >> ---
> >> V2: New patch. Note, that this might break other stuff which relies on the
> >> current
On Wed, Aug 26 2020 at 22:14, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:17:02 +0100,
> Thomas Gleixner wrote:
>> @@ -103,6 +105,7 @@ config PCIE_XILINX_CPM
>> bool "Xilinx Versal CPM host bridge support"
>> depends on ARCH_ZYNQMP || COMPILE_TEST
>> select PCI_HOST_COMMON
>> +
On Wed, 26 Aug 2020 12:17:09 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> For the upcoming device MSI support it's required to have a default
> irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
> need to care.
>
> Signed-off-by: Thomas Gleixner
>
> ---
On Wed, Aug 26 2020 at 20:50, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:16:32 +0100,
> Thomas Gleixner wrote:
>> ---
>> V2: New patch. Note, that this might break other stuff which relies on the
>> current behaviour, but the hierarchy composition of DT based chips is
>> really hard to
On Wed, 26 Aug 2020 12:17:02 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture
> requires them or not. Architectures which are fully utilizing hierarchical
> irq domains should never call into that code.
>
>
On Wed, 2020-08-26 at 21:42 +0100, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:16:51 +0100,
> Thomas Gleixner wrote:
> > From: Thomas Gleixner
> >
> > PCI devices behind a VMD bus are not subject to interrupt remapping, but
> > the irq domain for VMD MSI cannot be distinguished from a regular
On Wed, Aug 26 2020 at 20:32, Thomas Gleixner wrote:
> On Wed, Aug 26 2020 at 09:50, Megha Dey wrote:
>>> @@ -329,15 +329,15 @@ static struct irq_chip dmar_msi_controll
>>> static irq_hw_number_t dmar_msi_get_hwirq(struct msi_domain_info *info,
>>>
On Wed, 26 Aug 2020 12:16:52 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> Devices on the VMD bus use their own MSI irq domain, but it is not
> distinguishable from regular PCI/MSI irq domains. This is required
> to exclude VMD devices from getting the irq domain pointer set by
>
On Wed, Aug 26 2020 at 21:21, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:16:47 +0100,
> Thomas Gleixner wrote:
>> -void pci_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
>> -{
>> -arg->desc = desc;
>> -arg->hwirq = pci_msi_domain_calc_hwirq(desc);
>> -}
>>
On Wed, 26 Aug 2020 12:16:51 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> PCI devices behind a VMD bus are not subject to interrupt remapping, but
> the irq domain for VMD MSI cannot be distinguished from a regular PCI/MSI
> irq domain.
>
> Add a new domain bus token and allow
On Wed, 26 Aug 2020 12:16:45 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> Retrieve the PCI device from the msi descriptor instead of doing so at the
> call sites.
>
> Signed-off-by: Thomas Gleixner
> Acked-by: Bjorn Helgaas
Acked-by: Marc Zyngier
M.
--
Without
On Wed, 26 Aug 2020 12:16:47 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> pci_msi_get_hwirq() and pci_msi_set_desc are not longer special. Enable the
> generic MSI domain ops in the core and PCI MSI code unconditionally and get
> rid of the x86 specific implementations in the
On Wed, 26 Aug 2020 12:16:32 +0100,
Thomas Gleixner wrote:
>
> The documentation of irq_chip_compose_msi_msg() claims that with
> hierarchical irq domains the first chip in the hierarchy which has an
> irq_compose_msi_msg() callback is chosen. But the code just keeps
> iterating after it finds a
On Wed, Aug 26 2020 at 20:06, Marc Zyngier wrote:
> On Wed, 26 Aug 2020 12:16:57 +0100,
> Thomas Gleixner wrote:
>> /**
>> - * msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain
>> associated tp @dev
>> - * @domain: The domain to managing the interrupts
>> + *
On Wed, 26 Aug 2020 12:16:57 +0100,
Thomas Gleixner wrote:
>
> From: Thomas Gleixner
>
> To support MSI irq domains which do not fit at all into the regular MSI
> irqdomain scheme, like the XEN MSI interrupt management for PV/HVM/DOM0,
> it's necessary to allow to override the alloc/free
On Wed, Aug 26 2020 at 09:50, Megha Dey wrote:
>> @@ -329,15 +329,15 @@ static struct irq_chip dmar_msi_controll
>> static irq_hw_number_t dmar_msi_get_hwirq(struct msi_domain_info *info,
>>msi_alloc_info_t *arg)
>> {
>> -return arg->dmar_id;
>> +
On Mon, Aug 24, 2020 at 2:56 AM Tom Murphy wrote:
>
> Hi Logan/All,
>
> I have added a check for the sg_dma_len == 0 :
> """
> } __sgt_iter(struct scatterlist *sgl, bool dma) {
> struct sgt_iter s = { .sgp = sgl };
>
> + if (sgl && sg_dma_len(sgl) == 0)
> + s.sgp = NULL;
That would be great!
On Wed., Aug. 26, 2020, 2:14 p.m. Robin Murphy,
wrote:
> Hi Tom,
>
> On 2019-12-21 15:03, Tom Murphy wrote:
> > This patchset converts the intel iommu driver to the dma-iommu api.
> >
> > While converting the driver I exposed a bug in the intel i915 driver
> which causes a
Hi Tom,
On 2019-12-21 15:03, Tom Murphy wrote:
This patchset converts the intel iommu driver to the dma-iommu api.
While converting the driver I exposed a bug in the intel i915 driver which
causes a huge amount of artifacts on the screen of my laptop. You can see a
picture of it here:
Hi Thomas,
On 8/26/2020 4:16 AM, Thomas Gleixner wrote:
From: Thomas Gleixner
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5
The actual size of level-1 stream table is l1size. This looks like an
oversight on commit d2e88e7c081ef ("iommu/arm-smmu: Fix LOG2SIZE setting
for 2-level stream tables") which forgot to update the @size in error
message as well.
As memory allocation failure is already bad enough, nothing worse
[AMD Public Use]
+ Christian
> -Original Message-
> From: Kuehling, Felix
> Sent: Wednesday, August 26, 2020 11:22 AM
> To: Deucher, Alexander ; Joerg Roedel
> ; iommu@lists.linux-foundation.org; Huang, Ray
>
> Cc: jroe...@suse.de; Lendacky, Thomas ;
> Suthikulpanit, Suravee ; linux-
[AMD Public Use]
+ Felix, Christian
> -Original Message-
> From: Joerg Roedel
> Sent: Monday, August 24, 2020 6:54 AM
> To: iommu@lists.linux-foundation.org
> Cc: Joerg Roedel ; jroe...@suse.de; Lendacky, Thomas
> ; Suthikulpanit, Suravee
> ; Deucher, Alexander
> ;
[+Ray]
Thanks for the heads up. Currently KFD won't work on APUs when IOMMUv2
is disabled. But Ray is working on fallbacks that will allow KFD to work
on APUs even without IOMMUv2, similar to our dGPUs. Along with changes
in ROCm user mode, those fallbacks are necessary for making ROCm on APUs
On Wed, Aug 26 2020 at 13:17, Thomas Gleixner wrote:
> + * If CONFIG_PCI_MSI_ARCH_FALLBACKS is not selected they are replaced by
> + * stubs with warnings.
> */
> +#ifdef CONFIG_PCI_MSI_DISABLE_ARCH_FALLBACKS
Groan, I obviously failed to pull that back from the test box where I
fixed it. That
Hi,
On Wed, Aug 26, 2020 at 8:01 AM Sai Prakash Ranjan
wrote:
>
> On 2020-08-26 19:21, Robin Murphy wrote:
> > On 2020-08-26 13:17, Sai Prakash Ranjan wrote:
> >> On 2020-08-26 17:07, Robin Murphy wrote:
> >>> On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
> Currently the non-strict or lazy
On 2020-08-26 19:21, Robin Murphy wrote:
On 2020-08-26 13:17, Sai Prakash Ranjan wrote:
On 2020-08-26 17:07, Robin Murphy wrote:
On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
Currently the non-strict or lazy mode of TLB invalidation can only
be set
for all or no domains. This works well for
[AMD Public Use]
+ Felix, Christian
> -Original Message-
> From: Joerg Roedel
> Sent: Monday, August 24, 2020 6:54 AM
> To: iommu@lists.linux-foundation.org
> Cc: Joerg Roedel ; jroe...@suse.de; Lendacky, Thomas
> ; Suthikulpanit, Suravee
> ; Deucher, Alexander
> ;
[AMD Official Use Only - Internal Distribution Only]
+ Felix
From: Joerg Roedel
Sent: Monday, August 24, 2020 6:54 AM
To: iommu@lists.linux-foundation.org
Cc: Joerg Roedel ; jroe...@suse.de ;
Lendacky, Thomas ; Suthikulpanit, Suravee
; Deucher, Alexander
;
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.2, v5.7.16, v5.4.59, v4.19.140,
v4.14.193, v4.9.232, v4.4.232.
v5.8.2: Build
On 2020-08-26 13:17, Sai Prakash Ranjan wrote:
On 2020-08-26 17:07, Robin Murphy wrote:
On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
Currently the non-strict or lazy mode of TLB invalidation can only be
set
for all or no domains. This works well for development platforms where
setting to
Hi Marek,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on drm-intel/for-linux-next linus/master v5.9-rc2
next-20200826]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On Fri, Aug 21, 2020 at 03:15:34PM +0200, Jean-Philippe Brucker wrote:
> Add a topology description to the virtio-iommu driver and enable x86
> platforms.
>
> Since [v2] we have made some progress on adding ACPI support for
> virtio-iommu, which is the preferred boot method on x86. It will be a
>
On 2020-08-26 17:07, Robin Murphy wrote:
On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
Currently the non-strict or lazy mode of TLB invalidation can only be
set
for all or no domains. This works well for development platforms where
setting to non-strict/lazy mode is fine for performance
From: Thomas Gleixner
For devices which don't have a standard storage for MSI messages like the
upcoming IMS (Interrupt Message Storm) it's required to allocate storage
space before allocating interrupts and after freeing them.
This could be achieved with the existing callbacks, but that would
From: Thomas Gleixner
For the upcoming device MSI support it's required to have a default
irq_chip::ack implementation (irq_chip_ack_parent) so the drivers do not
need to care.
Signed-off-by: Thomas Gleixner
---
drivers/base/platform-msi.c |2 ++
1 file changed, 2 insertions(+)
---
Until now interrupt chips which support setting affinity are nit locking
the associated bus lock for two reasons:
- All chips which support affinity setting do not use buslock because they just
can operated directly on the hardware.
- All chips which use buslock do not support affinity
From: Thomas Gleixner
Rename it to x86_msi_prepare() and handle the allocation type setup
depending on the device type.
Add a new arch_msi_prepare define which will be utilized by the upcoming
device MSI support. Define it to NULL if not provided by an architecture in
the generic MSI header.
From: Thomas Gleixner
Add device specific MSI domain infrastructure for devices which have their
own resource management and interrupt chip. These devices are not related
to PCI and contrary to platform MSI they do not share a common resource and
interrupt chip. They provide their own domain
MSI interrupts have some common flags which should be set not only for
PCI/MSI interrupts.
Move the PCI/MSI flag setting into a common function so it can be reused.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/pci/msi.c |7 +--
include/linux/msi.h |1 +
Generic IMS irq chips and irq domain implementations for IMS based devices
in both variants:
- Message store in an array in device memory
- Message store in system RAM (part of queue memory)
Allocation and freeing of interrupts happens via the generic
msi_domain_alloc/free_irqs()
From: Thomas Gleixner
PCI devices behind a VMD bus are not subject to interrupt remapping, but
the irq domain for VMD MSI cannot be distinguished from a regular PCI/MSI
irq domain.
Add a new domain bus token and allow it in the bus token check in
msi_check_reservation_mode() to keep the
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
To achieve this XEN MSI interrupt management needs to be wrapped into an
irq domain.
Move the x86_msi ops setup
Now that the domain can be retrieved through device::msi_domain the domain
search for PCI_MSI[X] is not longer required. Remove it.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/iommu/intel/irq_remapping.c |3 ---
1 file changed, 3 deletions(-)
---
Now that the domain can be retrieved through device::msi_domain the domain
search for PCI_MSI[X] is not longer required. Remove it.
Signed-off-by: Thomas Gleixner
---
V2: New patch
---
drivers/iommu/amd/iommu.c |3 ---
1 file changed, 3 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++
From: Thomas Gleixner
As the next step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
It only overrides the irqdomain of devices which are handled by a regular
PCI/MSI irq domain which protects PCI devices
From: Thomas Gleixner
pci_msi_get_hwirq() and pci_msi_set_desc are not longer special. Enable the
generic MSI domain ops in the core and PCI MSI code unconditionally and get
rid of the x86 specific implementations in the X86 MSI code and in the
hyperv PCI driver.
Signed-off-by: Thomas Gleixner
From: Thomas Gleixner
Devices on the VMD bus use their own MSI irq domain, but it is not
distinguishable from regular PCI/MSI irq domains. This is required
to exclude VMD devices from getting the irq domain pointer set by
interrupt remapping.
Override the default bus token.
Signed-off-by:
From: Thomas Gleixner
The arch_.*_msi_irq[s] fallbacks are compiled in whether an architecture
requires them or not. Architectures which are fully utilizing hierarchical
irq domains should never call into that code.
It's not only architectures which depend on that by implementing one or
more of
From: Thomas Gleixner
struct irq_alloc_info is a horrible zoo of unnamed structs in a union. Many
of the struct fields can be generic and don't have to be type specific like
hpet_id, ioapic_id...
Provide a generic set of members to prepare for the consolidation. The goal
is to make
From: Thomas Gleixner
Provide a helper function to check whether a PCI device is handled by a
non-standard PCI/MSI domain. This will be used to exclude such devices
which hang of a special bus, e.g. VMD, to be excluded from the irq domain
override in irq remapping.
Signed-off-by: Thomas
From: Thomas Gleixner
To allow utilizing the irq domain pointer in struct device it is necessary
to make XEN/MSI irq domain compatible.
While the right solution would be to truly convert XEN to irq domains, this
is an exercise which is not possible for mere mortals with limited XENology.
From: Thomas Gleixner
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/intel/irq_remapping.c | 67
1 file changed, 24 insertions(+), 43
From: Thomas Gleixner
Retrieve the PCI device from the msi descriptor instead of doing so at the
call sites.
Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
---
V2: Address Bjorns comments (subject prefix, pdev/dev)
---
arch/x86/kernel/apic/msi.c |2 +-
drivers/pci/msi.c
From: Thomas Gleixner
The only user is in the same file and the name is too generic because this
function is only ever used for HVM domains.
Signed-off-by: Thomas Gleixner
Reviewed-by: Juergen Gross
---
arch/x86/pci/xen.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
From: Thomas Gleixner
Adding a function call before the first #ifdef in arch_pci_init() triggers
a 'mixed declarations and code' warning if PCI_DIRECT is enabled.
Use stub functions and move the #ifdeffery to the header file where it is
not in the way.
Signed-off-by: Thomas Gleixner
---
From: Thomas Gleixner
As a first step to make X86 utilize the direct MSI irq domain operations
store the irq domain pointer in the device struct when a device is probed.
This is done from dmar_pci_bus_add_dev() because it has to work even when
DMA remapping is disabled. It only overrides the
From: Thomas Gleixner
irq_remapping_ir_irq_domain() is used to retrieve the remapping parent
domain for an allocation type. irq_remapping_irq_domain() is for retrieving
the actual device domain for allocating interrupts for a device.
The two functions are similar and can be unified by using
From: Thomas Gleixner
To support MSI irq domains which do not fit at all into the regular MSI
irqdomain scheme, like the XEN MSI interrupt management for PV/HVM/DOM0,
it's necessary to allow to override the alloc/free implementation.
This is a preperatory step to switch X86 away from
From: Thomas Gleixner
Move the UV specific fields into their own struct for readability sake. Get
rid of the #ifdeffery as it does not matter at all whether the alloc info
is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h | 21
From: Thomas Gleixner
Now that interrupt remapping sets the irqdomain pointer when a PCI device
is added it's possible to store the default irq domain in the device struct
in pcibios_add_device().
If the bus to which a device is connected has an irq domain associated then
this domain is used
From: Thomas Gleixner
No functional change.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |4 ++--
arch/x86/kernel/apic/msi.c |6 +++---
drivers/iommu/amd/iommu.c | 24
drivers/iommu/intel/irq_remapping.c | 18
From: Thomas Gleixner
None of the magic HPET fields are required in any way.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |7 ---
arch/x86/kernel/apic/msi.c | 14 +++---
drivers/iommu/amd/iommu.c |2 +-
From: Thomas Gleixner
Get rid of all the gunk and remove the 'select PCI_MSI_ARCH_FALLBACK' from
the x86 Kconfig so the weak functions in the PCI core are replaced by stubs
which emit a warning, which ensures that any fail to set the irq domain
pointer results in a warning when the device is
From: Thomas Gleixner
No point to call it from both 32bit and 64bit implementations of
default_setup_apic_routing(). Move it to the caller.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/apic/apic.c |3 +++
arch/x86/kernel/apic/probe_32.c |3 ---
From: Thomas Gleixner
The irq domain request mode is now indicated in irq_alloc_info::type.
Consolidate the two getter functions into one.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c | 65 ++
1 file changed, 21 insertions(+), 44
From: Thomas Gleixner
For the upcoming device MSI support a new allocation type is
required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -40,6 +40,7 @@
From: Thomas Gleixner
Nothing except XEN uses the setup/teardown ops. Hide them there.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/x86_init.h |2 --
arch/x86/pci/xen.c | 21 ++---
2 files changed, 14 insertions(+), 9 deletions(-)
---
From: Thomas Gleixner
Move the IOAPIC specific fields into their own struct and reuse the common
devid. Get rid of the #ifdeffery as it does not matter at all whether the
alloc info is a couple of bytes longer or not.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |
From: Thomas Gleixner
X86 cannot store the irq domain pointer in struct device without breaking
XEN because the irq domain pointer takes precedence over arch_*_msi_irqs()
fallbacks.
XENs MSI teardown relies on default_teardown_msi_irqs() which invokes
arch_teardown_msi_irq().
From: Thomas Gleixner
No point in initializing the default PCI/MSI interrupt domain early and no
point to create it when XEN PV/HVM/DOM0 are active.
Move the initialization to pci_arch_init() and convert it to init ops so
that XEN can override it as XEN has it's own PCI/MSI management. The XEN
From: Thomas Gleixner
Convert the interrupt remap drivers to retrieve the pci device from the msi
descriptor and use info::hwirq.
This is the first step to prepare x86 for using the generic MSI domain ops.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |8
From: Thomas Gleixner
Some past platform removal forgot to get rid of this unused ballast.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/mpspec.h | 10 --
arch/x86/include/asm/x86_init.h | 10 --
arch/x86/kernel/mpparse.c | 26
Composing the MSI message at the MSI chip level is wrong because the
underlying parent domain is the one which knows how the message should be
composed for the direct vector delivery or the interrupt remapping table
entry.
The interrupt remapping aware PCI/MSI chip does that already. Make the
Setting the irq_set_vcpu_affinity() callback to
irq_chip_set_vcpu_affinity_parent() is a pointless exercise because the
function which utilizes it searchs the domain hierarchy to find a parent
domain which has such a callback.
Remove the useless indirection.
Signed-off-by: Thomas Gleixner
---
This is the second version of providing a base to support device MSI (non
PCI based) and on top of that support for IMS (Interrupt Message Storm)
based devices in a halfways architecture independent way.
The first version can be found here:
From: Thomas Gleixner
Now that the iommu implementations handle the X86_*_GET_PARENT_DOMAIN
types, consolidate the two getter functions.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/irq_remapping.h |8
arch/x86/kernel/apic/io_apic.c |2 +-
The documentation of irq_chip_compose_msi_msg() claims that with
hierarchical irq domains the first chip in the hierarchy which has an
irq_compose_msi_msg() callback is chosen. But the code just keeps
iterating after it finds a chip with a compose callback.
The x86 HPET MSI implementation relies
From: Thomas Gleixner
None of the DMAR specific fields are required.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/hw_irq.h |6 --
arch/x86/kernel/apic/msi.c| 10 +-
2 files changed, 5 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/hw_irq.h
+++
From: Thomas Gleixner
Dereferencing irq_data before checking it for NULL is suboptimal.
Signed-off-by: Thomas Gleixner
---
drivers/iommu/amd/iommu.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iommu/amd/iommu.c
+++ b/drivers/iommu/amd/iommu.c
@@ -3717,8
VMD has it's own PCI/MSI interrupt domain which is not in any way depending
on the x86 vector domain. PCI devices behind VMD share the VMD MSIX vector
entries via a VMD specific message translation to the actual VMD MSIX
vector. The VMD device interrupt handler for the VMD MSIX vectors invokes
all
On 2020-08-25 16:42, Sai Prakash Ranjan wrote:
Currently the non-strict or lazy mode of TLB invalidation can only be set
for all or no domains. This works well for development platforms where
setting to non-strict/lazy mode is fine for performance reasons but on
production devices, we need a
The "page" pointer can be used with out being initialized.
Fixes: d7e673ec2c8e ("dma-pool: Only allocate from CMA when in same memory
zone")
Signed-off-by: Dan Carpenter
---
kernel/dma/pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/pool.c
On Wed, Aug 26, 2020 at 06:27:51AM -0400, FelixCuioc wrote:
> After acpi device in RMRR is detected,it is necessary
> to establish a mapping for these devices.
> In acpi_device_create_direct_mappings(),create a mapping
> for the acpi device in RMRR.
> Add a helper to achieve the acpi namespace
On Wed, Aug 26, 2020 at 06:27:52AM -0400, FelixCuioc wrote:
> In the probe_acpi_namespace_devices function,when the physical
> node of the acpi device is NULL,the unlock function is missing.
> Add mutex_unlock(>physical_node_lock).
>
> Reported-by: Dan Carpenter
> Signed-off-by: FelixCuioc
On Wed, Aug 26, 2020 at 06:27:50AM -0400, FelixCuioc wrote:
> Some ACPI devices need to issue dma requests to access
> the reserved memory area.BIOS uses the device scope type
> ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
> This patch add support for detecting ACPI devices in RMRR.
In the probe_acpi_namespace_devices function,when the physical
node of the acpi device is NULL,the unlock function is missing.
Add mutex_unlock(>physical_node_lock).
Reported-by: Dan Carpenter
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 74
BIOS allocate reserved memory ranges that may be DMA targets.
BIOS may report each such reserved memory region through the
RMRR structures,along with the devices that requires access to
the specified reserved memory region.
The purpose of this series is to achieve ACPI device in RMRR
access
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the RMRR region.
Signed-off-by: FelixCuioc
---
In the probe_acpi_namespace_devices function,when the physical
node of the acpi device is NULL,the unlock function is missing.
Add mutex_unlock(>physical_node_lock).
Reported-by: Dan Carpenter
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/iommu.c | 1 +
1 file changed, 1 insertion(+)
diff
Some ACPI devices need to issue dma requests to access
the reserved memory area.BIOS uses the device scope type
ACPI_NAMESPACE_DEVICE in RMRR to report these ACPI devices.
This patch add support for detecting ACPI devices in RMRR.
Signed-off-by: FelixCuioc
---
drivers/iommu/intel/dmar.c | 74
BIOS allocate reserved memory ranges that may be DMA targets.
BIOS may report each such reserved memory region through the
RMRR structures,along with the devices that requires access to
the specified reserved memory region.
The purpose of this series is to achieve ACPI device in RMRR
access
After acpi device in RMRR is detected,it is necessary
to establish a mapping for these devices.
In acpi_device_create_direct_mappings(),create a mapping
for the acpi device in RMRR.
Add a helper to achieve the acpi namespace device can
access the RMRR region.
Signed-off-by: FelixCuioc
---
1 - 100 of 137 matches
Mail list logo
