From: Kai-Heng Feng <kai.heng.feng@canonical.com> To: "Deucher, Alexander" <Alexander.Deucher@amd.com> Cc: Joerg Roedel <joro@8bytes.org>, Christoph Hellwig <hch@infradead.org>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Kernel development list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems Date: Mon, 6 Jan 2020 16:37:04 +0800 [thread overview] Message-ID: <C4ADFDF0-8252-412A-8CFE-8E5ACE853B0A@canonical.com> (raw) In-Reply-To: <84CFD1EE-2DB7-451F-98E4-58C4B0046A81@canonical.com> > On Dec 20, 2019, at 10:13, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote: > > > >> On Dec 20, 2019, at 03:15, Deucher, Alexander <Alexander.Deucher@amd.com> wrote: >> >>> -----Original Message----- >>> From: Kai-Heng Feng <kai.heng.feng@canonical.com> >>> Sent: Wednesday, December 18, 2019 12:45 PM >>> To: Joerg Roedel <joro@8bytes.org> >>> Cc: Christoph Hellwig <hch@infradead.org>; Deucher, Alexander >>> <Alexander.Deucher@amd.com>; iommu@lists.linux-foundation.org; Kernel >>> development list <linux-kernel@vger.kernel.org> >>> Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge >>> systems >>> >>> >>> >>>> On Dec 17, 2019, at 17:53, Joerg Roedel <joro@8bytes.org> wrote: >>>> >>>> On Fri, Dec 06, 2019 at 01:57:41PM +0800, Kai-Heng Feng wrote: >>>>> Hi Joerg, >>>>> >>>>>> On Dec 3, 2019, at 01:00, Christoph Hellwig <hch@infradead.org> wrote: >>>>>> >>>>>> On Fri, Nov 29, 2019 at 10:21:54PM +0800, Kai-Heng Feng wrote: >>>>>>> Serious screen flickering when Stoney Ridge outputs to a 4K monitor. >>>>>>> >>>>>>> According to Alex Deucher, IOMMU isn't enabled on Windows, so let's >>>>>>> do the same here to avoid screen flickering on 4K monitor. >>>>>> >>>>>> Disabling the IOMMU entirely seem pretty severe. Isn't it enough to >>>>>> identity map the GPU device? >>>>> >>>>> Ok, there's set_device_exclusion_range() to exclude the device from >>> IOMMU. >>>>> However I don't know how to generate range_start and range_length, >>> which are read from ACPI. >>>> >>>> set_device_exclusion_range() is not the solution here. The best is if >>>> the GPU device is put into a passthrough domain at boot, in which it >>>> will be identity mapped. DMA still goes through the IOMMU in this >>>> case, but it only needs to lookup the device-table, page-table walks >>>> will not be done anymore. >>>> >>>> The best way to implement this is to put it into the >>>> amd_iommu_add_device() in drivers/iommu/amd_iommu.c. There is this >>>> check: >>>> >>>> if (dev_data->iommu_v2) >>>> iommu_request_dm_for_dev(dev); >>>> >>>> The iommu_request_dm_for_dev() function causes the device to be >>>> identity mapped. The check can be extended to also check for a device >>>> white-list for devices that need identity mapping. >>> >>> My patch looks like this but the original behavior (4K screen flickering) is still >>> the same: >> >> Does reverting the patch to disable ATS along with this patch help? > > Unfortunately it doesn't help. Any further suggestion to let me try? Kai-Heng > > Kai-Heng > >> >> Alex >> >>> >>> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c >>> index bd25674ee4db..f913a25c9e92 100644 >>> --- a/drivers/iommu/amd_iommu.c >>> +++ b/drivers/iommu/amd_iommu.c >>> @@ -42,6 +42,7 @@ >>> #include <asm/iommu.h> >>> #include <asm/gart.h> >>> #include <asm/dma.h> >>> +#include <asm/pci-direct.h> >>> >>> #include "amd_iommu_proto.h" >>> #include "amd_iommu_types.h" >>> @@ -2159,6 +2160,8 @@ static int amd_iommu_add_device(struct device >>> *dev) >>> struct iommu_domain *domain; >>> struct amd_iommu *iommu; >>> int ret, devid; >>> + bool need_identity_mapping = false; >>> + u32 header; >>> >>> if (!check_device(dev) || get_dev_data(dev)) >>> return 0; >>> @@ -2184,7 +2187,11 @@ static int amd_iommu_add_device(struct device >>> *dev) >>> >>> BUG_ON(!dev_data); >>> >>> - if (dev_data->iommu_v2) >>> + header = read_pci_config(0, PCI_BUS_NUM(devid), PCI_SLOT(devid), >>> PCI_FUNC(devid)); >>> + if ((header & 0xffff) == 0x1002 && (header >> 16) == 0x98e4) >>> + need_identity_mapping = true; >>> + >>> + if (dev_data->iommu_v2 || need_identity_mapping) >>> iommu_request_dm_for_dev(dev); >>> >>> /* Domains are initialized for this device - have a look what we ended up >>> with */ >>> >>> >>> $ dmesg | grep -i direct >>> [ 0.011446] Using GB pages for direct mapping >>> [ 0.703369] pci 0000:00:01.0: Using iommu direct mapping >>> [ 0.703830] pci 0000:00:08.0: Using iommu direct mapping >>> >>> So the graphics device (pci 0000:00:01.0:) is using direct mapping after the >>> change. >>> >>> Kai-Heng >>> >>>> >>>> HTH, >>>> >>>> Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Kai-Heng Feng <kai.heng.feng@canonical.com> To: "Deucher, Alexander" <Alexander.Deucher@amd.com> Cc: "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, Kernel development list <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems Date: Mon, 6 Jan 2020 16:37:04 +0800 [thread overview] Message-ID: <C4ADFDF0-8252-412A-8CFE-8E5ACE853B0A@canonical.com> (raw) In-Reply-To: <84CFD1EE-2DB7-451F-98E4-58C4B0046A81@canonical.com> > On Dec 20, 2019, at 10:13, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote: > > > >> On Dec 20, 2019, at 03:15, Deucher, Alexander <Alexander.Deucher@amd.com> wrote: >> >>> -----Original Message----- >>> From: Kai-Heng Feng <kai.heng.feng@canonical.com> >>> Sent: Wednesday, December 18, 2019 12:45 PM >>> To: Joerg Roedel <joro@8bytes.org> >>> Cc: Christoph Hellwig <hch@infradead.org>; Deucher, Alexander >>> <Alexander.Deucher@amd.com>; iommu@lists.linux-foundation.org; Kernel >>> development list <linux-kernel@vger.kernel.org> >>> Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge >>> systems >>> >>> >>> >>>> On Dec 17, 2019, at 17:53, Joerg Roedel <joro@8bytes.org> wrote: >>>> >>>> On Fri, Dec 06, 2019 at 01:57:41PM +0800, Kai-Heng Feng wrote: >>>>> Hi Joerg, >>>>> >>>>>> On Dec 3, 2019, at 01:00, Christoph Hellwig <hch@infradead.org> wrote: >>>>>> >>>>>> On Fri, Nov 29, 2019 at 10:21:54PM +0800, Kai-Heng Feng wrote: >>>>>>> Serious screen flickering when Stoney Ridge outputs to a 4K monitor. >>>>>>> >>>>>>> According to Alex Deucher, IOMMU isn't enabled on Windows, so let's >>>>>>> do the same here to avoid screen flickering on 4K monitor. >>>>>> >>>>>> Disabling the IOMMU entirely seem pretty severe. Isn't it enough to >>>>>> identity map the GPU device? >>>>> >>>>> Ok, there's set_device_exclusion_range() to exclude the device from >>> IOMMU. >>>>> However I don't know how to generate range_start and range_length, >>> which are read from ACPI. >>>> >>>> set_device_exclusion_range() is not the solution here. The best is if >>>> the GPU device is put into a passthrough domain at boot, in which it >>>> will be identity mapped. DMA still goes through the IOMMU in this >>>> case, but it only needs to lookup the device-table, page-table walks >>>> will not be done anymore. >>>> >>>> The best way to implement this is to put it into the >>>> amd_iommu_add_device() in drivers/iommu/amd_iommu.c. There is this >>>> check: >>>> >>>> if (dev_data->iommu_v2) >>>> iommu_request_dm_for_dev(dev); >>>> >>>> The iommu_request_dm_for_dev() function causes the device to be >>>> identity mapped. The check can be extended to also check for a device >>>> white-list for devices that need identity mapping. >>> >>> My patch looks like this but the original behavior (4K screen flickering) is still >>> the same: >> >> Does reverting the patch to disable ATS along with this patch help? > > Unfortunately it doesn't help. Any further suggestion to let me try? Kai-Heng > > Kai-Heng > >> >> Alex >> >>> >>> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c >>> index bd25674ee4db..f913a25c9e92 100644 >>> --- a/drivers/iommu/amd_iommu.c >>> +++ b/drivers/iommu/amd_iommu.c >>> @@ -42,6 +42,7 @@ >>> #include <asm/iommu.h> >>> #include <asm/gart.h> >>> #include <asm/dma.h> >>> +#include <asm/pci-direct.h> >>> >>> #include "amd_iommu_proto.h" >>> #include "amd_iommu_types.h" >>> @@ -2159,6 +2160,8 @@ static int amd_iommu_add_device(struct device >>> *dev) >>> struct iommu_domain *domain; >>> struct amd_iommu *iommu; >>> int ret, devid; >>> + bool need_identity_mapping = false; >>> + u32 header; >>> >>> if (!check_device(dev) || get_dev_data(dev)) >>> return 0; >>> @@ -2184,7 +2187,11 @@ static int amd_iommu_add_device(struct device >>> *dev) >>> >>> BUG_ON(!dev_data); >>> >>> - if (dev_data->iommu_v2) >>> + header = read_pci_config(0, PCI_BUS_NUM(devid), PCI_SLOT(devid), >>> PCI_FUNC(devid)); >>> + if ((header & 0xffff) == 0x1002 && (header >> 16) == 0x98e4) >>> + need_identity_mapping = true; >>> + >>> + if (dev_data->iommu_v2 || need_identity_mapping) >>> iommu_request_dm_for_dev(dev); >>> >>> /* Domains are initialized for this device - have a look what we ended up >>> with */ >>> >>> >>> $ dmesg | grep -i direct >>> [ 0.011446] Using GB pages for direct mapping >>> [ 0.703369] pci 0000:00:01.0: Using iommu direct mapping >>> [ 0.703830] pci 0000:00:08.0: Using iommu direct mapping >>> >>> So the graphics device (pci 0000:00:01.0:) is using direct mapping after the >>> change. >>> >>> Kai-Heng >>> >>>> >>>> HTH, >>>> >>>> Joerg _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-01-06 8:37 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-29 14:21 [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems Kai-Heng Feng 2019-11-29 14:21 ` Kai-Heng Feng 2019-12-01 12:42 ` Lucas Stach 2019-12-01 12:42 ` Lucas Stach 2019-12-02 16:36 ` Deucher, Alexander 2019-12-02 16:36 ` Deucher, Alexander 2019-12-04 16:08 ` Deucher, Alexander 2019-12-04 16:08 ` Deucher, Alexander 2019-12-06 5:59 ` Kai-Heng Feng 2019-12-06 5:59 ` Kai-Heng Feng 2019-12-06 8:57 ` Christian König 2019-12-06 8:57 ` Christian König 2019-12-02 17:00 ` Christoph Hellwig 2019-12-02 17:00 ` Christoph Hellwig 2019-12-06 5:57 ` Kai-Heng Feng 2019-12-06 5:57 ` Kai-Heng Feng 2019-12-17 9:53 ` Joerg Roedel 2019-12-17 9:53 ` Joerg Roedel 2019-12-18 17:45 ` Kai-Heng Feng 2019-12-18 17:45 ` Kai-Heng Feng 2019-12-19 19:15 ` Deucher, Alexander 2019-12-19 19:15 ` Deucher, Alexander 2019-12-20 2:13 ` Kai-Heng Feng 2019-12-20 2:13 ` Kai-Heng Feng 2020-01-06 8:37 ` Kai-Heng Feng [this message] 2020-01-06 8:37 ` Kai-Heng Feng 2020-02-05 10:10 ` Kai-Heng Feng 2020-02-05 10:10 ` Kai-Heng Feng 2020-02-05 13:24 ` Joerg Roedel 2020-02-05 13:24 ` Joerg Roedel
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=C4ADFDF0-8252-412A-8CFE-8E5ACE853B0A@canonical.com \ --to=kai.heng.feng@canonical.com \ --cc=Alexander.Deucher@amd.com \ --cc=hch@infradead.org \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.