[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed by a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a quirk to the EFI fb driver to find the BAR associated with
the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
that the PCI core will leave it alone.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v3: check device is enabled before attempting to claim the resource

 drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 8c4dc1e1f94f..88f653864a01 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include <linux/efi.h>
 #include <linux/errno.h>
 #include <linux/fb.h>
+#include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/screen_info.h>
 #include <video/vga.h>
@@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
 };
 ATTRIBUTE_GROUPS(efifb);
 
+static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
+static bool pci_dev_disabled;	/* was the device disabled? */
+
 static int efifb_probe(struct platform_device *dev)
 {
 	struct fb_info *info;
@@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
 	unsigned int size_total;
 	char *option = NULL;
 
-	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
 		return -ENODEV;
 
 	if (fb_get_options("efifb", &option))
@@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
 };
 
 builtin_platform_driver(efifb_driver);
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+	u16 word;
+
+	pci_bar_found = true;
+
+	pci_read_config_word(dev, PCI_COMMAND, &word);
+	if (!(word & PCI_COMMAND_MEMORY)) {
+		pci_dev_disabled = true;
+		dev_err(&dev->dev,
+			"BAR %d: assigned to efifb but device is disabled!\n",
+			idx);
+		return;
+	}
+
+	if (pci_claim_resource(dev, idx)) {
+		pci_dev_disabled = true;
+		dev_err(&dev->dev,
+			"BAR %d: failed to claim resource for efifb!\n", idx);
+		return;
+	}
+
+	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+	u64 base = screen_info.lfb_base;
+	u64 size = screen_info.lfb_size;
+	int i;
+
+	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+		return;
+
+	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+		base |= (u64)screen_info.ext_lfb_base << 32;
+
+	if (!base)
+		return;
+
+	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+		struct resource *res = &dev->resource[i];
+
+		if (!(res->flags & IORESOURCE_MEM))
+			continue;
+
+		if (res->start <= base && res->end >= base + size - 1) {
+			claim_efifb_bar(dev, i);
+			break;
+		}
+	}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
-- 
2.7.4

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed by a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a quirk to the EFI fb driver to find the BAR associated with
the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
that the PCI core will leave it alone.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v3: check device is enabled before attempting to claim the resource

 drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 8c4dc1e1f94f..88f653864a01 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include <linux/efi.h>
 #include <linux/errno.h>
 #include <linux/fb.h>
+#include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/screen_info.h>
 #include <video/vga.h>
@@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
 };
 ATTRIBUTE_GROUPS(efifb);
 
+static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
+static bool pci_dev_disabled;	/* was the device disabled? */
+
 static int efifb_probe(struct platform_device *dev)
 {
 	struct fb_info *info;
@@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
 	unsigned int size_total;
 	char *option = NULL;
 
-	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
 		return -ENODEV;
 
 	if (fb_get_options("efifb", &option))
@@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
 };
 
 builtin_platform_driver(efifb_driver);
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+	u16 word;
+
+	pci_bar_found = true;
+
+	pci_read_config_word(dev, PCI_COMMAND, &word);
+	if (!(word & PCI_COMMAND_MEMORY)) {
+		pci_dev_disabled = true;
+		dev_err(&dev->dev,
+			"BAR %d: assigned to efifb but device is disabled!\n",
+			idx);
+		return;
+	}
+
+	if (pci_claim_resource(dev, idx)) {
+		pci_dev_disabled = true;
+		dev_err(&dev->dev,
+			"BAR %d: failed to claim resource for efifb!\n", idx);
+		return;
+	}
+
+	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+	u64 base = screen_info.lfb_base;
+	u64 size = screen_info.lfb_size;
+	int i;
+
+	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+		return;
+
+	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+		base |= (u64)screen_info.ext_lfb_base << 32;
+
+	if (!base)
+		return;
+
+	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+		struct resource *res = &dev->resource[i];
+
+		if (!(res->flags & IORESOURCE_MEM))
+			continue;
+
+		if (res->start <= base && res->end >= base + size - 1) {
+			claim_efifb_bar(dev, i);
+			break;
+		}
+	}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
-- 
2.7.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On UEFI systems, the PCI subsystem is enumerated by the firmware,
and if a graphical framebuffer is exposed by a PCI device, its base
address and size are exposed to the OS via the Graphics Output
Protocol (GOP).

On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
scratch at boot. This may result in the GOP framebuffer address to
become stale, if the BAR covering the framebuffer is modified. This
will cause the framebuffer to become unresponsive, and may in some
cases result in unpredictable behavior if the range is reassigned to
another device.

So add a quirk to the EFI fb driver to find the BAR associated with
the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
that the PCI core will leave it alone.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
v3: check device is enabled before attempting to claim the resource

 drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
 1 file changed, 59 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 8c4dc1e1f94f..88f653864a01 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -10,6 +10,7 @@
 #include <linux/efi.h>
 #include <linux/errno.h>
 #include <linux/fb.h>
+#include <linux/pci.h>
 #include <linux/platform_device.h>
 #include <linux/screen_info.h>
 #include <video/vga.h>
@@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
 };
 ATTRIBUTE_GROUPS(efifb);
 
+static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
+static bool pci_dev_disabled;	/* was the device disabled? */
+
 static int efifb_probe(struct platform_device *dev)
 {
 	struct fb_info *info;
@@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
 	unsigned int size_total;
 	char *option = NULL;
 
-	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
 		return -ENODEV;
 
 	if (fb_get_options("efifb", &option))
@@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
 };
 
 builtin_platform_driver(efifb_driver);
+
+static void claim_efifb_bar(struct pci_dev *dev, int idx)
+{
+	u16 word;
+
+	pci_bar_found = true;
+
+	pci_read_config_word(dev, PCI_COMMAND, &word);
+	if (!(word & PCI_COMMAND_MEMORY)) {
+		pci_dev_disabled = true;
+		dev_err(&dev->dev,
+			"BAR %d: assigned to efifb but device is disabled!\n",
+			idx);
+		return;
+	}
+
+	if (pci_claim_resource(dev, idx)) {
+		pci_dev_disabled = true;
+		dev_err(&dev->dev,
+			"BAR %d: failed to claim resource for efifb!\n", idx);
+		return;
+	}
+
+	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
+}
+
+static void efifb_fixup_resources(struct pci_dev *dev)
+{
+	u64 base = screen_info.lfb_base;
+	u64 size = screen_info.lfb_size;
+	int i;
+
+	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
+		return;
+
+	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
+		base |= (u64)screen_info.ext_lfb_base << 32;
+
+	if (!base)
+		return;
+
+	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
+		struct resource *res = &dev->resource[i];
+
+		if (!(res->flags & IORESOURCE_MEM))
+			continue;
+
+		if (res->start <= base && res->end >= base + size - 1) {
+			claim_efifb_bar(dev, i);
+			break;
+		}
+	}
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
-- 
2.7.4

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lukas Wunner]

On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> and if a graphical framebuffer is exposed by a PCI device, its base
> address and size are exposed to the OS via the Graphics Output
> Protocol (GOP).
> 
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified. This
> will cause the framebuffer to become unresponsive, and may in some
> cases result in unpredictable behavior if the range is reassigned to
> another device.

Hm, commit message seems to indicate the issue is restricted to arm64,
yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?


> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);

Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?

Thanks,

Lukas

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lukas Wunner]

On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> and if a graphical framebuffer is exposed by a PCI device, its base
> address and size are exposed to the OS via the Graphics Output
> Protocol (GOP).
> 
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified. This
> will cause the framebuffer to become unresponsive, and may in some
> cases result in unpredictable behavior if the range is reassigned to
> another device.

Hm, commit message seems to indicate the issue is restricted to arm64,
yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?


> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);

Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?

Thanks,

Lukas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lukas Wunner]

On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> and if a graphical framebuffer is exposed by a PCI device, its base
> address and size are exposed to the OS via the Graphics Output
> Protocol (GOP).
> 
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified. This
> will cause the framebuffer to become unresponsive, and may in some
> cases result in unpredictable behavior if the range is reassigned to
> another device.

Hm, commit message seems to indicate the issue is restricted to arm64,
yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?


> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);

Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?

Thanks,

Lukas

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> and if a graphical framebuffer is exposed by a PCI device, its base
>> address and size are exposed to the OS via the Graphics Output
>> Protocol (GOP).
>>
>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> scratch at boot. This may result in the GOP framebuffer address to
>> become stale, if the BAR covering the framebuffer is modified. This
>> will cause the framebuffer to become unresponsive, and may in some
>> cases result in unpredictable behavior if the range is reassigned to
>> another device.
>
> Hm, commit message seems to indicate the issue is restricted to arm64,
> yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>

True. I am eager to get some x86 coverage for this, since I would
expect this not to do any harm. But I'm fine with making it ARM/arm64
specific in the final version.

>
>> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
>
> Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
>

How does one do that with DECLARE_PCI_FIXUP_HEADER?

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> and if a graphical framebuffer is exposed by a PCI device, its base
>> address and size are exposed to the OS via the Graphics Output
>> Protocol (GOP).
>>
>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> scratch at boot. This may result in the GOP framebuffer address to
>> become stale, if the BAR covering the framebuffer is modified. This
>> will cause the framebuffer to become unresponsive, and may in some
>> cases result in unpredictable behavior if the range is reassigned to
>> another device.
>
> Hm, commit message seems to indicate the issue is restricted to arm64,
> yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>

True. I am eager to get some x86 coverage for this, since I would
expect this not to do any harm. But I'm fine with making it ARM/arm64
specific in the final version.

>
>> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
>
> Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
>

How does one do that with DECLARE_PCI_FIXUP_HEADER?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> and if a graphical framebuffer is exposed by a PCI device, its base
>> address and size are exposed to the OS via the Graphics Output
>> Protocol (GOP).
>>
>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> scratch at boot. This may result in the GOP framebuffer address to
>> become stale, if the BAR covering the framebuffer is modified. This
>> will cause the framebuffer to become unresponsive, and may in some
>> cases result in unpredictable behavior if the range is reassigned to
>> another device.
>
> Hm, commit message seems to indicate the issue is restricted to arm64,
> yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>

True. I am eager to get some x86 coverage for this, since I would
expect this not to do any harm. But I'm fine with making it ARM/arm64
specific in the final version.

>
>> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
>
> Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
>

How does one do that with DECLARE_PCI_FIXUP_HEADER?

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:31 PM, Lukas Wunner wrote:
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified.

Does this code still work with the case where resources are not reassigned on ARM64?

As far as I know, kernel honors resource assignments done by the UEFI BIOS if
they are correct. Kernel will reassign the resources only if something is wrong.

Will this code break other platforms/architectures?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:31 PM, Lukas Wunner wrote:
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified.

Does this code still work with the case where resources are not reassigned on ARM64?

As far as I know, kernel honors resource assignments done by the UEFI BIOS if
they are correct. Kernel will reassign the resources only if something is wrong.

Will this code break other platforms/architectures?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:31 PM, Lukas Wunner wrote:
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified.

Does this code still work with the case where resources are not reassigned on ARM64?

As far as I know, kernel honors resource assignments done by the UEFI BIOS if
they are correct. Kernel will reassign the resources only if something is wrong.

Will this code break other platforms/architectures?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:36, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:31 PM, Lukas Wunner wrote:
>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> scratch at boot. This may result in the GOP framebuffer address to
>> become stale, if the BAR covering the framebuffer is modified.
>
> Does this code still work with the case where resources are not reassigned on ARM64?
>
> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
> they are correct. Kernel will reassign the resources only if something is wrong.
>

No, the kernel always reassigns all BARs on arm64.

> Will this code break other platforms/architectures?
>

Which platforms/architectures are you referring to? EFIFB on a PCI
device is currently broken on arm64. On x86, it works, given that BARs
are usually not reassigned, and so the patch should be a no-op in that
case (although I'd argue it is still an improvement to check whether
the device that owns the BAR actually has memory decoding enabled
before we attach the framebuffer driver to it)

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:36, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:31 PM, Lukas Wunner wrote:
>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> scratch at boot. This may result in the GOP framebuffer address to
>> become stale, if the BAR covering the framebuffer is modified.
>
> Does this code still work with the case where resources are not reassigned on ARM64?
>
> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
> they are correct. Kernel will reassign the resources only if something is wrong.
>

No, the kernel always reassigns all BARs on arm64.

> Will this code break other platforms/architectures?
>

Which platforms/architectures are you referring to? EFIFB on a PCI
device is currently broken on arm64. On x86, it works, given that BARs
are usually not reassigned, and so the patch should be a no-op in that
case (although I'd argue it is still an improvement to check whether
the device that owns the BAR actually has memory decoding enabled
before we attach the framebuffer driver to it)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:36, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:31 PM, Lukas Wunner wrote:
>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> scratch at boot. This may result in the GOP framebuffer address to
>> become stale, if the BAR covering the framebuffer is modified.
>
> Does this code still work with the case where resources are not reassigned on ARM64?
>
> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
> they are correct. Kernel will reassign the resources only if something is wrong.
>

No, the kernel always reassigns all BARs on arm64.

> Will this code break other platforms/architectures?
>

Which platforms/architectures are you referring to? EFIFB on a PCI
device is currently broken on arm64. On x86, it works, given that BARs
are usually not reassigned, and so the patch should be a no-op in that
case (although I'd argue it is still an improvement to check whether
the device that owns the BAR actually has memory decoding enabled
before we attach the framebuffer driver to it)

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>> they are correct. Kernel will reassign the resources only if something is wrong.
>>
> No, the kernel always reassigns all BARs on arm64.

I think this is where the problem is.

I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
combination only. 

I see that kernel honored the resources assigned by UEFI BIOS if I compare
the BAR addresses.

I see reassignment only when something is horribly broken. Then, there would
be a bridge configuration invalid message in the boot log to confirm this.

> 
>> Will this code break other platforms/architectures?
>>
> Which platforms/architectures are you referring to? EFIFB on a PCI
> device is currently broken on arm64. 

In general or on your particular platform?

> On x86, it works, given that BARs
> are usually not reassigned, and so the patch should be a no-op in that
> case (although I'd argue it is still an improvement to check whether
> the device that owns the BAR actually has memory decoding enabled
> before we attach the framebuffer driver to it)
> 

I'm fine as long as it doesn't break anything. That's why, I'm asking.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>> they are correct. Kernel will reassign the resources only if something is wrong.
>>
> No, the kernel always reassigns all BARs on arm64.

I think this is where the problem is.

I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
combination only. 

I see that kernel honored the resources assigned by UEFI BIOS if I compare
the BAR addresses.

I see reassignment only when something is horribly broken. Then, there would
be a bridge configuration invalid message in the boot log to confirm this.

> 
>> Will this code break other platforms/architectures?
>>
> Which platforms/architectures are you referring to? EFIFB on a PCI
> device is currently broken on arm64. 

In general or on your particular platform?

> On x86, it works, given that BARs
> are usually not reassigned, and so the patch should be a no-op in that
> case (although I'd argue it is still an improvement to check whether
> the device that owns the BAR actually has memory decoding enabled
> before we attach the framebuffer driver to it)
> 

I'm fine as long as it doesn't break anything. That's why, I'm asking.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>> they are correct. Kernel will reassign the resources only if something is wrong.
>>
> No, the kernel always reassigns all BARs on arm64.

I think this is where the problem is.

I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
combination only. 

I see that kernel honored the resources assigned by UEFI BIOS if I compare
the BAR addresses.

I see reassignment only when something is horribly broken. Then, there would
be a bridge configuration invalid message in the boot log to confirm this.

> 
>> Will this code break other platforms/architectures?
>>
> Which platforms/architectures are you referring to? EFIFB on a PCI
> device is currently broken on arm64. 

In general or on your particular platform?

> On x86, it works, given that BARs
> are usually not reassigned, and so the patch should be a no-op in that
> case (although I'd argue it is still an improvement to check whether
> the device that owns the BAR actually has memory decoding enabled
> before we attach the framebuffer driver to it)
> 

I'm fine as long as it doesn't break anything. That's why, I'm asking.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:49, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>
>> No, the kernel always reassigns all BARs on arm64.
>
> I think this is where the problem is.
>
> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
> combination only.
>
> I see that kernel honored the resources assigned by UEFI BIOS if I compare
> the BAR addresses.
>

Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
driver in UEFI, the logic is quite similar, and so you usually end up
with the same resource assignments. But the kernel does recompute them
from scratch, and ignores the existing configuration that is present
in the BARs

> I see reassignment only when something is horribly broken. Then, there would
> be a bridge configuration invalid message in the boot log to confirm this.
>
>>
>>> Will this code break other platforms/architectures?
>>>
>> Which platforms/architectures are you referring to? EFIFB on a PCI
>> device is currently broken on arm64.
>
> In general or on your particular platform?
>
>> On x86, it works, given that BARs
>> are usually not reassigned, and so the patch should be a no-op in that
>> case (although I'd argue it is still an improvement to check whether
>> the device that owns the BAR actually has memory decoding enabled
>> before we attach the framebuffer driver to it)
>>
>
> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>

If you have working EFIFB on your platform, it works by accident. This
patch is needed to ensure that the BAR associated with the EFI
framebuffer is left untouched.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:49, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>
>> No, the kernel always reassigns all BARs on arm64.
>
> I think this is where the problem is.
>
> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
> combination only.
>
> I see that kernel honored the resources assigned by UEFI BIOS if I compare
> the BAR addresses.
>

Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
driver in UEFI, the logic is quite similar, and so you usually end up
with the same resource assignments. But the kernel does recompute them
from scratch, and ignores the existing configuration that is present
in the BARs

> I see reassignment only when something is horribly broken. Then, there would
> be a bridge configuration invalid message in the boot log to confirm this.
>
>>
>>> Will this code break other platforms/architectures?
>>>
>> Which platforms/architectures are you referring to? EFIFB on a PCI
>> device is currently broken on arm64.
>
> In general or on your particular platform?
>
>> On x86, it works, given that BARs
>> are usually not reassigned, and so the patch should be a no-op in that
>> case (although I'd argue it is still an improvement to check whether
>> the device that owns the BAR actually has memory decoding enabled
>> before we attach the framebuffer driver to it)
>>
>
> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>

If you have working EFIFB on your platform, it works by accident. This
patch is needed to ensure that the BAR associated with the EFI
framebuffer is left untouched.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:49, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>
>> No, the kernel always reassigns all BARs on arm64.
>
> I think this is where the problem is.
>
> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
> combination only.
>
> I see that kernel honored the resources assigned by UEFI BIOS if I compare
> the BAR addresses.
>

Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
driver in UEFI, the logic is quite similar, and so you usually end up
with the same resource assignments. But the kernel does recompute them
from scratch, and ignores the existing configuration that is present
in the BARs

> I see reassignment only when something is horribly broken. Then, there would
> be a bridge configuration invalid message in the boot log to confirm this.
>
>>
>>> Will this code break other platforms/architectures?
>>>
>> Which platforms/architectures are you referring to? EFIFB on a PCI
>> device is currently broken on arm64.
>
> In general or on your particular platform?
>
>> On x86, it works, given that BARs
>> are usually not reassigned, and so the patch should be a no-op in that
>> case (although I'd argue it is still an improvement to check whether
>> the device that owns the BAR actually has memory decoding enabled
>> before we attach the framebuffer driver to it)
>>
>
> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>

If you have working EFIFB on your platform, it works by accident. This
patch is needed to ensure that the BAR associated with the EFI
framebuffer is left untouched.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:49, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>>
>>> No, the kernel always reassigns all BARs on arm64.
>>
>> I think this is where the problem is.
>>
>> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
>> combination only.
>>
>> I see that kernel honored the resources assigned by UEFI BIOS if I compare
>> the BAR addresses.
>>
> 
> Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
> driver in UEFI, the logic is quite similar, and so you usually end up
> with the same resource assignments. But the kernel does recompute them
> from scratch, and ignores the existing configuration that is present
> in the BARs

Yes, standard stuff in UEFI. OK. That may explain what I'm seeing.

> 
>> I see reassignment only when something is horribly broken. Then, there would
>> be a bridge configuration invalid message in the boot log to confirm this.
>>
>>>
>>>> Will this code break other platforms/architectures?
>>>>
>>> Which platforms/architectures are you referring to? EFIFB on a PCI
>>> device is currently broken on arm64.
>>
>> In general or on your particular platform?
>>
>>> On x86, it works, given that BARs
>>> are usually not reassigned, and so the patch should be a no-op in that
>>> case (although I'd argue it is still an improvement to check whether
>>> the device that owns the BAR actually has memory decoding enabled
>>> before we attach the framebuffer driver to it)
>>>
>>
>> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>>
> 
> If you have working EFIFB on your platform, it works by accident. This
> patch is needed to ensure that the BAR associated with the EFI
> framebuffer is left untouched.
> 

I never claimed that. I was just double checking your assumptions.
I really don't like ARM64 specific PCI code in general. PCI doesn't care
about CPU type. I hope to see this patch become part of common code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:49, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>>
>>> No, the kernel always reassigns all BARs on arm64.
>>
>> I think this is where the problem is.
>>
>> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
>> combination only.
>>
>> I see that kernel honored the resources assigned by UEFI BIOS if I compare
>> the BAR addresses.
>>
> 
> Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
> driver in UEFI, the logic is quite similar, and so you usually end up
> with the same resource assignments. But the kernel does recompute them
> from scratch, and ignores the existing configuration that is present
> in the BARs

Yes, standard stuff in UEFI. OK. That may explain what I'm seeing.

> 
>> I see reassignment only when something is horribly broken. Then, there would
>> be a bridge configuration invalid message in the boot log to confirm this.
>>
>>>
>>>> Will this code break other platforms/architectures?
>>>>
>>> Which platforms/architectures are you referring to? EFIFB on a PCI
>>> device is currently broken on arm64.
>>
>> In general or on your particular platform?
>>
>>> On x86, it works, given that BARs
>>> are usually not reassigned, and so the patch should be a no-op in that
>>> case (although I'd argue it is still an improvement to check whether
>>> the device that owns the BAR actually has memory decoding enabled
>>> before we attach the framebuffer driver to it)
>>>
>>
>> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>>
> 
> If you have working EFIFB on your platform, it works by accident. This
> patch is needed to ensure that the BAR associated with the EFI
> framebuffer is left untouched.
> 

I never claimed that. I was just double checking your assumptions.
I really don't like ARM64 specific PCI code in general. PCI doesn't care
about CPU type. I hope to see this patch become part of common code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:49, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>>
>>> No, the kernel always reassigns all BARs on arm64.
>>
>> I think this is where the problem is.
>>
>> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
>> combination only.
>>
>> I see that kernel honored the resources assigned by UEFI BIOS if I compare
>> the BAR addresses.
>>
> 
> Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
> driver in UEFI, the logic is quite similar, and so you usually end up
> with the same resource assignments. But the kernel does recompute them
> from scratch, and ignores the existing configuration that is present
> in the BARs

Yes, standard stuff in UEFI. OK. That may explain what I'm seeing.

> 
>> I see reassignment only when something is horribly broken. Then, there would
>> be a bridge configuration invalid message in the boot log to confirm this.
>>
>>>
>>>> Will this code break other platforms/architectures?
>>>>
>>> Which platforms/architectures are you referring to? EFIFB on a PCI
>>> device is currently broken on arm64.
>>
>> In general or on your particular platform?
>>
>>> On x86, it works, given that BARs
>>> are usually not reassigned, and so the patch should be a no-op in that
>>> case (although I'd argue it is still an improvement to check whether
>>> the device that owns the BAR actually has memory decoding enabled
>>> before we attach the framebuffer driver to it)
>>>
>>
>> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>>
> 
> If you have working EFIFB on your platform, it works by accident. This
> patch is needed to ensure that the BAR associated with the EFI
> framebuffer is left untouched.
> 

I never claimed that. I was just double checking your assumptions.
I really don't like ARM64 specific PCI code in general. PCI doesn't care
about CPU type. I hope to see this patch become part of common code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:57, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
[..]
>> If you have working EFIFB on your platform, it works by accident. This
>> patch is needed to ensure that the BAR associated with the EFI
>> framebuffer is left untouched.
>>
>
> I never claimed that. I was just double checking your assumptions.
> I really don't like ARM64 specific PCI code in general. PCI doesn't care
> about CPU type. I hope to see this patch become part of common code.
>

Good! Thanks

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:57, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
[..]
>> If you have working EFIFB on your platform, it works by accident. This
>> patch is needed to ensure that the BAR associated with the EFI
>> framebuffer is left untouched.
>>
>
> I never claimed that. I was just double checking your assumptions.
> I really don't like ARM64 specific PCI code in general. PCI doesn't care
> about CPU type. I hope to see this patch become part of common code.
>

Good! Thanks

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 22 March 2017 at 19:57, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
[..]
>> If you have working EFIFB on your platform, it works by accident. This
>> patch is needed to ensure that the BAR associated with the EFI
>> framebuffer is left untouched.
>>
>
> I never claimed that. I was just double checking your assumptions.
> I really don't like ARM64 specific PCI code in general. PCI doesn't care
> about CPU type. I hope to see this patch become part of common code.
>

Good! Thanks

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lukas Wunner]

On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:31, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> address and size are exposed to the OS via the Graphics Output
> >> Protocol (GOP).
> >>
> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> scratch at boot. This may result in the GOP framebuffer address to
> >> become stale, if the BAR covering the framebuffer is modified. This
> >> will cause the framebuffer to become unresponsive, and may in some
> >> cases result in unpredictable behavior if the range is reassigned to
> >> another device.
> >
> > Hm, commit message seems to indicate the issue is restricted to arm64,
> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> 
> True. I am eager to get some x86 coverage for this, since I would
> expect this not to do any harm. But I'm fine with making it ARM/arm64
> specific in the final version.

I see.  IIUC, this is only a problem because pci_bus_assign_resources()
is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
the host drivers) and x86 isn't affected because it doesn't do that.

I have no opinion on executing the quirk on x86 as well, I was just
confused by the discrepancy between commit message and patch, but that
can easily be remedied with a copy+paste of what you replied to Sinan:

       "On x86, it works, given that BARs are usually not reassigned,
	and so the patch should be a no-op in that case, although it
	should still be an improvement to check whether the device that
	owns the BAR actually has memory decoding enabled before we
	attach the framebuffer driver to it."


> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> >
> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
> 
> How does one do that with DECLARE_PCI_FIXUP_HEADER?

With DECLARE_PCI_FIXUP_CLASS_HEADER().

Thanks,

Lukas

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lukas Wunner]

On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> address and size are exposed to the OS via the Graphics Output
> >> Protocol (GOP).
> >>
> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> scratch at boot. This may result in the GOP framebuffer address to
> >> become stale, if the BAR covering the framebuffer is modified. This
> >> will cause the framebuffer to become unresponsive, and may in some
> >> cases result in unpredictable behavior if the range is reassigned to
> >> another device.
> >
> > Hm, commit message seems to indicate the issue is restricted to arm64,
> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> 
> True. I am eager to get some x86 coverage for this, since I would
> expect this not to do any harm. But I'm fine with making it ARM/arm64
> specific in the final version.

I see.  IIUC, this is only a problem because pci_bus_assign_resources()
is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
the host drivers) and x86 isn't affected because it doesn't do that.

I have no opinion on executing the quirk on x86 as well, I was just
confused by the discrepancy between commit message and patch, but that
can easily be remedied with a copy+paste of what you replied to Sinan:

       "On x86, it works, given that BARs are usually not reassigned,
	and so the patch should be a no-op in that case, although it
	should still be an improvement to check whether the device that
	owns the BAR actually has memory decoding enabled before we
	attach the framebuffer driver to it."


> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> >
> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
> 
> How does one do that with DECLARE_PCI_FIXUP_HEADER?

With DECLARE_PCI_FIXUP_CLASS_HEADER().

Thanks,

Lukas

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lukas Wunner]

On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> address and size are exposed to the OS via the Graphics Output
> >> Protocol (GOP).
> >>
> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> scratch at boot. This may result in the GOP framebuffer address to
> >> become stale, if the BAR covering the framebuffer is modified. This
> >> will cause the framebuffer to become unresponsive, and may in some
> >> cases result in unpredictable behavior if the range is reassigned to
> >> another device.
> >
> > Hm, commit message seems to indicate the issue is restricted to arm64,
> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> 
> True. I am eager to get some x86 coverage for this, since I would
> expect this not to do any harm. But I'm fine with making it ARM/arm64
> specific in the final version.

I see.  IIUC, this is only a problem because pci_bus_assign_resources()
is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
the host drivers) and x86 isn't affected because it doesn't do that.

I have no opinion on executing the quirk on x86 as well, I was just
confused by the discrepancy between commit message and patch, but that
can easily be remedied with a copy+paste of what you replied to Sinan:

       "On x86, it works, given that BARs are usually not reassigned,
	and so the patch should be a no-op in that case, although it
	should still be an improvement to check whether the device that
	owns the BAR actually has memory decoding enabled before we
	attach the framebuffer driver to it."


> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> >
> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
> 
> How does one do that with DECLARE_PCI_FIXUP_HEADER?

With DECLARE_PCI_FIXUP_CLASS_HEADER().

Thanks,

Lukas

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> address and size are exposed to the OS via the Graphics Output
>> >> Protocol (GOP).
>> >>
>> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> will cause the framebuffer to become unresponsive, and may in some
>> >> cases result in unpredictable behavior if the range is reassigned to
>> >> another device.
>> >
>> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>>
>> True. I am eager to get some x86 coverage for this, since I would
>> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> specific in the final version.
>
> I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> the host drivers) and x86 isn't affected because it doesn't do that.
>

Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
(or the legacy PCI bios) performed the resource assignment already.
One could argue that this is equally the case when running arm64 in
ACPI mode, but in general, you cannot assume the presence of firmware
on ARM/arm64 that has already taken care of this, and so the state of
the BARs has to be presumed invalid.

> I have no opinion on executing the quirk on x86 as well, I was just
> confused by the discrepancy between commit message and patch, but that
> can easily be remedied with a copy+paste of what you replied to Sinan:
>
>        "On x86, it works, given that BARs are usually not reassigned,
>         and so the patch should be a no-op in that case, although it
>         should still be an improvement to check whether the device that
>         owns the BAR actually has memory decoding enabled before we
>         attach the framebuffer driver to it."
>
>

OK, I will include that.

>> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
>> >
>> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
>>
>> How does one do that with DECLARE_PCI_FIXUP_HEADER?
>
> With DECLARE_PCI_FIXUP_CLASS_HEADER().
>

Ah ok, thanks for pointing that out.

I do wonder whether it makes sense to keep the code as is, so that we
spot unexpected configurations, i.e., where the GOP points into a BAR
that is unrelated to graphics. In this case, I think we should disable
efifb rather than proceed without claiming any PCI resources (as we
did without this patch)

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> address and size are exposed to the OS via the Graphics Output
>> >> Protocol (GOP).
>> >>
>> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> will cause the framebuffer to become unresponsive, and may in some
>> >> cases result in unpredictable behavior if the range is reassigned to
>> >> another device.
>> >
>> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>>
>> True. I am eager to get some x86 coverage for this, since I would
>> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> specific in the final version.
>
> I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> the host drivers) and x86 isn't affected because it doesn't do that.
>

Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
(or the legacy PCI bios) performed the resource assignment already.
One could argue that this is equally the case when running arm64 in
ACPI mode, but in general, you cannot assume the presence of firmware
on ARM/arm64 that has already taken care of this, and so the state of
the BARs has to be presumed invalid.

> I have no opinion on executing the quirk on x86 as well, I was just
> confused by the discrepancy between commit message and patch, but that
> can easily be remedied with a copy+paste of what you replied to Sinan:
>
>        "On x86, it works, given that BARs are usually not reassigned,
>         and so the patch should be a no-op in that case, although it
>         should still be an improvement to check whether the device that
>         owns the BAR actually has memory decoding enabled before we
>         attach the framebuffer driver to it."
>
>

OK, I will include that.

>> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
>> >
>> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
>>
>> How does one do that with DECLARE_PCI_FIXUP_HEADER?
>
> With DECLARE_PCI_FIXUP_CLASS_HEADER().
>

Ah ok, thanks for pointing that out.

I do wonder whether it makes sense to keep the code as is, so that we
spot unexpected configurations, i.e., where the GOP points into a BAR
that is unrelated to graphics. In this case, I think we should disable
efifb rather than proceed without claiming any PCI resources (as we
did without this patch)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> address and size are exposed to the OS via the Graphics Output
>> >> Protocol (GOP).
>> >>
>> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> will cause the framebuffer to become unresponsive, and may in some
>> >> cases result in unpredictable behavior if the range is reassigned to
>> >> another device.
>> >
>> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>>
>> True. I am eager to get some x86 coverage for this, since I would
>> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> specific in the final version.
>
> I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> the host drivers) and x86 isn't affected because it doesn't do that.
>

Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
(or the legacy PCI bios) performed the resource assignment already.
One could argue that this is equally the case when running arm64 in
ACPI mode, but in general, you cannot assume the presence of firmware
on ARM/arm64 that has already taken care of this, and so the state of
the BARs has to be presumed invalid.

> I have no opinion on executing the quirk on x86 as well, I was just
> confused by the discrepancy between commit message and patch, but that
> can easily be remedied with a copy+paste of what you replied to Sinan:
>
>        "On x86, it works, given that BARs are usually not reassigned,
>         and so the patch should be a no-op in that case, although it
>         should still be an improvement to check whether the device that
>         owns the BAR actually has memory decoding enabled before we
>         attach the framebuffer driver to it."
>
>

