diff mbox

ACPICA: ACPI 6.0: Add support for IORT table.

Message ID 1487198095-1887-1-git-send-email-sgoel@codeaurora.org (mailing list archive)
State New, archived
Headers show

Commit Message

Goel, Sameer Feb. 15, 2017, 10:34 p.m. UTC
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>
---
 xen/include/acpi/actbl2.h | 148 +++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 146 insertions(+), 2 deletions(-)

Comments

Jan Beulich Feb. 16, 2017, 9:57 a.m. UTC | #1
>>> 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
Stefano Stabellini Feb. 17, 2017, 12:59 a.m. UTC | #2
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
Goel, Sameer Feb. 22, 2017, 8:29 p.m. UTC | #3
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
> 
>
Goel, Sameer Feb. 22, 2017, 8:30 p.m. UTC | #4
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
Jan Beulich Feb. 23, 2017, 7:39 a.m. UTC | #5
>>> 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
Julien Grall Feb. 23, 2017, 1:59 p.m. UTC | #6
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,
Jan Beulich Feb. 23, 2017, 3:02 p.m. UTC | #7
>>> 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
Julien Grall Feb. 23, 2017, 3:14 p.m. UTC | #8
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 mbox

Patch

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
  *