NAK: [SRU][B/C/D] iommu/amd: Reserve and correctly set exclusion range in iova-domain

[Jeffrey Lane]

Thanks. This was supposed to be a reply in that same thread. Not sure
exactly how I managed to de-thread this. Thank you for cleaning that up and
my apologies for the confusion.

On Fri, Jun 28, 2019 at 07:24 Kleber Souza <kleber.souza at canonical.com>
wrote:

> On 6/24/19 8:21 PM, Jeffrey Lane wrote:
> > Hi,
> >
> > I wanted to ask if there was anything I could do to help get this
> > acked so it makes the next SRU cycle?
>
> Hi Jeff,
>
> I see two threads sent to the mailing-list, with the other one already
> ACK'ed
> and applied for the next SRU cycle:
>
> https://lists.ubuntu.com/archives/kernel-team/2019-June/101705.html
>
> Based on that I'm NAK'ing this particular thread only because it's
> duplicated,
> but the fixes are still committed.
>
>
> Thanks,
> Kleber
>
>
> >
> > Thanks
> > Jeff
> >
> > On Mon, Jun 17, 2019 at 9:52 AM Jeffrey Lane <jeffrey.lane at canonical.com>
> wrote:
> >>
> >> Hi,
> >>
> >> Could I get a second ack on these (connork acked it earlier)?
> >> I was hoping this could make this cycle, if at all possible.
> >>
> >> Thanks
> >> Jeff
> >>
> >> On Fri, Jun 7, 2019 at 1:34 PM Jeff Lane <jeffrey.lane at canonical.com>
> wrote:
> >>>
> >>> BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1823037
> >>>
> >>> [Impact]
> >>> If a device has an exclusion range specified in the IVRS table, this
> region
> >>> needs to be reserved in the iova-domain of that device. This hasn't
> happened
> >>> until now and can cause data corruption on data transfered with these
> devices.
> >>>
> >>> The exlcusion range limit register needs to contain the base-address
> of the
> >>> last page that is part of the range, as bits 0-11 of this register are
> treated
> >>> as 0xfff by the hardware for comparisons.
> >>>
> >>> So correctly set the exclusion range in the hardware to the last page
> which is
> >>> _in_ the range.
> >>>
> >>> [Testing]
> >>> This was tested by Dell for 24+ hours with positive test results.
> Testing
> >>> involved creating multiple directories with a million files each and
> then
> >>> another script was used across 3-5 threads copying files from one
> location
> >>> to another.  Prior to using test kernels with these patches applied,
> the system
> >>> would fail within 1 - 2 hours consistently.
> >>>
> >>> [Regression Risk]
> >>> Low,this adds memory protection to the driver and has already been
> applied
> >>> upstream and patched test kernels for all three releases have been
> tested by
> >>> Dell for 24 hours with no failures noted.
> >>>
> >>> Patches cleanly apply to Bionic, Cosmic and Disco. Bionic and Cosmic
> require
> >>> both patches, but Disco only requires the second patch (Set exclusion
> rage
> >>> correctly) as the first patch was already picked up in a previous SRU
> >>> (LP: #1830934)
> >>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Jeff Lane
> >> Technical Partnership and Server Certification Programmes
> >>
> >> "Entropy isn't what it used to be."
> >
> >
> >
>
> --
Sent from my iPhone so please forgive any typos, top posting and such.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20190628/6a031e26/attachment.html>