qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 3/8] acpi/gpex: Inform os to keep firmware resource map


From: Jiahui Cen
Subject: Re: [PATCH v3 3/8] acpi/gpex: Inform os to keep firmware resource map
Date: Thu, 31 Dec 2020 11:30:47 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2


On 2020/12/29 21:41, Igor Mammedov wrote:
> On Wed, 23 Dec 2020 17:08:31 +0800
> Jiahui Cen <cenjiahui@huawei.com> wrote:
> 
>> There may be some differences in pci resource assignment between guest os
>> and firmware.
>>
>> Eg. A Bridge with Bus [d2]
>>     -+-[0000:d2]---01.0-[d3]----01.0
>>
>>     where [d2:01.00] is a pcie-pci-bridge with BAR0 (mem, 64-bit, non-pref) 
>> [size=256]
>>           [d3:01.00] is a PCI Device with BAR0 (mem, 64-bit, pref) 
>> [size=128K]
>>                                           BAR4 (mem, 64-bit, pref) [size=64M]
>>
>>     In EDK2, the Resource Map would be:
>>         PciBus: Resource Map for Bridge [D2|01|00]
>>         Type = PMem64; Base = 0x8004000000;     Length = 0x4100000;     
>> Alignment = 0x3FFFFFF
>>            Base = 0x8004000000; Length = 0x4000000;     Alignment = 
>> 0x3FFFFFF;  Owner = PCI [D3|01|00:20]
>>            Base = 0x8008000000; Length = 0x20000;       Alignment = 0x1FFFF; 
>>    Owner = PCI [D3|01|00:10]
>>         Type =  Mem64; Base = 0x8008100000;     Length = 0x100; Alignment = 
>> 0xFFF
>>     It would use 0x4100000 to calculate the root bus's PMem64 resource 
>> window.
>>
>>     While in Linux, kernel will use 0x1FFFFFF as the alignment to calculate
>>     the PMem64 size, which would be 0x6000000. So kernel would try to
>>     allocate 0x6000000 from the PMem64 resource window, but since the window
>>     size is 0x4100000 as assigned by EDK2, the allocation would fail.
>>
>> The diffences could result in resource assignment failure.
>>
>> Using _DSM #5 method to inform guest os not to ignore the PCI configuration
>> that firmware has done at boot time could handle the differences.
> 
> I'm not sure about this one, 
> OS should able to reconfigure PCI resources according to what and where is 
> plugged
> (and it even more true is hotplug is taken into account)

I think the problem is that OS can not reconfigure the resource windows set in 
_CRS
by firmware, which means the total resource range where OS can assign from is 
limited.
So would it be better that OS prefers the resource assignment by firmware and
reconfigures those not properly assigned resources?

And the bios seems to have taken hotplug reserved resources into account.

Thanks,
Jiahui

>>
>> Signed-off-by: Jiahui Cen <cenjiahui@huawei.com>
>> ---
>>  hw/pci-host/gpex-acpi.c | 18 ++++++++++++++++--
>>  1 file changed, 16 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/pci-host/gpex-acpi.c b/hw/pci-host/gpex-acpi.c
>> index 11b3db8f71..c189306599 100644
>> --- a/hw/pci-host/gpex-acpi.c
>> +++ b/hw/pci-host/gpex-acpi.c
>> @@ -112,10 +112,24 @@ static void acpi_dsdt_add_pci_osc(Aml *dev)
>>      UUID = aml_touuid("E5C937D0-3553-4D7A-9117-EA4D19C3434D");
>>      ifctx = aml_if(aml_equal(aml_arg(0), UUID));
>>      ifctx1 = aml_if(aml_equal(aml_arg(2), aml_int(0)));
>> -    uint8_t byte_list[1] = {1};
>> -    buf = aml_buffer(1, byte_list);
>> +    uint8_t byte_list[] = {
>> +                0x1 << 0 /* support for functions other than function 0 */ |
>> +                0x1 << 5 /* support for function 5 */
>> +                };
>> +    buf = aml_buffer(ARRAY_SIZE(byte_list), byte_list);
>>      aml_append(ifctx1, aml_return(buf));
>>      aml_append(ifctx, ifctx1);
>> +
>> +    /* PCI Firmware Specification 3.1
>> +     * 4.6.5. _DSM for Ignoring PCI Boot Configurations
>> +     */
>> +    /* Arg2: Function Index: 5 */
>> +    ifctx1 = aml_if(aml_equal(aml_arg(2), aml_int(5)));
>> +    /* 0 - The operating system must not ignore the PCI configuration that
>> +     *     firmware has done at boot time.
>> +     */
>> +    aml_append(ifctx1, aml_return(aml_int(0)));
>> +    aml_append(ifctx, ifctx1);
>>      aml_append(method, ifctx);
>>  
>>      byte_list[0] = 0;
> 
> .
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]