Message ID | 1487198095-1887-1-git-send-email-sgoel@codeaurora.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
>>> On 15.02.17 at 23:34, <sgoel@codeaurora.org> wrote: > From: Lv Zheng <lv.zheng@intel.com> > > ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca > > This patch adds support for IORT (IO Remapping Table) in iasl. > > Note that some field names are modified to shrink their length or the > decompiled IORT ASL will contain fields with ugly ":" alignment. > > The IORT contains field definitions around "Memory Access Properties". This > patch also adds support to encode/decode it using inline table. > > This patch doesn't add inline table support for the SMMU interrupt fields > due to a limitation in current ACPICA data table support. Lv Zheng. > > Link: https://github.com/acpica/acpica/commit/5de82757 > Signed-off-by: Lv Zheng <lv.zheng@intel.com> > Signed-off-by: Bob Moore <robert.moore@intel.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > [Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf] > [only port the IORT changes] > Signed-off-by: Sameer Goel <sgoel@codeaurora.org> While you've Cc-ed quite a few people, you didn't Cc the Xen side maintainers of the code you change. Plus with this not being part of a series, it would also help if you clarified what the change is going to be needed for, as on its own it'll be an addition of dead code. Jan
On Wed, 15 Feb 2017, Sameer Goel wrote: > From: Lv Zheng <lv.zheng@intel.com> > > ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca > > This patch adds support for IORT (IO Remapping Table) in iasl. > > Note that some field names are modified to shrink their length or the > decompiled IORT ASL will contain fields with ugly ":" alignment. > > The IORT contains field definitions around "Memory Access Properties". This > patch also adds support to encode/decode it using inline table. > > This patch doesn't add inline table support for the SMMU interrupt fields > due to a limitation in current ACPICA data table support. Lv Zheng. > > Link: https://github.com/acpica/acpica/commit/5de82757 > Signed-off-by: Lv Zheng <lv.zheng@intel.com> > Signed-off-by: Bob Moore <robert.moore@intel.com> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > [Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf] > [only port the IORT changes] > Signed-off-by: Sameer Goel <sgoel@codeaurora.org> if this is a straight port from linux, then please don't make other changes on top of it such as: > @@ -5,7 +5,7 @@ > *****************************************************************************/ > > /* > - * Copyright (C) 2000 - 2011, Intel Corp. > + * Copyright (C) 2000 - 2016, Intel Corp. > * All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > @@ -67,7 +67,8 @@ > #define ACPI_SIG_DBGP "DBGP" /* Debug Port table */ > #define ACPI_SIG_DMAR "DMAR" /* DMA Remapping table */ > #define ACPI_SIG_HPET "HPET" /* High Precision Event Timer table */ > -#define ACPI_SIG_IBFT "IBFT" /* i_sCSI Boot Firmware Table */ > +#define ACPI_SIG_IBFT "IBFT" /* iSCSI Boot Firmware Table */ [...] > +enum acpi_iort_node_type { > + ACPI_IORT_NODE_ITS_GROUP = 0x00, > + ACPI_IORT_NODE_NAMED_COMPONENT = 0x01, > + ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02, > + ACPI_IORT_NODE_SMMU = 0x03, > + ACPI_IORT_NODE_SMMU_V3 = 0x04 SMMU_V3 wasn't present in 874f6a723e56d0da9e481629b17482bcd3801ecf > +struct acpi_iort_smmu_v3 { > + u64 base_address; /* SMMUv3 base address */ > + u32 flags; > + u32 reserved; > + u64 vatos_address; > + u32 model; /* O: generic SMMUv3 */ > + u32 event_gsiv; > + u32 pri_gsiv; > + u32 gerr_gsiv; > + u32 sync_gsiv; > +}; > + > +/* Masks for Flags field above */ > + > +#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1) > +#define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1) Same here. I think you also need 4ac78baf88d85c49883fcc87d31198ebe408e54d
Appreciate the feedback. I want to use these defines for parsing out SMMUv3 components defined in ACPI. Since, I am picking these defines directly from Linux, I did not want to make this a part of a newly developed patch set. I will update the cc list. Thanks, Sameer On 2/16/2017 2:57 AM, Jan Beulich wrote: >>>> On 15.02.17 at 23:34, <sgoel@codeaurora.org> wrote: >> From: Lv Zheng <lv.zheng@intel.com> >> >> ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca >> >> This patch adds support for IORT (IO Remapping Table) in iasl. >> >> Note that some field names are modified to shrink their length or the >> decompiled IORT ASL will contain fields with ugly ":" alignment. >> >> The IORT contains field definitions around "Memory Access Properties". This >> patch also adds support to encode/decode it using inline table. >> >> This patch doesn't add inline table support for the SMMU interrupt fields >> due to a limitation in current ACPICA data table support. Lv Zheng. >> >> Link: https://github.com/acpica/acpica/commit/5de82757 >> Signed-off-by: Lv Zheng <lv.zheng@intel.com> >> Signed-off-by: Bob Moore <robert.moore@intel.com> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> [Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf] >> [only port the IORT changes] >> Signed-off-by: Sameer Goel <sgoel@codeaurora.org> > > While you've Cc-ed quite a few people, you didn't Cc the Xen > side maintainers of the code you change. Plus with this not > being part of a series, it would also help if you clarified what > the change is going to be needed for, as on its own it'll be an > addition of dead code. > > Jan > >
On 2/16/2017 5:59 PM, Stefano Stabellini wrote: > On Wed, 15 Feb 2017, Sameer Goel wrote: >> From: Lv Zheng <lv.zheng@intel.com> >> >> ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca >> >> This patch adds support for IORT (IO Remapping Table) in iasl. >> >> Note that some field names are modified to shrink their length or the >> decompiled IORT ASL will contain fields with ugly ":" alignment. >> >> The IORT contains field definitions around "Memory Access Properties". This >> patch also adds support to encode/decode it using inline table. >> >> This patch doesn't add inline table support for the SMMU interrupt fields >> due to a limitation in current ACPICA data table support. Lv Zheng. >> >> Link: https://github.com/acpica/acpica/commit/5de82757 >> Signed-off-by: Lv Zheng <lv.zheng@intel.com> >> Signed-off-by: Bob Moore <robert.moore@intel.com> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> [Linux commit 874f6a723e56d0da9e481629b17482bcd3801ecf] >> [only port the IORT changes] >> Signed-off-by: Sameer Goel <sgoel@codeaurora.org> > > if this is a straight port from linux, then please don't make other > changes on top of it such as: > > >> @@ -5,7 +5,7 @@ >> *****************************************************************************/ >> >> /* >> - * Copyright (C) 2000 - 2011, Intel Corp. >> + * Copyright (C) 2000 - 2016, Intel Corp. >> * All rights reserved. >> * >> * Redistribution and use in source and binary forms, with or without >> @@ -67,7 +67,8 @@ >> #define ACPI_SIG_DBGP "DBGP" /* Debug Port table */ >> #define ACPI_SIG_DMAR "DMAR" /* DMA Remapping table */ >> #define ACPI_SIG_HPET "HPET" /* High Precision Event Timer table */ >> -#define ACPI_SIG_IBFT "IBFT" /* i_sCSI Boot Firmware Table */ >> +#define ACPI_SIG_IBFT "IBFT" /* iSCSI Boot Firmware Table */ > > [...] > >> +enum acpi_iort_node_type { >> + ACPI_IORT_NODE_ITS_GROUP = 0x00, >> + ACPI_IORT_NODE_NAMED_COMPONENT = 0x01, >> + ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02, >> + ACPI_IORT_NODE_SMMU = 0x03, >> + ACPI_IORT_NODE_SMMU_V3 = 0x04 > > SMMU_V3 wasn't present in 874f6a723e56d0da9e481629b17482bcd3801ecf > > >> +struct acpi_iort_smmu_v3 { >> + u64 base_address; /* SMMUv3 base address */ >> + u32 flags; >> + u32 reserved; >> + u64 vatos_address; >> + u32 model; /* O: generic SMMUv3 */ >> + u32 event_gsiv; >> + u32 pri_gsiv; >> + u32 gerr_gsiv; >> + u32 sync_gsiv; >> +}; >> + >> +/* Masks for Flags field above */ >> + >> +#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1) >> +#define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1) > > Same here. > > I think you also need 4ac78baf88d85c49883fcc87d31198ebe408e54d > Thanks for the feedback Stefano. I will make the required changes. Sameer
>>> On 22.02.17 at 21:29, <sgoel@codeaurora.org> wrote: Please don't top-post. > Appreciate the feedback. I want to use these defines for parsing out SMMUv3 > components defined in ACPI. Since, I am picking these defines directly from > Linux, I did not want to make this a part of a newly developed patch set. What's wrong with the patch here being part of a patch set, allowing reviewers to understand context? Jan
Hi, On 23/02/17 07:39, Jan Beulich wrote: >>>> On 22.02.17 at 21:29, <sgoel@codeaurora.org> wrote: > > Please don't top-post. > >> Appreciate the feedback. I want to use these defines for parsing out SMMUv3 >> components defined in ACPI. Since, I am picking these defines directly from >> Linux, I did not want to make this a part of a newly developed patch set. > > What's wrong with the patch here being part of a patch set, allowing > reviewers to understand context? The IORT will be used to retrieve information to configure different drivers (ITS and SMMUs). All the drivers don't have dependency between each other but the IORT. As they will be contributed by different stakeholders, it would be good to get this header checked-in in Xen as soon as possible to have a common ground for adding drivers. Ideally, I would like to see the IORT parsing going at the same time as this header. So everyone could re-use it without having to depend on unrelated series. Cheers,
>>> On 23.02.17 at 14:59, <julien.grall@arm.com> wrote: > On 23/02/17 07:39, Jan Beulich wrote: >>>>> On 22.02.17 at 21:29, <sgoel@codeaurora.org> wrote: >>> Appreciate the feedback. I want to use these defines for parsing out SMMUv3 >>> components defined in ACPI. Since, I am picking these defines directly from >>> Linux, I did not want to make this a part of a newly developed patch set. >> >> What's wrong with the patch here being part of a patch set, allowing >> reviewers to understand context? > > The IORT will be used to retrieve information to configure different > drivers (ITS and SMMUs). All the drivers don't have dependency between > each other but the IORT. As they will be contributed by different > stakeholders, it would be good to get this header checked-in in Xen as > soon as possible to have a common ground for adding drivers. > > Ideally, I would like to see the IORT parsing going at the same time as > this header. So everyone could re-use it without having to depend on > unrelated series. Well, you basically confirm that the header on its own isn't of much use - you want parsing code to go in at the same time. That is what I'm asking for: Have some user of the new definitions to allow seeing context of what they are needed for. Jan
Hi Jan, On 23/02/17 15:02, Jan Beulich wrote: >>>> On 23.02.17 at 14:59, <julien.grall@arm.com> wrote: >> On 23/02/17 07:39, Jan Beulich wrote: >>>>>> On 22.02.17 at 21:29, <sgoel@codeaurora.org> wrote: >>>> Appreciate the feedback. I want to use these defines for parsing out SMMUv3 >>>> components defined in ACPI. Since, I am picking these defines directly from >>>> Linux, I did not want to make this a part of a newly developed patch set. >>> >>> What's wrong with the patch here being part of a patch set, allowing >>> reviewers to understand context? >> >> The IORT will be used to retrieve information to configure different >> drivers (ITS and SMMUs). All the drivers don't have dependency between >> each other but the IORT. As they will be contributed by different >> stakeholders, it would be good to get this header checked-in in Xen as >> soon as possible to have a common ground for adding drivers. >> >> Ideally, I would like to see the IORT parsing going at the same time as >> this header. So everyone could re-use it without having to depend on >> unrelated series. > > Well, you basically confirm that the header on its own isn't of much > use - you want parsing code to go in at the same time. That is what > I'm asking for: Have some user of the new definitions to allow seeing > context of what they are needed for. I don't think the parsing is strictly necessary to have it at first, hence why I said ideally. The IORT is clearly defined in the spec ([1]), so I don't see any risk to accept this header before hand. The benefits is we can get people starting to write code using IORT either for parsing or generating it. Cheers, [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
diff --git a/xen/include/acpi/actbl2.h b/xen/include/acpi/actbl2.h index d2327d2..e13c823 100644 --- a/xen/include/acpi/actbl2.h +++ b/xen/include/acpi/actbl2.h @@ -5,7 +5,7 @@ *****************************************************************************/ /* - * Copyright (C) 2000 - 2011, Intel Corp. + * Copyright (C) 2000 - 2016, Intel Corp. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -67,7 +67,8 @@ #define ACPI_SIG_DBGP "DBGP" /* Debug Port table */ #define ACPI_SIG_DMAR "DMAR" /* DMA Remapping table */ #define ACPI_SIG_HPET "HPET" /* High Precision Event Timer table */ -#define ACPI_SIG_IBFT "IBFT" /* i_sCSI Boot Firmware Table */ +#define ACPI_SIG_IBFT "IBFT" /* iSCSI Boot Firmware Table */ +#define ACPI_SIG_IORT "IORT" /* IO Remapping Table */ #define ACPI_SIG_IVRS "IVRS" /* I/O Virtualization Reporting Structure */ #define ACPI_SIG_MCFG "MCFG" /* PCI Memory Mapped Configuration table */ #define ACPI_SIG_MCHI "MCHI" /* Management Controller Host Interface table */ @@ -556,6 +557,149 @@ struct acpi_ibft_target { /******************************************************************************* * + * IORT - IO Remapping Table + * + * Conforms to "IO Remapping Table System Software on ARM Platforms", + * Document number: ARM DEN 0049B, October 2015 + * + ******************************************************************************/ + +struct acpi_table_iort { + struct acpi_table_header header; + u32 node_count; + u32 node_offset; + u32 reserved; +}; + +/* + * IORT subtables + */ +struct acpi_iort_node { + u8 type; + u16 length; + u8 revision; + u32 reserved; + u32 mapping_count; + u32 mapping_offset; + char node_data[1]; +}; + +/* Values for subtable Type above */ + +enum acpi_iort_node_type { + ACPI_IORT_NODE_ITS_GROUP = 0x00, + ACPI_IORT_NODE_NAMED_COMPONENT = 0x01, + ACPI_IORT_NODE_PCI_ROOT_COMPLEX = 0x02, + ACPI_IORT_NODE_SMMU = 0x03, + ACPI_IORT_NODE_SMMU_V3 = 0x04 +}; + +struct acpi_iort_id_mapping { + u32 input_base; /* Lowest value in input range */ + u32 id_count; /* Number of IDs */ + u32 output_base; /* Lowest value in output range */ + u32 output_reference; /* A reference to the output node */ + u32 flags; +}; + +/* Masks for Flags field above for IORT subtable */ + +#define ACPI_IORT_ID_SINGLE_MAPPING (1) + +struct acpi_iort_memory_access { + u32 cache_coherency; + u8 hints; + u16 reserved; + u8 memory_flags; +}; + +/* Values for cache_coherency field above */ + +#define ACPI_IORT_NODE_COHERENT 0x00000001 /* The device node is fully coherent */ +#define ACPI_IORT_NODE_NOT_COHERENT 0x00000000 /* The device node is not coherent */ + +/* Masks for Hints field above */ + +#define ACPI_IORT_HT_TRANSIENT (1) +#define ACPI_IORT_HT_WRITE (1<<1) +#define ACPI_IORT_HT_READ (1<<2) +#define ACPI_IORT_HT_OVERRIDE (1<<3) + +/* Masks for memory_flags field above */ + +#define ACPI_IORT_MF_COHERENCY (1) +#define ACPI_IORT_MF_ATTRIBUTES (1<<1) + +/* + * IORT node specific subtables + */ +struct acpi_iort_its_group { + u32 its_count; + u32 identifiers[1]; /* GIC ITS identifier arrary */ +}; + +struct acpi_iort_named_component { + u32 node_flags; + u64 memory_properties; /* Memory access properties */ + u8 memory_address_limit; /* Memory address size limit */ + char device_name[1]; /* Path of namespace object */ +}; + +struct acpi_iort_root_complex { + u64 memory_properties; /* Memory access properties */ + u32 ats_attribute; + u32 pci_segment_number; +}; + +/* Values for ats_attribute field above */ + +#define ACPI_IORT_ATS_SUPPORTED 0x00000001 /* The root complex supports ATS */ +#define ACPI_IORT_ATS_UNSUPPORTED 0x00000000 /* The root complex doesn't support ATS */ + +struct acpi_iort_smmu { + u64 base_address; /* SMMU base address */ + u64 span; /* Length of memory range */ + u32 model; + u32 flags; + u32 global_interrupt_offset; + u32 context_interrupt_count; + u32 context_interrupt_offset; + u32 pmu_interrupt_count; + u32 pmu_interrupt_offset; + u64 interrupts[1]; /* Interrupt array */ +}; + +/* Values for Model field above */ + +#define ACPI_IORT_SMMU_V1 0x00000000 /* Generic SMMUv1 */ +#define ACPI_IORT_SMMU_V2 0x00000001 /* Generic SMMUv2 */ +#define ACPI_IORT_SMMU_CORELINK_MMU400 0x00000002 /* ARM Corelink MMU-400 */ +#define ACPI_IORT_SMMU_CORELINK_MMU500 0x00000003 /* ARM Corelink MMU-500 */ + +/* Masks for Flags field above */ + +#define ACPI_IORT_SMMU_DVM_SUPPORTED (1) +#define ACPI_IORT_SMMU_COHERENT_WALK (1<<1) + +struct acpi_iort_smmu_v3 { + u64 base_address; /* SMMUv3 base address */ + u32 flags; + u32 reserved; + u64 vatos_address; + u32 model; /* O: generic SMMUv3 */ + u32 event_gsiv; + u32 pri_gsiv; + u32 gerr_gsiv; + u32 sync_gsiv; +}; + +/* Masks for Flags field above */ + +#define ACPI_IORT_SMMU_V3_COHACC_OVERRIDE (1) +#define ACPI_IORT_SMMU_V3_HTTU_OVERRIDE (1<<1) + +/******************************************************************************* + * * IVRS - I/O Virtualization Reporting Structure * Version 1 *