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

Re: [Xen-devel] [RFC PATCH 10/12] libacpi: build ACPI MCFG table if requested



On Tue, 20 Mar 2018 09:03:56 +0000
Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:

>On Tue, Mar 20, 2018 at 07:46:04AM +1000, Alexey G wrote:
>> On Mon, 19 Mar 2018 17:33:34 +0000
>> Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote:
>>   
>> >On Tue, Mar 13, 2018 at 04:33:55AM +1000, Alexey Gerasimenko
>> >wrote:  
>> >> This adds construct_mcfg() function to libacpi which allows to
>> >> build MCFG table for a given mmconfig_addr/mmconfig_len pair if
>> >> the ACPI_HAS_MCFG flag was specified in acpi_config struct.
>> >> 
>> >> The maximum bus number is calculated from mmconfig_len using
>> >> MCFG_SIZE_TO_NUM_BUSES macro (1MByte of MMIO space per bus).
>> >> 
>> >> Signed-off-by: Alexey Gerasimenko <x1917x@xxxxxxxxx>
>> >> ---
>> >>  tools/libacpi/acpi2_0.h | 21 +++++++++++++++++++++
>> >>  tools/libacpi/build.c   | 42
>> >> ++++++++++++++++++++++++++++++++++++++++++ tools/libacpi/libacpi.h
>> >> |  4 ++++ 3 files changed, 67 insertions(+)
>> >> 
>> >> diff --git a/tools/libacpi/acpi2_0.h b/tools/libacpi/acpi2_0.h
>> >> index 2619ba32db..209ad1acd3 100644
>> >> --- a/tools/libacpi/acpi2_0.h
>> >> +++ b/tools/libacpi/acpi2_0.h
>> >> @@ -422,6 +422,25 @@ struct acpi_20_slit {
>> >>  };
>> >>  
>> >>  /*
>> >> + * PCI Express Memory Mapped Configuration Description Table
>> >> + */
>> >> +struct mcfg_range_entry {
>> >> +    uint64_t base_address;
>> >> +    uint16_t pci_segment;
>> >> +    uint8_t  start_pci_bus_num;
>> >> +    uint8_t  end_pci_bus_num;
>> >> +    uint32_t reserved;
>> >> +};
>> >> +
>> >> +struct acpi_mcfg {
>> >> +    struct acpi_header header;
>> >> +    uint8_t reserved[8];
>> >> +    struct mcfg_range_entry entries[1];
>> >> +};    
>> >
>> >I would define this as:
>> >
>> >struct acpi_10_mcfg {
>> >    struct acpi_header header;
>> >    uint8_t reserved[8];
>> >    struct acpi_10_mcfg_entry {
>> >        uint64_t base_address;
>> >        uint16_t pci_segment;
>> >        uint8_t  start_pci_bus;
>> >        uint8_t  end_pci_bus;
>> >        uint32_t reserved;
>> >    } entries[1];
>> >};  
>> 
>> Hmm, a choice of preference, but OK, will move it inside.  
>
>Note the name change also (acpi_10_mcfg). Also I think you can drop
>the acpi_10_mcfg_entry name and just use an anonymous struct.
>
>> >> +
>> >> +    mcfg->entries[0].base_address = config->mmconfig_addr;
>> >> +    mcfg->entries[0].pci_segment = 0;
>> >> +    mcfg->entries[0].start_pci_bus_num = 0;
>> >> +    mcfg->entries[0].end_pci_bus_num =
>> >> +        MCFG_SIZE_TO_NUM_BUSES(config->mmconfig_len) - 1;    
>> >
>> >Why not pass the start_bus and end_bus values in acpi_config at
>> >least?  
>> 
>> start_pci_bus_num will be always 0.
>> 
>> It will be kinda ugly to pass config->mmconfig_addr along with
>> config->end_pci_bus_num, baseaddr+size combo looks nicer I think.  
>I'm not going to insist, but ACPI doesn't really care about the size,
>it just needs to know the start and end. Seems pointless to write a
>value here that later libacpi needs to convert to the value it
>actually needs. Also start/end buses are uint8_t, size is uint32_t.

As the underlying implementation is limited to just one PCI segment
and we need to pass only one MCFG range entry, I guess it will be ok to
use the mmconfig_addr + mmconfig_num_buses pair (almost same as
end_bus, but more size-descriptive).



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.