OK, I will include that.

>> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
>> >
>> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
>>
>> How does one do that with DECLARE_PCI_FIXUP_HEADER?
>
> With DECLARE_PCI_FIXUP_CLASS_HEADER().
>

Ah ok, thanks for pointing that out.

I do wonder whether it makes sense to keep the code as is, so that we
spot unexpected configurations, i.e., where the GOP points into a BAR
that is unrelated to graphics. In this case, I think we should disable
efifb rather than proceed without claiming any PCI resources (as we
did without this patch)

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
> On 23 March 2017 at 08:48, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> >> address and size are exposed to the OS via the Graphics Output
> >> >> Protocol (GOP).
> >> >>
> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> >> scratch at boot. This may result in the GOP framebuffer address to
> >> >> become stale, if the BAR covering the framebuffer is modified. This
> >> >> will cause the framebuffer to become unresponsive, and may in some
> >> >> cases result in unpredictable behavior if the range is reassigned to
> >> >> another device.
> >> >
> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> >>
> >> True. I am eager to get some x86 coverage for this, since I would
> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
> >> specific in the final version.
> >
> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> > the host drivers) and x86 isn't affected because it doesn't do that.
> >
> 
> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
> (or the legacy PCI bios) performed the resource assignment already.
> One could argue that this is equally the case when running arm64 in
> ACPI mode, but in general, you cannot assume the presence of firmware
> on ARM/arm64 that has already taken care of this, and so the state of
> the BARs has to be presumed invalid.

The story is a bit more convoluted than that owing to x86 (and other
arches) legacy.

x86 tries to claim all PCI resources (in two passes - first enabled
devices, second disabled devices) and that predates ACPI/UEFI.

Mind, x86 reassign resources that can't be claimed too, the only
difference with ARM64 is that, for the better or the worse, we
have decided not to claim the FW PCI set-up on ARM64 even if it
is sane, we do not even try, it was a deliberate choice.

This patch should be harmless on x86 since if the FB PCI BAR is set
up sanely, claiming it again should be a nop (to be checked).

For all the talk about PCI being arch agnostic as I said manifold
times before, that's just theory. In practice different arches
treat PCI FW set-up differently, it would be ideal to make them
uniform but legacy is huge and there is a massive risk of triggering
regressions, it is no mean feat (if achievable at all).

Lorenzo

> > I have no opinion on executing the quirk on x86 as well, I was just
> > confused by the discrepancy between commit message and patch, but that
> > can easily be remedied with a copy+paste of what you replied to Sinan:
> >
> >        "On x86, it works, given that BARs are usually not reassigned,
> >         and so the patch should be a no-op in that case, although it
> >         should still be an improvement to check whether the device that
> >         owns the BAR actually has memory decoding enabled before we
> >         attach the framebuffer driver to it."
> >
> >
> 
> OK, I will include that.
> 
> >> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> >> >
> >> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
> >>
> >> How does one do that with DECLARE_PCI_FIXUP_HEADER?
> >
> > With DECLARE_PCI_FIXUP_CLASS_HEADER().
> >
> 
> Ah ok, thanks for pointing that out.
> 
> I do wonder whether it makes sense to keep the code as is, so that we
> spot unexpected configurations, i.e., where the GOP points into a BAR
> that is unrelated to graphics. In this case, I think we should disable
> efifb rather than proceed without claiming any PCI resources (as we
> did without this patch)

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> >> address and size are exposed to the OS via the Graphics Output
> >> >> Protocol (GOP).
> >> >>
> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> >> scratch at boot. This may result in the GOP framebuffer address to
> >> >> become stale, if the BAR covering the framebuffer is modified. This
> >> >> will cause the framebuffer to become unresponsive, and may in some
> >> >> cases result in unpredictable behavior if the range is reassigned to
> >> >> another device.
> >> >
> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> >>
> >> True. I am eager to get some x86 coverage for this, since I would
> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
> >> specific in the final version.
> >
> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> > the host drivers) and x86 isn't affected because it doesn't do that.
> >
> 
> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
> (or the legacy PCI bios) performed the resource assignment already.
> One could argue that this is equally the case when running arm64 in
> ACPI mode, but in general, you cannot assume the presence of firmware
> on ARM/arm64 that has already taken care of this, and so the state of
> the BARs has to be presumed invalid.

The story is a bit more convoluted than that owing to x86 (and other
arches) legacy.

x86 tries to claim all PCI resources (in two passes - first enabled
devices, second disabled devices) and that predates ACPI/UEFI.

Mind, x86 reassign resources that can't be claimed too, the only
difference with ARM64 is that, for the better or the worse, we
have decided not to claim the FW PCI set-up on ARM64 even if it
is sane, we do not even try, it was a deliberate choice.

This patch should be harmless on x86 since if the FB PCI BAR is set
up sanely, claiming it again should be a nop (to be checked).

For all the talk about PCI being arch agnostic as I said manifold
times before, that's just theory. In practice different arches
treat PCI FW set-up differently, it would be ideal to make them
uniform but legacy is huge and there is a massive risk of triggering
regressions, it is no mean feat (if achievable at all).

Lorenzo

> > I have no opinion on executing the quirk on x86 as well, I was just
> > confused by the discrepancy between commit message and patch, but that
> > can easily be remedied with a copy+paste of what you replied to Sinan:
> >
> >        "On x86, it works, given that BARs are usually not reassigned,
> >         and so the patch should be a no-op in that case, although it
> >         should still be an improvement to check whether the device that
> >         owns the BAR actually has memory decoding enabled before we
> >         attach the framebuffer driver to it."
> >
> >
> 
> OK, I will include that.
> 
> >> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> >> >
> >> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
> >>
> >> How does one do that with DECLARE_PCI_FIXUP_HEADER?
> >
> > With DECLARE_PCI_FIXUP_CLASS_HEADER().
> >
> 
> Ah ok, thanks for pointing that out.
> 
> I do wonder whether it makes sense to keep the code as is, so that we
> spot unexpected configurations, i.e., where the GOP points into a BAR
> that is unrelated to graphics. In this case, I think we should disable
> efifb rather than proceed without claiming any PCI resources (as we
> did without this patch)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> >> address and size are exposed to the OS via the Graphics Output
> >> >> Protocol (GOP).
> >> >>
> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> >> scratch at boot. This may result in the GOP framebuffer address to
> >> >> become stale, if the BAR covering the framebuffer is modified. This
> >> >> will cause the framebuffer to become unresponsive, and may in some
> >> >> cases result in unpredictable behavior if the range is reassigned to
> >> >> another device.
> >> >
> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> >>
> >> True. I am eager to get some x86 coverage for this, since I would
> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
> >> specific in the final version.
> >
> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> > the host drivers) and x86 isn't affected because it doesn't do that.
> >
> 
> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
> (or the legacy PCI bios) performed the resource assignment already.
> One could argue that this is equally the case when running arm64 in
> ACPI mode, but in general, you cannot assume the presence of firmware
> on ARM/arm64 that has already taken care of this, and so the state of
> the BARs has to be presumed invalid.

The story is a bit more convoluted than that owing to x86 (and other
arches) legacy.

x86 tries to claim all PCI resources (in two passes - first enabled
devices, second disabled devices) and that predates ACPI/UEFI.

Mind, x86 reassign resources that can't be claimed too, the only
difference with ARM64 is that, for the better or the worse, we
have decided not to claim the FW PCI set-up on ARM64 even if it
is sane, we do not even try, it was a deliberate choice.

This patch should be harmless on x86 since if the FB PCI BAR is set
up sanely, claiming it again should be a nop (to be checked).

For all the talk about PCI being arch agnostic as I said manifold
times before, that's just theory. In practice different arches
treat PCI FW set-up differently, it would be ideal to make them
uniform but legacy is huge and there is a massive risk of triggering
regressions, it is no mean feat (if achievable at all).

Lorenzo

> > I have no opinion on executing the quirk on x86 as well, I was just
> > confused by the discrepancy between commit message and patch, but that
> > can easily be remedied with a copy+paste of what you replied to Sinan:
> >
> >        "On x86, it works, given that BARs are usually not reassigned,
> >         and so the patch should be a no-op in that case, although it
> >         should still be an improvement to check whether the device that
> >         owns the BAR actually has memory decoding enabled before we
> >         attach the framebuffer driver to it."
> >
> >
> 
> OK, I will include that.
> 
> >> >> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> >> >
> >> > Maybe this can be constrained to PCI_BASE_CLASS_DISPLAY?
> >>
> >> How does one do that with DECLARE_PCI_FIXUP_HEADER?
> >
> > With DECLARE_PCI_FIXUP_CLASS_HEADER().
> >
> 
> Ah ok, thanks for pointing that out.
> 
> I do wonder whether it makes sense to keep the code as is, so that we
> spot unexpected configurations, i.e., where the GOP points into a BAR
> that is unrelated to graphics. In this case, I think we should disable
> efifb rather than proceed without claiming any PCI resources (as we
> did without this patch)

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
> On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>> On 23 March 2017 at 08:48, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
>> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
>> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> >> address and size are exposed to the OS via the Graphics Output
>> >> >> Protocol (GOP).
>> >> >>
>> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> >> will cause the framebuffer to become unresponsive, and may in some
>> >> >> cases result in unpredictable behavior if the range is reassigned to
>> >> >> another device.
>> >> >
>> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>> >>
>> >> True. I am eager to get some x86 coverage for this, since I would
>> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> >> specific in the final version.
>> >
>> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>> > the host drivers) and x86 isn't affected because it doesn't do that.
>> >
>>
>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> (or the legacy PCI bios) performed the resource assignment already.
>> One could argue that this is equally the case when running arm64 in
>> ACPI mode, but in general, you cannot assume the presence of firmware
>> on ARM/arm64 that has already taken care of this, and so the state of
>> the BARs has to be presumed invalid.
>
> The story is a bit more convoluted than that owing to x86 (and other
> arches) legacy.
>
> x86 tries to claim all PCI resources (in two passes - first enabled
> devices, second disabled devices) and that predates ACPI/UEFI.
>
> Mind, x86 reassign resources that can't be claimed too, the only
> difference with ARM64 is that, for the better or the worse, we
> have decided not to claim the FW PCI set-up on ARM64 even if it
> is sane, we do not even try, it was a deliberate choice.
>
> This patch should be harmless on x86 since if the FB PCI BAR is set
> up sanely, claiming it again should be a nop (to be checked).
>

I have checked this with OVMF under QEMU. Claiming the resource early
like we do this in this patch does not result in any diagnostic output
or other symptoms that would suggest that anything unexpected occurs.

For the record: I applied the following hunk on top of the current
version of this patch

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 88f653864a01..98b7c437a448 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -380,7 +380,10 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
                return;
        }

-       if (pci_claim_resource(dev, idx)) {
+       if (dev->resource[idx].parent != NULL) {
+               dev_info(&dev->dev, "BAR %d: resource already claimed\n", idx);
+               while (1) { asm ("hlt"); }
+       } else if (pci_claim_resource(dev, idx)) {
                pci_dev_disabled = true;
                dev_err(&dev->dev,
                        "BAR %d: failed to claim resource for efifb!\n", idx);

and got the following output in the kernel log related to BDF 0/2/0 and efifb

pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:00:02.0: BAR 0: assigned to efifb
pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
efifb: probing for efifb
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

whereas a kernel without this patch gives me

pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
efifb: probing for efifb
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

/proc/iomem looks exactly the same.

So in summary, x86 does not seem to care.

Furthermore, I tested with this change, as suggested by Lukas

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 88f653864a01..c72d84590343 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -417,4 +417,5 @@ static void efifb_fixup_resources(struct pci_dev *dev)
                }
        }
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+                              16, efifb_fixup_resources);


which does appear to work fine, and thinking about it, I feel there is
only so much we can do to sanity check the efifb against the PCI setup
performed by the firmware, so I am inclined to fold this in.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> >> address and size are exposed to the OS via the Graphics Output
>> >> >> Protocol (GOP).
>> >> >>
>> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> >> will cause the framebuffer to become unresponsive, and may in some
>> >> >> cases result in unpredictable behavior if the range is reassigned to
>> >> >> another device.
>> >> >
>> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>> >>
>> >> True. I am eager to get some x86 coverage for this, since I would
>> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> >> specific in the final version.
>> >
>> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>> > the host drivers) and x86 isn't affected because it doesn't do that.
>> >
>>
>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> (or the legacy PCI bios) performed the resource assignment already.
>> One could argue that this is equally the case when running arm64 in
>> ACPI mode, but in general, you cannot assume the presence of firmware
>> on ARM/arm64 that has already taken care of this, and so the state of
>> the BARs has to be presumed invalid.
>
> The story is a bit more convoluted than that owing to x86 (and other
> arches) legacy.
>
> x86 tries to claim all PCI resources (in two passes - first enabled
> devices, second disabled devices) and that predates ACPI/UEFI.
>
> Mind, x86 reassign resources that can't be claimed too, the only
> difference with ARM64 is that, for the better or the worse, we
> have decided not to claim the FW PCI set-up on ARM64 even if it
> is sane, we do not even try, it was a deliberate choice.
>
> This patch should be harmless on x86 since if the FB PCI BAR is set
> up sanely, claiming it again should be a nop (to be checked).
>

I have checked this with OVMF under QEMU. Claiming the resource early
like we do this in this patch does not result in any diagnostic output
or other symptoms that would suggest that anything unexpected occurs.

For the record: I applied the following hunk on top of the current
version of this patch

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 88f653864a01..98b7c437a448 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -380,7 +380,10 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
                return;
        }

-       if (pci_claim_resource(dev, idx)) {
+       if (dev->resource[idx].parent != NULL) {
+               dev_info(&dev->dev, "BAR %d: resource already claimed\n", idx);
+               while (1) { asm ("hlt"); }
+       } else if (pci_claim_resource(dev, idx)) {
                pci_dev_disabled = true;
                dev_err(&dev->dev,
                        "BAR %d: failed to claim resource for efifb!\n", idx);

and got the following output in the kernel log related to BDF 0/2/0 and efifb

pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:00:02.0: BAR 0: assigned to efifb
pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
efifb: probing for efifb
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

whereas a kernel without this patch gives me

pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
efifb: probing for efifb
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

/proc/iomem looks exactly the same.

So in summary, x86 does not seem to care.

Furthermore, I tested with this change, as suggested by Lukas

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 88f653864a01..c72d84590343 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -417,4 +417,5 @@ static void efifb_fixup_resources(struct pci_dev *dev)
                }
        }
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+                              16, efifb_fixup_resources);


which does appear to work fine, and thinking about it, I feel there is
only so much we can do to sanity check the efifb against the PCI setup
performed by the firmware, so I am inclined to fold this in.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> >> address and size are exposed to the OS via the Graphics Output
>> >> >> Protocol (GOP).
>> >> >>
>> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> >> will cause the framebuffer to become unresponsive, and may in some
>> >> >> cases result in unpredictable behavior if the range is reassigned to
>> >> >> another device.
>> >> >
>> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>> >>
>> >> True. I am eager to get some x86 coverage for this, since I would
>> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> >> specific in the final version.
>> >
>> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>> > the host drivers) and x86 isn't affected because it doesn't do that.
>> >
>>
>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> (or the legacy PCI bios) performed the resource assignment already.
>> One could argue that this is equally the case when running arm64 in
>> ACPI mode, but in general, you cannot assume the presence of firmware
>> on ARM/arm64 that has already taken care of this, and so the state of
>> the BARs has to be presumed invalid.
>
> The story is a bit more convoluted than that owing to x86 (and other
> arches) legacy.
>
> x86 tries to claim all PCI resources (in two passes - first enabled
> devices, second disabled devices) and that predates ACPI/UEFI.
>
> Mind, x86 reassign resources that can't be claimed too, the only
> difference with ARM64 is that, for the better or the worse, we
> have decided not to claim the FW PCI set-up on ARM64 even if it
> is sane, we do not even try, it was a deliberate choice.
>
> This patch should be harmless on x86 since if the FB PCI BAR is set
> up sanely, claiming it again should be a nop (to be checked).
>

I have checked this with OVMF under QEMU. Claiming the resource early
like we do this in this patch does not result in any diagnostic output
or other symptoms that would suggest that anything unexpected occurs.

For the record: I applied the following hunk on top of the current
version of this patch

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 88f653864a01..98b7c437a448 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -380,7 +380,10 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
                return;
        }

-       if (pci_claim_resource(dev, idx)) {
+       if (dev->resource[idx].parent != NULL) {
+               dev_info(&dev->dev, "BAR %d: resource already claimed\n", idx);
+               while (1) { asm ("hlt"); }
+       } else if (pci_claim_resource(dev, idx)) {
                pci_dev_disabled = true;
                dev_err(&dev->dev,
                        "BAR %d: failed to claim resource for efifb!\n", idx);

and got the following output in the kernel log related to BDF 0/2/0 and efifb

pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:00:02.0: BAR 0: assigned to efifb
pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
efifb: probing for efifb
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

whereas a kernel without this patch gives me

pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
efifb: probing for efifb
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
efifb: mode is 800x600x32, linelength=3200, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0

/proc/iomem looks exactly the same.

So in summary, x86 does not seem to care.

Furthermore, I tested with this change, as suggested by Lukas

diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index 88f653864a01..c72d84590343 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -417,4 +417,5 @@ static void efifb_fixup_resources(struct pci_dev *dev)
                }
        }
 }
-DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
+                              16, efifb_fixup_resources);


which does appear to work fine, and thinking about it, I feel there is
only so much we can do to sanity check the efifb against the PCI setup
performed by the firmware, so I am inclined to fold this in.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> >> >> address and size are exposed to the OS via the Graphics Output
> >> >> >> Protocol (GOP).
> >> >> >>
> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
> >> >> >> will cause the framebuffer to become unresponsive, and may in some
> >> >> >> cases result in unpredictable behavior if the range is reassigned to
> >> >> >> another device.
> >> >> >
> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> >> >>
> >> >> True. I am eager to get some x86 coverage for this, since I would
> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
> >> >> specific in the final version.
> >> >
> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> >> > the host drivers) and x86 isn't affected because it doesn't do that.
> >> >
> >>
> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
> >> (or the legacy PCI bios) performed the resource assignment already.
> >> One could argue that this is equally the case when running arm64 in
> >> ACPI mode, but in general, you cannot assume the presence of firmware
> >> on ARM/arm64 that has already taken care of this, and so the state of
> >> the BARs has to be presumed invalid.
> >
> > The story is a bit more convoluted than that owing to x86 (and other
> > arches) legacy.
> >
> > x86 tries to claim all PCI resources (in two passes - first enabled
> > devices, second disabled devices) and that predates ACPI/UEFI.
> >
> > Mind, x86 reassign resources that can't be claimed too, the only
> > difference with ARM64 is that, for the better or the worse, we
> > have decided not to claim the FW PCI set-up on ARM64 even if it
> > is sane, we do not even try, it was a deliberate choice.
> >
> > This patch should be harmless on x86 since if the FB PCI BAR is set
> > up sanely, claiming it again should be a nop (to be checked).
> >
> 
> I have checked this with OVMF under QEMU. Claiming the resource early
> like we do this in this patch does not result in any diagnostic output
> or other symptoms that would suggest that anything unexpected occurs.

There is something that I do not understand on how the resource
claiming works on x86. IIUC on x86, resource claiming is done in:

arch/x86/pci/legacy.c

pci_subsys_init()
 -> pcibios_init()
  -> pcibios_resource_survey()

pci_subsys_init() is run in a subsys_initcall.

Now, how do we ensure that resource claiming is carried out _after_
the PCI root busses have been actually scanned ?

The ACPI scan handler interface (so the interface to actually scan
a PCI root bridge in ACPI) is initialized in acpi_init() (which
is a subsys_initcall), how do we guarantee that is run before
pci_subsys_init() ?

x86 implements pcibios_resource_survey_bus(), but that's called only
for hotplugged bridges (?):

drivers/acpi/pci_root.c -> acpi_pci_root_add()

>From the log below, I see two options:

- x86 pcibios_resource_survey() is called before any root bus is added
  (so it does precious little)
- x86 pcibios_resource_survey() is called after root busses are added and
  the PCI device fixup has been applied (and the additional claim in it
  succeeds silently)

I am certainly missing something here, I will grab an x86 box to add
a couple of logs and see if my assumptions are correct, I would like
to get to the bottom of this, I think that's important.

Lorenzo
 
> For the record: I applied the following hunk on top of the current
> version of this patch
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 88f653864a01..98b7c437a448 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -380,7 +380,10 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
>                 return;
>         }
> 
> -       if (pci_claim_resource(dev, idx)) {
> +       if (dev->resource[idx].parent != NULL) {
> +               dev_info(&dev->dev, "BAR %d: resource already claimed\n", idx);
> +               while (1) { asm ("hlt"); }
> +       } else if (pci_claim_resource(dev, idx)) {
>                 pci_dev_disabled = true;
>                 dev_err(&dev->dev,
>                         "BAR %d: failed to claim resource for efifb!\n", idx);
> 
> and got the following output in the kernel log related to BDF 0/2/0 and efifb
> 
> pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
> pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
> pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
> pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:00:02.0: BAR 0: assigned to efifb
> pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
> no compatible bridge window
> pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
> pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
> efifb: probing for efifb
> efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> whereas a kernel without this patch gives me
> 
> pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
> pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
> pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
> pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
> no compatible bridge window
> pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
> pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
> efifb: probing for efifb
> efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> /proc/iomem looks exactly the same.
> 
> So in summary, x86 does not seem to care.
> 
> Furthermore, I tested with this change, as suggested by Lukas
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 88f653864a01..c72d84590343 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -417,4 +417,5 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>                 }
>         }
>  }
> -DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
> +                              16, efifb_fixup_resources);
> 
> 
> which does appear to work fine, and thinking about it, I feel there is
> only so much we can do to sanity check the efifb against the PCI setup
> performed by the firmware, so I am inclined to fold this in.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> >> >> address and size are exposed to the OS via the Graphics Output
> >> >> >> Protocol (GOP).
> >> >> >>
> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
> >> >> >> will cause the framebuffer to become unresponsive, and may in some
> >> >> >> cases result in unpredictable behavior if the range is reassigned to
> >> >> >> another device.
> >> >> >
> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> >> >>
> >> >> True. I am eager to get some x86 coverage for this, since I would
> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
> >> >> specific in the final version.
> >> >
> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> >> > the host drivers) and x86 isn't affected because it doesn't do that.
> >> >
> >>
> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
> >> (or the legacy PCI bios) performed the resource assignment already.
> >> One could argue that this is equally the case when running arm64 in
> >> ACPI mode, but in general, you cannot assume the presence of firmware
> >> on ARM/arm64 that has already taken care of this, and so the state of
> >> the BARs has to be presumed invalid.
> >
> > The story is a bit more convoluted than that owing to x86 (and other
> > arches) legacy.
> >
> > x86 tries to claim all PCI resources (in two passes - first enabled
> > devices, second disabled devices) and that predates ACPI/UEFI.
> >
> > Mind, x86 reassign resources that can't be claimed too, the only
> > difference with ARM64 is that, for the better or the worse, we
> > have decided not to claim the FW PCI set-up on ARM64 even if it
> > is sane, we do not even try, it was a deliberate choice.
> >
> > This patch should be harmless on x86 since if the FB PCI BAR is set
> > up sanely, claiming it again should be a nop (to be checked).
> >
> 
> I have checked this with OVMF under QEMU. Claiming the resource early
> like we do this in this patch does not result in any diagnostic output
> or other symptoms that would suggest that anything unexpected occurs.

There is something that I do not understand on how the resource
claiming works on x86. IIUC on x86, resource claiming is done in:

arch/x86/pci/legacy.c

pci_subsys_init()
 -> pcibios_init()
  -> pcibios_resource_survey()

pci_subsys_init() is run in a subsys_initcall.

Now, how do we ensure that resource claiming is carried out _after_
the PCI root busses have been actually scanned ?

The ACPI scan handler interface (so the interface to actually scan
a PCI root bridge in ACPI) is initialized in acpi_init() (which
is a subsys_initcall), how do we guarantee that is run before
pci_subsys_init() ?

x86 implements pcibios_resource_survey_bus(), but that's called only
for hotplugged bridges (?):

drivers/acpi/pci_root.c -> acpi_pci_root_add()

>From the log below, I see two options:

- x86 pcibios_resource_survey() is called before any root bus is added
  (so it does precious little)
- x86 pcibios_resource_survey() is called after root busses are added and
  the PCI device fixup has been applied (and the additional claim in it
  succeeds silently)

I am certainly missing something here, I will grab an x86 box to add
a couple of logs and see if my assumptions are correct, I would like
to get to the bottom of this, I think that's important.

Lorenzo
 
> For the record: I applied the following hunk on top of the current
> version of this patch
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 88f653864a01..98b7c437a448 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -380,7 +380,10 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
>                 return;
>         }
> 
> -       if (pci_claim_resource(dev, idx)) {
> +       if (dev->resource[idx].parent != NULL) {
> +               dev_info(&dev->dev, "BAR %d: resource already claimed\n", idx);
> +               while (1) { asm ("hlt"); }
> +       } else if (pci_claim_resource(dev, idx)) {
>                 pci_dev_disabled = true;
>                 dev_err(&dev->dev,
>                         "BAR %d: failed to claim resource for efifb!\n", idx);
> 
> and got the following output in the kernel log related to BDF 0/2/0 and efifb
> 
> pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
> pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
> pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
> pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:00:02.0: BAR 0: assigned to efifb
> pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
> no compatible bridge window
> pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
> pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
> efifb: probing for efifb
> efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> whereas a kernel without this patch gives me
> 
> pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
> pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
> pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
> pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
> no compatible bridge window
> pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
> pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
> efifb: probing for efifb
> efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> /proc/iomem looks exactly the same.
> 
> So in summary, x86 does not seem to care.
> 
> Furthermore, I tested with this change, as suggested by Lukas
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 88f653864a01..c72d84590343 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -417,4 +417,5 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>                 }
>         }
>  }
> -DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
> +                              16, efifb_fixup_resources);
> 
> 
> which does appear to work fine, and thinking about it, I feel there is
> only so much we can do to sanity check the efifb against the PCI setup
> performed by the firmware, so I am inclined to fold this in.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
> >> >> >> address and size are exposed to the OS via the Graphics Output
> >> >> >> Protocol (GOP).
> >> >> >>
> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
> >> >> >> will cause the framebuffer to become unresponsive, and may in some
> >> >> >> cases result in unpredictable behavior if the range is reassigned to
> >> >> >> another device.
> >> >> >
> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
> >> >>
> >> >> True. I am eager to get some x86 coverage for this, since I would
> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
> >> >> specific in the final version.
> >> >
> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
> >> > the host drivers) and x86 isn't affected because it doesn't do that.
> >> >
> >>
> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
> >> (or the legacy PCI bios) performed the resource assignment already.
> >> One could argue that this is equally the case when running arm64 in
> >> ACPI mode, but in general, you cannot assume the presence of firmware
> >> on ARM/arm64 that has already taken care of this, and so the state of
> >> the BARs has to be presumed invalid.
> >
> > The story is a bit more convoluted than that owing to x86 (and other
> > arches) legacy.
> >
> > x86 tries to claim all PCI resources (in two passes - first enabled
> > devices, second disabled devices) and that predates ACPI/UEFI.
> >
> > Mind, x86 reassign resources that can't be claimed too, the only
> > difference with ARM64 is that, for the better or the worse, we
> > have decided not to claim the FW PCI set-up on ARM64 even if it
> > is sane, we do not even try, it was a deliberate choice.
> >
> > This patch should be harmless on x86 since if the FB PCI BAR is set
> > up sanely, claiming it again should be a nop (to be checked).
> >
> 
> I have checked this with OVMF under QEMU. Claiming the resource early
> like we do this in this patch does not result in any diagnostic output
> or other symptoms that would suggest that anything unexpected occurs.

There is something that I do not understand on how the resource
claiming works on x86. IIUC on x86, resource claiming is done in:

arch/x86/pci/legacy.c

pci_subsys_init()
 -> pcibios_init()
  -> pcibios_resource_survey()

pci_subsys_init() is run in a subsys_initcall.

Now, how do we ensure that resource claiming is carried out _after_
the PCI root busses have been actually scanned ?

The ACPI scan handler interface (so the interface to actually scan
a PCI root bridge in ACPI) is initialized in acpi_init() (which
is a subsys_initcall), how do we guarantee that is run before
pci_subsys_init() ?

x86 implements pcibios_resource_survey_bus(), but that's called only
for hotplugged bridges (?):

drivers/acpi/pci_root.c -> acpi_pci_root_add()

>From the log below, I see two options:

- x86 pcibios_resource_survey() is called before any root bus is added
  (so it does precious little)
- x86 pcibios_resource_survey() is called after root busses are added and
  the PCI device fixup has been applied (and the additional claim in it
  succeeds silently)

I am certainly missing something here, I will grab an x86 box to add
a couple of logs and see if my assumptions are correct, I would like
to get to the bottom of this, I think that's important.

Lorenzo
 
> For the record: I applied the following hunk on top of the current
> version of this patch
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 88f653864a01..98b7c437a448 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -380,7 +380,10 @@ static void claim_efifb_bar(struct pci_dev *dev, int idx)
>                 return;
>         }
> 
> -       if (pci_claim_resource(dev, idx)) {
> +       if (dev->resource[idx].parent != NULL) {
> +               dev_info(&dev->dev, "BAR %d: resource already claimed\n", idx);
> +               while (1) { asm ("hlt"); }
> +       } else if (pci_claim_resource(dev, idx)) {
>                 pci_dev_disabled = true;
>                 dev_err(&dev->dev,
>                         "BAR %d: failed to claim resource for efifb!\n", idx);
> 
> and got the following output in the kernel log related to BDF 0/2/0 and efifb
> 
> pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
> pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
> pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
> pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:00:02.0: BAR 0: assigned to efifb
> pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
> no compatible bridge window
> pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
> pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
> efifb: probing for efifb
> efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> whereas a kernel without this patch gives me
> 
> pci 0000:00:02.0: [1234:1111] type 00 class 0x030000
> pci 0000:00:02.0: reg 0x10: [mem 0x80000000-0x80ffffff pref]
> pci 0000:00:02.0: reg 0x18: [mem 0x81020000-0x81020fff]
> pci 0000:00:02.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:00:02.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
> no compatible bridge window
> pci 0000:00:02.0: BAR 6: assigned [mem 0x08040000-0x0804ffff pref]
> pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
> efifb: probing for efifb
> efifb: framebuffer at 0x80000000, using 1876k, total 1875k
> efifb: mode is 800x600x32, linelength=3200, pages=1
> efifb: scrolling: redraw
> efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> 
> /proc/iomem looks exactly the same.
> 
> So in summary, x86 does not seem to care.
> 
> Furthermore, I tested with this change, as suggested by Lukas
> 
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 88f653864a01..c72d84590343 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -417,4 +417,5 @@ static void efifb_fixup_resources(struct pci_dev *dev)
>                 }
>         }
>  }
> -DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);
> +DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_ANY_ID, PCI_ANY_ID, PCI_BASE_CLASS_DISPLAY,
> +                              16, efifb_fixup_resources);
> 
> 
> which does appear to work fine, and thinking about it, I feel there is
> only so much we can do to sanity check the efifb against the PCI setup
> performed by the firmware, so I am inclined to fold this in.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 14:31, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
> On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
>> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
>> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
>> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote:
>> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> >> >> address and size are exposed to the OS via the Graphics Output
>> >> >> >> Protocol (GOP).
>> >> >> >>
>> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> >> >> will cause the framebuffer to become unresponsive, and may in some
>> >> >> >> cases result in unpredictable behavior if the range is reassigned to
>> >> >> >> another device.
>> >> >> >
>> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>> >> >>
>> >> >> True. I am eager to get some x86 coverage for this, since I would
>> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> >> >> specific in the final version.
>> >> >
>> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>> >> > the host drivers) and x86 isn't affected because it doesn't do that.
>> >> >
>> >>
>> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> >> (or the legacy PCI bios) performed the resource assignment already.
>> >> One could argue that this is equally the case when running arm64 in
>> >> ACPI mode, but in general, you cannot assume the presence of firmware
>> >> on ARM/arm64 that has already taken care of this, and so the state of
>> >> the BARs has to be presumed invalid.
>> >
>> > The story is a bit more convoluted than that owing to x86 (and other
>> > arches) legacy.
>> >
>> > x86 tries to claim all PCI resources (in two passes - first enabled
>> > devices, second disabled devices) and that predates ACPI/UEFI.
>> >
>> > Mind, x86 reassign resources that can't be claimed too, the only
>> > difference with ARM64 is that, for the better or the worse, we
>> > have decided not to claim the FW PCI set-up on ARM64 even if it
>> > is sane, we do not even try, it was a deliberate choice.
>> >
>> > This patch should be harmless on x86 since if the FB PCI BAR is set
>> > up sanely, claiming it again should be a nop (to be checked).
>> >
>>
>> I have checked this with OVMF under QEMU. Claiming the resource early
>> like we do this in this patch does not result in any diagnostic output
>> or other symptoms that would suggest that anything unexpected occurs.
>
> There is something that I do not understand on how the resource
> claiming works on x86. IIUC on x86, resource claiming is done in:
>
> arch/x86/pci/legacy.c
>
> pci_subsys_init()
>  -> pcibios_init()
>   -> pcibios_resource_survey()
>
> pci_subsys_init() is run in a subsys_initcall.
>

