Hi Joerg, Is Ning's answer sufficient to justify merging the patch?
Thanks, Shaohua On Mon, Apr 10, 2017 at 09:28:46PM +0000, Sun, Ning wrote: > From tboot perspective, it is ok to add the option "tboot_noforce" to Linux > kernel Intel_iommu parameter for those performance hungry tboot users, so > long as the users are aware of the security implication behind of this option. > > Thanks, > -ning > > -----Original Message----- > From: Shaohua Li [mailto:[email protected]] > Sent: Sunday, April 09, 2017 9:31 PM > To: Sun, Ning <[email protected]> > Cc: Joerg Roedel <[email protected]>; [email protected]; Wei, Gang > <[email protected]>; [email protected]; [email protected]; > [email protected]; [email protected]; Eydelberg, Alex <[email protected]> > Subject: Re: [RFC] x86/tboot: add an option to disable iommu force on > > On Fri, Apr 07, 2017 at 09:49:52PM +0000, Sun, Ning wrote: > > Hi Shaohua, > > > > One question, did you still see the network performance penalty when Linux > > kernel cmdline intel_iommu was set to off ( intel_iommu=off) ? > > the boot parameter has no effect, it runs very early and set dmar_disable=1. > The tboot code (tboot_force_iommu) runs later and force dmar_disabled = 0. > > Thanks, > Shaohua > > > Thanks, > > -ning > > > > -----Original Message----- > > From: Joerg Roedel [mailto:[email protected]] > > Sent: Friday, April 07, 2017 3:09 AM > > To: Shaohua Li <[email protected]> > > Cc: [email protected]; Wei, Gang <[email protected]>; > > [email protected]; [email protected]; [email protected]; Sun, Ning > > <[email protected]>; [email protected]; Eydelberg, Alex > > <[email protected]> > > Subject: Re: [RFC] x86/tboot: add an option to disable iommu force on > > > > On Mon, Apr 03, 2017 at 12:19:28PM -0700, Shaohua Li wrote: > > > On Wed, Mar 22, 2017 at 07:50:55AM -0400, Shaohua Li wrote: > > > > On Wed, Mar 22, 2017 at 11:49:00AM +0100, Joerg Roedel wrote: > > > > > Hi Shaohua, > > > > > > > > > > On Tue, Mar 21, 2017 at 11:37:51AM -0700, Shaohua Li wrote: > > > > > > IOMMU harms performance signficantly when we run very fast > > > > > > networking workloads. This is a limitation in hardware based > > > > > > on our observation, so we'd like to disable the IOMMU force > > > > > > on, but we do want to use TBOOT and we can sacrifice the DMA > > > > > > security bought by IOMMU. I must admit I know nothing about > > > > > > TBOOT, but TBOOT guys (cc-ed) think not eabling IOMMU is totally ok. > > > > > > > > > > Can you elaborate a bit more on the setup where the IOMMU still > > > > > harms network performance? With the recent scalability > > > > > improvements I measured only a minimal impact on 10GBit networking. > > > > Hi, > > > > > > > > It's 40GB networking doing XDP test. Software overhead is almost > > > > unaware, but it's the IOTLB miss (based on our analysis) which > > > > kills the performance. We observed the same performance issue even > > > > with software passthrough (identity mapping), only the hardware > > > > passthrough survives. The pps with iommu (with software passthrough) is > > > > only about ~30% of that without it. > > > > > > Any update on this? > > > > An explicit Ack from the tboot guys would be good to have. > > > > > > Joerg > >
