[PATCH 1/1] iommu/amd: Fix the overwritten exclusion range with multiple IVMDs

[Huang Adrian]

Hi Joerg,

> On Mon, Nov 11, 2019 at 11:22 PM Joerg Roedel <joro at 8bytes.org> wrote:
>
> Hi Adrian,
>
> On Mon, Nov 04, 2019 at 01:58:52PM +0800, Adrian Huang wrote:
> >       2) When set_device_exclusion_range() parses the IVMD of devce id
> >          '4200', the exclusion range of the amd_iommu struct becomes:
> >
> >               iommu->exclusion_start = 0x9F58D000;
> >               iommu->exclusion_length = 0x8040000;
> >
> >       3) When parsing the second IVMD (device id '4300') in
> >          set_device_exclusion_range(), the exclusion range of the
> >          amd_iommu struct becomes:
> >
> >               iommu->exclusion_start = 0x9754D000;
> >               iommu->exclusion_length = 0x8040000;
> >
> >          This overwrites the first IVMD configuration, which leads to
> >          the failure of the first RAID controller.
>
> Okay, I think this is clearly a BIOS bug as the BIOS should not define
> two different exclusion ranges in the IVRS table.

Thanks for the review.

Yes. I understand this is a BIOS bug. The purpose of this patch is to
prevent the failure event though the system boots with the buggy BIOS.

> So there are a couple of options here:
>
>         1) Bail out and disable the IOMMU as the BIOS screwed up
>
>         2) Treat per-device exclusion ranges just as r/w unity-mapped
>            regions.
>
>
> I think option 2) is the best fix here.

Yes. This is what this patch does (The first exclusion region still
uses the exclusion range while the remaining exclusion regions are
modified to be r/w unity-mapped regions when detecting multiple
exclusion regions) .

But, I'm guessing you're talking about that BIOS has to define r/w
unity-mapped regions instead of the per-device exclusions (Fix from
BIOS, not prevent the failure from kernel). Right?

-- Adrian