linux-kernel - Re: [Intel-gfx] [PATCH v3 3/9] PCI/VGA: Switch to aperture_contain_firmware_fb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d490f455-5228-b85a-656a-dce11586dee5@loongson.cn>
Date:   Thu, 20 Jul 2023 06:04:21 +0800
From:   suijingfeng <suijingfeng@...ngson.cn>
To:     Bjorn Helgaas <helgaas@...nel.org>,
        Sui Jingfeng <sui.jingfeng@...ux.dev>
Cc:     David Airlie <airlied@...il.com>, linux-fbdev@...r.kernel.org,
        kvm@...r.kernel.org, intel-gfx@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        amd-gfx@...ts.freedesktop.org, linux-pci@...r.kernel.org
Subject: Re: [Intel-gfx] [PATCH v3 3/9] PCI/VGA: Switch to
 aperture_contain_firmware_fb_nonreloc()

Hi,

On 2023/7/20 04:43, Bjorn Helgaas wrote:
> [+cc linux-pci; I don't apply or ack PCI patches unless they appear there]
>
> On Wed, Jul 12, 2023 at 12:43:04AM +0800, Sui Jingfeng wrote:
>> From: Sui Jingfeng <suijingfeng@...ngson.cn>
>>
>> The observation behind this is that we should avoid accessing the global
>> screen_info directly. Call the aperture_contain_firmware_fb_nonreloc()
>> function to implement the detection of whether an aperture contains the
>> firmware FB.
> Because it's better to access the global screen_info from
> aperture_contain_firmware_fb_nonreloc()?  The reasoning here is not
> super clear to me.

Yes, honestly the benefits of this patch is not obvious.

But I do have some (may not practical) ideas in my mind when I create 
this patch.

See my explanation at the end.


>> This patch helps to decouple the determination from the implementation.
>> Or, in other words, we intend to make the determination opaque to the
>> caller. The determination may choose to be arch-dependent or
>> arch-independent. But vgaarb, as a consumer of the determination,
>> shouldn't care how the does determination is implemented.
> "how the determination ..."  (drop the "does")
Ok, will be fixed at the next version.
>
> Are you saying that aperture_contain_firmware_fb_nonreloc() might be
> arch-dependent?  Are there multiple callers?  Or does this just move
> code from one place to a more appropriate place?

1) To form a unify approach, and drop the screen_info.h header.

There are similar cleanup patch at patchwork.


screen_info.h is definitely arch-dependent, while vgaarb is just 
device-dependent.

I think, they do have subtle difference.


2) Convert the *device driven* to the "driver driven".

Move it from vgaarb.c to video/apperture allow code sharing.

While this function are not going to be shared in vgaarb.

Previous it is the device make the decision,

after applied this patch it allow driver make the decision.

They do have subtle difference.

Emm, I will try to give some examples at the next version.


3) I was imagine to drag platform display controllers in (get platform 
devices involved in the arbitration).

As Alex seem hint to implement something platform-independent.

The aperture_contain_firmware_fb_nonreloc() actually is possible be shared.

The aperture of platform device will be not moved.

So it seems that platform device driver could call this function to do 
something else.


>> Signed-off-by: Sui Jingfeng <suijingfeng@...ngson.cn>
>> ---
>>   drivers/pci/vgaarb.c | 19 ++++---------------
>>   1 file changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
>> index bf96e085751d..953daf731b2c 100644
>> --- a/drivers/pci/vgaarb.c
>> +++ b/drivers/pci/vgaarb.c
>> @@ -14,6 +14,7 @@
>>   #define vgaarb_info(dev, fmt, arg...)	dev_info(dev, "vgaarb: " fmt, ##arg)
>>   #define vgaarb_err(dev, fmt, arg...)	dev_err(dev, "vgaarb: " fmt, ##arg)
>>   
>> +#include <linux/aperture.h>
>>   #include <linux/module.h>
>>   #include <linux/kernel.h>
>>   #include <linux/pci.h>
>> @@ -26,7 +27,6 @@
>>   #include <linux/poll.h>
>>   #include <linux/miscdevice.h>
>>   #include <linux/slab.h>
>> -#include <linux/screen_info.h>
>>   #include <linux/vt.h>
>>   #include <linux/console.h>
>>   #include <linux/acpi.h>
>> @@ -558,20 +558,11 @@ void vga_put(struct pci_dev *pdev, unsigned int rsrc)
>>   }
>>   EXPORT_SYMBOL(vga_put);
>>   
>> +/* Select the device owning the boot framebuffer if there is one */
>>   static bool vga_is_firmware_default(struct pci_dev *pdev)
>>   {
>>   #if defined(CONFIG_X86) || defined(CONFIG_IA64)
>> -	u64 base = screen_info.lfb_base;
>> -	u64 size = screen_info.lfb_size;
>>   	struct resource *r;
>> -	u64 limit;
>> -
>> -	/* Select the device owning the boot framebuffer if there is one */
>> -
>> -	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
>> -		base |= (u64)screen_info.ext_lfb_base << 32;
>> -
>> -	limit = base + size;
>>   
>>   	/* Does firmware framebuffer belong to us? */
>>   	pci_dev_for_each_resource(pdev, r) {
>> @@ -581,10 +572,8 @@ static bool vga_is_firmware_default(struct pci_dev *pdev)
>>   		if (!r->start || !r->end)
>>   			continue;
>>   
>> -		if (base < r->start || limit >= r->end)
>> -			continue;
>> -
>> -		return true;
>> +		if (aperture_contain_firmware_fb_nonreloc(r->start, r->end))
>> +			return true;
>>   	}
>>   #endif
>>   	return false;
>> -- 
>> 2.25.1
>>