Yes, the call trace I get for the resource claim for the efifb BAR
without this patch is

pci_subsys_init+0x3f/0x43
- pcibios_init+0x2c/0x3d
-- pcibios_resource_survey+0x38/0x6a
--- pci_legacy_init+0x2e/0x2e
---- pcibios_allocate_resources+0x8a/0x240
----- pci_claim_resource+0xdc/0x140


> Now, how do we ensure that resource claiming is carried out _after_
> the PCI root busses have been actually scanned ?
>
> The ACPI scan handler interface (so the interface to actually scan
> a PCI root bridge in ACPI) is initialized in acpi_init() (which
> is a subsys_initcall), how do we guarantee that is run before
> pci_subsys_init() ?
>

$ nm vmlinux |grep -E '__initcall_(acpi_init|pci_subsys_init)'
ffffffff81d540b8 t __initcall_acpi_init4
ffffffff81d54158 t __initcall_pci_subsys_init4

so it appears to depend on link order currently.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 14:31, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
>> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> >> >> address and size are exposed to the OS via the Graphics Output
>> >> >> >> Protocol (GOP).
>> >> >> >>
>> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> >> >> will cause the framebuffer to become unresponsive, and may in some
>> >> >> >> cases result in unpredictable behavior if the range is reassigned to
>> >> >> >> another device.
>> >> >> >
>> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>> >> >>
>> >> >> True. I am eager to get some x86 coverage for this, since I would
>> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> >> >> specific in the final version.
>> >> >
>> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>> >> > the host drivers) and x86 isn't affected because it doesn't do that.
>> >> >
>> >>
>> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> >> (or the legacy PCI bios) performed the resource assignment already.
>> >> One could argue that this is equally the case when running arm64 in
>> >> ACPI mode, but in general, you cannot assume the presence of firmware
>> >> on ARM/arm64 that has already taken care of this, and so the state of
>> >> the BARs has to be presumed invalid.
>> >
>> > The story is a bit more convoluted than that owing to x86 (and other
>> > arches) legacy.
>> >
>> > x86 tries to claim all PCI resources (in two passes - first enabled
>> > devices, second disabled devices) and that predates ACPI/UEFI.
>> >
>> > Mind, x86 reassign resources that can't be claimed too, the only
>> > difference with ARM64 is that, for the better or the worse, we
>> > have decided not to claim the FW PCI set-up on ARM64 even if it
>> > is sane, we do not even try, it was a deliberate choice.
>> >
>> > This patch should be harmless on x86 since if the FB PCI BAR is set
>> > up sanely, claiming it again should be a nop (to be checked).
>> >
>>
>> I have checked this with OVMF under QEMU. Claiming the resource early
>> like we do this in this patch does not result in any diagnostic output
>> or other symptoms that would suggest that anything unexpected occurs.
>
> There is something that I do not understand on how the resource
> claiming works on x86. IIUC on x86, resource claiming is done in:
>
> arch/x86/pci/legacy.c
>
> pci_subsys_init()
>  -> pcibios_init()
>   -> pcibios_resource_survey()
>
> pci_subsys_init() is run in a subsys_initcall.
>

Yes, the call trace I get for the resource claim for the efifb BAR
without this patch is

pci_subsys_init+0x3f/0x43
- pcibios_init+0x2c/0x3d
-- pcibios_resource_survey+0x38/0x6a
--- pci_legacy_init+0x2e/0x2e
---- pcibios_allocate_resources+0x8a/0x240
----- pci_claim_resource+0xdc/0x140


> Now, how do we ensure that resource claiming is carried out _after_
> the PCI root busses have been actually scanned ?
>
> The ACPI scan handler interface (so the interface to actually scan
> a PCI root bridge in ACPI) is initialized in acpi_init() (which
> is a subsys_initcall), how do we guarantee that is run before
> pci_subsys_init() ?
>

$ nm vmlinux |grep -E '__initcall_(acpi_init|pci_subsys_init)'
ffffffff81d540b8 t __initcall_acpi_init4
ffffffff81d54158 t __initcall_pci_subsys_init4

so it appears to depend on link order currently.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 14:31, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
>> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>> >> >> >> address and size are exposed to the OS via the Graphics Output
>> >> >> >> Protocol (GOP).
>> >> >> >>
>> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
>> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
>> >> >> >> will cause the framebuffer to become unresponsive, and may in some
>> >> >> >> cases result in unpredictable behavior if the range is reassigned to
>> >> >> >> another device.
>> >> >> >
>> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>> >> >>
>> >> >> True. I am eager to get some x86 coverage for this, since I would
>> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>> >> >> specific in the final version.
>> >> >
>> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>> >> > the host drivers) and x86 isn't affected because it doesn't do that.
>> >> >
>> >>
>> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> >> (or the legacy PCI bios) performed the resource assignment already.
>> >> One could argue that this is equally the case when running arm64 in
>> >> ACPI mode, but in general, you cannot assume the presence of firmware
>> >> on ARM/arm64 that has already taken care of this, and so the state of
>> >> the BARs has to be presumed invalid.
>> >
>> > The story is a bit more convoluted than that owing to x86 (and other
>> > arches) legacy.
>> >
>> > x86 tries to claim all PCI resources (in two passes - first enabled
>> > devices, second disabled devices) and that predates ACPI/UEFI.
>> >
>> > Mind, x86 reassign resources that can't be claimed too, the only
>> > difference with ARM64 is that, for the better or the worse, we
>> > have decided not to claim the FW PCI set-up on ARM64 even if it
>> > is sane, we do not even try, it was a deliberate choice.
>> >
>> > This patch should be harmless on x86 since if the FB PCI BAR is set
>> > up sanely, claiming it again should be a nop (to be checked).
>> >
>>
>> I have checked this with OVMF under QEMU. Claiming the resource early
>> like we do this in this patch does not result in any diagnostic output
>> or other symptoms that would suggest that anything unexpected occurs.
>
> There is something that I do not understand on how the resource
> claiming works on x86. IIUC on x86, resource claiming is done in:
>
> arch/x86/pci/legacy.c
>
> pci_subsys_init()
>  -> pcibios_init()
>   -> pcibios_resource_survey()
>
> pci_subsys_init() is run in a subsys_initcall.
>

Yes, the call trace I get for the resource claim for the efifb BAR
without this patch is

pci_subsys_init+0x3f/0x43
- pcibios_init+0x2c/0x3d
-- pcibios_resource_survey+0x38/0x6a
--- pci_legacy_init+0x2e/0x2e
---- pcibios_allocate_resources+0x8a/0x240
----- pci_claim_resource+0xdc/0x140


> Now, how do we ensure that resource claiming is carried out _after_
> the PCI root busses have been actually scanned ?
>
> The ACPI scan handler interface (so the interface to actually scan
> a PCI root bridge in ACPI) is initialized in acpi_init() (which
> is a subsys_initcall), how do we guarantee that is run before
> pci_subsys_init() ?
>

$ nm vmlinux |grep -E '__initcall_(acpi_init|pci_subsys_init)'
ffffffff81d540b8 t __initcall_acpi_init4
ffffffff81d54158 t __initcall_pci_subsys_init4

so it appears to depend on link order currently.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 15:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 23 March 2017 at 14:31, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
>>> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>>> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>>> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>>> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>>> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>>> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>>> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>>> >> >> >> address and size are exposed to the OS via the Graphics Output
>>> >> >> >> Protocol (GOP).
>>> >> >> >>
>>> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>>> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
>>> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
>>> >> >> >> will cause the framebuffer to become unresponsive, and may in some
>>> >> >> >> cases result in unpredictable behavior if the range is reassigned to
>>> >> >> >> another device.
>>> >> >> >
>>> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>>> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>>> >> >>
>>> >> >> True. I am eager to get some x86 coverage for this, since I would
>>> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>>> >> >> specific in the final version.
>>> >> >
>>> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>>> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>>> >> > the host drivers) and x86 isn't affected because it doesn't do that.
>>> >> >
>>> >>
>>> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> >> (or the legacy PCI bios) performed the resource assignment already.
>>> >> One could argue that this is equally the case when running arm64 in
>>> >> ACPI mode, but in general, you cannot assume the presence of firmware
>>> >> on ARM/arm64 that has already taken care of this, and so the state of
>>> >> the BARs has to be presumed invalid.
>>> >
>>> > The story is a bit more convoluted than that owing to x86 (and other
>>> > arches) legacy.
>>> >
>>> > x86 tries to claim all PCI resources (in two passes - first enabled
>>> > devices, second disabled devices) and that predates ACPI/UEFI.
>>> >
>>> > Mind, x86 reassign resources that can't be claimed too, the only
>>> > difference with ARM64 is that, for the better or the worse, we
>>> > have decided not to claim the FW PCI set-up on ARM64 even if it
>>> > is sane, we do not even try, it was a deliberate choice.
>>> >
>>> > This patch should be harmless on x86 since if the FB PCI BAR is set
>>> > up sanely, claiming it again should be a nop (to be checked).
>>> >
>>>
>>> I have checked this with OVMF under QEMU. Claiming the resource early
>>> like we do this in this patch does not result in any diagnostic output
>>> or other symptoms that would suggest that anything unexpected occurs.
>>
>> There is something that I do not understand on how the resource
>> claiming works on x86. IIUC on x86, resource claiming is done in:
>>
>> arch/x86/pci/legacy.c
>>
>> pci_subsys_init()
>>  -> pcibios_init()
>>   -> pcibios_resource_survey()
>>
>> pci_subsys_init() is run in a subsys_initcall.
>>
>
> Yes, the call trace I get for the resource claim for the efifb BAR
> without this patch is
>
> pci_subsys_init+0x3f/0x43
> - pcibios_init+0x2c/0x3d
> -- pcibios_resource_survey+0x38/0x6a
> --- pci_legacy_init+0x2e/0x2e
> ---- pcibios_allocate_resources+0x8a/0x240
> ----- pci_claim_resource+0xdc/0x140
>
>
>> Now, how do we ensure that resource claiming is carried out _after_
>> the PCI root busses have been actually scanned ?
>>
>> The ACPI scan handler interface (so the interface to actually scan
>> a PCI root bridge in ACPI) is initialized in acpi_init() (which
>> is a subsys_initcall), how do we guarantee that is run before
>> pci_subsys_init() ?
>>
>
> $ nm vmlinux |grep -E '__initcall_(acpi_init|pci_subsys_init)'
> ffffffff81d540b8 t __initcall_acpi_init4
> ffffffff81d54158 t __initcall_pci_subsys_init4
>
> so it appears to depend on link order currently.

Bjorn, what is your take on this?

Claiming the BAR resources associated with the efifb region from a
DECLARE_PCI_FIXUP_HEADER() handler does not seem to interfere with the
way resources are claimed later on. For arm64, we need this to ensure
that the BAR doesn't move, but for x86 this does not seem to be an
issue. This means we could potentially make the quirk ARM-only, but I
am a bit reluctant to do so and create even more divergence.

Thanks,
Ard.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 15:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 23 March 2017 at 14:31, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
>>> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>>> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>>> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>>> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>>> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>>> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>>> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>>> >> >> >> address and size are exposed to the OS via the Graphics Output
>>> >> >> >> Protocol (GOP).
>>> >> >> >>
>>> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>>> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
>>> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
>>> >> >> >> will cause the framebuffer to become unresponsive, and may in some
>>> >> >> >> cases result in unpredictable behavior if the range is reassigned to
>>> >> >> >> another device.
>>> >> >> >
>>> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>>> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>>> >> >>
>>> >> >> True. I am eager to get some x86 coverage for this, since I would
>>> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>>> >> >> specific in the final version.
>>> >> >
>>> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>>> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>>> >> > the host drivers) and x86 isn't affected because it doesn't do that.
>>> >> >
>>> >>
>>> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> >> (or the legacy PCI bios) performed the resource assignment already.
>>> >> One could argue that this is equally the case when running arm64 in
>>> >> ACPI mode, but in general, you cannot assume the presence of firmware
>>> >> on ARM/arm64 that has already taken care of this, and so the state of
>>> >> the BARs has to be presumed invalid.
>>> >
>>> > The story is a bit more convoluted than that owing to x86 (and other
>>> > arches) legacy.
>>> >
>>> > x86 tries to claim all PCI resources (in two passes - first enabled
>>> > devices, second disabled devices) and that predates ACPI/UEFI.
>>> >
>>> > Mind, x86 reassign resources that can't be claimed too, the only
>>> > difference with ARM64 is that, for the better or the worse, we
>>> > have decided not to claim the FW PCI set-up on ARM64 even if it
>>> > is sane, we do not even try, it was a deliberate choice.
>>> >
>>> > This patch should be harmless on x86 since if the FB PCI BAR is set
>>> > up sanely, claiming it again should be a nop (to be checked).
>>> >
>>>
>>> I have checked this with OVMF under QEMU. Claiming the resource early
>>> like we do this in this patch does not result in any diagnostic output
>>> or other symptoms that would suggest that anything unexpected occurs.
>>
>> There is something that I do not understand on how the resource
>> claiming works on x86. IIUC on x86, resource claiming is done in:
>>
>> arch/x86/pci/legacy.c
>>
>> pci_subsys_init()
>>  -> pcibios_init()
>>   -> pcibios_resource_survey()
>>
>> pci_subsys_init() is run in a subsys_initcall.
>>
>
> Yes, the call trace I get for the resource claim for the efifb BAR
> without this patch is
>
> pci_subsys_init+0x3f/0x43
> - pcibios_init+0x2c/0x3d
> -- pcibios_resource_survey+0x38/0x6a
> --- pci_legacy_init+0x2e/0x2e
> ---- pcibios_allocate_resources+0x8a/0x240
> ----- pci_claim_resource+0xdc/0x140
>
>
>> Now, how do we ensure that resource claiming is carried out _after_
>> the PCI root busses have been actually scanned ?
>>
>> The ACPI scan handler interface (so the interface to actually scan
>> a PCI root bridge in ACPI) is initialized in acpi_init() (which
>> is a subsys_initcall), how do we guarantee that is run before
>> pci_subsys_init() ?
>>
>
> $ nm vmlinux |grep -E '__initcall_(acpi_init|pci_subsys_init)'
> ffffffff81d540b8 t __initcall_acpi_init4
> ffffffff81d54158 t __initcall_pci_subsys_init4
>
> so it appears to depend on link order currently.

Bjorn, what is your take on this?

Claiming the BAR resources associated with the efifb region from a
DECLARE_PCI_FIXUP_HEADER() handler does not seem to interfere with the
way resources are claimed later on. For arm64, we need this to ensure
that the BAR doesn't move, but for x86 this does not seem to be an
issue. This means we could potentially make the quirk ARM-only, but I
am a bit reluctant to do so and create even more divergence.

Thanks,
Ard.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 March 2017 at 15:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 23 March 2017 at 14:31, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 23, 2017 at 12:25:48PM +0000, Ard Biesheuvel wrote:
>>> On 23 March 2017 at 10:57, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> > On Thu, Mar 23, 2017 at 09:04:03AM +0000, Ard Biesheuvel wrote:
>>> >> On 23 March 2017 at 08:48, Lukas Wunner <lukas@wunner.de> wrote:
>>> >> > On Wed, Mar 22, 2017 at 07:32:43PM +0000, Ard Biesheuvel wrote:
>>> >> >> On 22 March 2017 at 19:31, Lukas Wunner <lukas@wunner.de> wrote:
>>> >> >> > On Wed, Mar 22, 2017 at 03:30:29PM +0000, Ard Biesheuvel wrote:
>>> >> >> >> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>>> >> >> >> and if a graphical framebuffer is exposed by a PCI device, its base
>>> >> >> >> address and size are exposed to the OS via the Graphics Output
>>> >> >> >> Protocol (GOP).
>>> >> >> >>
>>> >> >> >> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>>> >> >> >> scratch at boot. This may result in the GOP framebuffer address to
>>> >> >> >> become stale, if the BAR covering the framebuffer is modified. This
>>> >> >> >> will cause the framebuffer to become unresponsive, and may in some
>>> >> >> >> cases result in unpredictable behavior if the range is reassigned to
>>> >> >> >> another device.
>>> >> >> >
>>> >> >> > Hm, commit message seems to indicate the issue is restricted to arm64,
>>> >> >> > yet there's no IS_ENABLED(ARM64) to constrain the added code to that arch?
>>> >> >>
>>> >> >> True. I am eager to get some x86 coverage for this, since I would
>>> >> >> expect this not to do any harm. But I'm fine with making it ARM/arm64
>>> >> >> specific in the final version.
>>> >> >
>>> >> > I see.  IIUC, this is only a problem because pci_bus_assign_resources()
>>> >> > is called from arch/arm64/kernel/pci.c:pci_acpi_scan_root() (as well as
>>> >> > the host drivers) and x86 isn't affected because it doesn't do that.
>>> >> >
>>> >>
>>> >> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> >> (or the legacy PCI bios) performed the resource assignment already.
>>> >> One could argue that this is equally the case when running arm64 in
>>> >> ACPI mode, but in general, you cannot assume the presence of firmware
>>> >> on ARM/arm64 that has already taken care of this, and so the state of
>>> >> the BARs has to be presumed invalid.
>>> >
>>> > The story is a bit more convoluted than that owing to x86 (and other
>>> > arches) legacy.
>>> >
>>> > x86 tries to claim all PCI resources (in two passes - first enabled
>>> > devices, second disabled devices) and that predates ACPI/UEFI.
>>> >
>>> > Mind, x86 reassign resources that can't be claimed too, the only
>>> > difference with ARM64 is that, for the better or the worse, we
>>> > have decided not to claim the FW PCI set-up on ARM64 even if it
>>> > is sane, we do not even try, it was a deliberate choice.
>>> >
>>> > This patch should be harmless on x86 since if the FB PCI BAR is set
>>> > up sanely, claiming it again should be a nop (to be checked).
>>> >
>>>
>>> I have checked this with OVMF under QEMU. Claiming the resource early
>>> like we do this in this patch does not result in any diagnostic output
>>> or other symptoms that would suggest that anything unexpected occurs.
>>
>> There is something that I do not understand on how the resource
>> claiming works on x86. IIUC on x86, resource claiming is done in:
>>
>> arch/x86/pci/legacy.c
>>
>> pci_subsys_init()
>>  -> pcibios_init()
>>   -> pcibios_resource_survey()
>>
>> pci_subsys_init() is run in a subsys_initcall.
>>
>
> Yes, the call trace I get for the resource claim for the efifb BAR
> without this patch is
>
> pci_subsys_init+0x3f/0x43
> - pcibios_init+0x2c/0x3d
> -- pcibios_resource_survey+0x38/0x6a
> --- pci_legacy_init+0x2e/0x2e
> ---- pcibios_allocate_resources+0x8a/0x240
> ----- pci_claim_resource+0xdc/0x140
>
>
>> Now, how do we ensure that resource claiming is carried out _after_
>> the PCI root busses have been actually scanned ?
>>
>> The ACPI scan handler interface (so the interface to actually scan
>> a PCI root bridge in ACPI) is initialized in acpi_init() (which
>> is a subsys_initcall), how do we guarantee that is run before
>> pci_subsys_init() ?
>>
>
> $ nm vmlinux |grep -E '__initcall_(acpi_init|pci_subsys_init)'
> ffffffff81d540b8 t __initcall_acpi_init4
> ffffffff81d54158 t __initcall_pci_subsys_init4
>
> so it appears to depend on link order currently.

Bjorn, what is your take on this?

Claiming the BAR resources associated with the efifb region from a
DECLARE_PCI_FIXUP_HEADER() handler does not seem to interfere with the
way resources are claimed later on. For arm64, we need this to ensure
that the BAR doesn't move, but for x86 this does not seem to be an
issue. This means we could potentially make the quirk ARM-only, but I
am a bit reluctant to do so and create even more divergence.

Thanks,
Ard.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

Hi Lorenzo,

On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> (or the legacy PCI bios) performed the resource assignment already.
>> One could argue that this is equally the case when running arm64 in
>> ACPI mode, but in general, you cannot assume the presence of firmware
>> on ARM/arm64 that has already taken care of this, and so the state of
>> the BARs has to be presumed invalid.
> The story is a bit more convoluted than that owing to x86 (and other
> arches) legacy.
> 
> x86 tries to claim all PCI resources (in two passes - first enabled
> devices, second disabled devices) and that predates ACPI/UEFI.
> 
> Mind, x86 reassign resources that can't be claimed too, the only
> difference with ARM64 is that, for the better or the worse, we
> have decided not to claim the FW PCI set-up on ARM64 even if it
> is sane, we do not even try, it was a deliberate choice.
> 
> This patch should be harmless on x86 since if the FB PCI BAR is set
> up sanely, claiming it again should be a nop (to be checked).
> 
> For all the talk about PCI being arch agnostic as I said manifold
> times before, that's just theory. In practice different arches
> treat PCI FW set-up differently, it would be ideal to make them
> uniform but legacy is huge and there is a massive risk of triggering
> regressions, it is no mean feat (if achievable at all).

Can we explore having a uniform behavior across ALL ACPI bases systems
by trying to reuse the resources assigned by firmware first and reassign
them only if something is wrong?

There are protocols like hotplug reservation in UEFI. It looks like Linux
is not honoring any of these protocols by being too smart.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

Hi Lorenzo,

On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> (or the legacy PCI bios) performed the resource assignment already.
>> One could argue that this is equally the case when running arm64 in
>> ACPI mode, but in general, you cannot assume the presence of firmware
>> on ARM/arm64 that has already taken care of this, and so the state of
>> the BARs has to be presumed invalid.
> The story is a bit more convoluted than that owing to x86 (and other
> arches) legacy.
> 
> x86 tries to claim all PCI resources (in two passes - first enabled
> devices, second disabled devices) and that predates ACPI/UEFI.
> 
> Mind, x86 reassign resources that can't be claimed too, the only
> difference with ARM64 is that, for the better or the worse, we
> have decided not to claim the FW PCI set-up on ARM64 even if it
> is sane, we do not even try, it was a deliberate choice.
> 
> This patch should be harmless on x86 since if the FB PCI BAR is set
> up sanely, claiming it again should be a nop (to be checked).
> 
> For all the talk about PCI being arch agnostic as I said manifold
> times before, that's just theory. In practice different arches
> treat PCI FW set-up differently, it would be ideal to make them
> uniform but legacy is huge and there is a massive risk of triggering
> regressions, it is no mean feat (if achievable at all).

Can we explore having a uniform behavior across ALL ACPI bases systems
by trying to reuse the resources assigned by firmware first and reassign
them only if something is wrong?

There are protocols like hotplug reservation in UEFI. It looks like Linux
is not honoring any of these protocols by being too smart.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

Hi Lorenzo,

On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>> (or the legacy PCI bios) performed the resource assignment already.
>> One could argue that this is equally the case when running arm64 in
>> ACPI mode, but in general, you cannot assume the presence of firmware
>> on ARM/arm64 that has already taken care of this, and so the state of
>> the BARs has to be presumed invalid.
> The story is a bit more convoluted than that owing to x86 (and other
> arches) legacy.
> 
> x86 tries to claim all PCI resources (in two passes - first enabled
> devices, second disabled devices) and that predates ACPI/UEFI.
> 
> Mind, x86 reassign resources that can't be claimed too, the only
> difference with ARM64 is that, for the better or the worse, we
> have decided not to claim the FW PCI set-up on ARM64 even if it
> is sane, we do not even try, it was a deliberate choice.
> 
> This patch should be harmless on x86 since if the FB PCI BAR is set
> up sanely, claiming it again should be a nop (to be checked).
> 
> For all the talk about PCI being arch agnostic as I said manifold
> times before, that's just theory. In practice different arches
> treat PCI FW set-up differently, it would be ideal to make them
> uniform but legacy is huge and there is a massive risk of triggering
> regressions, it is no mean feat (if achievable at all).

Can we explore having a uniform behavior across ALL ACPI bases systems
by trying to reuse the resources assigned by firmware first and reassign
them only if something is wrong?

There are protocols like hotplug reservation in UEFI. It looks like Linux
is not honoring any of these protocols by being too smart.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
> Hi Lorenzo,
>
> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> (or the legacy PCI bios) performed the resource assignment already.
>>> One could argue that this is equally the case when running arm64 in
>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>> on ARM/arm64 that has already taken care of this, and so the state of
>>> the BARs has to be presumed invalid.
>> The story is a bit more convoluted than that owing to x86 (and other
>> arches) legacy.
>>
>> x86 tries to claim all PCI resources (in two passes - first enabled
>> devices, second disabled devices) and that predates ACPI/UEFI.
>>
>> Mind, x86 reassign resources that can't be claimed too, the only
>> difference with ARM64 is that, for the better or the worse, we
>> have decided not to claim the FW PCI set-up on ARM64 even if it
>> is sane, we do not even try, it was a deliberate choice.
>>
>> This patch should be harmless on x86 since if the FB PCI BAR is set
>> up sanely, claiming it again should be a nop (to be checked).
>>
>> For all the talk about PCI being arch agnostic as I said manifold
>> times before, that's just theory. In practice different arches
>> treat PCI FW set-up differently, it would be ideal to make them
>> uniform but legacy is huge and there is a massive risk of triggering
>> regressions, it is no mean feat (if achievable at all).
>
> Can we explore having a uniform behavior across ALL ACPI bases systems
> by trying to reuse the resources assigned by firmware first and reassign
> them only if something is wrong?
>
> There are protocols like hotplug reservation in UEFI. It looks like Linux
> is not honoring any of these protocols by being too smart.
>

Could you be more specific? Which protocol do you mean exactly, and
how does not reusing resources interfere with it?

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
> Hi Lorenzo,
>
> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> (or the legacy PCI bios) performed the resource assignment already.
>>> One could argue that this is equally the case when running arm64 in
>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>> on ARM/arm64 that has already taken care of this, and so the state of
>>> the BARs has to be presumed invalid.
>> The story is a bit more convoluted than that owing to x86 (and other
>> arches) legacy.
>>
>> x86 tries to claim all PCI resources (in two passes - first enabled
>> devices, second disabled devices) and that predates ACPI/UEFI.
>>
>> Mind, x86 reassign resources that can't be claimed too, the only
>> difference with ARM64 is that, for the better or the worse, we
>> have decided not to claim the FW PCI set-up on ARM64 even if it
>> is sane, we do not even try, it was a deliberate choice.
>>
>> This patch should be harmless on x86 since if the FB PCI BAR is set
>> up sanely, claiming it again should be a nop (to be checked).
>>
>> For all the talk about PCI being arch agnostic as I said manifold
>> times before, that's just theory. In practice different arches
>> treat PCI FW set-up differently, it would be ideal to make them
>> uniform but legacy is huge and there is a massive risk of triggering
>> regressions, it is no mean feat (if achievable at all).
>
> Can we explore having a uniform behavior across ALL ACPI bases systems
> by trying to reuse the resources assigned by firmware first and reassign
> them only if something is wrong?
>
> There are protocols like hotplug reservation in UEFI. It looks like Linux
> is not honoring any of these protocols by being too smart.
>

Could you be more specific? Which protocol do you mean exactly, and
how does not reusing resources interfere with it?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
> Hi Lorenzo,
>
> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>> (or the legacy PCI bios) performed the resource assignment already.
>>> One could argue that this is equally the case when running arm64 in
>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>> on ARM/arm64 that has already taken care of this, and so the state of
>>> the BARs has to be presumed invalid.
>> The story is a bit more convoluted than that owing to x86 (and other
>> arches) legacy.
>>
>> x86 tries to claim all PCI resources (in two passes - first enabled
>> devices, second disabled devices) and that predates ACPI/UEFI.
>>
>> Mind, x86 reassign resources that can't be claimed too, the only
>> difference with ARM64 is that, for the better or the worse, we
>> have decided not to claim the FW PCI set-up on ARM64 even if it
>> is sane, we do not even try, it was a deliberate choice.
>>
>> This patch should be harmless on x86 since if the FB PCI BAR is set
>> up sanely, claiming it again should be a nop (to be checked).
>>
>> For all the talk about PCI being arch agnostic as I said manifold
>> times before, that's just theory. In practice different arches
>> treat PCI FW set-up differently, it would be ideal to make them
>> uniform but legacy is huge and there is a massive risk of triggering
>> regressions, it is no mean feat (if achievable at all).
>
> Can we explore having a uniform behavior across ALL ACPI bases systems
> by trying to reuse the resources assigned by firmware first and reassign
> them only if something is wrong?
>
> There are protocols like hotplug reservation in UEFI. It looks like Linux
> is not honoring any of these protocols by being too smart.
>

Could you be more specific? Which protocol do you mean exactly, and
how does not reusing resources interfere with it?

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
> On 28 March 2017 at 22:27, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> Hi Lorenzo,
>>
>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>> One could argue that this is equally the case when running arm64 in
>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>> the BARs has to be presumed invalid.
>>> The story is a bit more convoluted than that owing to x86 (and other
>>> arches) legacy.
>>>
>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>
>>> Mind, x86 reassign resources that can't be claimed too, the only
>>> difference with ARM64 is that, for the better or the worse, we
>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>> is sane, we do not even try, it was a deliberate choice.
>>>
>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>> up sanely, claiming it again should be a nop (to be checked).
>>>
>>> For all the talk about PCI being arch agnostic as I said manifold
>>> times before, that's just theory. In practice different arches
>>> treat PCI FW set-up differently, it would be ideal to make them
>>> uniform but legacy is huge and there is a massive risk of triggering
>>> regressions, it is no mean feat (if achievable at all).
>>
>> Can we explore having a uniform behavior across ALL ACPI bases systems
>> by trying to reuse the resources assigned by firmware first and reassign
>> them only if something is wrong?
>>
>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>> is not honoring any of these protocols by being too smart.
>>
> 
> Could you be more specific? Which protocol do you mean exactly, and
> how does not reusing resources interfere with it?
> 

Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
assigned BAR addresses, would you still have this problem that you are trying to
fix by a quirk?

The protocol that I was looking at specifically is called hotplug reservation
protocol.

http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html

The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
system without any cards present. when you do to hotplug, OS uses the range
reserved by the BIOS for inserting the new card.

what I see is that the bridge windows get overridden by the OS.

I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
of working around it by quirks.

I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.

Legacy only applies to DT based systems. 

If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
this using some DMI/SMBIOS and setting a time bomb like products after this date
shall follow the new behavior.

We are not in a very hardened position when it comes to changes for ACPI based
systems.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
> On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
>> Hi Lorenzo,
>>
>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>> One could argue that this is equally the case when running arm64 in
>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>> the BARs has to be presumed invalid.
>>> The story is a bit more convoluted than that owing to x86 (and other
>>> arches) legacy.
>>>
>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>
>>> Mind, x86 reassign resources that can't be claimed too, the only
>>> difference with ARM64 is that, for the better or the worse, we
>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>> is sane, we do not even try, it was a deliberate choice.
>>>
>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>> up sanely, claiming it again should be a nop (to be checked).
>>>
>>> For all the talk about PCI being arch agnostic as I said manifold
>>> times before, that's just theory. In practice different arches
>>> treat PCI FW set-up differently, it would be ideal to make them
>>> uniform but legacy is huge and there is a massive risk of triggering
>>> regressions, it is no mean feat (if achievable at all).
>>
>> Can we explore having a uniform behavior across ALL ACPI bases systems
>> by trying to reuse the resources assigned by firmware first and reassign
>> them only if something is wrong?
>>
>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>> is not honoring any of these protocols by being too smart.
>>
> 
> Could you be more specific? Which protocol do you mean exactly, and
> how does not reusing resources interfere with it?
> 

Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
assigned BAR addresses, would you still have this problem that you are trying to
fix by a quirk?

The protocol that I was looking at specifically is called hotplug reservation
protocol.

http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html

The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
system without any cards present. when you do to hotplug, OS uses the range
reserved by the BIOS for inserting the new card.

what I see is that the bridge windows get overridden by the OS.

I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
of working around it by quirks.

I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.

Legacy only applies to DT based systems. 

If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
this using some DMI/SMBIOS and setting a time bomb like products after this date
shall follow the new behavior.

We are not in a very hardened position when it comes to changes for ACPI based
systems.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
> On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
>> Hi Lorenzo,
>>
>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>> One could argue that this is equally the case when running arm64 in
>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>> the BARs has to be presumed invalid.
>>> The story is a bit more convoluted than that owing to x86 (and other
>>> arches) legacy.
>>>
>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>
>>> Mind, x86 reassign resources that can't be claimed too, the only
>>> difference with ARM64 is that, for the better or the worse, we
>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>> is sane, we do not even try, it was a deliberate choice.
>>>
>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>> up sanely, claiming it again should be a nop (to be checked).
>>>
>>> For all the talk about PCI being arch agnostic as I said manifold
>>> times before, that's just theory. In practice different arches
>>> treat PCI FW set-up differently, it would be ideal to make them
>>> uniform but legacy is huge and there is a massive risk of triggering
>>> regressions, it is no mean feat (if achievable at all).
>>
>> Can we explore having a uniform behavior across ALL ACPI bases systems
>> by trying to reuse the resources assigned by firmware first and reassign
>> them only if something is wrong?
>>
>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>> is not honoring any of these protocols by being too smart.
>>
> 
> Could you be more specific? Which protocol do you mean exactly, and
> how does not reusing resources interfere with it?
> 

Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
assigned BAR addresses, would you still have this problem that you are trying to
fix by a quirk?

