* Tom Lendacky wrote:
> This patch series provides support for AMD's new Secure Memory Encryption
> (SME)
> feature.
I'm wondering, what's the typical performance hit to DRAM access latency when
SME
is enabled?
On that same note, if the performance hit is noticeable I'd expect SME to not
b
* Joerg Roedel wrote:
> Hi Ingo,
>
> The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
>
> Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
> tags/ioapic-clea
* Joerg Roedel wrote:
> Hi Ingo,
>
> On Fri, Jan 25, 2013 at 11:49:15AM +0100, Ingo Molnar wrote:
> > Hm, there are some not so trivial looking conflicts in
> > io_apic.c, due to the MSI patches I applied yesterday:
> >
> > 5ca72c4f7c41 AHCI: Support multip
* Shuah Khan wrote:
> When dma_ops are initialized the unity mappings are created. The
> init_device_table_dma() function makes sure DMA from all devices is
> blocked by default. This opens a short window in time where DMA to
> unity mapped regions is blocked by the IOMMU. Make sure this does no
* Joerg Roedel wrote:
> On Thu, Feb 07, 2013 at 11:49:05AM +0100, Ingo Molnar wrote:
> >
> > * Shuah Khan wrote:
> > > arch/x86/kernel/amd_iommu_init.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > That file d
* Thomas Gleixner wrote:
> 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 t
* 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.
> >
> > Before Linux 4.18 we
* tedheadster wrote:
> > But you said without the fix it doesn't work at all? Or is this
> > the same box, just with the aic7xxx controller disabled?
> >
> > In general the patch should only have two effects:
> >
> > - set a small amount of memory aside for bounce buffering
> > - switch the
* Suresh Siddha wrote:
> Ingo,
>
> Here is the Joerg's irq_remap_ops patchset updated for the latest -tip.
> Simplified some of the naming conventions to follow the irq_remapping
> terminology. There are still some "if (irq_remapping_enabled)" checks in
> io_apic.c that I would like to roll int
* Yinghai Lu wrote:
> On Sat, Mar 31, 2012 at 1:14 AM, Ingo Molnar wrote:
> >
> > * Suresh Siddha wrote:
> >
> >> Ingo,
> >>
> >> Here is the Joerg's irq_remap_ops patchset updated for the latest -tip.
> >> Simplified some of the n
* Suresh Siddha wrote:
> Fix the below UP build failure with CONFIG_IRQ_REMAP enabled.
>
> drivers/iommu/intel_irq_remapping.c:955:19: error: ‘struct irq_data’ has no
> member named ‘affinity’
hm:
> +++ b/drivers/iommu/intel_irq_remapping.c
> +#ifdef CONFIG_SMP
> +#endif
> +#ifdef CONFIG_SM
another problem is that drivers/iommu/intel_irq_remapping.c is
supplied with comments rather poorly - I have to page down
almost 300 lines to see the first substantial comment! Copyright
notices would be nice as well.
So lets do a better job and document this thing a bit better.
Please also a
* Suresh Siddha wrote:
> On Tue, 2012-05-08 at 11:09 +0200, Ingo Molnar wrote:
> > * Suresh Siddha wrote:
> >
> > > Fix the below UP build failure with CONFIG_IRQ_REMAP enabled.
> > >
> > > drivers/iommu/intel_irq_remapping.c:955:19: error: ‘s
* David Woodhouse wrote:
> > well, one could argue it may be easier to claim the space
> > reserved in the OS then making yet another hole in the
> > available IO address space in the ACPI tables.
>
> But how? It's got to work with operating systems that predate
> the IOMMU. The registers *h
* David Woodhouse wrote:
> On Wed, 2012-06-06 at 10:16 +0200, Ingo Molnar wrote:
>
> > So basically the patch-set is fine as-is, we just want a
> > sufficiently nasty sounding warning message about the BIOS
> > bug,
>
> No. The other change that's requ
* Joerg Roedel wrote:
> The VT-d IOMMU requires a special setup of the IO-APIC to
> remap its interrupts. Therefore the print_IO_APIC routine
> has seperate code paths to accout for that and print out the
> special setup. This is not required on AMD IOMMU systems, so
> make these path really Int
* Joerg Roedel wrote:
> On Fri, Jul 06, 2012 at 10:50:36AM +0200, Ingo Molnar wrote:
> >
> > * Joerg Roedel wrote:
> > > extern int irq_remapping_enabled;
> > > +extern int intel_irq_remap_debug;
>
> > Instead of yet another set of global flags thr
* Joerg Roedel wrote:
> From: Joerg Roedel
>
> The semaphore used by the AMD IOMMU to signal command
> completion lived on the stack until now, which was safe as
> the driver busy-waited on the semaphore with IRQs disabled,
> so the stack can't go away under the driver.
>
> But the recently i
* Joerg Roedel wrote:
> On Wed, Sep 14, 2016 at 11:27:12PM +0200, Joerg Roedel wrote:
> > On Wed, Sep 14, 2016 at 05:26:48PM +0200, Ingo Molnar wrote:
> > >
> > > Cool, thanks! I'll put this into tip:x86/asm which has the virtually
> > > mapped stack
* Joerg Roedel wrote:
> Hi Ingo,
>
> On Thu, Sep 15, 2016 at 07:44:35AM +0200, Ingo Molnar wrote:
> > Yeah, I can still remove it - just zapped it in fact.
>
> Thanks, and sorry for the hassle. Here is the v2 patch that has the
> correct locking. I tested it with and
> header files).
>
> Signed-off-by: Randy Dunlap
Nice find:
Reviewed-by: Ingo Molnar
I agree that it needs to go through 0-day to find any hidden dependencies we
might
have grown due to this.
Thanks,
Ingo
___
iommu mailin
the upstreaming route for these patches?
While it's a multi-arch series it's all pretty x86-heavy as well so we can host
it
in -tip (in tip:core/dma or such), but feel free to handle it yourself as well:
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Christoph Hellwig wrote:
> On Tue, Mar 20, 2018 at 09:37:51AM +0100, Ingo Molnar wrote:
> > > git://git.infradead.org/users/hch/misc.git dma-direct-x86
> >
> > Btw., what's the upstreaming route for these patches?
> >
> > While it's a multi-ar
[ Sorry, had to trim the Cc: list from hell. Tried to keep all the
mailing lists and all x86 developers. ]
* Khalid Aziz wrote:
> From: Juerg Haefliger
>
> This patch adds basic support infrastructure for XPFO which protects
> against 'ret2dir' kernel attacks. The basic idea is to enforc
* Khalid Aziz wrote:
> > I.e. the original motivation of the XPFO patches was to prevent execution
> > of direct kernel mappings. Is this motivation still present if those
> > mappings are non-executable?
> >
> > (Sorry if this has been asked and answered in previous discussions.)
>
> Hi In
* Nadav Amit wrote:
> > On Apr 17, 2019, at 10:09 AM, Ingo Molnar wrote:
> >
> >
> > * Khalid Aziz wrote:
> >
> >>> I.e. the original motivation of the XPFO patches was to prevent execution
> >>> of direct kernel mappings. Is this mot
* Thomas Gleixner wrote:
> - if (unlikely(!ret))
> + if (unlikely(!ret)) {
> + if (!trace->nr_entries) {
> + /*
> + * If save_trace fails here, the printing might
> + * trigger a WARN but because of the !nr_entrie
ons(-)
I suspect you'd like to carry this in the -mm tree?
Acked-by: Ingo Molnar
Thanks,
Ingo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
* Mike Rapoport wrote:
> On Tue, Jul 28, 2020 at 12:44:40PM +0200, Ingo Molnar wrote:
> >
> > * Mike Rapoport wrote:
> >
> > > From: Mike Rapoport
> > >
> > > numa_clear_kernel_node_hotplug() function first traverses numa_meminfo
> >
>
> Signed-off-by: Mike Rapoport
Assuming there's no hidden dependency here breaking something:
Acked-by: Ingo Molnar
Thanks,
Ingo
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
om limited range will anyway fail if there is no enough
> memory, so there is no need for extra traversal of memblock.memory
>
> Signed-off-by: Mike Rapoport
Assuming that this got or will get tested with a crash kernel:
Acked-by: Ingo
2 +-
> arch/x86/mm/numa.c | 2 +-
> include/linux/memblock.h | 19 ---
> mm/memblock.c | 4 ++--
> mm/page_alloc.c| 8
> 8 files changed, 28 insertions(+), 14 deletions(-)
* Steven Rostedt wrote:
> But please, next time, go easy on the Cc list. Maybe just use bcc for those
> not
> on the list, stating that you BCC'd a lot of people to make sure this is
> sane,
> but didn't want to spam everyone with every reply.
Not just that, such a long Cc: list is a semi-g
33 matches
Mail list logo
