linux-kernel - Re: [PATCH 1/4] ACPICA: Define MRRM ACPI table

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJZ5v0gfeiHOVzi=YLJivuc7yt=1Rmbo6u759B0=xp_hTOAjXg@mail.gmail.com>
Date: Tue, 11 Feb 2025 13:16:05 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Tony Luck <tony.luck@...el.com>
Cc: Robert Moore <robert.moore@...el.com>, 
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>, Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org, 
	acpica-devel@...ts.linux.dev, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, David Hildenbrand <david@...hat.com>, Oscar Salvador <osalvador@...e.de>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Danilo Krummrich <dakr@...nel.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org, 
	Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [PATCH 1/4] ACPICA: Define MRRM ACPI table

On Mon, Feb 10, 2025 at 10:12 PM Tony Luck <tony.luck@...el.com> wrote:
>
> From: Fenghua Yu <fenghua.yu@...el.com>
>
> The MRRM table describes association between physical address ranges
> and "region numbers". This is used by:
>
> 1) The /sys/fs/resctrl filesystem to report memory traffic per-RMID for
> each region.
> 2) Perf subsystem to report memory related uncore events per region.
>
> Structure defined in the Intel Resource Director Technology (RDT)
> Architecture specification downloadable from www.intel.com/sdm
>
> Signed-off-by: Fenghua Yu <fenghua.yu@...el.com>
> Signed-off-by: Tony Luck <tony.luck@...el.com>

So the process for ACPICA changes is that they first need to go into
the upstream ACPICA project on GitHub.

Once merged there, you can submit a corresponding Linux patch pointing
to the upstream commit, but submitting it is not mandatory because
upstream material lands in the Linux kernel eventually automatically.

> ---
>  include/acpi/actbl3.h | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
>
> diff --git a/include/acpi/actbl3.h b/include/acpi/actbl3.h
> index 5cd755143b7d..1b9a03ff73ba 100644
> --- a/include/acpi/actbl3.h
> +++ b/include/acpi/actbl3.h
> @@ -42,6 +42,7 @@
>  #define ACPI_SIG_WSMT           "WSMT" /* Windows SMM Security Mitigations Table */
>  #define ACPI_SIG_XENV           "XENV" /* Xen Environment table */
>  #define ACPI_SIG_XXXX           "XXXX" /* Intermediate AML header for ASL/ASL+ converter */
> +#define ACPI_SIG_MRRM           "MRRM" /* Memory Range and Region Mapping table */
>
>  /*
>   * All tables must be byte-packed to match the ACPI specification, since
> @@ -793,6 +794,45 @@ struct acpi_table_xenv {
>         u8 event_flags;
>  };
>
> +/*******************************************************************************
> + *
> + * MRRM - Memory Range and Region Mapping (MRRM) table
> + *
> + ******************************************************************************/
> +
> +struct acpi_table_mrrm {
> +       struct acpi_table_header header;
> +       u8 max_mem_region;      /* Max Memory Regions supported */
> +       u8 flags;               /* Region assignment type */
> +       u8 reserved[26];
> +       /* Memory range entry array */
> +};
> +#define ACPI_MRRM_FLAGS_REGION_ASSIGNMENT_OS   (1<<0)
> +
> +/*******************************************************************************
> + *
> + * Memory Range entry - Memory Range entry in MRRM table
> + *
> + ******************************************************************************/
> +
> +struct acpi_table_mrrm_mem_range_entry {
> +       u16 type;               /* Type 0="MRRM" */
> +       u16 length;             /* 32B + sizeof(Region-ID Programming Reg[]) */
> +       u32 reserved;           /* Reserved */
> +       u32 base_addr_low;      /* Low 32 bits of base addr of the mem range */
> +       u32 base_addr_high;     /* High 32 bits of base addr of the mem range */
> +       u32 len_low;            /* Low 32 bits of length of the mem range */
> +       u32 len_high;           /* High 32 bits of length of the mem range */
> +       u16 region_id_flags;    /* Valid local or remote Region-ID */
> +       u8  local_region_id;    /* Platform-assigned static local Region-ID */
> +       u8  remote_region_id;   /* Platform-assigned static remote Region-ID */
> +       u32 reserved1;          /* Reserved */
> +       /* Region-ID Programming Registers[] */
> +};
> +
> +#define ACPI_MRRM_VALID_REGION_ID_FLAGS_LOCAL  (1<<0)
> +#define ACPI_MRRM_VALID_REGION_ID_FLAGS_REMOTE (1<<1)
> +
>  /* Reset to default packing */
>
>  #pragma pack()
> --
> 2.48.1
>
>