The protocol that I was looking at specifically is called hotplug reservation
protocol.

http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html

The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
system without any cards present. when you do to hotplug, OS uses the range
reserved by the BIOS for inserting the new card.

what I see is that the bridge windows get overridden by the OS.

I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
of working around it by quirks.

I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.

Legacy only applies to DT based systems. 

If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
this using some DMI/SMBIOS and setting a time bomb like products after this date
shall follow the new behavior.

We are not in a very hardened position when it comes to changes for ACPI based
systems.

Sinan

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 28 March 2017 at 22:49, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
>> On 28 March 2017 at 22:27, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>>> Hi Lorenzo,
>>>
>>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>>> One could argue that this is equally the case when running arm64 in
>>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>>> the BARs has to be presumed invalid.
>>>> The story is a bit more convoluted than that owing to x86 (and other
>>>> arches) legacy.
>>>>
>>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>>
>>>> Mind, x86 reassign resources that can't be claimed too, the only
>>>> difference with ARM64 is that, for the better or the worse, we
>>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>>> is sane, we do not even try, it was a deliberate choice.
>>>>
>>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>>> up sanely, claiming it again should be a nop (to be checked).
>>>>
>>>> For all the talk about PCI being arch agnostic as I said manifold
>>>> times before, that's just theory. In practice different arches
>>>> treat PCI FW set-up differently, it would be ideal to make them
>>>> uniform but legacy is huge and there is a massive risk of triggering
>>>> regressions, it is no mean feat (if achievable at all).
>>>
>>> Can we explore having a uniform behavior across ALL ACPI bases systems
>>> by trying to reuse the resources assigned by firmware first and reassign
>>> them only if something is wrong?
>>>
>>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>>> is not honoring any of these protocols by being too smart.
>>>
>>
>> Could you be more specific? Which protocol do you mean exactly, and
>> how does not reusing resources interfere with it?
>>
>
> Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
> assigned BAR addresses, would you still have this problem that you are trying to
> fix by a quirk?
>

Probably not. Although I should point out that the same issue exists
on DT systems, and so we will need this patch regardless.

> The protocol that I was looking at specifically is called hotplug reservation
> protocol.
>
> http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html
>
> The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
> system without any cards present. when you do to hotplug, OS uses the range
> reserved by the BIOS for inserting the new card.
>
> what I see is that the bridge windows get overridden by the OS.
>
> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> of working around it by quirks.
>
> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>
> Legacy only applies to DT based systems.
>

I fully agree with this point: ACPI implies firmware, and so we should
be able to rely on firmware to have initialized the PCIe subsystem by
the time the kernel gets to access it.

> If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
> this using some DMI/SMBIOS and setting a time bomb like products after this date
> shall follow the new behavior.
>
> We are not in a very hardened position when it comes to changes for ACPI based
> systems.
>
> Sinan
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 28 March 2017 at 22:49, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
>> On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
>>> Hi Lorenzo,
>>>
>>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>>> One could argue that this is equally the case when running arm64 in
>>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>>> the BARs has to be presumed invalid.
>>>> The story is a bit more convoluted than that owing to x86 (and other
>>>> arches) legacy.
>>>>
>>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>>
>>>> Mind, x86 reassign resources that can't be claimed too, the only
>>>> difference with ARM64 is that, for the better or the worse, we
>>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>>> is sane, we do not even try, it was a deliberate choice.
>>>>
>>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>>> up sanely, claiming it again should be a nop (to be checked).
>>>>
>>>> For all the talk about PCI being arch agnostic as I said manifold
>>>> times before, that's just theory. In practice different arches
>>>> treat PCI FW set-up differently, it would be ideal to make them
>>>> uniform but legacy is huge and there is a massive risk of triggering
>>>> regressions, it is no mean feat (if achievable at all).
>>>
>>> Can we explore having a uniform behavior across ALL ACPI bases systems
>>> by trying to reuse the resources assigned by firmware first and reassign
>>> them only if something is wrong?
>>>
>>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>>> is not honoring any of these protocols by being too smart.
>>>
>>
>> Could you be more specific? Which protocol do you mean exactly, and
>> how does not reusing resources interfere with it?
>>
>
> Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
> assigned BAR addresses, would you still have this problem that you are trying to
> fix by a quirk?
>

Probably not. Although I should point out that the same issue exists
on DT systems, and so we will need this patch regardless.

> The protocol that I was looking at specifically is called hotplug reservation
> protocol.
>
> http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html
>
> The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
> system without any cards present. when you do to hotplug, OS uses the range
> reserved by the BIOS for inserting the new card.
>
> what I see is that the bridge windows get overridden by the OS.
>
> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> of working around it by quirks.
>
> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>
> Legacy only applies to DT based systems.
>

I fully agree with this point: ACPI implies firmware, and so we should
be able to rely on firmware to have initialized the PCIe subsystem by
the time the kernel gets to access it.

> If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
> this using some DMI/SMBIOS and setting a time bomb like products after this date
> shall follow the new behavior.
>
> We are not in a very hardened position when it comes to changes for ACPI based
> systems.
>
> Sinan
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 28 March 2017 at 22:49, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/28/2017 5:39 PM, Ard Biesheuvel wrote:
>> On 28 March 2017 at 22:27, Sinan Kaya <okaya@codeaurora.org> wrote:
>>> Hi Lorenzo,
>>>
>>> On 3/23/2017 6:57 AM, Lorenzo Pieralisi wrote:
>>>>> Correct. But on x86 (or rather, on a PC), you can be sure that UEFI
>>>>> (or the legacy PCI bios) performed the resource assignment already.
>>>>> One could argue that this is equally the case when running arm64 in
>>>>> ACPI mode, but in general, you cannot assume the presence of firmware
>>>>> on ARM/arm64 that has already taken care of this, and so the state of
>>>>> the BARs has to be presumed invalid.
>>>> The story is a bit more convoluted than that owing to x86 (and other
>>>> arches) legacy.
>>>>
>>>> x86 tries to claim all PCI resources (in two passes - first enabled
>>>> devices, second disabled devices) and that predates ACPI/UEFI.
>>>>
>>>> Mind, x86 reassign resources that can't be claimed too, the only
>>>> difference with ARM64 is that, for the better or the worse, we
>>>> have decided not to claim the FW PCI set-up on ARM64 even if it
>>>> is sane, we do not even try, it was a deliberate choice.
>>>>
>>>> This patch should be harmless on x86 since if the FB PCI BAR is set
>>>> up sanely, claiming it again should be a nop (to be checked).
>>>>
>>>> For all the talk about PCI being arch agnostic as I said manifold
>>>> times before, that's just theory. In practice different arches
>>>> treat PCI FW set-up differently, it would be ideal to make them
>>>> uniform but legacy is huge and there is a massive risk of triggering
>>>> regressions, it is no mean feat (if achievable at all).
>>>
>>> Can we explore having a uniform behavior across ALL ACPI bases systems
>>> by trying to reuse the resources assigned by firmware first and reassign
>>> them only if something is wrong?
>>>
>>> There are protocols like hotplug reservation in UEFI. It looks like Linux
>>> is not honoring any of these protocols by being too smart.
>>>
>>
>> Could you be more specific? Which protocol do you mean exactly, and
>> how does not reusing resources interfere with it?
>>
>
> Let's assume for the moment that if ARM64 adaptation of PCIE reused the firmware
> assigned BAR addresses, would you still have this problem that you are trying to
> fix by a quirk?
>

Probably not. Although I should point out that the same issue exists
on DT systems, and so we will need this patch regardless.

> The protocol that I was looking at specifically is called hotplug reservation
> protocol.
>
> http://www.intel.com/content/www/us/en/architecture-and-technology/unified-extensible-firmware-interface/efi-hot-plug-pci-initialization-protocol-specification.html
>
> The idea is to pad the PCIe bridge window by some amount in UEFI. You boot the
> system without any cards present. when you do to hotplug, OS uses the range
> reserved by the BIOS for inserting the new card.
>
> what I see is that the bridge windows get overridden by the OS.
>
> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> of working around it by quirks.
>
> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>
> Legacy only applies to DT based systems.
>

I fully agree with this point: ACPI implies firmware, and so we should
be able to rely on firmware to have initialized the PCIe subsystem by
the time the kernel gets to access it.

> If there is still a legacy problem in ACPI ARM64, generic Linux code deals with
> this using some DMI/SMBIOS and setting a time bomb like products after this date
> shall follow the new behavior.
>
> We are not in a very hardened position when it comes to changes for ACPI based
> systems.
>
> Sinan
>
> --
> Sinan Kaya
> Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:

[...]

> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> > of working around it by quirks.
> >
> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
> >
> > Legacy only applies to DT based systems.
> >
> 
> I fully agree with this point: ACPI implies firmware, and so we should
> be able to rely on firmware to have initialized the PCIe subsystem by
> the time the kernel gets to access it.

https://lkml.org/lkml/2016/3/3/458

Lorenzo

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:

[...]

> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> > of working around it by quirks.
> >
> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
> >
> > Legacy only applies to DT based systems.
> >
> 
> I fully agree with this point: ACPI implies firmware, and so we should
> be able to rely on firmware to have initialized the PCIe subsystem by
> the time the kernel gets to access it.

https://lkml.org/lkml/2016/3/3/458

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:

[...]

> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> > of working around it by quirks.
> >
> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
> >
> > Legacy only applies to DT based systems.
> >
> 
> I fully agree with this point: ACPI implies firmware, and so we should
> be able to rely on firmware to have initialized the PCIe subsystem by
> the time the kernel gets to access it.

https://lkml.org/lkml/2016/3/3/458

Lorenzo

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>> > of working around it by quirks.
>> >
>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>> >
>> > Legacy only applies to DT based systems.
>> >
>>
>> I fully agree with this point: ACPI implies firmware, and so we should
>> be able to rely on firmware to have initialized the PCIe subsystem by
>> the time the kernel gets to access it.
>
> https://lkml.org/lkml/2016/3/3/458
>

I don't think the fact that at least one system existed over a year
ago whose UEFI assigned resources incorrectly should prevent us from
being normative in this case.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>> > of working around it by quirks.
>> >
>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>> >
>> > Legacy only applies to DT based systems.
>> >
>>
>> I fully agree with this point: ACPI implies firmware, and so we should
>> be able to rely on firmware to have initialized the PCIe subsystem by
>> the time the kernel gets to access it.
>
> https://lkml.org/lkml/2016/3/3/458
>

I don't think the fact that at least one system existed over a year
ago whose UEFI assigned resources incorrectly should prevent us from
being normative in this case.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>> > of working around it by quirks.
>> >
>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>> >
>> > Legacy only applies to DT based systems.
>> >
>>
>> I fully agree with this point: ACPI implies firmware, and so we should
>> be able to rely on firmware to have initialized the PCIe subsystem by
>> the time the kernel gets to access it.
>
> https://lkml.org/lkml/2016/3/3/458
>

I don't think the fact that at least one system existed over a year
ago whose UEFI assigned resources incorrectly should prevent us from
being normative in this case.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[okaya]

On 2017-03-30 06:09, Ard Biesheuvel wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi 
> <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>> 
>> [...]
>> 
>>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> > of working around it by quirks.
>>> >
>>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >
>>> > Legacy only applies to DT based systems.
>>> >
>>> 
>>> I fully agree with this point: ACPI implies firmware, and so we 
>>> should
>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> the time the kernel gets to access it.
>> 
>> https://lkml.org/lkml/2016/3/3/458
>> 
> 
> I don't think the fact that at least one system existed over a year
> ago whose UEFI assigned resources incorrectly should prevent us from
> being normative in this case.

My suggestion is to try to reuse the resources if possible. Otherwise, 
reassign the resources.

There were implementation problems by the time you proposed your patch 
and it was delaying progess. That was my objection.

Now that base pci support is in and everybody is  somewhat happy, let's 
figure out the bugs and get this done.

I am ready to test/debug.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[okaya]

On 2017-03-30 06:09, Ard Biesheuvel wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi 
> <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>> 
>> [...]
>> 
>>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> > of working around it by quirks.
>>> >
>>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >
>>> > Legacy only applies to DT based systems.
>>> >
>>> 
>>> I fully agree with this point: ACPI implies firmware, and so we 
>>> should
>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> the time the kernel gets to access it.
>> 
>> https://lkml.org/lkml/2016/3/3/458
>> 
> 
> I don't think the fact that at least one system existed over a year
> ago whose UEFI assigned resources incorrectly should prevent us from
> being normative in this case.

My suggestion is to try to reuse the resources if possible. Otherwise, 
reassign the resources.

There were implementation problems by the time you proposed your patch 
and it was delaying progess. That was my objection.

Now that base pci support is in and everybody is  somewhat happy, let's 
figure out the bugs and get this done.

I am ready to test/debug.



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[okaya at codeaurora.org]

On 2017-03-30 06:09, Ard Biesheuvel wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi 
> <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>> 
>> [...]
>> 
>>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> > of working around it by quirks.
>>> >
>>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >
>>> > Legacy only applies to DT based systems.
>>> >
>>> 
>>> I fully agree with this point: ACPI implies firmware, and so we 
>>> should
>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> the time the kernel gets to access it.
>> 
>> https://lkml.org/lkml/2016/3/3/458
>> 
> 
> I don't think the fact that at least one system existed over a year
> ago whose UEFI assigned resources incorrectly should prevent us from
> being normative in this case.

My suggestion is to try to reuse the resources if possible. Otherwise, 
reassign the resources.

There were implementation problems by the time you proposed your patch 
and it was delaying progess. That was my objection.

Now that base pci support is in and everybody is  somewhat happy, let's 
figure out the bugs and get this done.

I am ready to test/debug.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>
>> [...]
>>
>>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> > of working around it by quirks.
>>> >
>>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >
>>> > Legacy only applies to DT based systems.
>>> >
>>>
>>> I fully agree with this point: ACPI implies firmware, and so we should
>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> the time the kernel gets to access it.
>>
>> https://lkml.org/lkml/2016/3/3/458
>>
>
> I don't think the fact that at least one system existed over a year
> ago whose UEFI assigned resources incorrectly should prevent us from
> being normative in this case.

In any case, given that EFIFB is enabled by default on some distros,
and the fact that DT boot is affected as well, I should get this patch
in to prevent serious potential issues that could arise when someone
with a graphical UEFI stack updates to such a new kernel.

So I think we are in agreement that this is needed on both ARM and
arm64, since their PCI configuration is usually not preserved. The
open question is whether there is any harm in enabling it for x86 as
well.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>
>> [...]
>>
>>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> > of working around it by quirks.
>>> >
>>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >
>>> > Legacy only applies to DT based systems.
>>> >
>>>
>>> I fully agree with this point: ACPI implies firmware, and so we should
>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> the time the kernel gets to access it.
>>
>> https://lkml.org/lkml/2016/3/3/458
>>
>
> I don't think the fact that at least one system existed over a year
> ago whose UEFI assigned resources incorrectly should prevent us from
> being normative in this case.

In any case, given that EFIFB is enabled by default on some distros,
and the fact that DT boot is affected as well, I should get this patch
in to prevent serious potential issues that could arise when someone
with a graphical UEFI stack updates to such a new kernel.

So I think we are in agreement that this is needed on both ARM and
arm64, since their PCI configuration is usually not preserved. The
open question is whether there is any harm in enabling it for x86 as
well.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>
>> [...]
>>
>>> > I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> > of working around it by quirks.
>>> >
>>> > I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >
>>> > Legacy only applies to DT based systems.
>>> >
>>>
>>> I fully agree with this point: ACPI implies firmware, and so we should
>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> the time the kernel gets to access it.
>>
>> https://lkml.org/lkml/2016/3/3/458
>>
>
> I don't think the fact that at least one system existed over a year
> ago whose UEFI assigned resources incorrectly should prevent us from
> being normative in this case.

In any case, given that EFIFB is enabled by default on some distros,
and the fact that DT boot is affected as well, I should get this patch
in to prevent serious potential issues that could arise when someone
with a graphical UEFI stack updates to such a new kernel.

So I think we are in agreement that this is needed on both ARM and
arm64, since their PCI configuration is usually not preserved. The
open question is whether there is any harm in enabling it for x86 as
well.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>
>>> [...]
>>>
>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>> of working around it by quirks.
>>>>>
>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>
>>>>> Legacy only applies to DT based systems.
>>>>>
>>>>
>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>> the time the kernel gets to access it.
>>>
>>> https://lkml.org/lkml/2016/3/3/458
>>>
>>
>> I don't think the fact that at least one system existed over a year
>> ago whose UEFI assigned resources incorrectly should prevent us from
>> being normative in this case.
> 
> In any case, given that EFIFB is enabled by default on some distros,
> and the fact that DT boot is affected as well, I should get this patch
> in to prevent serious potential issues that could arise when someone
> with a graphical UEFI stack updates to such a new kernel.
> 
> So I think we are in agreement that this is needed on both ARM and
> arm64, since their PCI configuration is usually not preserved. The
> open question is whether there is any harm in enabling it for x86 as
> well.
> 

Agreed, the other issue is about compatibility with UEFI and future
proofing Linux for other potential issues like hotplug reservation.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>
>>> [...]
>>>
>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>> of working around it by quirks.
>>>>>
>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>
>>>>> Legacy only applies to DT based systems.
>>>>>
>>>>
>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>> the time the kernel gets to access it.
>>>
>>> https://lkml.org/lkml/2016/3/3/458
>>>
>>
>> I don't think the fact that at least one system existed over a year
>> ago whose UEFI assigned resources incorrectly should prevent us from
>> being normative in this case.
> 
> In any case, given that EFIFB is enabled by default on some distros,
> and the fact that DT boot is affected as well, I should get this patch
> in to prevent serious potential issues that could arise when someone
> with a graphical UEFI stack updates to such a new kernel.
> 
> So I think we are in agreement that this is needed on both ARM and
> arm64, since their PCI configuration is usually not preserved. The
> open question is whether there is any harm in enabling it for x86 as
> well.
> 

Agreed, the other issue is about compatibility with UEFI and future
proofing Linux for other potential issues like hotplug reservation.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>
>>> [...]
>>>
>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>> of working around it by quirks.
>>>>>
>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>
>>>>> Legacy only applies to DT based systems.
>>>>>
>>>>
>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>> the time the kernel gets to access it.
>>>
>>> https://lkml.org/lkml/2016/3/3/458
>>>
>>
>> I don't think the fact that at least one system existed over a year
>> ago whose UEFI assigned resources incorrectly should prevent us from
>> being normative in this case.
> 
> In any case, given that EFIFB is enabled by default on some distros,
> and the fact that DT boot is affected as well, I should get this patch
> in to prevent serious potential issues that could arise when someone
> with a graphical UEFI stack updates to such a new kernel.
> 
> So I think we are in agreement that this is needed on both ARM and
> arm64, since their PCI configuration is usually not preserved. The
> open question is whether there is any harm in enabling it for x86 as
> well.
> 

Agreed, the other issue is about compatibility with UEFI and future
proofing Linux for other potential issues like hotplug reservation.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 14:50, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>>
>>>> [...]
>>>>
>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>>> of working around it by quirks.
>>>>>>
>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>>
>>>>>> Legacy only applies to DT based systems.
>>>>>>
>>>>>
>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>>> the time the kernel gets to access it.
>>>>
>>>> https://lkml.org/lkml/2016/3/3/458
>>>>
>>>
>>> I don't think the fact that at least one system existed over a year
>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>> being normative in this case.
>>
>> In any case, given that EFIFB is enabled by default on some distros,
>> and the fact that DT boot is affected as well, I should get this patch
>> in to prevent serious potential issues that could arise when someone
>> with a graphical UEFI stack updates to such a new kernel.
>>
>> So I think we are in agreement that this is needed on both ARM and
>> arm64, since their PCI configuration is usually not preserved. The
>> open question is whether there is any harm in enabling it for x86 as
>> well.
>>
>
> Agreed, the other issue is about compatibility with UEFI and future
> proofing Linux for other potential issues like hotplug reservation.
>

OK, given the lack of feedback regarding the suitability of this patch
for x86, I am going to rework it as a ARM/arm64 only patch, and queue
it as a fix for v4.11. This way, we can backport it to stable (which
is arguably appropriate, given that upgrading to a EFIFB enabled
kernel may cause severe breakage for existing systems that implement
the GOP protocol), and easily change the patch to apply to x86 going
forwards, by removing the #ifdefs

-- 
Ard.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>>
>>>> [...]
>>>>
>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>>> of working around it by quirks.
>>>>>>
>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>>
>>>>>> Legacy only applies to DT based systems.
>>>>>>
>>>>>
>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>>> the time the kernel gets to access it.
>>>>
>>>> https://lkml.org/lkml/2016/3/3/458
>>>>
>>>
>>> I don't think the fact that at least one system existed over a year
>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>> being normative in this case.
>>
>> In any case, given that EFIFB is enabled by default on some distros,
>> and the fact that DT boot is affected as well, I should get this patch
>> in to prevent serious potential issues that could arise when someone
>> with a graphical UEFI stack updates to such a new kernel.
>>
>> So I think we are in agreement that this is needed on both ARM and
>> arm64, since their PCI configuration is usually not preserved. The
>> open question is whether there is any harm in enabling it for x86 as
>> well.
>>
>
> Agreed, the other issue is about compatibility with UEFI and future
> proofing Linux for other potential issues like hotplug reservation.
>

OK, given the lack of feedback regarding the suitability of this patch
for x86, I am going to rework it as a ARM/arm64 only patch, and queue
it as a fix for v4.11. This way, we can backport it to stable (which
is arguably appropriate, given that upgrading to a EFIFB enabled
kernel may cause severe breakage for existing systems that implement
the GOP protocol), and easily change the patch to apply to x86 going
forwards, by removing the #ifdefs

-- 
Ard.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>>
>>>> [...]
>>>>
>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>>> of working around it by quirks.
>>>>>>
>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>>
>>>>>> Legacy only applies to DT based systems.
>>>>>>
>>>>>
>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>>> the time the kernel gets to access it.
>>>>
>>>> https://lkml.org/lkml/2016/3/3/458
>>>>
>>>
>>> I don't think the fact that at least one system existed over a year
>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>> being normative in this case.
>>
>> In any case, given that EFIFB is enabled by default on some distros,
>> and the fact that DT boot is affected as well, I should get this patch
>> in to prevent serious potential issues that could arise when someone
>> with a graphical UEFI stack updates to such a new kernel.
>>
>> So I think we are in agreement that this is needed on both ARM and
>> arm64, since their PCI configuration is usually not preserved. The
>> open question is whether there is any harm in enabling it for x86 as
>> well.
>>
>
> Agreed, the other issue is about compatibility with UEFI and future
> proofing Linux for other potential issues like hotplug reservation.
>

OK, given the lack of feedback regarding the suitability of this patch
for x86, I am going to rework it as a ARM/arm64 only patch, and queue
it as a fix for v4.11. This way, we can backport it to stable (which
is arguably appropriate, given that upgrading to a EFIFB enabled
kernel may cause severe breakage for existing systems that implement
the GOP protocol), and easily change the patch to apply to x86 going
forwards, by removing the #ifdefs

-- 
Ard.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 30 March 2017 at 14:50, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
>>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>>>> of working around it by quirks.
>>>>>>>
>>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>>>
>>>>>>> Legacy only applies to DT based systems.
>>>>>>>
>>>>>>
>>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>>>> the time the kernel gets to access it.
>>>>>
>>>>> https://lkml.org/lkml/2016/3/3/458
>>>>>
>>>>
>>>> I don't think the fact that at least one system existed over a year
>>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>>> being normative in this case.
>>>
>>> In any case, given that EFIFB is enabled by default on some distros,
>>> and the fact that DT boot is affected as well, I should get this patch
>>> in to prevent serious potential issues that could arise when someone
>>> with a graphical UEFI stack updates to such a new kernel.
>>>
>>> So I think we are in agreement that this is needed on both ARM and
>>> arm64, since their PCI configuration is usually not preserved. The
>>> open question is whether there is any harm in enabling it for x86 as
>>> well.
>>>
>>
>> Agreed, the other issue is about compatibility with UEFI and future
>> proofing Linux for other potential issues like hotplug reservation.
>>
>
> OK, given the lack of feedback regarding the suitability of this patch
> for x86, I am going to rework it as a ARM/arm64 only patch, and queue
> it as a fix for v4.11. This way, we can backport it to stable (which
> is arguably appropriate, given that upgrading to a EFIFB enabled
> kernel may cause severe breakage for existing systems that implement
> the GOP protocol), and easily change the patch to apply to x86 going
> forwards, by removing the #ifdefs
>

As it turns out, this patch does not solve the problem completely.

For EFI framebuffers that are backed by a PCI bar of a device residing
on bus 0, things work happily. However, claiming resources for devices
behind bridges doesn't work.

Given that we have not made the situation worse, fixing it is less
urgent than it was before. I.e., there is no longer a risk of
inadvertently poking the wrong BAR when writing to the framebuffer.
There is a regression in functionality, though, since EFI fb devices
that happened to work (because the firmware BAR == the kernel BAR)
have stopped working if they are behind a bridge, which is of course
always the case for PCIe.

So before starting the next round of hacking to work around this, I
would like rekindle the discussion regarding the way we blindly
reassign all resources on ACPI/arm64 systems, and whether there is a
way imaginable to avoid doing that.

I suppose the state of the BARs as we inherit it from the firmware
cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
with it). So should there be some side channel (UEFI config table
perhaps?) to describe this? How do other architectures deal with this?
Is this what the PCI bios accesses are for?

In any case, I have updated the UEFI firmware we have for ARM Juno to
use EDK2's generic PCI host bridge driver instead of one that was
specially written for ARM Juno, and may deviate in the way it
allocates PCI resources.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>>>> of working around it by quirks.
>>>>>>>
>>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>>>
>>>>>>> Legacy only applies to DT based systems.
>>>>>>>
>>>>>>
>>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>>>> the time the kernel gets to access it.
>>>>>
>>>>> https://lkml.org/lkml/2016/3/3/458
>>>>>
>>>>
>>>> I don't think the fact that at least one system existed over a year
>>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>>> being normative in this case.
>>>
>>> In any case, given that EFIFB is enabled by default on some distros,
>>> and the fact that DT boot is affected as well, I should get this patch
>>> in to prevent serious potential issues that could arise when someone
>>> with a graphical UEFI stack updates to such a new kernel.
>>>
>>> So I think we are in agreement that this is needed on both ARM and
>>> arm64, since their PCI configuration is usually not preserved. The
>>> open question is whether there is any harm in enabling it for x86 as
>>> well.
>>>
>>
>> Agreed, the other issue is about compatibility with UEFI and future
>> proofing Linux for other potential issues like hotplug reservation.
>>
>
> OK, given the lack of feedback regarding the suitability of this patch
> for x86, I am going to rework it as a ARM/arm64 only patch, and queue
> it as a fix for v4.11. This way, we can backport it to stable (which
> is arguably appropriate, given that upgrading to a EFIFB enabled
> kernel may cause severe breakage for existing systems that implement
> the GOP protocol), and easily change the patch to apply to x86 going
> forwards, by removing the #ifdefs
>

As it turns out, this patch does not solve the problem completely.

For EFI framebuffers that are backed by a PCI bar of a device residing
on bus 0, things work happily. However, claiming resources for devices
behind bridges doesn't work.

Given that we have not made the situation worse, fixing it is less
urgent than it was before. I.e., there is no longer a risk of
inadvertently poking the wrong BAR when writing to the framebuffer.
There is a regression in functionality, though, since EFI fb devices
that happened to work (because the firmware BAR == the kernel BAR)
have stopped working if they are behind a bridge, which is of course
always the case for PCIe.

So before starting the next round of hacking to work around this, I
would like rekindle the discussion regarding the way we blindly
reassign all resources on ACPI/arm64 systems, and whether there is a
way imaginable to avoid doing that.

I suppose the state of the BARs as we inherit it from the firmware
cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
with it). So should there be some side channel (UEFI config table
perhaps?) to describe this? How do other architectures deal with this?
Is this what the PCI bios accesses are for?

In any case, I have updated the UEFI firmware we have for ARM Juno to
use EDK2's generic PCI host bridge driver instead of one that was
specially written for ARM Juno, and may deviate in the way it
allocates PCI resources.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>>>>>> of working around it by quirks.
>>>>>>>
>>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>>>>>>
>>>>>>> Legacy only applies to DT based systems.
>>>>>>>
>>>>>>
>>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>>>>> the time the kernel gets to access it.
>>>>>
>>>>> https://lkml.org/lkml/2016/3/3/458
>>>>>
>>>>
>>>> I don't think the fact that at least one system existed over a year
>>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>>> being normative in this case.
>>>
>>> In any case, given that EFIFB is enabled by default on some distros,
>>> and the fact that DT boot is affected as well, I should get this patch
>>> in to prevent serious potential issues that could arise when someone
>>> with a graphical UEFI stack updates to such a new kernel.
>>>
>>> So I think we are in agreement that this is needed on both ARM and
>>> arm64, since their PCI configuration is usually not preserved. The
>>> open question is whether there is any harm in enabling it for x86 as
>>> well.
>>>
>>
>> Agreed, the other issue is about compatibility with UEFI and future
>> proofing Linux for other potential issues like hotplug reservation.
>>
>
> OK, given the lack of feedback regarding the suitability of this patch
> for x86, I am going to rework it as a ARM/arm64 only patch, and queue
> it as a fix for v4.11. This way, we can backport it to stable (which
> is arguably appropriate, given that upgrading to a EFIFB enabled
> kernel may cause severe breakage for existing systems that implement
> the GOP protocol), and easily change the patch to apply to x86 going
> forwards, by removing the #ifdefs
>

As it turns out, this patch does not solve the problem completely.

For EFI framebuffers that are backed by a PCI bar of a device residing
on bus 0, things work happily. However, claiming resources for devices
behind bridges doesn't work.

Given that we have not made the situation worse, fixing it is less
urgent than it was before. I.e., there is no longer a risk of
inadvertently poking the wrong BAR when writing to the framebuffer.
There is a regression in functionality, though, since EFI fb devices
that happened to work (because the firmware BAR == the kernel BAR)
have stopped working if they are behind a bridge, which is of course
always the case for PCIe.

So before starting the next round of hacking to work around this, I
would like rekindle the discussion regarding the way we blindly
reassign all resources on ACPI/arm64 systems, and whether there is a
way imaginable to avoid doing that.

I suppose the state of the BARs as we inherit it from the firmware
cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
with it). So should there be some side channel (UEFI config table
perhaps?) to describe this? How do other architectures deal with this?
Is this what the PCI bios accesses are for?

In any case, I have updated the UEFI firmware we have for ARM Juno to
use EDK2's generic PCI host bridge driver instead of one that was
specially written for ARM Juno, and may deviate in the way it
allocates PCI resources.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> >>>>>>> of working around it by quirks.
> >>>>>>>
> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
> >>>>>>>
> >>>>>>> Legacy only applies to DT based systems.
> >>>>>>>
> >>>>>>
> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
> >>>>>> the time the kernel gets to access it.
> >>>>>
> >>>>> https://lkml.org/lkml/2016/3/3/458
> >>>>>
> >>>>
> >>>> I don't think the fact that at least one system existed over a year
> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
> >>>> being normative in this case.
> >>>
> >>> In any case, given that EFIFB is enabled by default on some distros,
> >>> and the fact that DT boot is affected as well, I should get this patch
> >>> in to prevent serious potential issues that could arise when someone
> >>> with a graphical UEFI stack updates to such a new kernel.
> >>>
> >>> So I think we are in agreement that this is needed on both ARM and
> >>> arm64, since their PCI configuration is usually not preserved. The
> >>> open question is whether there is any harm in enabling it for x86 as
> >>> well.
> >>>
> >>
> >> Agreed, the other issue is about compatibility with UEFI and future
> >> proofing Linux for other potential issues like hotplug reservation.
> >>
> >
> > OK, given the lack of feedback regarding the suitability of this patch
> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
> > it as a fix for v4.11. This way, we can backport it to stable (which
> > is arguably appropriate, given that upgrading to a EFIFB enabled
> > kernel may cause severe breakage for existing systems that implement
> > the GOP protocol), and easily change the patch to apply to x86 going
> > forwards, by removing the #ifdefs
> >
> 
> As it turns out, this patch does not solve the problem completely.
> 
> For EFI framebuffers that are backed by a PCI bar of a device residing
> on bus 0, things work happily. However, claiming resources for devices
> behind bridges doesn't work.

May I ask you to elaborate on this please ? It is because we do not
claim the bridge windows upstream the device and they are reassigned ?

> Given that we have not made the situation worse, fixing it is less
> urgent than it was before. I.e., there is no longer a risk of
> inadvertently poking the wrong BAR when writing to the framebuffer.
> There is a regression in functionality, though, since EFI fb devices
> that happened to work (because the firmware BAR == the kernel BAR)
> have stopped working if they are behind a bridge, which is of course
> always the case for PCIe.
> 
> So before starting the next round of hacking to work around this, I
> would like rekindle the discussion regarding the way we blindly
> reassign all resources on ACPI/arm64 systems, and whether there is a
> way imaginable to avoid doing that.

