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
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 t
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
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.
> >
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
> >
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 >
s rid of the
> arch_dma_supported hook entirely.
Shouldn't this go before the other two?
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
r now, as it is used in the wild
> to override the too generic VIA quirk.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
ristoph Hellwig
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
more work than I'm willing to do right now.
Yeah, this thing is on the todo list ...
> Signed-off-by: Christoph Hellwig
Other than the above nits:
Reviewed-by: Thomas Gleixner
> ---
> Documentation/x86/x86_64/boot-options.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
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, whi
STA2x11 SOC. The generic implementations are based on the x86
> code, so they provide the same functionality.
Reviewed-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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
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 dm
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
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
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 bitfield.
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 io
On Fri, 6 Oct 2017, Joerg Roedel wrote:
> From: Joerg Roedel
>
> Make use of the new alignment capability of
> alloc_irq_index() to enforce IRQ index alignment
> for MSI.
>
> Reported-by: Thomas Gleixner
> Fixes: 2b324506341cb ('iommu/amd: Add routines to m
On Fri, 6 Oct 2017, Joerg Roedel wrote:
> From: Joerg Roedel
>
> 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.
>
> Reported-by: Tho
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 coheren
: Thomas Gleixner
Cc: Joerg Roedel
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
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1121,6
: Thomas Gleixner
Cc: Joerg Roedel
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/amd_iommu.c
@@ -4170,16 +4170,25 @@ static void
On Sun, 27 Aug 2017, Christoph Hellwig wrote:
> 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 coherent memory.
>
> Signed-off-by: Christoph Hellwig
> ---
>
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.
___
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:
h series 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 involve
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
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
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
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
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__
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
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
config
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
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
---
arch/x86/include/asm/irq_remapping.h |2 ++
arch/x86
Add the missing name, so debugging will work proper.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
---
drivers/iommu/intel_irq_remapping.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/iommu/intel_irq_remapping.c
+++ b
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
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/amd_iommu.c
@@ -4395,13 +4395,20 @@ static struct
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
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_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
Add the missing name, so debugging will work proper.
Signed-off-by: Thomas Gleixner
Cc: Joerg Roedel
Cc: iommu@lists.linux-foundation.org
---
drivers/iommu/amd_iommu.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu
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
Acked-by: Joerg Roedel
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 Gle
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
Cc: Joerg Roedel
Cc:
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 Gle
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 *des
a page boundary (oops!)
> - Make the locking hardirq-safe to satisfy lockdep
That looks way better.
Acked-by: Thomas Gleixner
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
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 rea
On Tue, 23 Aug 2016, Robin Murphy wrote:
> + cookie = domain->iova_cookie;
> + iovad = &cookie->iovad;
> +
> + spin_lock(&cookie->msi_lock);
> + list_for_each_entry(msi_page, &cookie->msi_page_list, list)
> + if (msi_page->phys_hi == msg->address_hi &&
> +
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
> -> i
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 n
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 ar
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
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
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 = true;
>
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
> pl
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.
> + *
On Tue, 19 Jul 2016, Eric Auger wrote:
> +bool msi_doorbell_safe(void)
> +{
> + struct irqchip_doorbell *db;
> + bool irq_remapping = true;
> +
> + mutex_lock(&irqchip_doorbell_mutex);
> + list_for_each_entry(db, &irqchip_doorbell_list, next) {
> + irq_remapping &= db->i
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 << order
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);
> +static
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 doorbell_is_pe
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
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_drhd_
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 dmar_dr
On Fri, 26 Feb 2016, Eric Auger wrote:
> +static int msi_map_doorbell(struct iommu_domain *d, struct msi_msg *msg)
> +{
> +#ifdef CONFIG_IOMMU_DMA_RESERVED
> + dma_addr_t iova;
> + phys_addr_t addr;
> + int ret;
> +
> +#ifdef CONFIG_PHYS_ADDR_T_64BIT
> + addr = ((phys_addr_t)(msg->a
On Fri, 26 Feb 2016, 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 Interrupt
> Translation Service. On Intel HW this capability is abstracted on IOMMU
> side while on ARM it is abstracte
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
Which
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;
> +
> + /*
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->irt
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 mig
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;
> +
> +
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 post
n the posted bit fields
with different meanings.
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
---
include/linux/dmar.h | 68
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 caus
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_suppo
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 vecto
On Mon, 10 Nov 2014, Feng Wu wrote:
> VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
> With VT-d Posted-Interrupts enabled, external interrupts from
> direct-assigned devices can be delivered to guests without VMM
> intervention when guest is running in non-root mode.
Can
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
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 re
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)
>
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.da
On Tue, 30 Sep 2014, Peter Hurley wrote:
> On 09/30/2014 07:45 PM, Thomas Gleixner wrote:
> > Whether the proposed patchset is the correct solution to support it is
> > a completely different question.
>
> This patchset has been in mainline since 3.16 and has already caused
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 evide
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. Be
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 th
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 pr
501 - 584 of 584 matches
Mail list logo
