Re: [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument

2014-09-25 Thread Thomas Gleixner
On Thu, 25 Sep 2014, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote: Msi_chip functions setup_irq/teardown_irq rarely use msi_chip argument. That's not true. Out of the four drivers that you modify two use the parameter. And the two that don't probably

Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip

2014-09-25 Thread Thomas Gleixner
On Thu, 25 Sep 2014, Yijing Wang wrote: Introduce weak arch_find_msi_chip() to find the match msi_chip. Currently, MSI chip associates pci bus to msi_chip. Because in ARM platform, there may be more than one MSI controller in system. Associate pci bus to msi_chip help pci device to find the

Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip

2014-09-26 Thread Thomas Gleixner
On Fri, 26 Sep 2014, Yijing Wang wrote: On 2014/9/25 18:38, Thomas Gleixner wrote: On Thu, 25 Sep 2014, Yijing Wang wrote: Introduce weak arch_find_msi_chip() to find the match msi_chip. Currently, MSI chip associates pci bus to msi_chip. Because in ARM platform, there may be more than

Re: [PATCH v3 0/5] enhance DMA CMA on x86

2014-09-30 Thread Thomas Gleixner
On Tue, 30 Sep 2014, Peter Hurley wrote: I read the UFS Unified Memory Extension v1.0 (JESD220-1) specification and it is not clear to me that using DMA mapping is the right approach to supporting UM, at least on x86. And without a mainline user, the merits of this approach are not evident.

Re: [Patch Part2 v3 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts

2014-10-28 Thread Thomas Gleixner
On Tue, 28 Oct 2014, Jiang Liu wrote: +static int msi_set_affinity(struct irq_data *data, const struct cpumask *mask, + bool force) +{ + struct irq_data *parent = data-parent_data; + int ret; - msg.data = ~MSI_DATA_VECTOR_MASK; - msg.data |=

Re: [Patch Part2 v3 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts

2014-10-29 Thread Thomas Gleixner
On Wed, 29 Oct 2014, Jiang Liu wrote: On 2014/10/29 5:37, Thomas Gleixner wrote: On Tue, 28 Oct 2014, Jiang Liu wrote: +static int msi_set_affinity(struct irq_data *data, const struct cpumask *mask, + bool force) +{ + struct irq_data *parent = data-parent_data

Re: [Patch Part2 v3 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts

2014-10-30 Thread Thomas Gleixner
On Thu, 30 Oct 2014, Jiang Liu wrote: On 2014/10/29 17:19, Thomas Gleixner wrote: IOAPIC runs into the same situation, but I need some more time to find a solution:) I'm sure you will! Hi Thomas, I have reviewed IOAPIC related change again, but the conclusion may not be what you

Re: [Patch Part2 v3 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts

2014-10-31 Thread Thomas Gleixner
On Fri, 31 Oct 2014, Jiang Liu wrote: On 2014/10/29 5:37, Thomas Gleixner wrote: Then it calls down the domain allocation chain. x86_msi_domain would simply hand down to the parent domain. That would either be the remap domain or the vector domain. The issue here is that, the hierarchy

Re: [PATCH 1/3] PCI/MSI: Initial hook for archs to declare multivector MSI support

2014-11-23 Thread Thomas Gleixner
On Fri, 21 Nov 2014, Alex Williamson wrote: For the most part multivector MSI is not supported and drivers and hardware wanting multiple vectors opt for MSI-X instead. It seems though that having the ability to query the arch/platform code to determine whether allocating multiple MSI vectors

Re: [PATCH 0/5] Fix Intel IRQ remapping initialization order

2014-12-15 Thread Thomas Gleixner
On Mon, 15 Dec 2014, Jiang Liu wrote: On 2014/12/15 23:13, Joerg Roedel wrote: Hi, here is a patch-set against tip/x86/apic to fix an initialization order problem with the IRQ remapping code. The problem is in the ordering of the irq_remapping_prepare and irq_remapping_supported

Re: [Patch v2 07/16] x86/apic: Refine enable_IR_x2apic() and related functions

2015-01-15 Thread Thomas Gleixner
On Wed, 7 Jan 2015, Jiang Liu wrote: Refine enable_IR_x2apic() and related functions for better readability. It also changes the way to handle IR in XAPIC mode when enabling X2APIC. Previously it just skips X2APIC initialization without checking max CPU APIC ID in system, which may cause

Re: [v5 3/9] iommu, x86: Abstract modify_irte() to accept two format of irte

2015-05-20 Thread Thomas Gleixner
. Extend struct irte to handle the differences between remap and posted mode by having three structs in the unions: - Shared - Remapped - Posted Signed-off-by: Thomas Gleixner t...@linutronix.de --- include/linux/dmar.h | 68

Re: [v9 0/9] Add VT-d Posted-Interrupts support - IOMMU part

2015-06-05 Thread Thomas Gleixner
On Fri, 5 Jun 2015, Feng Wu wrote: Divide the whole series which contain multiple components into three parts: - Prerequisite changes to irq subsystem (already merged in tip tree x86/apic branch) - IOMMU part (in this series) Please add Reviewed-by: Thomas Gleixner t...@linutronix.de

Re: [v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

2015-06-02 Thread Thomas Gleixner
On Wed, 27 May 2015, Feng Wu wrote: + /* stop posting interrupts, back to remapping mode */ + if (!vcpu_info) { + modify_irte(ir_data-irq_2_iommu, ir_data-irte_entry); + } else { + vcpu_pi_info = (struct vcpu_data *)vcpu_info; + + /* +

Re: [v7 4/8] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts

2015-05-25 Thread Thomas Gleixner
On Mon, 25 May 2015, Feng Wu wrote: We don't need to migrate the irqs for VT-d Posted-Interrupts here. When 'pst' is set in IRTE, the associated irq will be posted to guests instead of interrupt remapping. The destination of the interrupt is set in Posted-Interrupts Descriptor, and the

RE: [v7 4/8] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts

2015-05-26 Thread Thomas Gleixner
On Tue, 26 May 2015, Wu, Feng wrote: On Mon, 25 May 2015, Feng Wu wrote: + + /* We don't need to modify irte if the interrupt is for posting. */ + if (irte-pst != 1) + modify_irte(ir_data-irq_2_iommu, irte); I don't think this is correct. ir_data-irte_entry contains the

Re: [v6 3/8] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

2015-05-21 Thread Thomas Gleixner
On Thu, 21 May 2015, Feng Wu wrote: +static int intel_ir_set_vcpu_affinity(struct irq_data *data, void *vcpu_info) +{ + struct intel_ir_data *ir_data = data-chip_data; + struct irte *irte_pi = ir_data-irte_pi_entry; + struct vcpu_data *vcpu_pi_info; + + /* stop posting

Re: [v6 6/8] iommu, x86: Setup Posted-Interrupts capability for Intel iommu

2015-05-21 Thread Thomas Gleixner
On Thu, 21 May 2015, Feng Wu wrote: @@ -647,6 +647,20 @@ static int __init intel_enable_irq_remapping(void) + /* + * Set Posted-Interrupts capability. + */ + if (!disable_irq_post) { + intel_irq_remap_ops.capability |= 1 IRQ_POSTING_CAP; + +

Re: [Patch V2 1/4] iommu/vt-d: replace *hdr with hdr[0] in struct dmar_drhd_unit

2016-03-21 Thread Thomas Gleixner
On Mon, 21 Mar 2016, Wei Yang wrote: > On Sun, Mar 20, 2016 at 04:42:29PM +0100, Thomas Gleixner wrote: > >On Sun, 20 Mar 2016, Wei Yang wrote: > > > >> hdr in struct dmar_drhd_unit is used to point the DMAR hardware unit copied > >> at the end of struct dmar_dr

Re: [Patch V2 1/4] iommu/vt-d: replace *hdr with hdr[0] in struct dmar_drhd_unit

2016-03-20 Thread Thomas Gleixner
On Sun, 20 Mar 2016, Wei Yang wrote: > hdr in struct dmar_drhd_unit is used to point the DMAR hardware unit copied > at the end of struct dmar_drhd_unit. One zero-sized array may be more > elegant for this purpose. You forget to tell why. > This patch replace *hdr with hdr[0] in struct

Re: [PATCH v7 1/8] genirq/msi: Add a new MSI_FLAG_IRQ_REMAPPING flag

2016-04-22 Thread Thomas Gleixner
On Fri, 22 Apr 2016, Eric Auger wrote: > Robin, > On 04/22/2016 01:02 PM, Robin Murphy wrote: > > Hi Eric, > > > > On 19/04/16 18:13, Eric Auger wrote: > >> Let's introduce a new msi_domain_info flag value, MSI_FLAG_IRQ_REMAPPING > >> meant to tell the domain supports IRQ REMAPPING, also known as

Re: [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested

2016-07-26 Thread Thomas Gleixner
Eric, On Mon, 25 Jul 2016, Auger Eric wrote: > On 20/07/2016 11:09, Thomas Gleixner wrote: > > On Tue, 19 Jul 2016, Eric Auger wrote: > >> @@ -63,10 +63,18 @@ static int msi_compose(struct irq_data *irq_data, > >> { > >>int ret = 0; > &g

Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

2016-07-26 Thread Thomas Gleixner
B1;2802;0cEric, On Mon, 25 Jul 2016, Auger Eric wrote: > On 20/07/2016 11:04, Thomas Gleixner wrote: > > On Tue, 19 Jul 2016, Eric Auger wrote: > >> + if (ret) { > >> + for (; i >= 0; i--) { > >> + struct

Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

2016-07-26 Thread Thomas Gleixner
On Tue, 26 Jul 2016, Auger Eric wrote: > On 26/07/2016 11:00, Thomas Gleixner wrote: > > In your case you don't want to have a partial allocation, so instead of > > playing silly games with desc->irq you should add a flag which tells the PCI > > code that you are not

Re: [PATCH v11 03/10] genirq/irq: introduce msi_doorbell_info

2016-07-19 Thread Thomas Gleixner
On Tue, 19 Jul 2016, Eric Auger wrote: > > +/* Describe all the MSI doorbell regions for an irqchip */ > +struct irq_chip_msi_doorbell_info { > + union { > + phys_addr_t __percpu *percpu_doorbells; > + phys_addr_t global_doorbell; > + }; > + bool

Re: [PATCH v11 04/10] genirq/msi-doorbell: allow MSI doorbell (un)registration

2016-07-19 Thread Thomas Gleixner
On Tue, 19 Jul 2016, Eric Auger wrote: > + > +#include > +#include > +#include > + > +struct irqchip_doorbell { > + struct irq_chip_msi_doorbell_info info; > + struct list_head next; Again, please align the struct members. > +}; > + > +static LIST_HEAD(irqchip_doorbell_list); >

Re: [PATCH v11 05/10] genirq/msi-doorbell: msi_doorbell_pages

2016-07-19 Thread Thomas Gleixner
On Tue, 19 Jul 2016, Eric Auger wrote: > msi_doorbell_pages sum up the number of iommu pages of a given order adding () to the function name would make it immediately clear that msi_doorbell_pages is a function. > +/** > + * msi_doorbell_pages: compute the number of iommu pages of size 1 <<

Re: [PATCH v11 09/10] genirq/msi: map/unmap the MSI doorbells on msi_domain_alloc/free_irqs

2016-07-20 Thread Thomas Gleixner
On Tue, 19 Jul 2016, Eric Auger wrote: > /** > + * msi_handle_doorbell_mappings: in case the irq data corresponds to an > + * MSI that requires iommu mapping, traverse the irq domain hierarchy > + * to retrieve the doorbells to handle and iommu_map/unmap them according > + * to @map boolean. > +

Re: [PATCH v11 10/10] genirq/msi: use the MSI doorbell's IOVA when requested

2016-07-20 Thread Thomas Gleixner
On Tue, 19 Jul 2016, Eric Auger wrote: First of all - valid for all patches: Subject: sys/subsys: Sentence starts with an uppercase letter Now for this particular one: genirq/msi: use the MSI doorbell's IOVA when requested > On MSI message composition we now use the MSI doorbell's IOVA in >

Re: [PATCH v11 06/10] genirq/msi-doorbell: msi_doorbell_safe

2016-07-20 Thread Thomas Gleixner
On Tue, 19 Jul 2016, Eric Auger wrote: > +bool msi_doorbell_safe(void) > +{ > + struct irqchip_doorbell *db; > + bool irq_remapping = true; > + > + mutex_lock(_doorbell_mutex); > + list_for_each_entry(db, _doorbell_list, next) { > + irq_remapping &=

Re: [PATCH v12 02/11] genirq/msi: msi_compose wrapper

2016-08-09 Thread Thomas Gleixner
On Tue, 2 Aug 2016, Eric Auger wrote: > Currently the MSI message is composed by directly calling > irq_chip_compose_msi_msg and erased by setting the memory to zero. > > On some platforms, we will need to complexify this composition to > properly handle MSI emission through IOMMU. Also we will

Re: [PATCH v11 06/10] genirq/msi-doorbell: msi_doorbell_safe

2016-07-22 Thread Thomas Gleixner
On Thu, 21 Jul 2016, Auger Eric wrote: > On 20/07/2016 10:12, Thomas Gleixner wrote: > > On Tue, 19 Jul 2016, Eric Auger wrote: > >> +bool msi_doorbell_safe(void) > >> +{ > >> + struct irqchip_doorbell *db; > >> + bool irq_remapping = tr

Re: [PATCH] iommu/vt-d: Fix modify_irte NULL pointer

2016-08-22 Thread Thomas Gleixner
On Mon, 22 Aug 2016, Wanpeng Li wrote: > From: Wanpeng Li > > native_smp_prepare_cpus > -> default_setup_apic_routing > -> enable_IR_x2apic > -> irq_remapping_prepare > -> intel_prepare_irq_remapping > -> parse_ioapics_under_ir => return 0

Re: [RFC PATCH v2 04/20] x86: Secure Memory Encryption (SME) support

2016-08-25 Thread Thomas Gleixner
On Mon, 22 Aug 2016, Tom Lendacky wrote: > Provide support for Secure Memory Encryption (SME). This initial support > defines the memory encryption mask as a variable for quick access and an > accessor for retrieving the number of physical addressing bits lost if > SME is enabled. What is the

Re: [PATCH v6.1] iommu/dma: Add support for mapping MSIs

2016-09-09 Thread Thomas Gleixner
a page boundary (oops!) > - Make the locking hardirq-safe to satisfy lockdep That looks way better. Acked-by: Thomas Gleixner <t...@linutronix.de> ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v5 19/19] iommu/dma: Add support for mapping MSIs

2016-08-24 Thread Thomas Gleixner
On Tue, 23 Aug 2016, Robin Murphy wrote: > + cookie = domain->iova_cookie; > + iovad = >iovad; > + > + spin_lock(>msi_lock); > + list_for_each_entry(msi_page, >msi_page_list, list) > + if (msi_page->phys_hi == msg->address_hi && > + msi_page->phys_lo -

Re: [PATCH] arm64: SMMU-v2: Workaround for Cavium ThunderX erratum 28168

2016-10-24 Thread Thomas Gleixner
On Mon, 24 Oct 2016, Marc Zyngier wrote: > On 22/10/16 05:54, Geetha sowjanya wrote: > > diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c > > index be3c34e..6add8da 100644 > > --- a/kernel/irq/chip.c > > +++ b/kernel/irq/chip.c > > @@ -585,6 +585,10 @@ void handle_fasteoi_irq(struct irq_desc

Re: [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)

2017-07-18 Thread Thomas Gleixner
ies is a pre-cursor to another AMD processor feature called > Secure Encrypted Virtualization (SEV). The support for SEV will build upon > the SME support and will be submitted later. Details on SEV can be found > in the links below. Well done series. Thanks to all people involved, espec

Re: amd-iommu/x2apic: sleeping function called from invalid context

2017-07-26 Thread Thomas Gleixner
On Tue, 25 Jul 2017, Artem Savkov wrote: > Hi, > > Commit 1c3c5ea "sched/core: Enable might_sleep() and smp_processor_id() > checks early" seem to have uncovered an issue with amd-iommu/x2apic. > > Starting with that commit the following warning started to show up on AMD > systems during boot:

Re: [PATCH] iommu/amd: Fix schedule-while-atomic BUG in initialization code

2017-07-26 Thread Thomas Gleixner
On Wed, 26 Jul 2017, Joerg Roedel wrote: > Yes, that should fix it, but I think its better to just move the > register_syscore_ops() call to a later initialization step, like in the > patch below. I tested it an will queue it to my iommu/fixes branch. Fair enough. Acked-by-me.

[patch 11/18] iommu/of: Adjust system_state check

2017-05-14 Thread Thomas Gleixner
To enable smp_processor_id() and might_sleep() debug checks earlier, it's required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. Adjust the system_state check in of_iommu_driver_present() to handle the extra states. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc:

[patch 10/18] iommu/vt-d: Adjust system_state checks

2017-05-14 Thread Thomas Gleixner
To enable smp_processor_id() and might_sleep() debug checks earlier, it's required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. Adjust the system_state checks in dmar_parse_one_atsr() and dmar_iommu_notify_scope_dev() to handle the extra states. Signed-off-by: Thomas Gleixner

[patch V2 11/17] iommu/of: Adjust system_state check

2017-05-16 Thread Thomas Gleixner
To enable smp_processor_id() and might_sleep() debug checks earlier, it's required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. Adjust the system_state check in of_iommu_driver_present() to handle the extra states. Signed-off-by: Thomas Gleixner <t...@linutronix.de>

[patch 10/55] x86/msi: Provide new iommu irqdomain interface

2017-06-19 Thread Thomas Gleixner
Provide a new interface for creating the iommu remapping domains, so that the caller can supply a name and a id in order to create named irqdomains. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- arch

[patch 12/55] iommu/amd: Use named irq domain interface

2017-06-19 Thread Thomas Gleixner
Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- drivers/iommu/amd_iommu.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu

[patch 11/55] iommu/vt-d: Use named irq domain interface

2017-06-19 Thread Thomas Gleixner
Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- drivers/iommu/intel_irq_remapping.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) --- a/drivers/iommu/intel_irq_remap

[patch 02/55] iommu/amd: Add name to irq chip

2017-06-19 Thread Thomas Gleixner
Add the missing name, so debugging will work proper. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- drivers/iommu/amd_iommu.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) --- a/d

[patch 03/55] iommu/vt-d: Add name to irq chip

2017-06-19 Thread Thomas Gleixner
Add the missing name, so debugging will work proper. Signed-off-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- drivers/iommu/intel_irq_remapping.c |9 + 1 file changed, 5 insertions(+),

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

2017-06-21 Thread Thomas Gleixner
On Fri, 16 Jun 2017, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/mem_encrypt.h > b/arch/x86/include/asm/mem_encrypt.h > index a105796..988b336 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -15,16 +15,24 @@ > > #ifndef __ASSEMBLY__

Re: [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

2017-06-21 Thread Thomas Gleixner
On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +#ifndef pgprot_encrypted > +#define pgprot_encrypted(prot) (prot) > +#endif > + > +#ifndef pgprot_decrypted That looks wrong. It's not decrypted it's rather unencrypted, right? Thanks, tglx

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

2017-06-21 Thread Thomas Gleixner
On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit set

Re: [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

2017-06-20 Thread Thomas Gleixner
On Fri, 16 Jun 2017, Tom Lendacky wrote: > > +config ARCH_HAS_MEM_ENCRYPT > + def_bool y > + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place outside of x86/Kconfig then this should be

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

2017-06-20 Thread Thomas Gleixner
On Fri, 16 Jun 2017, Tom Lendacky wrote: > Currently there is a check if the address being mapped is in the ISA > range (is_ISA_range()), and if it is then phys_to_virt() is used to > perform the mapping. When SME is active, however, this will result > in the mapping having the encryption bit

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

2017-06-21 Thread Thomas Gleixner
On Wed, 21 Jun 2017, Tom Lendacky wrote: > On 6/21/2017 10:38 AM, Thomas Gleixner wrote: > > /* > > * Sanitize CPU configuration and retrieve the modifier > > * for the initial pgdir entry which will be programmed > > * into CR3. Depends on enabled

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

2017-06-21 Thread Thomas Gleixner
On Wed, 21 Jun 2017, Tom Lendacky wrote: > On 6/21/2017 2:16 AM, Thomas Gleixner wrote: > > Why is this an unconditional function? Isn't the mask simply 0 when the MEM > > ENCRYPT support is disabled? > > I made it unconditional because of the call from head_64.S. I can'

[patch V2 10/17] iommu/vt-d: Adjust system_state checks

2017-05-16 Thread Thomas Gleixner
To enable smp_processor_id() and might_sleep() debug checks earlier, it's required to add system states between SYSTEM_BOOTING and SYSTEM_RUNNING. Adjust the system_state checks in dmar_parse_one_atsr() and dmar_iommu_notify_scope_dev() to handle the extra states. Signed-off-by: Thomas Gleixner

[patch 45/52] iommu/vt-d: Reevaluate vector configuration on activate()

2017-09-13 Thread Thomas Gleixner
-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- drivers/iommu/intel_irq_remapping.c | 38 +++- 1 file changed, 21 insertions(+), 17 deletions(-) --- a/drivers/iommu/intel_irq_remapping.c +

[patch 46/52] iommu/amd: Reevaluate vector configuration on activate()

2017-09-13 Thread Thomas Gleixner
-by: Thomas Gleixner <t...@linutronix.de> Cc: Joerg Roedel <j...@8bytes.org> Cc: iommu@lists.linux-foundation.org --- drivers/iommu/amd_iommu.c | 39 +-- 1 file changed, 29 insertions(+), 10 deletions(-) --- a/drivers/iommu/amd_iommu.c +++ b/drivers/iommu

Re: [PATCH 2/2] iommu/amd: Enforce alignment for MSI IRQs

2017-10-08 Thread Thomas Gleixner
On Fri, 6 Oct 2017, Joerg Roedel wrote: > From: Joerg Roedel <jroe...@suse.de> > > Make use of the new alignment capability of > alloc_irq_index() to enforce IRQ index alignment > for MSI. > > Reported-by: Thomas Gleixner <t...@linutronix.de> > Fixes: 2b3

Re: [PATCH 1/2] iommu/amd: Add align parameter to alloc_irq_index()

2017-10-08 Thread Thomas Gleixner
On Fri, 6 Oct 2017, Joerg Roedel wrote: > From: Joerg Roedel <jroe...@suse.de> > > For multi-MSI IRQ ranges the IRQ index needs to be aligned > to the power-of-two of the requested IRQ count. Extend the > alloc_irq_index() function to allow such an allocation. > > R

RE: [PATCH 02/11] x86: make dma_cache_sync a no-op

2017-10-03 Thread Thomas Gleixner
On Tue, 3 Oct 2017, David Laight wrote: > From: Christoph Hellwig > > Sent: 03 October 2017 11:43 > > x86 does not implement DMA_ATTR_NON_CONSISTENT allocations, so it doesn't > > make any sense to do any work in dma_cache_sync given that it must be a > > no-op when dma_alloc_attrs returns

Re: [PATCH 04/12] x86: make dma_cache_sync a no-op

2017-08-31 Thread Thomas Gleixner
toph Hellwig <h...@lst.de Reviewed-by: Thomas Gleixner <t...@linutronix.de> > --- > arch/x86/include/asm/dma-mapping.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/x86/include/asm/dma-mapping.h > b/arch/x86/include/asm/dma-mapping.h > index 398c79889f5c.

Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs

2018-06-16 Thread Thomas Gleixner
On Fri, 15 Jun 2018, Ricardo Neri wrote: > On Fri, Jun 15, 2018 at 12:29:06PM +0200, Thomas Gleixner wrote: > > You have to consider two cases: > > > > 1) !remapped mode: > > > > That's reasonably simple because you just have to deal with the HPET >

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

2018-06-16 Thread Thomas Gleixner
On Fri, 15 Jun 2018, Ricardo Neri wrote: > On Fri, Jun 15, 2018 at 09:01:02AM +0100, Julien Thierry wrote: > > In my patches, I'm not sure there is much to adapt to your work as most of > > it is arch specific (although I wont say no to another pair of eyes looking > > at them). From what I've

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

2018-06-16 Thread Thomas Gleixner
On Fri, 15 Jun 2018, Ricardo Neri wrote: > On Fri, Jun 15, 2018 at 11:19:09AM +0200, Thomas Gleixner wrote: > > On Thu, 14 Jun 2018, Ricardo Neri wrote: > > > Alternatively, there could be a counter that skips reading the HPET status > > > register (and the detection

Re: [RFC PATCH 12/23] kernel/watchdog: Introduce a struct for NMI watchdog operations

2018-06-14 Thread Thomas Gleixner
On Thu, 14 Jun 2018, Nicholas Piggin wrote: > On Wed, 13 Jun 2018 18:31:17 -0700 > > I could look into creating the library for > > common code and relocate the hpet watchdog into arch/x86 for the hpet- > > specific parts. > > If you can investigate that approach, that would be appreciated. I

Re: [RFC PATCH 12/23] kernel/watchdog: Introduce a struct for NMI watchdog operations

2018-06-13 Thread Thomas Gleixner
On Wed, 13 Jun 2018, Peter Zijlstra wrote: > On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote: > > On Tue, 12 Jun 2018 17:57:32 -0700 > > Ricardo Neri wrote: > > > > > Instead of exposing individual functions for the operations of the NMI > > > watchdog, define a common interface

Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs

2018-06-13 Thread Thomas Gleixner
On Tue, 12 Jun 2018, Ricardo Neri wrote: > + /* There are no CPUs to monitor. */ > + if (!cpumask_weight(>monitored_mask)) > + return NMI_HANDLED; > + > inspect_for_hardlockups(regs); > > + /* > + * Target a new CPU. Keep trying until we find a monitored CPU.

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

2018-06-13 Thread Thomas Gleixner
On Wed, 13 Jun 2018, Julien Thierry wrote: > On 13/06/18 09:34, Peter Zijlstra wrote: > > On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote: > > > diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h > > > index 5426627..dbc5e02 100644 > > > --- a/include/linux/interrupt.h

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

2018-06-13 Thread Thomas Gleixner
On Tue, 12 Jun 2018, Ricardo Neri wrote: > @@ -183,6 +184,8 @@ static irqreturn_t hardlockup_detector_irq_handler(int > irq, void *data) > if (!(hdata->flags & HPET_DEV_PERI_CAP)) > kick_timer(hdata); > > + pr_err("This interrupt should not have happened. Ensure delivery

Re: [RFC PATCH 03/23] genirq: Introduce IRQF_DELIVER_AS_NMI

2018-06-13 Thread Thomas Gleixner
On Wed, 13 Jun 2018, Julien Thierry wrote: > On 13/06/18 10:20, Thomas Gleixner wrote: > > Adding NMI delivery support at low level architecture irq chip level is > > perfectly fine, but the exposure of that needs to be restricted very > > much. Adding it to the gene

Re: [RFC PATCH 20/23] watchdog/hardlockup/hpet: Rotate interrupt among all monitored CPUs

2018-06-15 Thread Thomas Gleixner
On Thu, 14 Jun 2018, Ricardo Neri wrote: > On Wed, Jun 13, 2018 at 11:48:09AM +0200, Thomas Gleixner wrote: > > On Tue, 12 Jun 2018, Ricardo Neri wrote: > > > + /* There are no CPUs to monitor. */ > > > + if (!cpumask_weight(>monitored_mask)) >

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

2018-06-15 Thread Thomas Gleixner
On Thu, 14 Jun 2018, Ricardo Neri wrote: > On Wed, Jun 13, 2018 at 11:40:00AM +0200, Thomas Gleixner wrote: > > On Tue, 12 Jun 2018, Ricardo Neri wrote: > > > @@ -183,6 +184,8 @@ static irqreturn_t > > > hardlockup_detector_irq_handler(int irq, void *data)

Re: [PATCH 4/7] x86: remove a stray reference to pci-nommu.c

2018-05-26 Thread Thomas Gleixner
more work than I'm willing to do right now. Yeah, this thing is on the todo list ... > Signed-off-by: Christoph Hellwig <h...@lst.de> Other than the above nits: Reviewed-by: Thomas Gleixner <t...@linutronix.de> > --- > Documentation/x86/x86_64/boot-options.txt | 4 ++-- &

Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag

2018-05-28 Thread Thomas Gleixner
On Mon, 28 May 2018, Christoph Hellwig wrote: > On Mon, May 28, 2018 at 08:23:35AM +0200, Thomas Gleixner wrote: > > > > They remove the commandline switch before having the replacement in > > > > place > > > > unless I'm misreading something. > > >

Re: [PATCH 6/7] x86: remove the explicit nodac and allowdac option

2018-05-28 Thread Thomas Gleixner
option for now, as it is used in the wild > to override the too generic VIA quirk. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Thomas Gleixner <t...@linutronix.de> ___ iommu mailing list iommu@lists.linux-foundation.o

Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag

2018-05-28 Thread Thomas Gleixner
lso gets rid of the > arch_dma_supported hook entirely. Shouldn't this go before the other two? > Signed-off-by: Christoph Hellwig <h...@lst.de> Reviewed-by: Thomas Gleixner <t...@linutronix.de> ___ iommu mailing list iommu@li

Re: [PATCH 5/7] x86: remove the experimental forcesac boot option

2018-05-28 Thread Thomas Gleixner
toph Hellwig <h...@lst.de> Reviewed-by: Thomas Gleixner <t...@linutronix.de> ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag

2018-05-28 Thread Thomas Gleixner
On Mon, 28 May 2018, Christoph Hellwig wrote: > On Mon, May 28, 2018 at 08:10:40AM +0200, Thomas Gleixner wrote: > > n Fri, 25 May 2018, Christoph Hellwig wrote: > > > > x86/pci-dma: ... > > > > Please > > > > > Instead of globally disabling >

Re: [PATCH 7/7] x86: switch the VIA 32-bit DMA quirk to use the struct device flag

2018-05-28 Thread Thomas Gleixner
On Mon, 28 May 2018, Christoph Hellwig wrote: > On Mon, May 28, 2018 at 08:18:46AM +0200, Thomas Gleixner wrote: > > > Which other two? The boot optional removal patches? They just remove > > > the visible interface, but keep the implementation which is converted > >

Re: [RFC PATCH 17/23] watchdog/hardlockup/hpet: Convert the timer's interrupt to NMI

2018-06-20 Thread Thomas Gleixner
On Tue, 19 Jun 2018, Ricardo Neri wrote: > On Sat, Jun 16, 2018 at 03:24:49PM +0200, Thomas Gleixner wrote: > > The status register is useless in case of MSI. MSI is edge triggered > > > > The only register which gives you proper information is the counter > >

Re: [PATCH] PCI: call dma_debug_add_bus for pci_bus_type in common code

2018-07-30 Thread Thomas Gleixner
On Mon, 30 Jul 2018, Christoph Hellwig wrote: > There is nothing arch specific about PCI or dma-debug, so move this > call to common code just after registering the bus type. > > Signed-off-by: Christoph Hellwig Acked-by: Thomas Gleixner _

Re: [PATCH 03/14] x86: use dma-direct

2018-03-15 Thread Thomas Gleixner
On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 09:56:13AM +0100, Thomas Gleixner wrote: > > On Wed, 14 Mar 2018, Christoph Hellwig wrote: > > > > > The generic dma-direct implementation is now functionally equivalent to > > > the x86

Re: [PATCH 04/14] x86: use generic swiotlb_ops

2018-03-15 Thread Thomas Gleixner
On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 10:00:57AM +0100, Thomas Gleixner wrote: > > On Wed, 14 Mar 2018, Christoph Hellwig wrote: > > > #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) > > > void *iommu; /* hook f

Re: [PATCH 03/14] x86: use dma-direct

2018-03-15 Thread Thomas Gleixner
On Wed, 14 Mar 2018, Christoph Hellwig wrote: > The generic dma-direct implementation is now functionally equivalent to > the x86 nommu dma_map implementation, so switch over to using it. Can you please convert the various drivers first and then remove the unused code? > Note that the various

Re: [PATCH 04/14] x86: use generic swiotlb_ops

2018-03-15 Thread Thomas Gleixner
On Wed, 14 Mar 2018, Christoph Hellwig wrote: > #if defined(CONFIG_INTEL_IOMMU) || defined(CONFIG_AMD_IOMMU) > void *iommu; /* hook for IOMMU specific extension */ > #endif > +#ifdef CONFIG_STA2X11 > + bool is_sta2x11 : 1; Huch? Please use either bool or an unsigned int based

Re: [PATCH 03/14] x86: use dma-direct

2018-03-15 Thread Thomas Gleixner
On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 01:53:52PM +0100, Thomas Gleixner wrote: > > > > > The generic dma-direct implementation is now functionally equivalent > > > > > to > > > > > the x86 nommu

Re: [PATCH 04/14] x86: use generic swiotlb_ops

2018-03-15 Thread Thomas Gleixner
On Thu, 15 Mar 2018, Christoph Hellwig wrote: > On Thu, Mar 15, 2018 at 01:52:14PM +0100, Thomas Gleixner wrote: > > Yeah, I know that the standard defines it, but that doesn't mean it makes > > sense. At least not to me. > > It makes sense in that it logically is a boo

Re: use generic dma-direct and swiotlb code for x86 V3

2018-03-19 Thread Thomas Gleixner
t; the STA2x11 SOC. The generic implementations are based on the x86 > code, so they provide the same functionality. Reviewed-by: Thomas Gleixner <t...@linutronix.de> ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoun

Re: [PATCH] swiotlb: swiotlb_{alloc,free}_buffer should depend on CONFIG_DMA_DIRECT_OPS

2018-03-23 Thread Thomas Gleixner
On Fri, 23 Mar 2018, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 23, 2018 at 06:49:30PM +0100, Christoph Hellwig wrote: > > Otherwise we might get unused symbol warnings for configs that built > > swiotlb.c only for use by xen-swiotlb.c and that don't otherwise select > > CONFIG_DMA_DIRECT_OPS,

Re: [PATCH] x86: enable swiotlb for > 4GiG ram on 32-bit kernels

2018-10-14 Thread Thomas Gleixner
On Sun, 14 Oct 2018, Christoph Hellwig wrote: > We already build the swiotlb code for 32b-t kernels with PAE support, > but the code to actually use swiotlb has only been enabled for 64-bit > kernel for an unknown reason. > > Before Linux 4.18 we papers over this fact because the networking

Re: [PATCH] x86: enable swiotlb for > 4GiG ram on 32-bit kernels

2018-10-14 Thread Thomas Gleixner
On Sun, 14 Oct 2018, Christoph Hellwig wrote: > On Sun, Oct 14, 2018 at 10:13:31AM +0200, Thomas Gleixner wrote: > > On Sun, 14 Oct 2018, Christoph Hellwig wrote: > > > > > We already build the swiotlb code for 32b-t kernels with PAE support, > > > but the code

Re: [PATCH] x86: enable swiotlb for > 4GiG ram on 32-bit kernels

2018-10-17 Thread Thomas Gleixner
On Tue, 16 Oct 2018, tedheadster wrote: > On Sun, Oct 14, 2018 at 3:52 AM Christoph Hellwig wrote: > > > > We already build the swiotlb code for 32b-t kernels with PAE support, > > but the code to actually use swiotlb has only been enabled for 64-bit > > kernel for an unknown reason. > > > >

Re: [PATCH v3 5/7] x86/dma/amd-gart: Stop resizing dma_debug_entry pool

2018-12-10 Thread Thomas Gleixner
=leak' parameter, which controlled nothing except whether > dma_debug_resize_entries() was called or not. > > CC: Thomas Gleixner > CC: Ingo Molnar > CC: Borislav Petkov > CC: "H. Peter Anvin" > CC: x...@kernel.org > Review

Re: [PATCH 7/7] x86: remove the x86_dma_fallback_dev hack

2019-03-23 Thread Thomas Gleixner
gh your DMA tree. Reviewed-by: Thomas Gleixner ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC PATCH v9 02/13] x86: always set IF before oopsing from page fault

2019-04-04 Thread Thomas Gleixner
On Thu, 4 Apr 2019, Tycho Andersen wrote: > leaq-PTREGS_SIZE(%rax), %rsp > UNWIND_HINT_FUNC sp_offset=PTREGS_SIZE > > + /* > + * If we oopsed in an interrupt handler, interrupts may be off. Let's > turn > + * them back on before going back to "normal" code. > +

Re: [RFC PATCH v9 12/13] xpfo, mm: Defer TLB flushes for non-current CPUs (x86 only)

2019-04-05 Thread Thomas Gleixner
On Thu, 4 Apr 2019, Khalid Aziz wrote: > When xpfo unmaps a page from physmap only (after mapping the page in > userspace in response to an allocation request from userspace) on one > processor, there is a small window of opportunity for ret2dir attack on > other cpus until the TLB entry in

Re: [PATCH v4 0/6] normalize IOMMU dma mode boot options

2019-04-08 Thread Thomas Gleixner
On Mon, 8 Apr 2019, Leizhen (ThunderTown) wrote: > > > > This will break systems using boot options as now, and I think > > this is unacceptable. If you want to do so, just introduce iommu.dma_mode > > on top of those iommu boot options with dma mode boot options unchanged, > > and iommu.dma_mode

Re: [PATCH V3 1/3] x86/Hyper-V: Set x2apic destination mode to physical when x2apic is available

2019-02-10 Thread Thomas Gleixner
C irqs have > 8-bit APIC id. This looks good now. Can that be applied independent of the IOMMU stuff or should this go together. If the latter: Reviewed-by: Thomas Gleixner If not, I just queue if for 5.1. Let me know, Thanks, tglx ___

[RFC patch 28/41] dma/debug: Simplify stracktrace retrieval

2019-04-10 Thread Thomas Gleixner
Replace the indirection through struct stack_trace with an invocation of the storage array based interface. Signed-off-by: Thomas Gleixner Cc: iommu@lists.linux-foundation.org Cc: Robin Murphy Cc: Christoph Hellwig Cc: Marek Szyprowski --- kernel/dma/debug.c | 13 + 1 file

  1   2   3   4   >