There is a way if the whole ARM ecosystem work together to sort this
out and we think that's the right way to do; I am personally not
entirely convinced about that.

> I suppose the state of the BARs as we inherit it from the firmware
> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> with it). So should there be some side channel (UEFI config table
> perhaps?) to describe this?

PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
Boot Configurations".

Do we want to enforce it on ARM ? I do not know to be honest (and it
still would not solve the DT firmware case).

Whatever we do, it is not going to be clean cut IMO. I think that
what x86 does is sensible (well, minus the link ordering dependency we
discovered), I can do it for ARM64 but get ready for regressions and
I still think we have no real FW binding support that would make this
behaviour robust.

I can provide you with examples where, by simply claiming resources
on an ARM system you trigger resources allocation regressions by
preventing the kernel from allocating bigger bridge windows than
the ones set-up by FW.

> How do other architectures deal with this?

On an arch specific basis that make things work.

> Is this what the PCI bios accesses are for?

Which ones :) ?

> In any case, I have updated the UEFI firmware we have for ARM Juno to
> use EDK2's generic PCI host bridge driver instead of one that was
> specially written for ARM Juno, and may deviate in the way it
> allocates PCI resources.

As long as the kernel is free to reallocate them and that FW quiesces
devices at FW->OS handover I see no issues with that.

If we want to try to claim the whole resource tree on boot (in ACPI)
I can send a patch for that but there will be regressions.

Lorenzo

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> >>>>>>> of working around it by quirks.
> >>>>>>>
> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
> >>>>>>>
> >>>>>>> Legacy only applies to DT based systems.
> >>>>>>>
> >>>>>>
> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
> >>>>>> the time the kernel gets to access it.
> >>>>>
> >>>>> https://lkml.org/lkml/2016/3/3/458
> >>>>>
> >>>>
> >>>> I don't think the fact that at least one system existed over a year
> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
> >>>> being normative in this case.
> >>>
> >>> In any case, given that EFIFB is enabled by default on some distros,
> >>> and the fact that DT boot is affected as well, I should get this patch
> >>> in to prevent serious potential issues that could arise when someone
> >>> with a graphical UEFI stack updates to such a new kernel.
> >>>
> >>> So I think we are in agreement that this is needed on both ARM and
> >>> arm64, since their PCI configuration is usually not preserved. The
> >>> open question is whether there is any harm in enabling it for x86 as
> >>> well.
> >>>
> >>
> >> Agreed, the other issue is about compatibility with UEFI and future
> >> proofing Linux for other potential issues like hotplug reservation.
> >>
> >
> > OK, given the lack of feedback regarding the suitability of this patch
> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
> > it as a fix for v4.11. This way, we can backport it to stable (which
> > is arguably appropriate, given that upgrading to a EFIFB enabled
> > kernel may cause severe breakage for existing systems that implement
> > the GOP protocol), and easily change the patch to apply to x86 going
> > forwards, by removing the #ifdefs
> >
> 
> As it turns out, this patch does not solve the problem completely.
> 
> For EFI framebuffers that are backed by a PCI bar of a device residing
> on bus 0, things work happily. However, claiming resources for devices
> behind bridges doesn't work.

May I ask you to elaborate on this please ? It is because we do not
claim the bridge windows upstream the device and they are reassigned ?

> Given that we have not made the situation worse, fixing it is less
> urgent than it was before. I.e., there is no longer a risk of
> inadvertently poking the wrong BAR when writing to the framebuffer.
> There is a regression in functionality, though, since EFI fb devices
> that happened to work (because the firmware BAR == the kernel BAR)
> have stopped working if they are behind a bridge, which is of course
> always the case for PCIe.
> 
> So before starting the next round of hacking to work around this, I
> would like rekindle the discussion regarding the way we blindly
> reassign all resources on ACPI/arm64 systems, and whether there is a
> way imaginable to avoid doing that.

There is a way if the whole ARM ecosystem work together to sort this
out and we think that's the right way to do; I am personally not
entirely convinced about that.

> I suppose the state of the BARs as we inherit it from the firmware
> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> with it). So should there be some side channel (UEFI config table
> perhaps?) to describe this?

PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
Boot Configurations".

Do we want to enforce it on ARM ? I do not know to be honest (and it
still would not solve the DT firmware case).

Whatever we do, it is not going to be clean cut IMO. I think that
what x86 does is sensible (well, minus the link ordering dependency we
discovered), I can do it for ARM64 but get ready for regressions and
I still think we have no real FW binding support that would make this
behaviour robust.

I can provide you with examples where, by simply claiming resources
on an ARM system you trigger resources allocation regressions by
preventing the kernel from allocating bigger bridge windows than
the ones set-up by FW.

> How do other architectures deal with this?

On an arch specific basis that make things work.

> Is this what the PCI bios accesses are for?

Which ones :) ?

> In any case, I have updated the UEFI firmware we have for ARM Juno to
> use EDK2's generic PCI host bridge driver instead of one that was
> specially written for ARM Juno, and may deviate in the way it
> allocates PCI resources.

As long as the kernel is free to reallocate them and that FW quiesces
devices at FW->OS handover I see no issues with that.

If we want to try to claim the whole resource tree on boot (in ACPI)
I can send a patch for that but there will be regressions.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
> >>>>>
> >>>>> [...]
> >>>>>
> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
> >>>>>>> of working around it by quirks.
> >>>>>>>
> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
> >>>>>>>
> >>>>>>> Legacy only applies to DT based systems.
> >>>>>>>
> >>>>>>
> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
> >>>>>> the time the kernel gets to access it.
> >>>>>
> >>>>> https://lkml.org/lkml/2016/3/3/458
> >>>>>
> >>>>
> >>>> I don't think the fact that at least one system existed over a year
> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
> >>>> being normative in this case.
> >>>
> >>> In any case, given that EFIFB is enabled by default on some distros,
> >>> and the fact that DT boot is affected as well, I should get this patch
> >>> in to prevent serious potential issues that could arise when someone
> >>> with a graphical UEFI stack updates to such a new kernel.
> >>>
> >>> So I think we are in agreement that this is needed on both ARM and
> >>> arm64, since their PCI configuration is usually not preserved. The
> >>> open question is whether there is any harm in enabling it for x86 as
> >>> well.
> >>>
> >>
> >> Agreed, the other issue is about compatibility with UEFI and future
> >> proofing Linux for other potential issues like hotplug reservation.
> >>
> >
> > OK, given the lack of feedback regarding the suitability of this patch
> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
> > it as a fix for v4.11. This way, we can backport it to stable (which
> > is arguably appropriate, given that upgrading to a EFIFB enabled
> > kernel may cause severe breakage for existing systems that implement
> > the GOP protocol), and easily change the patch to apply to x86 going
> > forwards, by removing the #ifdefs
> >
> 
> As it turns out, this patch does not solve the problem completely.
> 
> For EFI framebuffers that are backed by a PCI bar of a device residing
> on bus 0, things work happily. However, claiming resources for devices
> behind bridges doesn't work.

May I ask you to elaborate on this please ? It is because we do not
claim the bridge windows upstream the device and they are reassigned ?

> Given that we have not made the situation worse, fixing it is less
> urgent than it was before. I.e., there is no longer a risk of
> inadvertently poking the wrong BAR when writing to the framebuffer.
> There is a regression in functionality, though, since EFI fb devices
> that happened to work (because the firmware BAR == the kernel BAR)
> have stopped working if they are behind a bridge, which is of course
> always the case for PCIe.
> 
> So before starting the next round of hacking to work around this, I
> would like rekindle the discussion regarding the way we blindly
> reassign all resources on ACPI/arm64 systems, and whether there is a
> way imaginable to avoid doing that.

There is a way if the whole ARM ecosystem work together to sort this
out and we think that's the right way to do; I am personally not
entirely convinced about that.

> I suppose the state of the BARs as we inherit it from the firmware
> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> with it). So should there be some side channel (UEFI config table
> perhaps?) to describe this?

PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
Boot Configurations".

Do we want to enforce it on ARM ? I do not know to be honest (and it
still would not solve the DT firmware case).

Whatever we do, it is not going to be clean cut IMO. I think that
what x86 does is sensible (well, minus the link ordering dependency we
discovered), I can do it for ARM64 but get ready for regressions and
I still think we have no real FW binding support that would make this
behaviour robust.

I can provide you with examples where, by simply claiming resources
on an ARM system you trigger resources allocation regressions by
preventing the kernel from allocating bigger bridge windows than
the ones set-up by FW.

> How do other architectures deal with this?

On an arch specific basis that make things work.

> Is this what the PCI bios accesses are for?

Which ones :) ?

> In any case, I have updated the UEFI firmware we have for ARM Juno to
> use EDK2's generic PCI host bridge driver instead of one that was
> specially written for ARM Juno, and may deviate in the way it
> allocates PCI resources.

As long as the kernel is free to reallocate them and that FW quiesces
devices at FW->OS handover I see no issues with that.

If we want to try to claim the whole resource tree on boot (in ACPI)
I can send a patch for that but there will be regressions.

Lorenzo

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 4/10/2017 12:53 PM, Lorenzo Pieralisi wrote:
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
> 

Yes for ACPI on ARM. Probably no for DT. 

> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is sensible (well, minus the link ordering dependency we
> discovered), I can do it for ARM64 but get ready for regressions and
> I still think we have no real FW binding support that would make this
> behaviour robust.

Is it possible to move the code from arch/x86 into drivers/acpi directory
so that the code is shared across multiple ACPI based archs. We get more
coverage this way.

Can we fallback to the allocate everything behavior if we can't use the
stuff from FW or would it be too late to recover?

We can prevent regressions this way and issue a lot of warnings. We can
sit down and fix those warnings over time whether the issue is in 
UEFI BIOS or the code itself.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 4/10/2017 12:53 PM, Lorenzo Pieralisi wrote:
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
> 

Yes for ACPI on ARM. Probably no for DT. 

> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is sensible (well, minus the link ordering dependency we
> discovered), I can do it for ARM64 but get ready for regressions and
> I still think we have no real FW binding support that would make this
> behaviour robust.

Is it possible to move the code from arch/x86 into drivers/acpi directory
so that the code is shared across multiple ACPI based archs. We get more
coverage this way.

Can we fallback to the allocate everything behavior if we can't use the
stuff from FW or would it be too late to recover?

We can prevent regressions this way and issue a lot of warnings. We can
sit down and fix those warnings over time whether the issue is in 
UEFI BIOS or the code itself.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Sinan Kaya]

On 4/10/2017 12:53 PM, Lorenzo Pieralisi wrote:
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
> 

Yes for ACPI on ARM. Probably no for DT. 

> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is sensible (well, minus the link ordering dependency we
> discovered), I can do it for ARM64 but get ready for regressions and
> I still think we have no real FW binding support that would make this
> behaviour robust.

Is it possible to move the code from arch/x86 into drivers/acpi directory
so that the code is shared across multiple ACPI based archs. We get more
coverage this way.

Can we fallback to the allocate everything behavior if we can't use the
stuff from FW or would it be too late to recover?

We can prevent regressions this way and issue a lot of warnings. We can
sit down and fix those warnings over time whether the issue is in 
UEFI BIOS or the code itself.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 10 April 2017 at 17:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>> >>>>>
>> >>>>> [...]
>> >>>>>
>> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>> >>>>>>> of working around it by quirks.
>> >>>>>>>
>> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>> >>>>>>>
>> >>>>>>> Legacy only applies to DT based systems.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>> >>>>>> the time the kernel gets to access it.
>> >>>>>
>> >>>>> https://lkml.org/lkml/2016/3/3/458
>> >>>>>
>> >>>>
>> >>>> I don't think the fact that at least one system existed over a year
>> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
>> >>>> being normative in this case.
>> >>>
>> >>> In any case, given that EFIFB is enabled by default on some distros,
>> >>> and the fact that DT boot is affected as well, I should get this patch
>> >>> in to prevent serious potential issues that could arise when someone
>> >>> with a graphical UEFI stack updates to such a new kernel.
>> >>>
>> >>> So I think we are in agreement that this is needed on both ARM and
>> >>> arm64, since their PCI configuration is usually not preserved. The
>> >>> open question is whether there is any harm in enabling it for x86 as
>> >>> well.
>> >>>
>> >>
>> >> Agreed, the other issue is about compatibility with UEFI and future
>> >> proofing Linux for other potential issues like hotplug reservation.
>> >>
>> >
>> > OK, given the lack of feedback regarding the suitability of this patch
>> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
>> > it as a fix for v4.11. This way, we can backport it to stable (which
>> > is arguably appropriate, given that upgrading to a EFIFB enabled
>> > kernel may cause severe breakage for existing systems that implement
>> > the GOP protocol), and easily change the patch to apply to x86 going
>> > forwards, by removing the #ifdefs
>> >
>>
>> As it turns out, this patch does not solve the problem completely.
>>
>> For EFI framebuffers that are backed by a PCI bar of a device residing
>> on bus 0, things work happily. However, claiming resources for devices
>> behind bridges doesn't work.
>
> May I ask you to elaborate on this please ? It is because we do not
> claim the bridge windows upstream the device and they are reassigned ?
>

The pci_claim_resource() call fails like this

pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
no compatible bridge window
pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!

which is caused by the fact that the parent resources are all zeroes.
It appears the BAR configuration is never read from the bridges, so
the only way we will ever have meaningful values in there is if we
allocate them ourselves.

>> Given that we have not made the situation worse, fixing it is less
>> urgent than it was before. I.e., there is no longer a risk of
>> inadvertently poking the wrong BAR when writing to the framebuffer.
>> There is a regression in functionality, though, since EFI fb devices
>> that happened to work (because the firmware BAR == the kernel BAR)
>> have stopped working if they are behind a bridge, which is of course
>> always the case for PCIe.
>>
>> So before starting the next round of hacking to work around this, I
>> would like rekindle the discussion regarding the way we blindly
>> reassign all resources on ACPI/arm64 systems, and whether there is a
>> way imaginable to avoid doing that.
>
> There is a way if the whole ARM ecosystem work together to sort this
> out and we think that's the right way to do; I am personally not
> entirely convinced about that.
>

So what are the pros and cons here? EFI fb is not a hugely important
use case, but it is one that relies on BARs staying where they are.
Are there others like that?

>> I suppose the state of the BARs as we inherit it from the firmware
>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>> with it). So should there be some side channel (UEFI config table
>> perhaps?) to describe this?
>
> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> Boot Configurations".
>
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
>

No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
the pros outweigh the cons.

> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is sensible (well, minus the link ordering dependency we
> discovered), I can do it for ARM64 but get ready for regressions and
> I still think we have no real FW binding support that would make this
> behaviour robust.
>
> I can provide you with examples where, by simply claiming resources
> on an ARM system you trigger resources allocation regressions by
> preventing the kernel from allocating bigger bridge windows than
> the ones set-up by FW.
>

So how is this specific to ARM then? If we are running the same
resource allocation routines, why should we end up with a firmware
allocation that the kernel cannot use?

>> How do other architectures deal with this?
>
> On an arch specific basis that make things work.
>
>> Is this what the PCI bios accesses are for?
>
> Which ones :) ?
>

Well, some of them :-)

I guess the question was if the overridden __weak methods are supposed
to hook into tables or other BIOS structures that contain information
about the PCI resource allocations by the firmware.

>> In any case, I have updated the UEFI firmware we have for ARM Juno to
>> use EDK2's generic PCI host bridge driver instead of one that was
>> specially written for ARM Juno, and may deviate in the way it
>> allocates PCI resources.
>
> As long as the kernel is free to reallocate them and that FW quiesces
> devices at FW->OS handover I see no issues with that.
>

The reason is to eliminate another unknown from the discussion whether
UEFI can be expected to leave the entire PCI hierarchy in a sane
state.

> If we want to try to claim the whole resource tree on boot (in ACPI)
> I can send a patch for that but there will be regressions.
>

I would like to see it, yes.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 10 April 2017 at 17:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>> >>>>>
>> >>>>> [...]
>> >>>>>
>> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>> >>>>>>> of working around it by quirks.
>> >>>>>>>
>> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>> >>>>>>>
>> >>>>>>> Legacy only applies to DT based systems.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>> >>>>>> the time the kernel gets to access it.
>> >>>>>
>> >>>>> https://lkml.org/lkml/2016/3/3/458
>> >>>>>
>> >>>>
>> >>>> I don't think the fact that at least one system existed over a year
>> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
>> >>>> being normative in this case.
>> >>>
>> >>> In any case, given that EFIFB is enabled by default on some distros,
>> >>> and the fact that DT boot is affected as well, I should get this patch
>> >>> in to prevent serious potential issues that could arise when someone
>> >>> with a graphical UEFI stack updates to such a new kernel.
>> >>>
>> >>> So I think we are in agreement that this is needed on both ARM and
>> >>> arm64, since their PCI configuration is usually not preserved. The
>> >>> open question is whether there is any harm in enabling it for x86 as
>> >>> well.
>> >>>
>> >>
>> >> Agreed, the other issue is about compatibility with UEFI and future
>> >> proofing Linux for other potential issues like hotplug reservation.
>> >>
>> >
>> > OK, given the lack of feedback regarding the suitability of this patch
>> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
>> > it as a fix for v4.11. This way, we can backport it to stable (which
>> > is arguably appropriate, given that upgrading to a EFIFB enabled
>> > kernel may cause severe breakage for existing systems that implement
>> > the GOP protocol), and easily change the patch to apply to x86 going
>> > forwards, by removing the #ifdefs
>> >
>>
>> As it turns out, this patch does not solve the problem completely.
>>
>> For EFI framebuffers that are backed by a PCI bar of a device residing
>> on bus 0, things work happily. However, claiming resources for devices
>> behind bridges doesn't work.
>
> May I ask you to elaborate on this please ? It is because we do not
> claim the bridge windows upstream the device and they are reassigned ?
>

The pci_claim_resource() call fails like this

pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
no compatible bridge window
pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!

which is caused by the fact that the parent resources are all zeroes.
It appears the BAR configuration is never read from the bridges, so
the only way we will ever have meaningful values in there is if we
allocate them ourselves.

>> Given that we have not made the situation worse, fixing it is less
>> urgent than it was before. I.e., there is no longer a risk of
>> inadvertently poking the wrong BAR when writing to the framebuffer.
>> There is a regression in functionality, though, since EFI fb devices
>> that happened to work (because the firmware BAR == the kernel BAR)
>> have stopped working if they are behind a bridge, which is of course
>> always the case for PCIe.
>>
>> So before starting the next round of hacking to work around this, I
>> would like rekindle the discussion regarding the way we blindly
>> reassign all resources on ACPI/arm64 systems, and whether there is a
>> way imaginable to avoid doing that.
>
> There is a way if the whole ARM ecosystem work together to sort this
> out and we think that's the right way to do; I am personally not
> entirely convinced about that.
>

So what are the pros and cons here? EFI fb is not a hugely important
use case, but it is one that relies on BARs staying where they are.
Are there others like that?

>> I suppose the state of the BARs as we inherit it from the firmware
>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>> with it). So should there be some side channel (UEFI config table
>> perhaps?) to describe this?
>
> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> Boot Configurations".
>
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
>

No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
the pros outweigh the cons.

> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is sensible (well, minus the link ordering dependency we
> discovered), I can do it for ARM64 but get ready for regressions and
> I still think we have no real FW binding support that would make this
> behaviour robust.
>
> I can provide you with examples where, by simply claiming resources
> on an ARM system you trigger resources allocation regressions by
> preventing the kernel from allocating bigger bridge windows than
> the ones set-up by FW.
>

So how is this specific to ARM then? If we are running the same
resource allocation routines, why should we end up with a firmware
allocation that the kernel cannot use?

>> How do other architectures deal with this?
>
> On an arch specific basis that make things work.
>
>> Is this what the PCI bios accesses are for?
>
> Which ones :) ?
>

Well, some of them :-)

I guess the question was if the overridden __weak methods are supposed
to hook into tables or other BIOS structures that contain information
about the PCI resource allocations by the firmware.

>> In any case, I have updated the UEFI firmware we have for ARM Juno to
>> use EDK2's generic PCI host bridge driver instead of one that was
>> specially written for ARM Juno, and may deviate in the way it
>> allocates PCI resources.
>
> As long as the kernel is free to reallocate them and that FW quiesces
> devices at FW->OS handover I see no issues with that.
>

The reason is to eliminate another unknown from the discussion whether
UEFI can be expected to leave the entire PCI hierarchy in a sane
state.

> If we want to try to claim the whole resource tree on boot (in ACPI)
> I can send a patch for that but there will be regressions.
>

I would like to see it, yes.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 10 April 2017 at 17:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>> >>>>>
>> >>>>> [...]
>> >>>>>
>> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>> >>>>>>> of working around it by quirks.
>> >>>>>>>
>> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>> >>>>>>>
>> >>>>>>> Legacy only applies to DT based systems.
>> >>>>>>>
>> >>>>>>
>> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>> >>>>>> the time the kernel gets to access it.
>> >>>>>
>> >>>>> https://lkml.org/lkml/2016/3/3/458
>> >>>>>
>> >>>>
>> >>>> I don't think the fact that at least one system existed over a year
>> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
>> >>>> being normative in this case.
>> >>>
>> >>> In any case, given that EFIFB is enabled by default on some distros,
>> >>> and the fact that DT boot is affected as well, I should get this patch
>> >>> in to prevent serious potential issues that could arise when someone
>> >>> with a graphical UEFI stack updates to such a new kernel.
>> >>>
>> >>> So I think we are in agreement that this is needed on both ARM and
>> >>> arm64, since their PCI configuration is usually not preserved. The
>> >>> open question is whether there is any harm in enabling it for x86 as
>> >>> well.
>> >>>
>> >>
>> >> Agreed, the other issue is about compatibility with UEFI and future
>> >> proofing Linux for other potential issues like hotplug reservation.
>> >>
>> >
>> > OK, given the lack of feedback regarding the suitability of this patch
>> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
>> > it as a fix for v4.11. This way, we can backport it to stable (which
>> > is arguably appropriate, given that upgrading to a EFIFB enabled
>> > kernel may cause severe breakage for existing systems that implement
>> > the GOP protocol), and easily change the patch to apply to x86 going
>> > forwards, by removing the #ifdefs
>> >
>>
>> As it turns out, this patch does not solve the problem completely.
>>
>> For EFI framebuffers that are backed by a PCI bar of a device residing
>> on bus 0, things work happily. However, claiming resources for devices
>> behind bridges doesn't work.
>
> May I ask you to elaborate on this please ? It is because we do not
> claim the bridge windows upstream the device and they are reassigned ?
>

The pci_claim_resource() call fails like this

pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
no compatible bridge window
pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!

which is caused by the fact that the parent resources are all zeroes.
It appears the BAR configuration is never read from the bridges, so
the only way we will ever have meaningful values in there is if we
allocate them ourselves.

>> Given that we have not made the situation worse, fixing it is less
>> urgent than it was before. I.e., there is no longer a risk of
>> inadvertently poking the wrong BAR when writing to the framebuffer.
>> There is a regression in functionality, though, since EFI fb devices
>> that happened to work (because the firmware BAR == the kernel BAR)
>> have stopped working if they are behind a bridge, which is of course
>> always the case for PCIe.
>>
>> So before starting the next round of hacking to work around this, I
>> would like rekindle the discussion regarding the way we blindly
>> reassign all resources on ACPI/arm64 systems, and whether there is a
>> way imaginable to avoid doing that.
>
> There is a way if the whole ARM ecosystem work together to sort this
> out and we think that's the right way to do; I am personally not
> entirely convinced about that.
>

So what are the pros and cons here? EFI fb is not a hugely important
use case, but it is one that relies on BARs staying where they are.
Are there others like that?

>> I suppose the state of the BARs as we inherit it from the firmware
>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>> with it). So should there be some side channel (UEFI config table
>> perhaps?) to describe this?
>
> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> Boot Configurations".
>
> Do we want to enforce it on ARM ? I do not know to be honest (and it
> still would not solve the DT firmware case).
>

No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
the pros outweigh the cons.

> Whatever we do, it is not going to be clean cut IMO. I think that
> what x86 does is sensible (well, minus the link ordering dependency we
> discovered), I can do it for ARM64 but get ready for regressions and
> I still think we have no real FW binding support that would make this
> behaviour robust.
>
> I can provide you with examples where, by simply claiming resources
> on an ARM system you trigger resources allocation regressions by
> preventing the kernel from allocating bigger bridge windows than
> the ones set-up by FW.
>

So how is this specific to ARM then? If we are running the same
resource allocation routines, why should we end up with a firmware
allocation that the kernel cannot use?

>> How do other architectures deal with this?
>
> On an arch specific basis that make things work.
>
>> Is this what the PCI bios accesses are for?
>
> Which ones :) ?
>

Well, some of them :-)

I guess the question was if the overridden __weak methods are supposed
to hook into tables or other BIOS structures that contain information
about the PCI resource allocations by the firmware.

>> In any case, I have updated the UEFI firmware we have for ARM Juno to
>> use EDK2's generic PCI host bridge driver instead of one that was
>> specially written for ARM Juno, and may deviate in the way it
>> allocates PCI resources.
>
> As long as the kernel is free to reallocate them and that FW quiesces
> devices at FW->OS handover I see no issues with that.
>

The reason is to eliminate another unknown from the discussion whether
UEFI can be expected to leave the entire PCI hierarchy in a sane
state.

> If we want to try to claim the whole resource tree on boot (in ACPI)
> I can send a patch for that but there will be regressions.
>

I would like to see it, yes.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 10 April 2017 at 18:13, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 10 April 2017 at 17:53, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
>> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>>> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> > On 30 March 2017 at 14:50, Sinan Kaya <okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> wrote:
>>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org> wrote:
>>> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>> >>>>>
>>> >>>>> [...]
>>> >>>>>
>>> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> >>>>>>> of working around it by quirks.
>>> >>>>>>>
>>> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >>>>>>>
>>> >>>>>>> Legacy only applies to DT based systems.
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> >>>>>> the time the kernel gets to access it.
>>> >>>>>
>>> >>>>> https://lkml.org/lkml/2016/3/3/458
>>> >>>>>
>>> >>>>
>>> >>>> I don't think the fact that at least one system existed over a year
>>> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>> >>>> being normative in this case.
>>> >>>
>>> >>> In any case, given that EFIFB is enabled by default on some distros,
>>> >>> and the fact that DT boot is affected as well, I should get this patch
>>> >>> in to prevent serious potential issues that could arise when someone
>>> >>> with a graphical UEFI stack updates to such a new kernel.
>>> >>>
>>> >>> So I think we are in agreement that this is needed on both ARM and
>>> >>> arm64, since their PCI configuration is usually not preserved. The
>>> >>> open question is whether there is any harm in enabling it for x86 as
>>> >>> well.
>>> >>>
>>> >>
>>> >> Agreed, the other issue is about compatibility with UEFI and future
>>> >> proofing Linux for other potential issues like hotplug reservation.
>>> >>
>>> >
>>> > OK, given the lack of feedback regarding the suitability of this patch
>>> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
>>> > it as a fix for v4.11. This way, we can backport it to stable (which
>>> > is arguably appropriate, given that upgrading to a EFIFB enabled
>>> > kernel may cause severe breakage for existing systems that implement
>>> > the GOP protocol), and easily change the patch to apply to x86 going
>>> > forwards, by removing the #ifdefs
>>> >
>>>
>>> As it turns out, this patch does not solve the problem completely.
>>>
>>> For EFI framebuffers that are backed by a PCI bar of a device residing
>>> on bus 0, things work happily. However, claiming resources for devices
>>> behind bridges doesn't work.
>>
>> May I ask you to elaborate on this please ? It is because we do not
>> claim the bridge windows upstream the device and they are reassigned ?
>>
>
> The pci_claim_resource() call fails like this
>
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
>
> which is caused by the fact that the parent resources are all zeroes.
> It appears the BAR configuration is never read from the bridges, so
> the only way we will ever have meaningful values in there is if we
> allocate them ourselves.
>
>>> Given that we have not made the situation worse, fixing it is less
>>> urgent than it was before. I.e., there is no longer a risk of
>>> inadvertently poking the wrong BAR when writing to the framebuffer.
>>> There is a regression in functionality, though, since EFI fb devices
>>> that happened to work (because the firmware BAR == the kernel BAR)
>>> have stopped working if they are behind a bridge, which is of course
>>> always the case for PCIe.
>>>
>>> So before starting the next round of hacking to work around this, I
>>> would like rekindle the discussion regarding the way we blindly
>>> reassign all resources on ACPI/arm64 systems, and whether there is a
>>> way imaginable to avoid doing that.
>>
>> There is a way if the whole ARM ecosystem work together to sort this
>> out and we think that's the right way to do; I am personally not
>> entirely convinced about that.
>>
>
> So what are the pros and cons here? EFI fb is not a hugely important
> use case, but it is one that relies on BARs staying where they are.
> Are there others like that?
>
>>> I suppose the state of the BARs as we inherit it from the firmware
>>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>>> with it). So should there be some side channel (UEFI config table
>>> perhaps?) to describe this?
>>
>> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
>> Boot Configurations".
>>
>> Do we want to enforce it on ARM ? I do not know to be honest (and it
>> still would not solve the DT firmware case).
>>
>
> No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> the pros outweigh the cons.
>
>> Whatever we do, it is not going to be clean cut IMO. I think that
>> what x86 does is sensible (well, minus the link ordering dependency we
>> discovered), I can do it for ARM64 but get ready for regressions and
>> I still think we have no real FW binding support that would make this
>> behaviour robust.
>>
>> I can provide you with examples where, by simply claiming resources
>> on an ARM system you trigger resources allocation regressions by
>> preventing the kernel from allocating bigger bridge windows than
>> the ones set-up by FW.
>>
>
> So how is this specific to ARM then? If we are running the same
> resource allocation routines, why should we end up with a firmware
> allocation that the kernel cannot use?
>
>>> How do other architectures deal with this?
>>
>> On an arch specific basis that make things work.
>>
>>> Is this what the PCI bios accesses are for?
>>
>> Which ones :) ?
>>
>
> Well, some of them :-)
>
> I guess the question was if the overridden __weak methods are supposed
> to hook into tables or other BIOS structures that contain information
> about the PCI resource allocations by the firmware.
>
>>> In any case, I have updated the UEFI firmware we have for ARM Juno to
>>> use EDK2's generic PCI host bridge driver instead of one that was
>>> specially written for ARM Juno, and may deviate in the way it
>>> allocates PCI resources.
>>
>> As long as the kernel is free to reallocate them and that FW quiesces
>> devices at FW->OS handover I see no issues with that.
>>
>
> The reason is to eliminate another unknown from the discussion whether
> UEFI can be expected to leave the entire PCI hierarchy in a sane
> state.
>
>> If we want to try to claim the whole resource tree on boot (in ACPI)
>> I can send a patch for that but there will be regressions.
>>
>
> I would like to see it, yes.

