All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas Stach <dev@lynxeye.de>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>, joro@8bytes.org
Cc: Alex Deucher <alexander.deucher@amd.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems
Date: Sun, 01 Dec 2019 13:42:31 +0100	[thread overview]
Message-ID: <5b2097e8c4172a8516fcfc8c56dc98e3d105ffe2.camel@lynxeye.de> (raw)
In-Reply-To: <20191129142154.29658-1-kai.heng.feng@canonical.com>

Am Freitag, den 29.11.2019, 22:21 +0800 schrieb Kai-Heng Feng:
> 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.

This doesn't seem like a good solution, especially if there isn't a
method for the user to opt-out.  Some users might prefer having the
IOMMU support to 4K display output.

But before using the big hammer of disabling or breaking one of those
features, we should take a look at what's the issue here. Screen
flickering caused by the IOMMU being active hints to the IOMMU not
being able to sustain the translation bandwidth required by the high-
bandwidth isochronous transfers caused by 4K scanout, most likely due
to insufficient TLB space.

As far as I know the framebuffer memory for the display buffers is
located in stolen RAM, and thus contigous in memory. I don't know the
details of the GPU integration on those APUs, but maybe there even is a
way to bypass the IOMMU for the stolen VRAM regions?

If there isn't and all GPU traffic passes through the IOMMU when
active, we should check if the stolen RAM is mapped with hugepages on
the IOMMU side. All the stolen RAM can most likely be mapped with a few
hugepage mappings, which should reduce IOMMU TLB demand by a large
margin.

Regards,
Lucas

> Cc: Alex Deucher <alexander.deucher@amd.com>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/961
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> v2:
> - Find Stoney graphics instead of host bridge.
> 
>  drivers/iommu/amd_iommu_init.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index 568c52317757..139aa6fdadda 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -2516,6 +2516,7 @@ static int __init early_amd_iommu_init(void)
>  	struct acpi_table_header *ivrs_base;
>  	acpi_status status;
>  	int i, remap_cache_sz, ret = 0;
> +	u32 pci_id;
>  
>  	if (!amd_iommu_detected)
>  		return -ENODEV;
> @@ -2603,6 +2604,16 @@ static int __init early_amd_iommu_init(void)
>  	if (ret)
>  		goto out;
>  
> +	/* Disable IOMMU if there's Stoney Ridge graphics */
> +	for (i = 0; i < 32; i++) {
> +		pci_id = read_pci_config(0, i, 0, 0);
> +		if ((pci_id & 0xffff) == 0x1002 && (pci_id >> 16) == 0x98e4) {
> +			pr_info("Disable IOMMU on Stoney Ridge\n");
> +			amd_iommu_disabled = true;
> +			break;
> +		}
> +	}
> +
>  	/* Disable any previously enabled IOMMUs */
>  	if (!is_kdump_kernel() || amd_iommu_disabled)
>  		disable_iommus();
> @@ -2711,7 +2722,7 @@ static int __init state_next(void)
>  		ret = early_amd_iommu_init();
>  		init_state = ret ? IOMMU_INIT_ERROR : IOMMU_ACPI_FINISHED;
>  		if (init_state == IOMMU_ACPI_FINISHED && amd_iommu_disabled) {
> -			pr_info("AMD IOMMU disabled on kernel command-line\n");
> +			pr_info("AMD IOMMU disabled\n");
>  			init_state = IOMMU_CMDLINE_DISABLED;
>  			ret = -EINVAL;
>  		}


WARNING: multiple messages have this Message-ID (diff)
From: Lucas Stach <dev@lynxeye.de>
To: Kai-Heng Feng <kai.heng.feng@canonical.com>, joro@8bytes.org
Cc: Alex Deucher <alexander.deucher@amd.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] iommu/amd: Disable IOMMU on Stoney Ridge systems
Date: Sun, 01 Dec 2019 13:42:31 +0100	[thread overview]
Message-ID: <5b2097e8c4172a8516fcfc8c56dc98e3d105ffe2.camel@lynxeye.de> (raw)
In-Reply-To: <20191129142154.29658-1-kai.heng.feng@canonical.com>

Am Freitag, den 29.11.2019, 22:21 +0800 schrieb Kai-Heng Feng:
> 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.

This doesn't seem like a good solution, especially if there isn't a
method for the user to opt-out.  Some users might prefer having the
IOMMU support to 4K display output.

But before using the big hammer of disabling or breaking one of those
features, we should take a look at what's the issue here. Screen
flickering caused by the IOMMU being active hints to the IOMMU not
being able to sustain the translation bandwidth required by the high-
bandwidth isochronous transfers caused by 4K scanout, most likely due
to insufficient TLB space.

As far as I know the framebuffer memory for the display buffers is
located in stolen RAM, and thus contigous in memory. I don't know the
details of the GPU integration on those APUs, but maybe there even is a
way to bypass the IOMMU for the stolen VRAM regions?

If there isn't and all GPU traffic passes through the IOMMU when
active, we should check if the stolen RAM is mapped with hugepages on
the IOMMU side. All the stolen RAM can most likely be mapped with a few
hugepage mappings, which should reduce IOMMU TLB demand by a large
margin.

Regards,
Lucas

> Cc: Alex Deucher <alexander.deucher@amd.com>
> Bug: https://gitlab.freedesktop.org/drm/amd/issues/961
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> v2:
> - Find Stoney graphics instead of host bridge.
> 
>  drivers/iommu/amd_iommu_init.c | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
> index 568c52317757..139aa6fdadda 100644
> --- a/drivers/iommu/amd_iommu_init.c
> +++ b/drivers/iommu/amd_iommu_init.c
> @@ -2516,6 +2516,7 @@ static int __init early_amd_iommu_init(void)
>  	struct acpi_table_header *ivrs_base;
>  	acpi_status status;
>  	int i, remap_cache_sz, ret = 0;
> +	u32 pci_id;
>  
>  	if (!amd_iommu_detected)
>  		return -ENODEV;
> @@ -2603,6 +2604,16 @@ static int __init early_amd_iommu_init(void)
>  	if (ret)
>  		goto out;
>  
> +	/* Disable IOMMU if there's Stoney Ridge graphics */
> +	for (i = 0; i < 32; i++) {
> +		pci_id = read_pci_config(0, i, 0, 0);
> +		if ((pci_id & 0xffff) == 0x1002 && (pci_id >> 16) == 0x98e4) {
> +			pr_info("Disable IOMMU on Stoney Ridge\n");
> +			amd_iommu_disabled = true;
> +			break;
> +		}
> +	}
> +
>  	/* Disable any previously enabled IOMMUs */
>  	if (!is_kdump_kernel() || amd_iommu_disabled)
>  		disable_iommus();
> @@ -2711,7 +2722,7 @@ static int __init state_next(void)
>  		ret = early_amd_iommu_init();
>  		init_state = ret ? IOMMU_INIT_ERROR : IOMMU_ACPI_FINISHED;
>  		if (init_state == IOMMU_ACPI_FINISHED && amd_iommu_disabled) {
> -			pr_info("AMD IOMMU disabled on kernel command-line\n");
> +			pr_info("AMD IOMMU disabled\n");
>  			init_state = IOMMU_CMDLINE_DISABLED;
>  			ret = -EINVAL;
>  		}

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2019-12-01 12:48 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 [this message]
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
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=5b2097e8c4172a8516fcfc8c56dc98e3d105ffe2.camel@lynxeye.de \
    --to=dev@lynxeye.de \
    --cc=alexander.deucher@amd.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=kai.heng.feng@canonical.com \
    --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: link
Be 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.