Current Intel IOMMU does not support suspend and resume. In S3 event, kernel
crashes when IOMMU is enabled. The attached patch set implements the suspend and
resume feature for Intel IOMMU. It hooks to kernel suspend and resume interface.
When suspend happens, it saves necessary hardware registers. When resume happens
it restores the registers and restarts IOMMU.
This patch set is applied to the tip tree.
--
It looks like patch 1 calls dmar_reenable_qi but patch 2 defines it.
In 2.6.29, there's no dmar_disable_qi that I can see. Can you respin
these against something a little less scary than -tip during a merge
window? (Especially since -stable will need this soon.)
Thanks,
Andy
On Wed, Mar 25, 2009 at 2:45 PM, <[email protected]> wrote:
> Current Intel IOMMU does not support suspend and resume. In S3 event, kernel
> crashes when IOMMU is enabled. The attached patch set implements the suspend and
> resume feature for Intel IOMMU. It hooks to kernel suspend and resume interface.
> When suspend happens, it saves necessary hardware registers. When resume happens
> it restores the registers and restarts IOMMU.
>
> This patch set is applied to the tip tree.
>
> --
>
>
>Subject: Re: [patch 0/2] Intel IOMMU Suspend/Resume Support
>
>It looks like patch 1 calls dmar_reenable_qi but patch 2 defines it.
>
>In 2.6.29, there's no dmar_disable_qi that I can see. Can you respin
>these against something a little less scary than -tip during a merge
>window? (Especially since -stable will need this soon.)
>
dmar_disable_qi() is defined in tip tree already. This patch set is based on the tip tree. I do have another version of the patch set which is based on 2.6.29.
Ingo,
Do you think which tree this patch set should based on?
Thanks.
-Fenghua
* Yu, Fenghua <[email protected]> wrote:
> >Subject: Re: [patch 0/2] Intel IOMMU Suspend/Resume Support
> >
> >It looks like patch 1 calls dmar_reenable_qi but patch 2 defines it.
> >
> >In 2.6.29, there's no dmar_disable_qi that I can see. Can you respin
> >these against something a little less scary than -tip during a merge
> >window? (Especially since -stable will need this soon.)
> >
>
> dmar_disable_qi() is defined in tip tree already. This patch set
> is based on the tip tree. I do have another version of the patch
> set which is based on 2.6.29.
>
> Ingo,
>
> Do you think which tree this patch set should based on?
yes, dmar_disable_qi() was part of the x2apic fix patches (for
various crashes and hangs) from Suresh, merged by hpa, and they are
queued up for 2.6.30:
ce4e240: x86: add x2apic_wrmsr_fence() to x2apic flush tlb paths
fa4b57c: x86, dmar: use atomic allocations for QI and Intr-remapping init
68a8ca5: x86: fix broken irq migration logic while cleaning up multiple vectors
05c3dc2: x86, ioapic: Fix non atomic allocation with interrupts disabled
29b61be: x86, x2apic: cleanup ifdef CONFIG_INTR_REMAP in io_apic code
0280f7c: x86, x2apic: cleanup the IO-APIC level migration with interrupt-remapping
cf6567f: x86, x2apic: fix clear_local_APIC() in the presence of x2apic
7c6d9f9: x86, x2apic: use virtual wire A mode in disable_IO_APIC() with interrupt-remapping
2e93456: x86, intr-remapping: fix free_irte() to clear all the IRTE entries
1531a6a: x86, dmar: start with sane state while enabling dma and interrupt-remapping
eba67e5: x86, dmar: routines for disabling queued invalidation and intr remapping
9d783ba: x86, x2apic: enable fault handling for intr-remapping
0ac2491: x86, dmar: move page fault handling code to dmar.c
4c5502b: x86, x2apic: fix lock ordering during IRQ migration
0ca0f16: Merge branches 'x86/apic', 'x86/asm', 'x86/cleanups', 'x86/debug', 'x86/kconfig', 'x86/mm', 'x86/ptrace', 'x86/setup' and 'x86/urgent'; commit 'v2.6.29-rc8' into x86/core
So it would be nice to have this based on -tip, to reduce conflicts
- but it definitely needs David's review and acks. We can do a
separate branch for this if needed.
Ingo