FWIW, the following minimal [naive] patch

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4f0e3ebfea4b..37c4d2f116a4 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -27,7 +27,7 @@
  */
 void pcibios_fixup_bus(struct pci_bus *bus)
 {
-       /* nothing to do, expected to be removed in the future */
+       pci_read_bridge_bases(bus);
 }

 /*
@@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
acpi_pci_root *root)
        if (!bus)
                return NULL;

-       pci_bus_size_bridges(bus);
-       pci_bus_assign_resources(bus);
+       pci_assign_unassigned_root_bus_resources(bus);
+       pci_bus_claim_resources(bus);

        list_for_each_entry(child, &bus->children, node)
                pcie_bus_configure_settings(child);

running under QEMU+UEFI with the following PCI topology

-[0000:00]-+-00.0  Red Hat, Inc. Device 0008
           +-01.0-[01]----01.0  Device 1234:1111
           +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
           |            \-03.0  Red Hat, Inc Virtio block device
           \-03.0-[03]----04.0  Red Hat, Inc Virtio network device

results in the log below, preserving the configuration created by UEFI

pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
pci_bus 0000:00: root bus resource [bus 00-0f]
pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
no compatible bridge window
pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 10 April 2017 at 18:13, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 10 April 2017 at 17:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>>> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>> >>>>>
>>> >>>>> [...]
>>> >>>>>
>>> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> >>>>>>> of working around it by quirks.
>>> >>>>>>>
>>> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >>>>>>>
>>> >>>>>>> Legacy only applies to DT based systems.
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> >>>>>> the time the kernel gets to access it.
>>> >>>>>
>>> >>>>> https://lkml.org/lkml/2016/3/3/458
>>> >>>>>
>>> >>>>
>>> >>>> I don't think the fact that at least one system existed over a year
>>> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>> >>>> being normative in this case.
>>> >>>
>>> >>> In any case, given that EFIFB is enabled by default on some distros,
>>> >>> and the fact that DT boot is affected as well, I should get this patch
>>> >>> in to prevent serious potential issues that could arise when someone
>>> >>> with a graphical UEFI stack updates to such a new kernel.
>>> >>>
>>> >>> So I think we are in agreement that this is needed on both ARM and
>>> >>> arm64, since their PCI configuration is usually not preserved. The
>>> >>> open question is whether there is any harm in enabling it for x86 as
>>> >>> well.
>>> >>>
>>> >>
>>> >> Agreed, the other issue is about compatibility with UEFI and future
>>> >> proofing Linux for other potential issues like hotplug reservation.
>>> >>
>>> >
>>> > OK, given the lack of feedback regarding the suitability of this patch
>>> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
>>> > it as a fix for v4.11. This way, we can backport it to stable (which
>>> > is arguably appropriate, given that upgrading to a EFIFB enabled
>>> > kernel may cause severe breakage for existing systems that implement
>>> > the GOP protocol), and easily change the patch to apply to x86 going
>>> > forwards, by removing the #ifdefs
>>> >
>>>
>>> As it turns out, this patch does not solve the problem completely.
>>>
>>> For EFI framebuffers that are backed by a PCI bar of a device residing
>>> on bus 0, things work happily. However, claiming resources for devices
>>> behind bridges doesn't work.
>>
>> May I ask you to elaborate on this please ? It is because we do not
>> claim the bridge windows upstream the device and they are reassigned ?
>>
>
> The pci_claim_resource() call fails like this
>
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
>
> which is caused by the fact that the parent resources are all zeroes.
> It appears the BAR configuration is never read from the bridges, so
> the only way we will ever have meaningful values in there is if we
> allocate them ourselves.
>
>>> Given that we have not made the situation worse, fixing it is less
>>> urgent than it was before. I.e., there is no longer a risk of
>>> inadvertently poking the wrong BAR when writing to the framebuffer.
>>> There is a regression in functionality, though, since EFI fb devices
>>> that happened to work (because the firmware BAR == the kernel BAR)
>>> have stopped working if they are behind a bridge, which is of course
>>> always the case for PCIe.
>>>
>>> So before starting the next round of hacking to work around this, I
>>> would like rekindle the discussion regarding the way we blindly
>>> reassign all resources on ACPI/arm64 systems, and whether there is a
>>> way imaginable to avoid doing that.
>>
>> There is a way if the whole ARM ecosystem work together to sort this
>> out and we think that's the right way to do; I am personally not
>> entirely convinced about that.
>>
>
> So what are the pros and cons here? EFI fb is not a hugely important
> use case, but it is one that relies on BARs staying where they are.
> Are there others like that?
>
>>> I suppose the state of the BARs as we inherit it from the firmware
>>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>>> with it). So should there be some side channel (UEFI config table
>>> perhaps?) to describe this?
>>
>> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
>> Boot Configurations".
>>
>> Do we want to enforce it on ARM ? I do not know to be honest (and it
>> still would not solve the DT firmware case).
>>
>
> No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> the pros outweigh the cons.
>
>> Whatever we do, it is not going to be clean cut IMO. I think that
>> what x86 does is sensible (well, minus the link ordering dependency we
>> discovered), I can do it for ARM64 but get ready for regressions and
>> I still think we have no real FW binding support that would make this
>> behaviour robust.
>>
>> I can provide you with examples where, by simply claiming resources
>> on an ARM system you trigger resources allocation regressions by
>> preventing the kernel from allocating bigger bridge windows than
>> the ones set-up by FW.
>>
>
> So how is this specific to ARM then? If we are running the same
> resource allocation routines, why should we end up with a firmware
> allocation that the kernel cannot use?
>
>>> How do other architectures deal with this?
>>
>> On an arch specific basis that make things work.
>>
>>> Is this what the PCI bios accesses are for?
>>
>> Which ones :) ?
>>
>
> Well, some of them :-)
>
> I guess the question was if the overridden __weak methods are supposed
> to hook into tables or other BIOS structures that contain information
> about the PCI resource allocations by the firmware.
>
>>> In any case, I have updated the UEFI firmware we have for ARM Juno to
>>> use EDK2's generic PCI host bridge driver instead of one that was
>>> specially written for ARM Juno, and may deviate in the way it
>>> allocates PCI resources.
>>
>> As long as the kernel is free to reallocate them and that FW quiesces
>> devices at FW->OS handover I see no issues with that.
>>
>
> The reason is to eliminate another unknown from the discussion whether
> UEFI can be expected to leave the entire PCI hierarchy in a sane
> state.
>
>> If we want to try to claim the whole resource tree on boot (in ACPI)
>> I can send a patch for that but there will be regressions.
>>
>
> I would like to see it, yes.

FWIW, the following minimal [naive] patch

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4f0e3ebfea4b..37c4d2f116a4 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -27,7 +27,7 @@
  */
 void pcibios_fixup_bus(struct pci_bus *bus)
 {
-       /* nothing to do, expected to be removed in the future */
+       pci_read_bridge_bases(bus);
 }

 /*
@@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
acpi_pci_root *root)
        if (!bus)
                return NULL;

-       pci_bus_size_bridges(bus);
-       pci_bus_assign_resources(bus);
+       pci_assign_unassigned_root_bus_resources(bus);
+       pci_bus_claim_resources(bus);

        list_for_each_entry(child, &bus->children, node)
                pcie_bus_configure_settings(child);

running under QEMU+UEFI with the following PCI topology

-[0000:00]-+-00.0  Red Hat, Inc. Device 0008
           +-01.0-[01]----01.0  Device 1234:1111
           +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
           |            \-03.0  Red Hat, Inc Virtio block device
           \-03.0-[03]----04.0  Red Hat, Inc Virtio network device

results in the log below, preserving the configuration created by UEFI

pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
pci_bus 0000:00: root bus resource [bus 00-0f]
pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
no compatible bridge window
pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 10 April 2017 at 18:13, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 10 April 2017 at 17:53, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>> On Mon, Apr 10, 2017 at 04:28:11PM +0100, Ard Biesheuvel wrote:
>>> On 2 April 2017 at 16:16, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> > On 30 March 2017 at 14:50, Sinan Kaya <okaya@codeaurora.org> wrote:
>>> >> On 3/30/2017 9:38 AM, Ard Biesheuvel wrote:
>>> >>> On 30 March 2017 at 11:09, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> >>>> On 30 March 2017 at 11:05, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>>> >>>>> On Thu, Mar 30, 2017 at 09:46:39AM +0100, Ard Biesheuvel wrote:
>>> >>>>>
>>> >>>>> [...]
>>> >>>>>
>>> >>>>>>> I'm asking why we don't fix the actual problem in PCIe ARM64 adaptation instead
>>> >>>>>>> of working around it by quirks.
>>> >>>>>>>
>>> >>>>>>> I don't see any reason why ACPI ARM64 should carry the burden of legacy systems.
>>> >>>>>>>
>>> >>>>>>> Legacy only applies to DT based systems.
>>> >>>>>>>
>>> >>>>>>
>>> >>>>>> I fully agree with this point: ACPI implies firmware, and so we should
>>> >>>>>> be able to rely on firmware to have initialized the PCIe subsystem by
>>> >>>>>> the time the kernel gets to access it.
>>> >>>>>
>>> >>>>> https://lkml.org/lkml/2016/3/3/458
>>> >>>>>
>>> >>>>
>>> >>>> I don't think the fact that at least one system existed over a year
>>> >>>> ago whose UEFI assigned resources incorrectly should prevent us from
>>> >>>> being normative in this case.
>>> >>>
>>> >>> In any case, given that EFIFB is enabled by default on some distros,
>>> >>> and the fact that DT boot is affected as well, I should get this patch
>>> >>> in to prevent serious potential issues that could arise when someone
>>> >>> with a graphical UEFI stack updates to such a new kernel.
>>> >>>
>>> >>> So I think we are in agreement that this is needed on both ARM and
>>> >>> arm64, since their PCI configuration is usually not preserved. The
>>> >>> open question is whether there is any harm in enabling it for x86 as
>>> >>> well.
>>> >>>
>>> >>
>>> >> Agreed, the other issue is about compatibility with UEFI and future
>>> >> proofing Linux for other potential issues like hotplug reservation.
>>> >>
>>> >
>>> > OK, given the lack of feedback regarding the suitability of this patch
>>> > for x86, I am going to rework it as a ARM/arm64 only patch, and queue
>>> > it as a fix for v4.11. This way, we can backport it to stable (which
>>> > is arguably appropriate, given that upgrading to a EFIFB enabled
>>> > kernel may cause severe breakage for existing systems that implement
>>> > the GOP protocol), and easily change the patch to apply to x86 going
>>> > forwards, by removing the #ifdefs
>>> >
>>>
>>> As it turns out, this patch does not solve the problem completely.
>>>
>>> For EFI framebuffers that are backed by a PCI bar of a device residing
>>> on bus 0, things work happily. However, claiming resources for devices
>>> behind bridges doesn't work.
>>
>> May I ask you to elaborate on this please ? It is because we do not
>> claim the bridge windows upstream the device and they are reassigned ?
>>
>
> The pci_claim_resource() call fails like this
>
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
>
> which is caused by the fact that the parent resources are all zeroes.
> It appears the BAR configuration is never read from the bridges, so
> the only way we will ever have meaningful values in there is if we
> allocate them ourselves.
>
>>> Given that we have not made the situation worse, fixing it is less
>>> urgent than it was before. I.e., there is no longer a risk of
>>> inadvertently poking the wrong BAR when writing to the framebuffer.
>>> There is a regression in functionality, though, since EFI fb devices
>>> that happened to work (because the firmware BAR == the kernel BAR)
>>> have stopped working if they are behind a bridge, which is of course
>>> always the case for PCIe.
>>>
>>> So before starting the next round of hacking to work around this, I
>>> would like rekindle the discussion regarding the way we blindly
>>> reassign all resources on ACPI/arm64 systems, and whether there is a
>>> way imaginable to avoid doing that.
>>
>> There is a way if the whole ARM ecosystem work together to sort this
>> out and we think that's the right way to do; I am personally not
>> entirely convinced about that.
>>
>
> So what are the pros and cons here? EFI fb is not a hugely important
> use case, but it is one that relies on BARs staying where they are.
> Are there others like that?
>
>>> I suppose the state of the BARs as we inherit it from the firmware
>>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>>> with it). So should there be some side channel (UEFI config table
>>> perhaps?) to describe this?
>>
>> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
>> Boot Configurations".
>>
>> Do we want to enforce it on ARM ? I do not know to be honest (and it
>> still would not solve the DT firmware case).
>>
>
> No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> the pros outweigh the cons.
>
>> Whatever we do, it is not going to be clean cut IMO. I think that
>> what x86 does is sensible (well, minus the link ordering dependency we
>> discovered), I can do it for ARM64 but get ready for regressions and
>> I still think we have no real FW binding support that would make this
>> behaviour robust.
>>
>> I can provide you with examples where, by simply claiming resources
>> on an ARM system you trigger resources allocation regressions by
>> preventing the kernel from allocating bigger bridge windows than
>> the ones set-up by FW.
>>
>
> So how is this specific to ARM then? If we are running the same
> resource allocation routines, why should we end up with a firmware
> allocation that the kernel cannot use?
>
>>> How do other architectures deal with this?
>>
>> On an arch specific basis that make things work.
>>
>>> Is this what the PCI bios accesses are for?
>>
>> Which ones :) ?
>>
>
> Well, some of them :-)
>
> I guess the question was if the overridden __weak methods are supposed
> to hook into tables or other BIOS structures that contain information
> about the PCI resource allocations by the firmware.
>
>>> In any case, I have updated the UEFI firmware we have for ARM Juno to
>>> use EDK2's generic PCI host bridge driver instead of one that was
>>> specially written for ARM Juno, and may deviate in the way it
>>> allocates PCI resources.
>>
>> As long as the kernel is free to reallocate them and that FW quiesces
>> devices at FW->OS handover I see no issues with that.
>>
>
> The reason is to eliminate another unknown from the discussion whether
> UEFI can be expected to leave the entire PCI hierarchy in a sane
> state.
>
>> If we want to try to claim the whole resource tree on boot (in ACPI)
>> I can send a patch for that but there will be regressions.
>>
>
> I would like to see it, yes.

FWIW, the following minimal [naive] patch

diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 4f0e3ebfea4b..37c4d2f116a4 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -27,7 +27,7 @@
  */
 void pcibios_fixup_bus(struct pci_bus *bus)
 {
-       /* nothing to do, expected to be removed in the future */
+       pci_read_bridge_bases(bus);
 }

 /*
@@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
acpi_pci_root *root)
        if (!bus)
                return NULL;

-       pci_bus_size_bridges(bus);
-       pci_bus_assign_resources(bus);
+       pci_assign_unassigned_root_bus_resources(bus);
+       pci_bus_claim_resources(bus);

        list_for_each_entry(child, &bus->children, node)
                pcie_bus_configure_settings(child);

running under QEMU+UEFI with the following PCI topology

-[0000:00]-+-00.0  Red Hat, Inc. Device 0008
           +-01.0-[01]----01.0  Device 1234:1111
           +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
           |            \-03.0  Red Hat, Inc Virtio block device
           \-03.0-[03]----04.0  Red Hat, Inc Virtio network device

results in the log below, preserving the configuration created by UEFI

pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
pci_bus 0000:00: root bus resource [bus 00-0f]
pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
no compatible bridge window
pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:

[...]

> >>> So before starting the next round of hacking to work around this, I
> >>> would like rekindle the discussion regarding the way we blindly
> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
> >>> way imaginable to avoid doing that.
> >>
> >> There is a way if the whole ARM ecosystem work together to sort this
> >> out and we think that's the right way to do; I am personally not
> >> entirely convinced about that.
> >>
> >
> > So what are the pros and cons here? EFI fb is not a hugely important
> > use case, but it is one that relies on BARs staying where they are.
> > Are there others like that?

Not that I am aware of, which means that pros are thin on the ground.

> >>> I suppose the state of the BARs as we inherit it from the firmware
> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> >>> with it). So should there be some side channel (UEFI config table
> >>> perhaps?) to describe this?
> >>
> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> >> Boot Configurations".
> >>
> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
> >> still would not solve the DT firmware case).
> >>
> >
> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> > the pros outweigh the cons.

No one is screaming for that to happen, I can implement resource
claiming but at the moment I do not see the benefit.

[...]

> > The reason is to eliminate another unknown from the discussion whether
> > UEFI can be expected to leave the entire PCI hierarchy in a sane
> > state.
> >
> >> If we want to try to claim the whole resource tree on boot (in ACPI)
> >> I can send a patch for that but there will be regressions.
> >>
> >
> > I would like to see it, yes.
> 
> FWIW, the following minimal [naive] patch
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4f0e3ebfea4b..37c4d2f116a4 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -27,7 +27,7 @@
>   */
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -       /* nothing to do, expected to be removed in the future */
> +       pci_read_bridge_bases(bus);
>  }
> 
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);

I do not understand this code. If you reassign the whole thing
before claiming it I am not sure what's the point of claiming
the resources later, that's basically a nop. pci_bus_claim_resources()
should suffice (if FW set-up is sane - which also reads bridge bases,
BTW).

Lorenzo

>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
> 
> running under QEMU+UEFI with the following PCI topology
> 
> -[0000:00]-+-00.0  Red Hat, Inc. Device 0008
>            +-01.0-[01]----01.0  Device 1234:1111
>            +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
>            |            \-03.0  Red Hat, Inc Virtio block device
>            \-03.0-[03]----04.0  Red Hat, Inc Virtio network device
> 
> results in the log below, preserving the configuration created by UEFI
> 
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-0f]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
> pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
> pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
> pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
> pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
> pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
> pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
> pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
> pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
> pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
> pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
> pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
> pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
> pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
> pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
> pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
> pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
> pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
> pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
> pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
> pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
> pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
> pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
> pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
> pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
> pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
> pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
> pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
> pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
> pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
> pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
> pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
> pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
> pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
> pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
> pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:

[...]

> >>> So before starting the next round of hacking to work around this, I
> >>> would like rekindle the discussion regarding the way we blindly
> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
> >>> way imaginable to avoid doing that.
> >>
> >> There is a way if the whole ARM ecosystem work together to sort this
> >> out and we think that's the right way to do; I am personally not
> >> entirely convinced about that.
> >>
> >
> > So what are the pros and cons here? EFI fb is not a hugely important
> > use case, but it is one that relies on BARs staying where they are.
> > Are there others like that?

Not that I am aware of, which means that pros are thin on the ground.

> >>> I suppose the state of the BARs as we inherit it from the firmware
> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> >>> with it). So should there be some side channel (UEFI config table
> >>> perhaps?) to describe this?
> >>
> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> >> Boot Configurations".
> >>
> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
> >> still would not solve the DT firmware case).
> >>
> >
> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> > the pros outweigh the cons.

No one is screaming for that to happen, I can implement resource
claiming but at the moment I do not see the benefit.

[...]

> > The reason is to eliminate another unknown from the discussion whether
> > UEFI can be expected to leave the entire PCI hierarchy in a sane
> > state.
> >
> >> If we want to try to claim the whole resource tree on boot (in ACPI)
> >> I can send a patch for that but there will be regressions.
> >>
> >
> > I would like to see it, yes.
> 
> FWIW, the following minimal [naive] patch
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4f0e3ebfea4b..37c4d2f116a4 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -27,7 +27,7 @@
>   */
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -       /* nothing to do, expected to be removed in the future */
> +       pci_read_bridge_bases(bus);
>  }
> 
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);

I do not understand this code. If you reassign the whole thing
before claiming it I am not sure what's the point of claiming
the resources later, that's basically a nop. pci_bus_claim_resources()
should suffice (if FW set-up is sane - which also reads bridge bases,
BTW).

Lorenzo

>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
> 
> running under QEMU+UEFI with the following PCI topology
> 
> -[0000:00]-+-00.0  Red Hat, Inc. Device 0008
>            +-01.0-[01]----01.0  Device 1234:1111
>            +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
>            |            \-03.0  Red Hat, Inc Virtio block device
>            \-03.0-[03]----04.0  Red Hat, Inc Virtio network device
> 
> results in the log below, preserving the configuration created by UEFI
> 
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-0f]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
> pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
> pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
> pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
> pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
> pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
> pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
> pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
> pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
> pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
> pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
> pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
> pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
> pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
> pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
> pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
> pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
> pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
> pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
> pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
> pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
> pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
> pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
> pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
> pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
> pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
> pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
> pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
> pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
> pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
> pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
> pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
> pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
> pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
> pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
> pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Lorenzo Pieralisi]

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:

[...]

> >>> So before starting the next round of hacking to work around this, I
> >>> would like rekindle the discussion regarding the way we blindly
> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
> >>> way imaginable to avoid doing that.
> >>
> >> There is a way if the whole ARM ecosystem work together to sort this
> >> out and we think that's the right way to do; I am personally not
> >> entirely convinced about that.
> >>
> >
> > So what are the pros and cons here? EFI fb is not a hugely important
> > use case, but it is one that relies on BARs staying where they are.
> > Are there others like that?

Not that I am aware of, which means that pros are thin on the ground.

> >>> I suppose the state of the BARs as we inherit it from the firmware
> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
> >>> with it). So should there be some side channel (UEFI config table
> >>> perhaps?) to describe this?
> >>
> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
> >> Boot Configurations".
> >>
> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
> >> still would not solve the DT firmware case).
> >>
> >
> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
> > the pros outweigh the cons.

No one is screaming for that to happen, I can implement resource
claiming but at the moment I do not see the benefit.

[...]

> > The reason is to eliminate another unknown from the discussion whether
> > UEFI can be expected to leave the entire PCI hierarchy in a sane
> > state.
> >
> >> If we want to try to claim the whole resource tree on boot (in ACPI)
> >> I can send a patch for that but there will be regressions.
> >>
> >
> > I would like to see it, yes.
> 
> FWIW, the following minimal [naive] patch
> 
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index 4f0e3ebfea4b..37c4d2f116a4 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -27,7 +27,7 @@
>   */
>  void pcibios_fixup_bus(struct pci_bus *bus)
>  {
> -       /* nothing to do, expected to be removed in the future */
> +       pci_read_bridge_bases(bus);
>  }
> 
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);

I do not understand this code. If you reassign the whole thing
before claiming it I am not sure what's the point of claiming
the resources later, that's basically a nop. pci_bus_claim_resources()
should suffice (if FW set-up is sane - which also reads bridge bases,
BTW).

Lorenzo

