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

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

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

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 Part2 v3 15/24] x86, MSI: Use hierarchy irqdomain to manage MSI interrupts

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

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

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

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

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

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

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

. 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: [v8 3/9] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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()

-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()

-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

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()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=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

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

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)

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

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

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

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

Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, 17 Apr 2019, Nadav Amit wrote: > > On Apr 17, 2019, at 10:26 AM, Ingo Molnar wrote: > >> As I was curious, I looked at the paper. Here is a quote from it: > >> > >> "In x86-64, however, the permissions of physmap are not in sane state. > >> Kernels up to v3.8.13 violate the W^X property

Re: [RFC PATCH v9 03/13] mm: Add support for eXclusive Page Frame Ownership (XPFO)

On Wed, 17 Apr 2019, Linus Torvalds wrote: > On Wed, Apr 17, 2019, 14:20 Thomas Gleixner wrote: > > > > > It's not necessarily a W+X issue. The user space text is mapped in the > > kernel as well and even if it is mapped RX then this can happen. So any > > kern

  1   2   3   4   5   6   >