>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
> 
> running under QEMU+UEFI with the following PCI topology
> 
> -[0000:00]-+-00.0  Red Hat, Inc. Device 0008
>            +-01.0-[01]----01.0  Device 1234:1111
>            +-02.0-[02]--+-02.0  Red Hat, Inc Virtio RNG
>            |            \-03.0  Red Hat, Inc Virtio block device
>            \-03.0-[03]----04.0  Red Hat, Inc Virtio network device
> 
> results in the log below, preserving the configuration created by UEFI
> 
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-0f]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:01.0: reg 0x10: [mem 0x8000202000-0x80002020ff 64bit]
> pci 0000:00:02.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:02.0: reg 0x10: [mem 0x8000201000-0x80002010ff 64bit]
> pci 0000:00:03.0: [1b36:0001] type 01 class 0x060400
> pci 0000:00:03.0: reg 0x10: [mem 0x8000200000-0x80002000ff 64bit]
> pci 0000:01:01.0: [1234:1111] type 00 class 0x030000
> pci 0000:01:01.0: reg 0x10: [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: reg 0x18: [mem 0x11200000-0x11200fff]
> pci 0000:01:01.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
> pci 0000:01:01.0: can't claim BAR 0 [mem 0x10000000-0x10ffffff pref]:
> no compatible bridge window
> pci 0000:01:01.0: BAR 0: failed to claim resource for efifb!
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x11200000-0x112fffff]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x10ffffff 64bit pref]
> pci 0000:02:02.0: [1af4:1005] type 00 class 0x00ff00
> pci 0000:02:02.0: reg 0x10: [io  0x1040-0x105f]
> pci 0000:02:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:02:03.0: [1af4:1001] type 00 class 0x010000
> pci 0000:02:03.0: reg 0x10: [io  0x1000-0x103f]
> pci 0000:02:03.0: reg 0x14: [mem 0x11100000-0x11100fff]
> pci 0000:02:03.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11100000-0x111fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8000000000-0x80000fffff 64bit pref]
> pci 0000:03:04.0: [1af4:1000] type 00 class 0x020000
> pci 0000:03:04.0: reg 0x10: [io  0x0000-0x001f]
> pci 0000:03:04.0: reg 0x14: [mem 0x11000000-0x11000fff]
> pci 0000:03:04.0: reg 0x20: [mem 0x8000100000-0x8000103fff 64bit pref]
> pci 0000:03:04.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x0000-0x0fff]
> pci 0000:00:03.0:   bridge window [mem 0x11000000-0x110fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8000100000-0x80001fffff 64bit pref]
> pci 0000:00:01.0: BAR 14: assigned [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0: BAR 15: assigned [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: BAR 14: assigned [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0: BAR 15: assigned [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: BAR 14: assigned [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0: BAR 15: assigned [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:02.0: BAR 13: assigned [io  0x1000-0x1fff]
> pci 0000:00:03.0: BAR 13: assigned [io  0x2000-0x2fff]
> pci 0000:00:01.0: BAR 0: assigned [mem 0x8001200000-0x80012000ff 64bit]
> pci 0000:00:02.0: BAR 0: assigned [mem 0x8001200100-0x80012001ff 64bit]
> pci 0000:00:03.0: BAR 0: assigned [mem 0x8001200200-0x80012002ff 64bit]
> pci 0000:01:01.0: BAR 0: assigned [mem 0x10000000-0x10ffffff pref]
> pci 0000:01:01.0: BAR 6: assigned [mem 0x11000000-0x1100ffff pref]
> pci 0000:01:01.0: BAR 2: assigned [mem 0x11010000-0x11010fff]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:02:02.0: BAR 4: assigned [mem 0x8001000000-0x8001003fff 64bit pref]
> pci 0000:02:03.0: BAR 4: assigned [mem 0x8001004000-0x8001007fff 64bit pref]
> pci 0000:02:03.0: BAR 1: assigned [mem 0x11800000-0x11800fff]
> pci 0000:02:03.0: BAR 0: assigned [io  0x1000-0x103f]
> pci 0000:02:02.0: BAR 0: assigned [io  0x1040-0x105f]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:03:04.0: BAR 6: assigned [mem 0x11900000-0x1193ffff pref]
> pci 0000:03:04.0: BAR 4: assigned [mem 0x8001100000-0x8001103fff 64bit pref]
> pci 0000:03:04.0: BAR 1: assigned [mem 0x11940000-0x11940fff]
> pci 0000:03:04.0: BAR 0: assigned [io  0x2000-0x201f]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]
> pci_bus 0000:00: resource 4 [mem 0x10000000-0x3efeffff window]
> pci_bus 0000:00: resource 5 [io  0x0000-0xffff window]
> pci_bus 0000:00: resource 6 [mem 0x8000000000-0xffffffffff window]
> pci_bus 0000:01: resource 1 [mem 0x10000000-0x117fffff]
> pci_bus 0000:01: resource 2 [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci_bus 0000:02: resource 0 [io  0x1000-0x1fff]
> pci_bus 0000:02: resource 1 [mem 0x11800000-0x118fffff]
> pci_bus 0000:02: resource 2 [mem 0x8001000000-0x80010fffff 64bit pref]
> pci_bus 0000:03: resource 0 [io  0x2000-0x2fff]
> pci_bus 0000:03: resource 1 [mem 0x11900000-0x119fffff]
> pci_bus 0000:03: resource 2 [mem 0x8001100000-0x80011fffff 64bit pref]
> pci 0000:00:01.0: PCI bridge to [bus 01]
> pci 0000:00:01.0:   bridge window [mem 0x10000000-0x117fffff]
> pci 0000:00:01.0:   bridge window [mem 0x8000000000-0x8000ffffff 64bit pref]
> pci 0000:00:02.0: PCI bridge to [bus 02]
> pci 0000:00:02.0:   bridge window [io  0x1000-0x1fff]
> pci 0000:00:02.0:   bridge window [mem 0x11800000-0x118fffff]
> pci 0000:00:02.0:   bridge window [mem 0x8001000000-0x80010fffff 64bit pref]
> pci 0000:00:03.0: PCI bridge to [bus 03]
> pci 0000:00:03.0:   bridge window [io  0x2000-0x2fff]
> pci 0000:00:03.0:   bridge window [mem 0x11900000-0x119fffff]
> pci 0000:00:03.0:   bridge window [mem 0x8001100000-0x80011fffff 64bit pref]

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 11 April 2017 at 14:16, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> >>> So before starting the next round of hacking to work around this, I
>> >>> would like rekindle the discussion regarding the way we blindly
>> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
>> >>> way imaginable to avoid doing that.
>> >>
>> >> There is a way if the whole ARM ecosystem work together to sort this
>> >> out and we think that's the right way to do; I am personally not
>> >> entirely convinced about that.
>> >>
>> >
>> > So what are the pros and cons here? EFI fb is not a hugely important
>> > use case, but it is one that relies on BARs staying where they are.
>> > Are there others like that?
>
> Not that I am aware of, which means that pros are thin on the ground.
>

OK. Sinan?

>> >>> I suppose the state of the BARs as we inherit it from the firmware
>> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>> >>> with it). So should there be some side channel (UEFI config table
>> >>> perhaps?) to describe this?
>> >>
>> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
>> >> Boot Configurations".
>> >>
>> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
>> >> still would not solve the DT firmware case).
>> >>
>> >
>> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
>> > the pros outweigh the cons.
>
> No one is screaming for that to happen, I can implement resource
> claiming but at the moment I do not see the benefit.
>
> [...]
>
>> > The reason is to eliminate another unknown from the discussion whether
>> > UEFI can be expected to leave the entire PCI hierarchy in a sane
>> > state.
>> >
>> >> If we want to try to claim the whole resource tree on boot (in ACPI)
>> >> I can send a patch for that but there will be regressions.
>> >>
>> >
>> > I would like to see it, yes.
>>
>> FWIW, the following minimal [naive] patch
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 4f0e3ebfea4b..37c4d2f116a4 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -27,7 +27,7 @@
>>   */
>>  void pcibios_fixup_bus(struct pci_bus *bus)
>>  {
>> -       /* nothing to do, expected to be removed in the future */
>> +       pci_read_bridge_bases(bus);
>>  }
>>
>>  /*
>> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
>> acpi_pci_root *root)
>>         if (!bus)
>>                 return NULL;
>>
>> -       pci_bus_size_bridges(bus);
>> -       pci_bus_assign_resources(bus);
>> +       pci_assign_unassigned_root_bus_resources(bus);
>> +       pci_bus_claim_resources(bus);
>
> I do not understand this code. If you reassign the whole thing
> before claiming it I am not sure what's the point of claiming
> the resources later, that's basically a nop. pci_bus_claim_resources()
> should suffice (if FW set-up is sane - which also reads bridge bases,
> BTW).
>

OK, I'm struggling a bit with this code. As you know, it is not light
bedtime reading :-)

In any case, I am starting to see your point. While I am able to claim
most of the configuration by calling pci_bus_claim_resources() only
[modulo some I/O BARs for which I will send out a bugfix shortly], the
option ROM BARs are left disabled by UEFI, and so I end up with

pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:02:01.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:03:01.0: can't claim BAR 6 [mem 0xfffc0000-0xffffffff pref]:
no compatible bridge window

and everything else works fine.

Both PPC and x86 have similar code to infer from the BARs themselves
whether they were programmed, but in our case, it comes down to
checking whether a parent resource exists that covers the range.

It may still make sense to add support for the _DSM method, and leave
it to the firmware to tell the kernel whether the PCI configuration is
supposed to be correct, so I will send out an RFC for that as well.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 11 April 2017 at 14:16, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> >>> So before starting the next round of hacking to work around this, I
>> >>> would like rekindle the discussion regarding the way we blindly
>> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
>> >>> way imaginable to avoid doing that.
>> >>
>> >> There is a way if the whole ARM ecosystem work together to sort this
>> >> out and we think that's the right way to do; I am personally not
>> >> entirely convinced about that.
>> >>
>> >
>> > So what are the pros and cons here? EFI fb is not a hugely important
>> > use case, but it is one that relies on BARs staying where they are.
>> > Are there others like that?
>
> Not that I am aware of, which means that pros are thin on the ground.
>

OK. Sinan?

>> >>> I suppose the state of the BARs as we inherit it from the firmware
>> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>> >>> with it). So should there be some side channel (UEFI config table
>> >>> perhaps?) to describe this?
>> >>
>> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
>> >> Boot Configurations".
>> >>
>> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
>> >> still would not solve the DT firmware case).
>> >>
>> >
>> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
>> > the pros outweigh the cons.
>
> No one is screaming for that to happen, I can implement resource
> claiming but at the moment I do not see the benefit.
>
> [...]
>
>> > The reason is to eliminate another unknown from the discussion whether
>> > UEFI can be expected to leave the entire PCI hierarchy in a sane
>> > state.
>> >
>> >> If we want to try to claim the whole resource tree on boot (in ACPI)
>> >> I can send a patch for that but there will be regressions.
>> >>
>> >
>> > I would like to see it, yes.
>>
>> FWIW, the following minimal [naive] patch
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 4f0e3ebfea4b..37c4d2f116a4 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -27,7 +27,7 @@
>>   */
>>  void pcibios_fixup_bus(struct pci_bus *bus)
>>  {
>> -       /* nothing to do, expected to be removed in the future */
>> +       pci_read_bridge_bases(bus);
>>  }
>>
>>  /*
>> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
>> acpi_pci_root *root)
>>         if (!bus)
>>                 return NULL;
>>
>> -       pci_bus_size_bridges(bus);
>> -       pci_bus_assign_resources(bus);
>> +       pci_assign_unassigned_root_bus_resources(bus);
>> +       pci_bus_claim_resources(bus);
>
> I do not understand this code. If you reassign the whole thing
> before claiming it I am not sure what's the point of claiming
> the resources later, that's basically a nop. pci_bus_claim_resources()
> should suffice (if FW set-up is sane - which also reads bridge bases,
> BTW).
>

OK, I'm struggling a bit with this code. As you know, it is not light
bedtime reading :-)

In any case, I am starting to see your point. While I am able to claim
most of the configuration by calling pci_bus_claim_resources() only
[modulo some I/O BARs for which I will send out a bugfix shortly], the
option ROM BARs are left disabled by UEFI, and so I end up with

pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:02:01.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:03:01.0: can't claim BAR 6 [mem 0xfffc0000-0xffffffff pref]:
no compatible bridge window

and everything else works fine.

Both PPC and x86 have similar code to infer from the BARs themselves
whether they were programmed, but in our case, it comes down to
checking whether a parent resource exists that covers the range.

It may still make sense to add support for the _DSM method, and leave
it to the firmware to tell the kernel whether the PCI configuration is
supposed to be correct, so I will send out an RFC for that as well.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 11 April 2017 at 14:16, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
> On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>
> [...]
>
>> >>> So before starting the next round of hacking to work around this, I
>> >>> would like rekindle the discussion regarding the way we blindly
>> >>> reassign all resources on ACPI/arm64 systems, and whether there is a
>> >>> way imaginable to avoid doing that.
>> >>
>> >> There is a way if the whole ARM ecosystem work together to sort this
>> >> out and we think that's the right way to do; I am personally not
>> >> entirely convinced about that.
>> >>
>> >
>> > So what are the pros and cons here? EFI fb is not a hugely important
>> > use case, but it is one that relies on BARs staying where they are.
>> > Are there others like that?
>
> Not that I am aware of, which means that pros are thin on the ground.
>

OK. Sinan?

>> >>> I suppose the state of the BARs as we inherit it from the firmware
>> >>> cannot be blindly trusted (and IIUC, this is Lorenzo's primary issue
>> >>> with it). So should there be some side channel (UEFI config table
>> >>> perhaps?) to describe this?
>> >>
>> >> PCI firmware specifications rev 3.1, 4.6.5, "_DSM for Ignoring PCI
>> >> Boot Configurations".
>> >>
>> >> Do we want to enforce it on ARM ? I do not know to be honest (and it
>> >> still would not solve the DT firmware case).
>> >>
>> >
>> > No, it doesn't. But that doesn't mean we shouldn't solve it on ACPI if
>> > the pros outweigh the cons.
>
> No one is screaming for that to happen, I can implement resource
> claiming but at the moment I do not see the benefit.
>
> [...]
>
>> > The reason is to eliminate another unknown from the discussion whether
>> > UEFI can be expected to leave the entire PCI hierarchy in a sane
>> > state.
>> >
>> >> If we want to try to claim the whole resource tree on boot (in ACPI)
>> >> I can send a patch for that but there will be regressions.
>> >>
>> >
>> > I would like to see it, yes.
>>
>> FWIW, the following minimal [naive] patch
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index 4f0e3ebfea4b..37c4d2f116a4 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -27,7 +27,7 @@
>>   */
>>  void pcibios_fixup_bus(struct pci_bus *bus)
>>  {
>> -       /* nothing to do, expected to be removed in the future */
>> +       pci_read_bridge_bases(bus);
>>  }
>>
>>  /*
>> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
>> acpi_pci_root *root)
>>         if (!bus)
>>                 return NULL;
>>
>> -       pci_bus_size_bridges(bus);
>> -       pci_bus_assign_resources(bus);
>> +       pci_assign_unassigned_root_bus_resources(bus);
>> +       pci_bus_claim_resources(bus);
>
> I do not understand this code. If you reassign the whole thing
> before claiming it I am not sure what's the point of claiming
> the resources later, that's basically a nop. pci_bus_claim_resources()
> should suffice (if FW set-up is sane - which also reads bridge bases,
> BTW).
>

OK, I'm struggling a bit with this code. As you know, it is not light
bedtime reading :-)

In any case, I am starting to see your point. While I am able to claim
most of the configuration by calling pci_bus_claim_resources() only
[modulo some I/O BARs for which I will send out a bugfix shortly], the
option ROM BARs are left disabled by UEFI, and so I end up with

pci 0000:00:01.0: PCI bridge to [bus 01]
pci 0000:00:02.0: PCI bridge to [bus 02]
pci 0000:00:03.0: PCI bridge to [bus 03]
pci 0000:02:01.0: can't claim BAR 6 [mem 0xffff0000-0xffffffff pref]:
no compatible bridge window
pci 0000:03:01.0: can't claim BAR 6 [mem 0xfffc0000-0xffffffff pref]:
no compatible bridge window

and everything else works fine.

Both PPC and x86 have similar code to infer from the BARs themselves
whether they were programmed, but in our case, it comes down to
checking whether a parent resource exists that covers the range.

It may still make sense to add support for the _DSM method, and leave
it to the firmware to tell the kernel whether the PCI configuration is
supposed to be correct, so I will send out an RFC for that as well.

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Yinghai Lu]

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);
> 
>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
>

looks like those two lines are reversed. you should use:
                pcibios_resource_survey_bus(bus);
                pci_assign_unassigned_root_bus_resources(bus);

please check x86 pcibios_resource_survey_bus() definition in
	arch/x86/pci/i386.c

but pci_bus_claim_resources() should work too.

Yinghai

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Yinghai Lu]

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);
> 
>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
>

looks like those two lines are reversed. you should use:
                pcibios_resource_survey_bus(bus);
                pci_assign_unassigned_root_bus_resources(bus);

please check x86 pcibios_resource_survey_bus() definition in
	arch/x86/pci/i386.c

but pci_bus_claim_resources() should work too.

Yinghai

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Yinghai Lu]

On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>  /*
> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
> acpi_pci_root *root)
>         if (!bus)
>                 return NULL;
> 
> -       pci_bus_size_bridges(bus);
> -       pci_bus_assign_resources(bus);
> +       pci_assign_unassigned_root_bus_resources(bus);
> +       pci_bus_claim_resources(bus);
> 
>         list_for_each_entry(child, &bus->children, node)
>                 pcie_bus_configure_settings(child);
>

looks like those two lines are reversed. you should use:
                pcibios_resource_survey_bus(bus);
                pci_assign_unassigned_root_bus_resources(bus);

please check x86 pcibios_resource_survey_bus() definition in
	arch/x86/pci/i386.c

but pci_bus_claim_resources() should work too.

Yinghai

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 April 2017 at 02:45, Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>>  /*
>> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
>> acpi_pci_root *root)
>>         if (!bus)
>>                 return NULL;
>>
>> -       pci_bus_size_bridges(bus);
>> -       pci_bus_assign_resources(bus);
>> +       pci_assign_unassigned_root_bus_resources(bus);
>> +       pci_bus_claim_resources(bus);
>>
>>         list_for_each_entry(child, &bus->children, node)
>>                 pcie_bus_configure_settings(child);
>>
>
> looks like those two lines are reversed. you should use:
>                 pcibios_resource_survey_bus(bus);
>                 pci_assign_unassigned_root_bus_resources(bus);
>
> please check x86 pcibios_resource_survey_bus() definition in
>         arch/x86/pci/i386.c
>
> but pci_bus_claim_resources() should work too.
>

Thanks Yinghai

pcibios_resource_survey_bus() is actually an empty function on arm64,
but I guess that is where logic should go that checks the state of the
BARs before trying to claim anything?

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 April 2017 at 02:45, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>>  /*
>> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
>> acpi_pci_root *root)
>>         if (!bus)
>>                 return NULL;
>>
>> -       pci_bus_size_bridges(bus);
>> -       pci_bus_assign_resources(bus);
>> +       pci_assign_unassigned_root_bus_resources(bus);
>> +       pci_bus_claim_resources(bus);
>>
>>         list_for_each_entry(child, &bus->children, node)
>>                 pcie_bus_configure_settings(child);
>>
>
> looks like those two lines are reversed. you should use:
>                 pcibios_resource_survey_bus(bus);
>                 pci_assign_unassigned_root_bus_resources(bus);
>
> please check x86 pcibios_resource_survey_bus() definition in
>         arch/x86/pci/i386.c
>
> but pci_bus_claim_resources() should work too.
>

Thanks Yinghai

pcibios_resource_survey_bus() is actually an empty function on arm64,
but I guess that is where logic should go that checks the state of the
BARs before trying to claim anything?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Ard Biesheuvel]

On 23 April 2017 at 02:45, Yinghai Lu <yinghai@kernel.org> wrote:
> On Mon, Apr 10, 2017 at 06:29:27PM +0100, Ard Biesheuvel wrote:
>>  /*
>> @@ -208,8 +208,8 @@ struct pci_bus *pci_acpi_scan_root(struct
>> acpi_pci_root *root)
>>         if (!bus)
>>                 return NULL;
>>
>> -       pci_bus_size_bridges(bus);
>> -       pci_bus_assign_resources(bus);
>> +       pci_assign_unassigned_root_bus_resources(bus);
>> +       pci_bus_claim_resources(bus);
>>
>>         list_for_each_entry(child, &bus->children, node)
>>                 pcie_bus_configure_settings(child);
>>
>
> looks like those two lines are reversed. you should use:
>                 pcibios_resource_survey_bus(bus);
>                 pci_assign_unassigned_root_bus_resources(bus);
>
> please check x86 pcibios_resource_survey_bus() definition in
>         arch/x86/pci/i386.c
>
> but pci_bus_claim_resources() should work too.
>

Thanks Yinghai

pcibios_resource_survey_bus() is actually an empty function on arm64,
but I guess that is where logic should go that checks the state of the
BARs before trying to claim anything?

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Yinghai Lu]

On Thu, Apr 27, 2017 at 6:55 AM, Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On 23 April 2017 at 02:45, Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:

>>
>> looks like those two lines are reversed. you should use:
>>                 pcibios_resource_survey_bus(bus);
>>                 pci_assign_unassigned_root_bus_resources(bus);
>>
>> please check x86 pcibios_resource_survey_bus() definition in
>>         arch/x86/pci/i386.c
>>
>> but pci_bus_claim_resources() should work too.
>>
>
> pcibios_resource_survey_bus() is actually an empty function on arm64,
> but I guess that is where logic should go that checks the state of the
> BARs before trying to claim anything?

Yes. Please copy for x86 and simplify it for arm64.

Yinghai

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Yinghai Lu]

On Thu, Apr 27, 2017 at 6:55 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 23 April 2017 at 02:45, Yinghai Lu <yinghai@kernel.org> wrote:

>>
>> looks like those two lines are reversed. you should use:
>>                 pcibios_resource_survey_bus(bus);
>>                 pci_assign_unassigned_root_bus_resources(bus);
>>
>> please check x86 pcibios_resource_survey_bus() definition in
>>         arch/x86/pci/i386.c
>>
>> but pci_bus_claim_resources() should work too.
>>
>
> pcibios_resource_survey_bus() is actually an empty function on arm64,
> but I guess that is where logic should go that checks the state of the
> BARs before trying to claim anything?

Yes. Please copy for x86 and simplify it for arm64.

Yinghai

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Yinghai Lu]

On Thu, Apr 27, 2017 at 6:55 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 23 April 2017 at 02:45, Yinghai Lu <yinghai@kernel.org> wrote:

>>
>> looks like those two lines are reversed. you should use:
>>                 pcibios_resource_survey_bus(bus);
>>                 pci_assign_unassigned_root_bus_resources(bus);
>>
>> please check x86 pcibios_resource_survey_bus() definition in
>>         arch/x86/pci/i386.c
>>
>> but pci_bus_claim_resources() should work too.
>>
>
> pcibios_resource_survey_bus() is actually an empty function on arm64,
> but I guess that is where logic should go that checks the state of the
> BARs before trying to claim anything?

Yes. Please copy for x86 and simplify it for arm64.

Yinghai

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Heyi Guo]

Hi Ard,

I have one comment inclined.


在 3/22/2017 11:30 PM, Ard Biesheuvel 写道:
> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> and if a graphical framebuffer is exposed by a PCI device, its base
> address and size are exposed to the OS via the Graphics Output
> Protocol (GOP).
>
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified. This
> will cause the framebuffer to become unresponsive, and may in some
> cases result in unpredictable behavior if the range is reassigned to
> another device.
>
> So add a quirk to the EFI fb driver to find the BAR associated with
> the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
> that the PCI core will leave it alone.
>
> Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
> Cc: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> v3: check device is enabled before attempting to claim the resource
>
>   drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
>   1 file changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 8c4dc1e1f94f..88f653864a01 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -10,6 +10,7 @@
>   #include <linux/efi.h>
>   #include <linux/errno.h>
>   #include <linux/fb.h>
> +#include <linux/pci.h>
>   #include <linux/platform_device.h>
>   #include <linux/screen_info.h>
>   #include <video/vga.h>
> @@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
>   };
>   ATTRIBUTE_GROUPS(efifb);
>   
> +static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
> +static bool pci_dev_disabled;	/* was the device disabled? */
> +
>   static int efifb_probe(struct platform_device *dev)
>   {
>   	struct fb_info *info;
> @@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
>   	unsigned int size_total;
>   	char *option = NULL;
>   
> -	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> +	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
>   		return -ENODEV;
>   
>   	if (fb_get_options("efifb", &option))
> @@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
>   };
>   
>   builtin_platform_driver(efifb_driver);
> +
> +static void claim_efifb_bar(struct pci_dev *dev, int idx)
> +{
> +	u16 word;
> +
> +	pci_bar_found = true;
> +
> +	pci_read_config_word(dev, PCI_COMMAND, &word);
> +	if (!(word & PCI_COMMAND_MEMORY)) {
> +		pci_dev_disabled = true;
> +		dev_err(&dev->dev,
> +			"BAR %d: assigned to efifb but device is disabled!\n",
> +			idx);
> +		return;
> +	}
> +
> +	if (pci_claim_resource(dev, idx)) {
> +		pci_dev_disabled = true;
> +		dev_err(&dev->dev,
> +			"BAR %d: failed to claim resource for efifb!\n", idx);
> +		return;
> +	}
> +
> +	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
> +}
> +
> +static void efifb_fixup_resources(struct pci_dev *dev)
> +{
> +	u64 base = screen_info.lfb_base;
> +	u64 size = screen_info.lfb_size;
> +	int i;
> +
> +	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> +		return;
> +
> +	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> +		base |= (u64)screen_info.ext_lfb_base << 32;
> +
> +	if (!base)
> +		return;
> +
> +	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
> +		struct resource *res = &dev->resource[i];
> +
> +		if (!(res->flags & IORESOURCE_MEM))
> +			continue;
> +
> +		if (res->start <= base && res->end >= base + size - 1) {
Have we considered PCI address translation here? I suppose the address 
reported by EFI GOP should be the address of CPU domain, not address of 
PCI domain. Address read from PCI BAR is PCI address which should add 
translation offset before being compared to CPU domain address.

I've not familiar with Linux code, so please ignore my comment if the 
code has supported address translation.

Regards,

Gary (Heyi Guo)

> +			claim_efifb_bar(dev, i);
> +			break;
> +		}
> +	}
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Heyi Guo]

SGkgQXJkLAoKSSBoYXZlIG9uZSBjb21tZW50IGluY2xpbmVkLgoKCtTaIDMvMjIvMjAxNyAxMToz
MCBQTSwgQXJkIEJpZXNoZXV2ZWwg0LS1wDoKPiBPbiBVRUZJIHN5c3RlbXMsIHRoZSBQQ0kgc3Vi
c3lzdGVtIGlzIGVudW1lcmF0ZWQgYnkgdGhlIGZpcm13YXJlLAo+IGFuZCBpZiBhIGdyYXBoaWNh
bCBmcmFtZWJ1ZmZlciBpcyBleHBvc2VkIGJ5IGEgUENJIGRldmljZSwgaXRzIGJhc2UKPiBhZGRy
ZXNzIGFuZCBzaXplIGFyZSBleHBvc2VkIHRvIHRoZSBPUyB2aWEgdGhlIEdyYXBoaWNzIE91dHB1
dAo+IFByb3RvY29sIChHT1ApLgo+Cj4gT24gYXJtNjQgUENJIHN5c3RlbXMsIHRoZSBlbnRpcmUg
UENJIGhpZXJhcmNoeSBpcyByZWNvbmZpZ3VyZWQgZnJvbQo+IHNjcmF0Y2ggYXQgYm9vdC4gVGhp
cyBtYXkgcmVzdWx0IGluIHRoZSBHT1AgZnJhbWVidWZmZXIgYWRkcmVzcyB0bwo+IGJlY29tZSBz
dGFsZSwgaWYgdGhlIEJBUiBjb3ZlcmluZyB0aGUgZnJhbWVidWZmZXIgaXMgbW9kaWZpZWQuIFRo
aXMKPiB3aWxsIGNhdXNlIHRoZSBmcmFtZWJ1ZmZlciB0byBiZWNvbWUgdW5yZXNwb25zaXZlLCBh
bmQgbWF5IGluIHNvbWUKPiBjYXNlcyByZXN1bHQgaW4gdW5wcmVkaWN0YWJsZSBiZWhhdmlvciBp
ZiB0aGUgcmFuZ2UgaXMgcmVhc3NpZ25lZCB0bwo+IGFub3RoZXIgZGV2aWNlLgo+Cj4gU28gYWRk
IGEgcXVpcmsgdG8gdGhlIEVGSSBmYiBkcml2ZXIgdG8gZmluZCB0aGUgQkFSIGFzc29jaWF0ZWQg
d2l0aAo+IHRoZSBHT1AgYmFzZSBhZGRyZXNzLCBhbmQgc2V0IHRoZSBJT1JFU09VUkNFX1BDSV9G
SVhFRCBhdHRyaWJ1dGUgc28KPiB0aGF0IHRoZSBQQ0kgY29yZSB3aWxsIGxlYXZlIGl0IGFsb25l
Lgo+Cj4gQ2M6IE1hdHQgRmxlbWluZyA8bWF0dEBjb2RlYmx1ZXByaW50LmNvLnVrPgo+IENjOiBQ
ZXRlciBKb25lcyA8cGpvbmVzQHJlZGhhdC5jb20+Cj4gU2lnbmVkLW9mZi1ieTogQXJkIEJpZXNo
ZXV2ZWwgPGFyZC5iaWVzaGV1dmVsQGxpbmFyby5vcmc+Cj4gLS0tCj4gdjM6IGNoZWNrIGRldmlj
ZSBpcyBlbmFibGVkIGJlZm9yZSBhdHRlbXB0aW5nIHRvIGNsYWltIHRoZSByZXNvdXJjZQo+Cj4g
ICBkcml2ZXJzL3ZpZGVvL2ZiZGV2L2VmaWZiLmMgfCA2MCArKysrKysrKysrKysrKysrKysrLQo+
ICAgMSBmaWxlIGNoYW5nZWQsIDU5IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKPgo+IGRp
ZmYgLS1naXQgYS9kcml2ZXJzL3ZpZGVvL2ZiZGV2L2VmaWZiLmMgYi9kcml2ZXJzL3ZpZGVvL2Zi
ZGV2L2VmaWZiLmMKPiBpbmRleCA4YzRkYzFlMWY5NGYuLjg4ZjY1Mzg2NGEwMSAxMDA2NDQKPiAt
LS0gYS9kcml2ZXJzL3ZpZGVvL2ZiZGV2L2VmaWZiLmMKPiArKysgYi9kcml2ZXJzL3ZpZGVvL2Zi
ZGV2L2VmaWZiLmMKPiBAQCAtMTAsNiArMTAsNyBAQAo+ICAgI2luY2x1ZGUgPGxpbnV4L2VmaS5o
Pgo+ICAgI2luY2x1ZGUgPGxpbnV4L2Vycm5vLmg+Cj4gICAjaW5jbHVkZSA8bGludXgvZmIuaD4K
PiArI2luY2x1ZGUgPGxpbnV4L3BjaS5oPgo+ICAgI2luY2x1ZGUgPGxpbnV4L3BsYXRmb3JtX2Rl
dmljZS5oPgo+ICAgI2luY2x1ZGUgPGxpbnV4L3NjcmVlbl9pbmZvLmg+Cj4gICAjaW5jbHVkZSA8
dmlkZW8vdmdhLmg+Cj4gQEAgLTE0Myw2ICsxNDQsOSBAQCBzdGF0aWMgc3RydWN0IGF0dHJpYnV0
ZSAqZWZpZmJfYXR0cnNbXSA9IHsKPiAgIH07Cj4gICBBVFRSSUJVVEVfR1JPVVBTKGVmaWZiKTsK
PiAgIAo+ICtzdGF0aWMgYm9vbCBwY2lfYmFyX2ZvdW5kOwkvKiBkaWQgd2UgZmluZCBhIEJBUiBt
YXRjaGluZyB0aGUgZWZpZmIgYmFzZT8gKi8KPiArc3RhdGljIGJvb2wgcGNpX2Rldl9kaXNhYmxl
ZDsJLyogd2FzIHRoZSBkZXZpY2UgZGlzYWJsZWQ/ICovCj4gKwo+ICAgc3RhdGljIGludCBlZmlm
Yl9wcm9iZShzdHJ1Y3QgcGxhdGZvcm1fZGV2aWNlICpkZXYpCj4gICB7Cj4gICAJc3RydWN0IGZi
X2luZm8gKmluZm87Cj4gQEAgLTE1Miw3ICsxNTYsNyBAQCBzdGF0aWMgaW50IGVmaWZiX3Byb2Jl
KHN0cnVjdCBwbGF0Zm9ybV9kZXZpY2UgKmRldikKPiAgIAl1bnNpZ25lZCBpbnQgc2l6ZV90b3Rh
bDsKPiAgIAljaGFyICpvcHRpb24gPSBOVUxMOwo+ICAgCj4gLQlpZiAoc2NyZWVuX2luZm8ub3Jp
Z192aWRlb19pc1ZHQSAhPSBWSURFT19UWVBFX0VGSSkKPiArCWlmIChzY3JlZW5faW5mby5vcmln
X3ZpZGVvX2lzVkdBICE9IFZJREVPX1RZUEVfRUZJIHx8IHBjaV9kZXZfZGlzYWJsZWQpCj4gICAJ
CXJldHVybiAtRU5PREVWOwo+ICAgCj4gICAJaWYgKGZiX2dldF9vcHRpb25zKCJlZmlmYiIsICZv
cHRpb24pKQo+IEBAIC0zNjAsMyArMzY0LDU3IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJp
dmVyIGVmaWZiX2RyaXZlciA9IHsKPiAgIH07Cj4gICAKPiAgIGJ1aWx0aW5fcGxhdGZvcm1fZHJp
dmVyKGVmaWZiX2RyaXZlcik7Cj4gKwo+ICtzdGF0aWMgdm9pZCBjbGFpbV9lZmlmYl9iYXIoc3Ry
dWN0IHBjaV9kZXYgKmRldiwgaW50IGlkeCkKPiArewo+ICsJdTE2IHdvcmQ7Cj4gKwo+ICsJcGNp
X2Jhcl9mb3VuZCA9IHRydWU7Cj4gKwo+ICsJcGNpX3JlYWRfY29uZmlnX3dvcmQoZGV2LCBQQ0lf
Q09NTUFORCwgJndvcmQpOwo+ICsJaWYgKCEod29yZCAmIFBDSV9DT01NQU5EX01FTU9SWSkpIHsK
PiArCQlwY2lfZGV2X2Rpc2FibGVkID0gdHJ1ZTsKPiArCQlkZXZfZXJyKCZkZXYtPmRldiwKPiAr
CQkJIkJBUiAlZDogYXNzaWduZWQgdG8gZWZpZmIgYnV0IGRldmljZSBpcyBkaXNhYmxlZCFcbiIs
Cj4gKwkJCWlkeCk7Cj4gKwkJcmV0dXJuOwo+ICsJfQo+ICsKPiArCWlmIChwY2lfY2xhaW1fcmVz
b3VyY2UoZGV2LCBpZHgpKSB7Cj4gKwkJcGNpX2Rldl9kaXNhYmxlZCA9IHRydWU7Cj4gKwkJZGV2
X2VycigmZGV2LT5kZXYsCj4gKwkJCSJCQVIgJWQ6IGZhaWxlZCB0byBjbGFpbSByZXNvdXJjZSBm
b3IgZWZpZmIhXG4iLCBpZHgpOwo+ICsJCXJldHVybjsKPiArCX0KPiArCj4gKwlkZXZfaW5mbygm
ZGV2LT5kZXYsICJCQVIgJWQ6IGFzc2lnbmVkIHRvIGVmaWZiXG4iLCBpZHgpOwo+ICt9Cj4gKwo+
ICtzdGF0aWMgdm9pZCBlZmlmYl9maXh1cF9yZXNvdXJjZXMoc3RydWN0IHBjaV9kZXYgKmRldikK
PiArewo+ICsJdTY0IGJhc2UgPSBzY3JlZW5faW5mby5sZmJfYmFzZTsKPiArCXU2NCBzaXplID0g
c2NyZWVuX2luZm8ubGZiX3NpemU7Cj4gKwlpbnQgaTsKPiArCj4gKwlpZiAocGNpX2Jhcl9mb3Vu
ZCB8fCBzY3JlZW5faW5mby5vcmlnX3ZpZGVvX2lzVkdBICE9IFZJREVPX1RZUEVfRUZJKQo+ICsJ
CXJldHVybjsKPiArCj4gKwlpZiAoc2NyZWVuX2luZm8uY2FwYWJpbGl0aWVzICYgVklERU9fQ0FQ
QUJJTElUWV82NEJJVF9CQVNFKQo+ICsJCWJhc2UgfD0gKHU2NClzY3JlZW5faW5mby5leHRfbGZi
X2Jhc2UgPDwgMzI7Cj4gKwo+ICsJaWYgKCFiYXNlKQo+ICsJCXJldHVybjsKPiArCj4gKwlmb3Ig
KGkgPSAwOyBpIDwgUENJX1NURF9SRVNPVVJDRV9FTkQ7IGkrKykgewo+ICsJCXN0cnVjdCByZXNv
dXJjZSAqcmVzID0gJmRldi0+cmVzb3VyY2VbaV07Cj4gKwo+ICsJCWlmICghKHJlcy0+ZmxhZ3Mg
JiBJT1JFU09VUkNFX01FTSkpCj4gKwkJCWNvbnRpbnVlOwo+ICsKPiArCQlpZiAocmVzLT5zdGFy
dCA8PSBiYXNlICYmIHJlcy0+ZW5kID49IGJhc2UgKyBzaXplIC0gMSkgewpIYXZlIHdlIGNvbnNp
ZGVyZWQgUENJIGFkZHJlc3MgdHJhbnNsYXRpb24gaGVyZT8gSSBzdXBwb3NlIHRoZSBhZGRyZXNz
IApyZXBvcnRlZCBieSBFRkkgR09QIHNob3VsZCBiZSB0aGUgYWRkcmVzcyBvZiBDUFUgZG9tYWlu
LCBub3QgYWRkcmVzcyBvZiAKUENJIGRvbWFpbi4gQWRkcmVzcyByZWFkIGZyb20gUENJIEJBUiBp
cyBQQ0kgYWRkcmVzcyB3aGljaCBzaG91bGQgYWRkIAp0cmFuc2xhdGlvbiBvZmZzZXQgYmVmb3Jl
IGJlaW5nIGNvbXBhcmVkIHRvIENQVSBkb21haW4gYWRkcmVzcy4KCkkndmUgbm90IGZhbWlsaWFy
IHdpdGggTGludXggY29kZSwgc28gcGxlYXNlIGlnbm9yZSBteSBjb21tZW50IGlmIHRoZSAKY29k
ZSBoYXMgc3VwcG9ydGVkIGFkZHJlc3MgdHJhbnNsYXRpb24uCgpSZWdhcmRzLAoKR2FyeSAoSGV5
aSBHdW8pCgo+ICsJCQljbGFpbV9lZmlmYl9iYXIoZGV2LCBpKTsKPiArCQkJYnJlYWs7Cj4gKwkJ
fQo+ICsJfQo+ICt9Cj4gK0RFQ0xBUkVfUENJX0ZJWFVQX0hFQURFUihQQ0lfQU5ZX0lELCBQQ0lf
QU5ZX0lELCBlZmlmYl9maXh1cF9yZXNvdXJjZXMpOwoKCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0Cmxp
bnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Heyi Guo]

Hi Ard,

I have one comment inclined.


? 3/22/2017 11:30 PM, Ard Biesheuvel ??:
> On UEFI systems, the PCI subsystem is enumerated by the firmware,
> and if a graphical framebuffer is exposed by a PCI device, its base
> address and size are exposed to the OS via the Graphics Output
> Protocol (GOP).
>
> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> scratch at boot. This may result in the GOP framebuffer address to
> become stale, if the BAR covering the framebuffer is modified. This
> will cause the framebuffer to become unresponsive, and may in some
> cases result in unpredictable behavior if the range is reassigned to
> another device.
>
> So add a quirk to the EFI fb driver to find the BAR associated with
> the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
> that the PCI core will leave it alone.
>
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Cc: Peter Jones <pjones@redhat.com>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> v3: check device is enabled before attempting to claim the resource
>
>   drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
>   1 file changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 8c4dc1e1f94f..88f653864a01 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -10,6 +10,7 @@
>   #include <linux/efi.h>
>   #include <linux/errno.h>
>   #include <linux/fb.h>
> +#include <linux/pci.h>
>   #include <linux/platform_device.h>
>   #include <linux/screen_info.h>
>   #include <video/vga.h>
> @@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
>   };
>   ATTRIBUTE_GROUPS(efifb);
>   
> +static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
> +static bool pci_dev_disabled;	/* was the device disabled? */
> +
>   static int efifb_probe(struct platform_device *dev)
>   {
>   	struct fb_info *info;
> @@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
>   	unsigned int size_total;
>   	char *option = NULL;
>   
> -	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> +	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
>   		return -ENODEV;
>   
>   	if (fb_get_options("efifb", &option))
> @@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
>   };
>   
>   builtin_platform_driver(efifb_driver);
> +
> +static void claim_efifb_bar(struct pci_dev *dev, int idx)
> +{
> +	u16 word;
> +
> +	pci_bar_found = true;
> +
> +	pci_read_config_word(dev, PCI_COMMAND, &word);
> +	if (!(word & PCI_COMMAND_MEMORY)) {
> +		pci_dev_disabled = true;
> +		dev_err(&dev->dev,
> +			"BAR %d: assigned to efifb but device is disabled!\n",
> +			idx);
> +		return;
> +	}
> +
> +	if (pci_claim_resource(dev, idx)) {
> +		pci_dev_disabled = true;
> +		dev_err(&dev->dev,
> +			"BAR %d: failed to claim resource for efifb!\n", idx);
> +		return;
> +	}
> +
> +	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
> +}
> +
> +static void efifb_fixup_resources(struct pci_dev *dev)
> +{
> +	u64 base = screen_info.lfb_base;
> +	u64 size = screen_info.lfb_size;
> +	int i;
> +
> +	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> +		return;
> +
> +	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> +		base |= (u64)screen_info.ext_lfb_base << 32;
> +
> +	if (!base)
> +		return;
> +
> +	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
> +		struct resource *res = &dev->resource[i];
> +
> +		if (!(res->flags & IORESOURCE_MEM))
> +			continue;
> +
> +		if (res->start <= base && res->end >= base + size - 1) {
Have we considered PCI address translation here? I suppose the address 
reported by EFI GOP should be the address of CPU domain, not address of 
PCI domain. Address read from PCI BAR is PCI address which should add 
translation offset before being compared to CPU domain address.

I've not familiar with Linux code, so please ignore my comment if the 
code has supported address translation.

Regards,

Gary (Heyi Guo)

> +			claim_efifb_bar(dev, i);
> +			break;
> +		}
> +	}
> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_ANY_ID, PCI_ANY_ID, efifb_fixup_resources);

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Bjorn Helgaas]

Hi Gary,

Thanks for the question.

On Wed, May 03, 2017 at 11:09:51AM +0800, Heyi Guo wrote:
> Hi Ard,
> 
> I have one comment inclined.
> 
> 
> 在 3/22/2017 11:30 PM, Ard Biesheuvel 写道:
> >On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >and if a graphical framebuffer is exposed by a PCI device, its base
> >address and size are exposed to the OS via the Graphics Output
> >Protocol (GOP).
> >
> >On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >scratch at boot. This may result in the GOP framebuffer address to
> >become stale, if the BAR covering the framebuffer is modified. This
> >will cause the framebuffer to become unresponsive, and may in some
> >cases result in unpredictable behavior if the range is reassigned to
> >another device.
> >
> >So add a quirk to the EFI fb driver to find the BAR associated with
> >the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
> >that the PCI core will leave it alone.
> >
> >Cc: Matt Fleming <matt@codeblueprint.co.uk>
> >Cc: Peter Jones <pjones@redhat.com>
> >Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >---
> >v3: check device is enabled before attempting to claim the resource
> >
> >  drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
> >  1 file changed, 59 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> >index 8c4dc1e1f94f..88f653864a01 100644
> >--- a/drivers/video/fbdev/efifb.c
> >+++ b/drivers/video/fbdev/efifb.c
> >@@ -10,6 +10,7 @@
> >  #include <linux/efi.h>
> >  #include <linux/errno.h>
> >  #include <linux/fb.h>
> >+#include <linux/pci.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/screen_info.h>
> >  #include <video/vga.h>
> >@@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
> >  };
> >  ATTRIBUTE_GROUPS(efifb);
> >+static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
> >+static bool pci_dev_disabled;	/* was the device disabled? */
> >+
> >  static int efifb_probe(struct platform_device *dev)
> >  {
> >  	struct fb_info *info;
> >@@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
> >  	unsigned int size_total;
> >  	char *option = NULL;
> >-	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> >+	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
> >  		return -ENODEV;
> >  	if (fb_get_options("efifb", &option))
> >@@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
> >  };
> >  builtin_platform_driver(efifb_driver);
> >+
> >+static void claim_efifb_bar(struct pci_dev *dev, int idx)
> >+{
> >+	u16 word;
> >+
> >+	pci_bar_found = true;
> >+
> >+	pci_read_config_word(dev, PCI_COMMAND, &word);
> >+	if (!(word & PCI_COMMAND_MEMORY)) {
> >+		pci_dev_disabled = true;
> >+		dev_err(&dev->dev,
> >+			"BAR %d: assigned to efifb but device is disabled!\n",
> >+			idx);
> >+		return;
> >+	}
> >+
> >+	if (pci_claim_resource(dev, idx)) {
> >+		pci_dev_disabled = true;
> >+		dev_err(&dev->dev,
> >+			"BAR %d: failed to claim resource for efifb!\n", idx);
> >+		return;
> >+	}
> >+
> >+	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
> >+}
> >+
> >+static void efifb_fixup_resources(struct pci_dev *dev)
> >+{
> >+	u64 base = screen_info.lfb_base;
> >+	u64 size = screen_info.lfb_size;
> >+	int i;
> >+
> >+	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> >+		return;
> >+
> >+	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> >+		base |= (u64)screen_info.ext_lfb_base << 32;
> >+
> >+	if (!base)
> >+		return;
> >+
> >+	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
> >+		struct resource *res = &dev->resource[i];
> >+
> >+		if (!(res->flags & IORESOURCE_MEM))
> >+			continue;
> >+
> >+		if (res->start <= base && res->end >= base + size - 1) {
> Have we considered PCI address translation here? I suppose the
> address reported by EFI GOP should be the address of CPU domain, not
> address of PCI domain. Address read from PCI BAR is PCI address
> which should add translation offset before being compared to CPU
> domain address.

Every address in dev->resource[] is a CPU domain address, so address
translation offset should be handled correctly.

This is because __pci_read_base() calls pcibios_bus_to_resource() when
it fills in dev->resource[], and pcibios_bus_to_resource() applies any
host bridge address translation.

Bjorn

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Bjorn Helgaas]

SGkgR2FyeSwKClRoYW5rcyBmb3IgdGhlIHF1ZXN0aW9uLgoKT24gV2VkLCBNYXkgMDMsIDIwMTcg
YXQgMTE6MDk6NTFBTSArMDgwMCwgSGV5aSBHdW8gd3JvdGU6Cj4gSGkgQXJkLAo+IAo+IEkgaGF2
ZSBvbmUgY29tbWVudCBpbmNsaW5lZC4KPiAKPiAKPiDlnKggMy8yMi8yMDE3IDExOjMwIFBNLCBB
cmQgQmllc2hldXZlbCDlhpnpgZM6Cj4gPk9uIFVFRkkgc3lzdGVtcywgdGhlIFBDSSBzdWJzeXN0
ZW0gaXMgZW51bWVyYXRlZCBieSB0aGUgZmlybXdhcmUsCj4gPmFuZCBpZiBhIGdyYXBoaWNhbCBm
cmFtZWJ1ZmZlciBpcyBleHBvc2VkIGJ5IGEgUENJIGRldmljZSwgaXRzIGJhc2UKPiA+YWRkcmVz
cyBhbmQgc2l6ZSBhcmUgZXhwb3NlZCB0byB0aGUgT1MgdmlhIHRoZSBHcmFwaGljcyBPdXRwdXQK
PiA+UHJvdG9jb2wgKEdPUCkuCj4gPgo+ID5PbiBhcm02NCBQQ0kgc3lzdGVtcywgdGhlIGVudGly
ZSBQQ0kgaGllcmFyY2h5IGlzIHJlY29uZmlndXJlZCBmcm9tCj4gPnNjcmF0Y2ggYXQgYm9vdC4g
VGhpcyBtYXkgcmVzdWx0IGluIHRoZSBHT1AgZnJhbWVidWZmZXIgYWRkcmVzcyB0bwo+ID5iZWNv
bWUgc3RhbGUsIGlmIHRoZSBCQVIgY292ZXJpbmcgdGhlIGZyYW1lYnVmZmVyIGlzIG1vZGlmaWVk
LiBUaGlzCj4gPndpbGwgY2F1c2UgdGhlIGZyYW1lYnVmZmVyIHRvIGJlY29tZSB1bnJlc3BvbnNp
dmUsIGFuZCBtYXkgaW4gc29tZQo+ID5jYXNlcyByZXN1bHQgaW4gdW5wcmVkaWN0YWJsZSBiZWhh
dmlvciBpZiB0aGUgcmFuZ2UgaXMgcmVhc3NpZ25lZCB0bwo+ID5hbm90aGVyIGRldmljZS4KPiA+
Cj4gPlNvIGFkZCBhIHF1aXJrIHRvIHRoZSBFRkkgZmIgZHJpdmVyIHRvIGZpbmQgdGhlIEJBUiBh
c3NvY2lhdGVkIHdpdGgKPiA+dGhlIEdPUCBiYXNlIGFkZHJlc3MsIGFuZCBzZXQgdGhlIElPUkVT
T1VSQ0VfUENJX0ZJWEVEIGF0dHJpYnV0ZSBzbwo+ID50aGF0IHRoZSBQQ0kgY29yZSB3aWxsIGxl
YXZlIGl0IGFsb25lLgo+ID4KPiA+Q2M6IE1hdHQgRmxlbWluZyA8bWF0dEBjb2RlYmx1ZXByaW50
LmNvLnVrPgo+ID5DYzogUGV0ZXIgSm9uZXMgPHBqb25lc0ByZWRoYXQuY29tPgo+ID5TaWduZWQt
b2ZmLWJ5OiBBcmQgQmllc2hldXZlbCA8YXJkLmJpZXNoZXV2ZWxAbGluYXJvLm9yZz4KPiA+LS0t
Cj4gPnYzOiBjaGVjayBkZXZpY2UgaXMgZW5hYmxlZCBiZWZvcmUgYXR0ZW1wdGluZyB0byBjbGFp
bSB0aGUgcmVzb3VyY2UKPiA+Cj4gPiAgZHJpdmVycy92aWRlby9mYmRldi9lZmlmYi5jIHwgNjAg
KysrKysrKysrKysrKysrKysrKy0KPiA+ICAxIGZpbGUgY2hhbmdlZCwgNTkgaW5zZXJ0aW9ucygr
KSwgMSBkZWxldGlvbigtKQo+ID4KPiA+ZGlmZiAtLWdpdCBhL2RyaXZlcnMvdmlkZW8vZmJkZXYv
ZWZpZmIuYyBiL2RyaXZlcnMvdmlkZW8vZmJkZXYvZWZpZmIuYwo+ID5pbmRleCA4YzRkYzFlMWY5
NGYuLjg4ZjY1Mzg2NGEwMSAxMDA2NDQKPiA+LS0tIGEvZHJpdmVycy92aWRlby9mYmRldi9lZmlm
Yi5jCj4gPisrKyBiL2RyaXZlcnMvdmlkZW8vZmJkZXYvZWZpZmIuYwo+ID5AQCAtMTAsNiArMTAs
NyBAQAo+ID4gICNpbmNsdWRlIDxsaW51eC9lZmkuaD4KPiA+ICAjaW5jbHVkZSA8bGludXgvZXJy
bm8uaD4KPiA+ICAjaW5jbHVkZSA8bGludXgvZmIuaD4KPiA+KyNpbmNsdWRlIDxsaW51eC9wY2ku
aD4KPiA+ICAjaW5jbHVkZSA8bGludXgvcGxhdGZvcm1fZGV2aWNlLmg+Cj4gPiAgI2luY2x1ZGUg
PGxpbnV4L3NjcmVlbl9pbmZvLmg+Cj4gPiAgI2luY2x1ZGUgPHZpZGVvL3ZnYS5oPgo+ID5AQCAt
MTQzLDYgKzE0NCw5IEBAIHN0YXRpYyBzdHJ1Y3QgYXR0cmlidXRlICplZmlmYl9hdHRyc1tdID0g
ewo+ID4gIH07Cj4gPiAgQVRUUklCVVRFX0dST1VQUyhlZmlmYik7Cj4gPitzdGF0aWMgYm9vbCBw
Y2lfYmFyX2ZvdW5kOwkvKiBkaWQgd2UgZmluZCBhIEJBUiBtYXRjaGluZyB0aGUgZWZpZmIgYmFz
ZT8gKi8KPiA+K3N0YXRpYyBib29sIHBjaV9kZXZfZGlzYWJsZWQ7CS8qIHdhcyB0aGUgZGV2aWNl
IGRpc2FibGVkPyAqLwo+ID4rCj4gPiAgc3RhdGljIGludCBlZmlmYl9wcm9iZShzdHJ1Y3QgcGxh
dGZvcm1fZGV2aWNlICpkZXYpCj4gPiAgewo+ID4gIAlzdHJ1Y3QgZmJfaW5mbyAqaW5mbzsKPiA+
QEAgLTE1Miw3ICsxNTYsNyBAQCBzdGF0aWMgaW50IGVmaWZiX3Byb2JlKHN0cnVjdCBwbGF0Zm9y
bV9kZXZpY2UgKmRldikKPiA+ICAJdW5zaWduZWQgaW50IHNpemVfdG90YWw7Cj4gPiAgCWNoYXIg
Km9wdGlvbiA9IE5VTEw7Cj4gPi0JaWYgKHNjcmVlbl9pbmZvLm9yaWdfdmlkZW9faXNWR0EgIT0g
VklERU9fVFlQRV9FRkkpCj4gPisJaWYgKHNjcmVlbl9pbmZvLm9yaWdfdmlkZW9faXNWR0EgIT0g
VklERU9fVFlQRV9FRkkgfHwgcGNpX2Rldl9kaXNhYmxlZCkKPiA+ICAJCXJldHVybiAtRU5PREVW
Owo+ID4gIAlpZiAoZmJfZ2V0X29wdGlvbnMoImVmaWZiIiwgJm9wdGlvbikpCj4gPkBAIC0zNjAs
MyArMzY0LDU3IEBAIHN0YXRpYyBzdHJ1Y3QgcGxhdGZvcm1fZHJpdmVyIGVmaWZiX2RyaXZlciA9
IHsKPiA+ICB9Owo+ID4gIGJ1aWx0aW5fcGxhdGZvcm1fZHJpdmVyKGVmaWZiX2RyaXZlcik7Cj4g
PisKPiA+K3N0YXRpYyB2b2lkIGNsYWltX2VmaWZiX2JhcihzdHJ1Y3QgcGNpX2RldiAqZGV2LCBp
bnQgaWR4KQo+ID4rewo+ID4rCXUxNiB3b3JkOwo+ID4rCj4gPisJcGNpX2Jhcl9mb3VuZCA9IHRy
dWU7Cj4gPisKPiA+KwlwY2lfcmVhZF9jb25maWdfd29yZChkZXYsIFBDSV9DT01NQU5ELCAmd29y
ZCk7Cj4gPisJaWYgKCEod29yZCAmIFBDSV9DT01NQU5EX01FTU9SWSkpIHsKPiA+KwkJcGNpX2Rl
dl9kaXNhYmxlZCA9IHRydWU7Cj4gPisJCWRldl9lcnIoJmRldi0+ZGV2LAo+ID4rCQkJIkJBUiAl
ZDogYXNzaWduZWQgdG8gZWZpZmIgYnV0IGRldmljZSBpcyBkaXNhYmxlZCFcbiIsCj4gPisJCQlp
ZHgpOwo+ID4rCQlyZXR1cm47Cj4gPisJfQo+ID4rCj4gPisJaWYgKHBjaV9jbGFpbV9yZXNvdXJj
ZShkZXYsIGlkeCkpIHsKPiA+KwkJcGNpX2Rldl9kaXNhYmxlZCA9IHRydWU7Cj4gPisJCWRldl9l
cnIoJmRldi0+ZGV2LAo+ID4rCQkJIkJBUiAlZDogZmFpbGVkIHRvIGNsYWltIHJlc291cmNlIGZv
ciBlZmlmYiFcbiIsIGlkeCk7Cj4gPisJCXJldHVybjsKPiA+Kwl9Cj4gPisKPiA+KwlkZXZfaW5m
bygmZGV2LT5kZXYsICJCQVIgJWQ6IGFzc2lnbmVkIHRvIGVmaWZiXG4iLCBpZHgpOwo+ID4rfQo+
ID4rCj4gPitzdGF0aWMgdm9pZCBlZmlmYl9maXh1cF9yZXNvdXJjZXMoc3RydWN0IHBjaV9kZXYg
KmRldikKPiA+K3sKPiA+Kwl1NjQgYmFzZSA9IHNjcmVlbl9pbmZvLmxmYl9iYXNlOwo+ID4rCXU2
NCBzaXplID0gc2NyZWVuX2luZm8ubGZiX3NpemU7Cj4gPisJaW50IGk7Cj4gPisKPiA+KwlpZiAo
cGNpX2Jhcl9mb3VuZCB8fCBzY3JlZW5faW5mby5vcmlnX3ZpZGVvX2lzVkdBICE9IFZJREVPX1RZ
UEVfRUZJKQo+ID4rCQlyZXR1cm47Cj4gPisKPiA+KwlpZiAoc2NyZWVuX2luZm8uY2FwYWJpbGl0
aWVzICYgVklERU9fQ0FQQUJJTElUWV82NEJJVF9CQVNFKQo+ID4rCQliYXNlIHw9ICh1NjQpc2Ny
ZWVuX2luZm8uZXh0X2xmYl9iYXNlIDw8IDMyOwo+ID4rCj4gPisJaWYgKCFiYXNlKQo+ID4rCQly
ZXR1cm47Cj4gPisKPiA+Kwlmb3IgKGkgPSAwOyBpIDwgUENJX1NURF9SRVNPVVJDRV9FTkQ7IGkr
Kykgewo+ID4rCQlzdHJ1Y3QgcmVzb3VyY2UgKnJlcyA9ICZkZXYtPnJlc291cmNlW2ldOwo+ID4r
Cj4gPisJCWlmICghKHJlcy0+ZmxhZ3MgJiBJT1JFU09VUkNFX01FTSkpCj4gPisJCQljb250aW51
ZTsKPiA+Kwo+ID4rCQlpZiAocmVzLT5zdGFydCA8PSBiYXNlICYmIHJlcy0+ZW5kID49IGJhc2Ug
KyBzaXplIC0gMSkgewo+IEhhdmUgd2UgY29uc2lkZXJlZCBQQ0kgYWRkcmVzcyB0cmFuc2xhdGlv
biBoZXJlPyBJIHN1cHBvc2UgdGhlCj4gYWRkcmVzcyByZXBvcnRlZCBieSBFRkkgR09QIHNob3Vs
ZCBiZSB0aGUgYWRkcmVzcyBvZiBDUFUgZG9tYWluLCBub3QKPiBhZGRyZXNzIG9mIFBDSSBkb21h
aW4uIEFkZHJlc3MgcmVhZCBmcm9tIFBDSSBCQVIgaXMgUENJIGFkZHJlc3MKPiB3aGljaCBzaG91
bGQgYWRkIHRyYW5zbGF0aW9uIG9mZnNldCBiZWZvcmUgYmVpbmcgY29tcGFyZWQgdG8gQ1BVCj4g
ZG9tYWluIGFkZHJlc3MuCgpFdmVyeSBhZGRyZXNzIGluIGRldi0+cmVzb3VyY2VbXSBpcyBhIENQ
VSBkb21haW4gYWRkcmVzcywgc28gYWRkcmVzcwp0cmFuc2xhdGlvbiBvZmZzZXQgc2hvdWxkIGJl
IGhhbmRsZWQgY29ycmVjdGx5LgoKVGhpcyBpcyBiZWNhdXNlIF9fcGNpX3JlYWRfYmFzZSgpIGNh
bGxzIHBjaWJpb3NfYnVzX3RvX3Jlc291cmNlKCkgd2hlbgppdCBmaWxscyBpbiBkZXYtPnJlc291
cmNlW10sIGFuZCBwY2liaW9zX2J1c190b19yZXNvdXJjZSgpIGFwcGxpZXMgYW55Cmhvc3QgYnJp
ZGdlIGFkZHJlc3MgdHJhbnNsYXRpb24uCgpCam9ybgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGlu
dXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQu
b3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Bjorn Helgaas]

Hi Gary,

Thanks for the question.

On Wed, May 03, 2017 at 11:09:51AM +0800, Heyi Guo wrote:
> Hi Ard,
> 
> I have one comment inclined.
> 
> 
> ? 3/22/2017 11:30 PM, Ard Biesheuvel ??:
> >On UEFI systems, the PCI subsystem is enumerated by the firmware,
> >and if a graphical framebuffer is exposed by a PCI device, its base
> >address and size are exposed to the OS via the Graphics Output
> >Protocol (GOP).
> >
> >On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
> >scratch at boot. This may result in the GOP framebuffer address to
> >become stale, if the BAR covering the framebuffer is modified. This
> >will cause the framebuffer to become unresponsive, and may in some
> >cases result in unpredictable behavior if the range is reassigned to
> >another device.
> >
> >So add a quirk to the EFI fb driver to find the BAR associated with
> >the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
> >that the PCI core will leave it alone.
> >
> >Cc: Matt Fleming <matt@codeblueprint.co.uk>
> >Cc: Peter Jones <pjones@redhat.com>
> >Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >---
> >v3: check device is enabled before attempting to claim the resource
> >
> >  drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
> >  1 file changed, 59 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> >index 8c4dc1e1f94f..88f653864a01 100644
> >--- a/drivers/video/fbdev/efifb.c
> >+++ b/drivers/video/fbdev/efifb.c
> >@@ -10,6 +10,7 @@
> >  #include <linux/efi.h>
> >  #include <linux/errno.h>
> >  #include <linux/fb.h>
> >+#include <linux/pci.h>
> >  #include <linux/platform_device.h>
> >  #include <linux/screen_info.h>
> >  #include <video/vga.h>
> >@@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
> >  };
> >  ATTRIBUTE_GROUPS(efifb);
> >+static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
> >+static bool pci_dev_disabled;	/* was the device disabled? */
> >+
> >  static int efifb_probe(struct platform_device *dev)
> >  {
> >  	struct fb_info *info;
> >@@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
> >  	unsigned int size_total;
> >  	char *option = NULL;
> >-	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> >+	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
> >  		return -ENODEV;
> >  	if (fb_get_options("efifb", &option))
> >@@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
> >  };
> >  builtin_platform_driver(efifb_driver);
> >+
> >+static void claim_efifb_bar(struct pci_dev *dev, int idx)
> >+{
> >+	u16 word;
> >+
> >+	pci_bar_found = true;
> >+
> >+	pci_read_config_word(dev, PCI_COMMAND, &word);
> >+	if (!(word & PCI_COMMAND_MEMORY)) {
> >+		pci_dev_disabled = true;
> >+		dev_err(&dev->dev,
> >+			"BAR %d: assigned to efifb but device is disabled!\n",
> >+			idx);
> >+		return;
> >+	}
> >+
> >+	if (pci_claim_resource(dev, idx)) {
> >+		pci_dev_disabled = true;
> >+		dev_err(&dev->dev,
> >+			"BAR %d: failed to claim resource for efifb!\n", idx);
> >+		return;
> >+	}
> >+
> >+	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
> >+}
> >+
> >+static void efifb_fixup_resources(struct pci_dev *dev)
> >+{
> >+	u64 base = screen_info.lfb_base;
> >+	u64 size = screen_info.lfb_size;
> >+	int i;
> >+
> >+	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> >+		return;
> >+
> >+	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> >+		base |= (u64)screen_info.ext_lfb_base << 32;
> >+
> >+	if (!base)
> >+		return;
> >+
> >+	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
> >+		struct resource *res = &dev->resource[i];
> >+
> >+		if (!(res->flags & IORESOURCE_MEM))
> >+			continue;
> >+
> >+		if (res->start <= base && res->end >= base + size - 1) {
> Have we considered PCI address translation here? I suppose the
> address reported by EFI GOP should be the address of CPU domain, not
> address of PCI domain. Address read from PCI BAR is PCI address
> which should add translation offset before being compared to CPU
> domain address.

Every address in dev->resource[] is a CPU domain address, so address
translation offset should be handled correctly.

This is because __pci_read_base() calls pcibios_bus_to_resource() when
it fills in dev->resource[], and pcibios_bus_to_resource() applies any
host bridge address translation.

Bjorn

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Heyi Guo]

Hi Bjorn,

Many thanks for your clear answer.

Regards,

Gary (Heyi Guo)


在 5/18/2017 10:01 PM, Bjorn Helgaas 写道:
> Hi Gary,
>
> Thanks for the question.
>
> On Wed, May 03, 2017 at 11:09:51AM +0800, Heyi Guo wrote:
>> Hi Ard,
>>
>> I have one comment inclined.
>>
>>
>> 在 3/22/2017 11:30 PM, Ard Biesheuvel 写道:
>>> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>>> and if a graphical framebuffer is exposed by a PCI device, its base
>>> address and size are exposed to the OS via the Graphics Output
>>> Protocol (GOP).
>>>
>>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>>> scratch at boot. This may result in the GOP framebuffer address to
>>> become stale, if the BAR covering the framebuffer is modified. This
>>> will cause the framebuffer to become unresponsive, and may in some
>>> cases result in unpredictable behavior if the range is reassigned to
>>> another device.
>>>
>>> So add a quirk to the EFI fb driver to find the BAR associated with
>>> the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
>>> that the PCI core will leave it alone.
>>>
>>> Cc: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
>>> Cc: Peter Jones <pjones-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>>> ---
>>> v3: check device is enabled before attempting to claim the resource
>>>
>>>   drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
>>>   1 file changed, 59 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>>> index 8c4dc1e1f94f..88f653864a01 100644
>>> --- a/drivers/video/fbdev/efifb.c
>>> +++ b/drivers/video/fbdev/efifb.c
>>> @@ -10,6 +10,7 @@
>>>   #include <linux/efi.h>
>>>   #include <linux/errno.h>
>>>   #include <linux/fb.h>
>>> +#include <linux/pci.h>
>>>   #include <linux/platform_device.h>
>>>   #include <linux/screen_info.h>
>>>   #include <video/vga.h>
>>> @@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
>>>   };
>>>   ATTRIBUTE_GROUPS(efifb);
>>> +static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
>>> +static bool pci_dev_disabled;	/* was the device disabled? */
>>> +
>>>   static int efifb_probe(struct platform_device *dev)
>>>   {
>>>   	struct fb_info *info;
>>> @@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
>>>   	unsigned int size_total;
>>>   	char *option = NULL;
>>> -	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>>> +	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
>>>   		return -ENODEV;
>>>   	if (fb_get_options("efifb", &option))
>>> @@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
>>>   };
>>>   builtin_platform_driver(efifb_driver);
>>> +
>>> +static void claim_efifb_bar(struct pci_dev *dev, int idx)
>>> +{
>>> +	u16 word;
>>> +
>>> +	pci_bar_found = true;
>>> +
>>> +	pci_read_config_word(dev, PCI_COMMAND, &word);
>>> +	if (!(word & PCI_COMMAND_MEMORY)) {
>>> +		pci_dev_disabled = true;
>>> +		dev_err(&dev->dev,
>>> +			"BAR %d: assigned to efifb but device is disabled!\n",
>>> +			idx);
>>> +		return;
>>> +	}
>>> +
>>> +	if (pci_claim_resource(dev, idx)) {
>>> +		pci_dev_disabled = true;
>>> +		dev_err(&dev->dev,
>>> +			"BAR %d: failed to claim resource for efifb!\n", idx);
>>> +		return;
>>> +	}
>>> +
>>> +	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
>>> +}
>>> +
>>> +static void efifb_fixup_resources(struct pci_dev *dev)
>>> +{
>>> +	u64 base = screen_info.lfb_base;
>>> +	u64 size = screen_info.lfb_size;
>>> +	int i;
>>> +
>>> +	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>>> +		return;
>>> +
>>> +	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
>>> +		base |= (u64)screen_info.ext_lfb_base << 32;
>>> +
>>> +	if (!base)
>>> +		return;
>>> +
>>> +	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
>>> +		struct resource *res = &dev->resource[i];
>>> +
>>> +		if (!(res->flags & IORESOURCE_MEM))
>>> +			continue;
>>> +
>>> +		if (res->start <= base && res->end >= base + size - 1) {
>> Have we considered PCI address translation here? I suppose the
>> address reported by EFI GOP should be the address of CPU domain, not
>> address of PCI domain. Address read from PCI BAR is PCI address
>> which should add translation offset before being compared to CPU
>> domain address.
> Every address in dev->resource[] is a CPU domain address, so address
> translation offset should be handled correctly.
>
> This is because __pci_read_base() calls pcibios_bus_to_resource() when
> it fills in dev->resource[], and pcibios_bus_to_resource() applies any
> host bridge address translation.
>
> Bjorn

Re: [PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Heyi Guo]

Hi Bjorn,

Many thanks for your clear answer.

Regards,

Gary (Heyi Guo)


在 5/18/2017 10:01 PM, Bjorn Helgaas 写道:
> Hi Gary,
>
> Thanks for the question.
>
> On Wed, May 03, 2017 at 11:09:51AM +0800, Heyi Guo wrote:
>> Hi Ard,
>>
>> I have one comment inclined.
>>
>>
>> 在 3/22/2017 11:30 PM, Ard Biesheuvel 写道:
>>> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>>> and if a graphical framebuffer is exposed by a PCI device, its base
>>> address and size are exposed to the OS via the Graphics Output
>>> Protocol (GOP).
>>>
>>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>>> scratch at boot. This may result in the GOP framebuffer address to
>>> become stale, if the BAR covering the framebuffer is modified. This
>>> will cause the framebuffer to become unresponsive, and may in some
>>> cases result in unpredictable behavior if the range is reassigned to
>>> another device.
>>>
>>> So add a quirk to the EFI fb driver to find the BAR associated with
>>> the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
>>> that the PCI core will leave it alone.
>>>
>>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>>> Cc: Peter Jones <pjones@redhat.com>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>> v3: check device is enabled before attempting to claim the resource
>>>
>>>   drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
>>>   1 file changed, 59 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>>> index 8c4dc1e1f94f..88f653864a01 100644
>>> --- a/drivers/video/fbdev/efifb.c
>>> +++ b/drivers/video/fbdev/efifb.c
>>> @@ -10,6 +10,7 @@
>>>   #include <linux/efi.h>
>>>   #include <linux/errno.h>
>>>   #include <linux/fb.h>
>>> +#include <linux/pci.h>
>>>   #include <linux/platform_device.h>
>>>   #include <linux/screen_info.h>
>>>   #include <video/vga.h>
>>> @@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
>>>   };
>>>   ATTRIBUTE_GROUPS(efifb);
>>> +static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
>>> +static bool pci_dev_disabled;	/* was the device disabled? */
>>> +
>>>   static int efifb_probe(struct platform_device *dev)
>>>   {
>>>   	struct fb_info *info;
>>> @@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
>>>   	unsigned int size_total;
>>>   	char *option = NULL;
>>> -	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>>> +	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
>>>   		return -ENODEV;
>>>   	if (fb_get_options("efifb", &option))
>>> @@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
>>>   };
>>>   builtin_platform_driver(efifb_driver);
>>> +
>>> +static void claim_efifb_bar(struct pci_dev *dev, int idx)
>>> +{
>>> +	u16 word;
>>> +
>>> +	pci_bar_found = true;
>>> +
>>> +	pci_read_config_word(dev, PCI_COMMAND, &word);
>>> +	if (!(word & PCI_COMMAND_MEMORY)) {
>>> +		pci_dev_disabled = true;
>>> +		dev_err(&dev->dev,
>>> +			"BAR %d: assigned to efifb but device is disabled!\n",
>>> +			idx);
>>> +		return;
>>> +	}
>>> +
>>> +	if (pci_claim_resource(dev, idx)) {
>>> +		pci_dev_disabled = true;
>>> +		dev_err(&dev->dev,
>>> +			"BAR %d: failed to claim resource for efifb!\n", idx);
>>> +		return;
>>> +	}
>>> +
>>> +	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
>>> +}
>>> +
>>> +static void efifb_fixup_resources(struct pci_dev *dev)
>>> +{
>>> +	u64 base = screen_info.lfb_base;
>>> +	u64 size = screen_info.lfb_size;
>>> +	int i;
>>> +
>>> +	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>>> +		return;
>>> +
>>> +	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
>>> +		base |= (u64)screen_info.ext_lfb_base << 32;
>>> +
>>> +	if (!base)
>>> +		return;
>>> +
>>> +	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
>>> +		struct resource *res = &dev->resource[i];
>>> +
>>> +		if (!(res->flags & IORESOURCE_MEM))
>>> +			continue;
>>> +
>>> +		if (res->start <= base && res->end >= base + size - 1) {
>> Have we considered PCI address translation here? I suppose the
>> address reported by EFI GOP should be the address of CPU domain, not
>> address of PCI domain. Address read from PCI BAR is PCI address
>> which should add translation offset before being compared to CPU
>> domain address.
> Every address in dev->resource[] is a CPU domain address, so address
> translation offset should be handled correctly.
>
> This is because __pci_read_base() calls pcibios_bus_to_resource() when
> it fills in dev->resource[], and pcibios_bus_to_resource() applies any
> host bridge address translation.
>
> Bjorn

[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

[Heyi Guo]

Hi Bjorn,

Many thanks for your clear answer.

Regards,

Gary (Heyi Guo)


? 5/18/2017 10:01 PM, Bjorn Helgaas ??:
> Hi Gary,
>
> Thanks for the question.
>
> On Wed, May 03, 2017 at 11:09:51AM +0800, Heyi Guo wrote:
>> Hi Ard,
>>
>> I have one comment inclined.
>>
>>
>> ? 3/22/2017 11:30 PM, Ard Biesheuvel ??:
>>> On UEFI systems, the PCI subsystem is enumerated by the firmware,
>>> and if a graphical framebuffer is exposed by a PCI device, its base
>>> address and size are exposed to the OS via the Graphics Output
>>> Protocol (GOP).
>>>
>>> On arm64 PCI systems, the entire PCI hierarchy is reconfigured from
>>> scratch at boot. This may result in the GOP framebuffer address to
>>> become stale, if the BAR covering the framebuffer is modified. This
>>> will cause the framebuffer to become unresponsive, and may in some
>>> cases result in unpredictable behavior if the range is reassigned to
>>> another device.
>>>
>>> So add a quirk to the EFI fb driver to find the BAR associated with
>>> the GOP base address, and set the IORESOURCE_PCI_FIXED attribute so
>>> that the PCI core will leave it alone.
>>>
>>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>>> Cc: Peter Jones <pjones@redhat.com>
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>> v3: check device is enabled before attempting to claim the resource
>>>
>>>   drivers/video/fbdev/efifb.c | 60 +++++++++++++++++++-
>>>   1 file changed, 59 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
>>> index 8c4dc1e1f94f..88f653864a01 100644
>>> --- a/drivers/video/fbdev/efifb.c
>>> +++ b/drivers/video/fbdev/efifb.c
>>> @@ -10,6 +10,7 @@
>>>   #include <linux/efi.h>
>>>   #include <linux/errno.h>
>>>   #include <linux/fb.h>
>>> +#include <linux/pci.h>
>>>   #include <linux/platform_device.h>
>>>   #include <linux/screen_info.h>
>>>   #include <video/vga.h>
>>> @@ -143,6 +144,9 @@ static struct attribute *efifb_attrs[] = {
>>>   };
>>>   ATTRIBUTE_GROUPS(efifb);
>>> +static bool pci_bar_found;	/* did we find a BAR matching the efifb base? */
>>> +static bool pci_dev_disabled;	/* was the device disabled? */
>>> +
>>>   static int efifb_probe(struct platform_device *dev)
>>>   {
>>>   	struct fb_info *info;
>>> @@ -152,7 +156,7 @@ static int efifb_probe(struct platform_device *dev)
>>>   	unsigned int size_total;
>>>   	char *option = NULL;
>>> -	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>>> +	if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
>>>   		return -ENODEV;
>>>   	if (fb_get_options("efifb", &option))
>>> @@ -360,3 +364,57 @@ static struct platform_driver efifb_driver = {
>>>   };
>>>   builtin_platform_driver(efifb_driver);
>>> +
>>> +static void claim_efifb_bar(struct pci_dev *dev, int idx)
>>> +{
>>> +	u16 word;
>>> +
>>> +	pci_bar_found = true;
>>> +
>>> +	pci_read_config_word(dev, PCI_COMMAND, &word);
>>> +	if (!(word & PCI_COMMAND_MEMORY)) {
>>> +		pci_dev_disabled = true;
>>> +		dev_err(&dev->dev,
>>> +			"BAR %d: assigned to efifb but device is disabled!\n",
>>> +			idx);
>>> +		return;
>>> +	}
>>> +
>>> +	if (pci_claim_resource(dev, idx)) {
>>> +		pci_dev_disabled = true;
>>> +		dev_err(&dev->dev,
>>> +			"BAR %d: failed to claim resource for efifb!\n", idx);
>>> +		return;
>>> +	}
>>> +
>>> +	dev_info(&dev->dev, "BAR %d: assigned to efifb\n", idx);
>>> +}
>>> +
>>> +static void efifb_fixup_resources(struct pci_dev *dev)
>>> +{
>>> +	u64 base = screen_info.lfb_base;
>>> +	u64 size = screen_info.lfb_size;
>>> +	int i;
>>> +
>>> +	if (pci_bar_found || screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
>>> +		return;
>>> +
>>> +	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
>>> +		base |= (u64)screen_info.ext_lfb_base << 32;
>>> +
>>> +	if (!base)
>>> +		return;
>>> +
>>> +	for (i = 0; i < PCI_STD_RESOURCE_END; i++) {
>>> +		struct resource *res = &dev->resource[i];
>>> +
>>> +		if (!(res->flags & IORESOURCE_MEM))
>>> +			continue;
>>> +
>>> +		if (res->start <= base && res->end >= base + size - 1) {
>> Have we considered PCI address translation here? I suppose the
>> address reported by EFI GOP should be the address of CPU domain, not
>> address of PCI domain. Address read from PCI BAR is PCI address
>> which should add translation offset before being compared to CPU
>> domain address.
> Every address in dev->resource[] is a CPU domain address, so address
> translation offset should be handled correctly.
>
> This is because __pci_read_base() calls pcibios_bus_to_resource() when
> it fills in dev->resource[], and pcibios_bus_to_resource() applies any
> host bridge address translation.
>
> Bjorn