All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Sairaj Kodilkar <sarunkod@amd.com>
Cc: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>,
	Ani Sinha <anisinha@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Igor Mammedov <imammedo@redhat.com>,
	Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	qemu-devel@nongnu.org, vasant.hegde@amd.com,
	suravee.suthikulpanit@amd.com
Subject: Re: [PATCH 5/8] acpi_build: Introduce necessary macros and structs for AMD IOMMU IVRS
Date: Mon, 3 Aug 2026 18:08:15 -0400	[thread overview]
Message-ID: <20260803175632-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20260511123937.32743-6-sarunkod@amd.com>

On Mon, May 11, 2026 at 06:09:34PM +0530, Sairaj Kodilkar wrote:
> Introduce necessary macros, along with packed structs which represents
> the AMD IVRS data structure, to hold the necessary information. This
> will improve readability of the current code.
> 
> Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com>
> ---
>  hw/i386/acpi-build.h | 92 ++++++++++++++++++++++++++++++++++++++++++++
>  hw/i386/amd_iommu.h  |  6 +++
>  2 files changed, 98 insertions(+)
> 
> diff --git a/hw/i386/acpi-build.h b/hw/i386/acpi-build.h
> index 8ba3c33e4831..9fd60a186db1 100644
> --- a/hw/i386/acpi-build.h
> +++ b/hw/i386/acpi-build.h
> @@ -2,10 +2,102 @@
>  #ifndef HW_I386_ACPI_BUILD_H
>  #define HW_I386_ACPI_BUILD_H
>  #include "hw/acpi/acpi-defs.h"
> +#include "qemu/bitops.h"
>  
>  extern const struct AcpiGenericAddress x86_nvdimm_acpi_dsmio;
>  
>  void acpi_setup(void);
>  Object *acpi_get_i386_pci_host(void);
>  
> +#define AMD_IVINFO_EFR_SUP       BIT(0)
> +
> +#define AMD_IVHD_FLAG_HT_TUN_EN    BIT(0)
> +#define AMD_IVHD_FLAG_IOTLB_SUP    BIT(4)
> +#define AMD_IVHD_FLAG_PREF_SUP     BIT(6)
> +#define AMD_IVHD_FLAG_PPR_SUP      BIT(7)
> +
> +#define AMD_IVHD_FEATURE_REPORT_XT_SUP_SHIFT      (0)
> +#define AMD_IVHD_FEATURE_REPORT_GT_SUP_SHIFT      (2)
> +#define AMD_IVHD_FEATURE_REPORT_GLX_SUP_SHIFT     (3)
> +#define AMD_IVHD_FEATURE_REPORT_GA_SUP_SHIFT      (6)
> +#define AMD_IVHD_FEATURE_REPORT_GATS_SHIFT        (28)
> +#define AMD_IVHD_FEATURE_REPORT_HATS_SHIFT        (30)
> +
> +#define AMD_IVHD_ATTRIBUTES_HATDIS_SHIFT        (0)
> +
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_RESERVED             (0)
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_ALL                  (1)
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_SELECT               (2)
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_START_RANGE          (3)
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_END_RANGE            (4)
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_ALIAS_START_RANGE    (0x43)
> +#define AMD_IVHD_DEVICE_ENTRY_TYPE_SPECIAL_DEVICE       (0x48)
> +
> +#define IVHD_VARIETY_IOAPIC (1)
> +#define IVHD_VARIETY_HPET   (2)
> +
> +/*
> + * Vendor(AMD) specific fields in the IVRS header
> + * Excludes fields in ACPI table header
> + */
> +typedef
> +struct AmdIvrsVendorHdr {
> +    uint32_t ivinfo;
> +    uint64_t reserved;
> +} __attribute__((packed)) AmdIvrsVendorHdr;
> +
> +/* IVHD type 10h */
> +typedef
> +struct AmdIvhdHdr10 {
> +    uint8_t type;
> +    uint8_t flags;
> +    uint16_t length;
> +    uint16_t devid;
> +    uint16_t capab_offset;
> +    uint64_t base_addr;
> +    uint16_t pci_seg;
> +    uint16_t iommu_info;
> +    uint32_t iommu_feature_report;
> +} __attribute__((packed)) AmdIvhdHdr10;
> +
> +/* IVHD type 11h */
> +typedef
> +struct AmdIvhdHdr11 {
> +    uint8_t type;
> +    uint8_t flags;
> +    uint16_t length;
> +    uint16_t devid;
> +    uint16_t capab_offset;
> +    uint64_t base_addr;
> +    uint16_t pci_seg;
> +    uint16_t iommu_info;
> +    uint32_t iommu_attributes;
> +    uint64_t efr;
> +    uint64_t efr2;
> +} __attribute__((packed)) AmdIvhdHdr11;
> +
> +typedef
> +struct AmdIvhdDeviceEntry {
> +    uint8_t type;
> +    uint16_t devid;
> +    uint8_t dte_setting;
> +} __attribute__((packed)) AmdIvhdDeviceEntry;
> +
> +typedef
> +struct AmdIvhdDeviceEntryExt {
> +    uint8_t type;
> +    uint16_t devid_a;
> +    uint8_t dte_setting;
> +    union {
> +        struct {
> +            uint8_t handle;
> +            uint16_t devid_b;
> +            uint8_t variety;
> +        } __attribute__((packed));
> +        struct {
> +            uint32_t ext_dte_setting;
> +        } __attribute__((packed));
> +    };
> +} __attribute__((packed)) AmdIvhdDeviceEntryExt;
> +
>  #endif


Pls do not do this is not how we build ACPI tables.
It is completely impossible to match fields and structs to
spec since it does not repeat it verbatim.



Instead of all this write functions matching spec exactly.
Examples:

	/* Table 104: IVHD Device Entry Type Codes (8-byte) */
	build_append_int_noprefix(....) /* Handle */
	build_append_int_noprefix(....) /* DevIDb */
	build_append_int_noprefix(....) /* Variety */


Same with all these numbers they are used exactly once.
Instead of a macro document in a comment:

build_append_int_noprefix(.... (0x0 << 30 /* 00b = 4 levels HATS */) |
			  ....)



You must also find and document for each table the *earliest*
spec that gives the features you are using and where it is in
that spec.
Why earliest? it gives people better idea which guests it can be
compatible with.


> diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
> index fe8f4a6cdc74..d97ddbd612dc 100644
> --- a/hw/i386/amd_iommu.h
> +++ b/hw/i386/amd_iommu.h
> @@ -175,9 +175,15 @@
>  #define AMDVI_DTE_QUAD3_RESERVED        (GENMASK64(14, 0) | GENMASK64(53, 48))
>  
>  /* AMDVI paging mode */
> +#define AMDVI_GATS_MODE_SHIFT           (12)
> +#define AMDVI_GATS_MODE_MASK            (3ULL <<  12)
>  #define AMDVI_GATS_MODE                 (2ULL <<  12)
> +#define AMDVI_HATS_MODE_SHIFT           (10)
> +#define AMDVI_HATS_MODE_MASK            (3ULL <<  10)
>  #define AMDVI_HATS_MODE                 (2ULL <<  10)
>  #define AMDVI_HATS_MODE_RESERVED        (3ULL <<  10)
> +#define AMDVI_GLX_SUP_SHIFT             (14)
> +#define AMDVI_GLX_SUP_MASK              (3ULL << 14)
>  
>  /* Page Table format */
>  
> -- 
> 2.34.1



  parent reply	other threads:[~2026-08-03 22:09 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11 12:39 [PATCH 0/8] acpi_build: Refactor and cleanup AMD IVRS build Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 1/8] tests/acpi: x86: Allow IVRS acpi table changes Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 2/8] amd_iommu: update PA, GVA and VA size macros Sairaj Kodilkar
2026-05-19  8:39   ` Vasant Hegde
2026-07-30 21:41   ` Alejandro Jimenez
2026-08-03 22:15   ` Michael S. Tsirkin
2026-05-11 12:39 ` [PATCH 3/8] amd_iommu: Return empty efr for stub call Sairaj Kodilkar
2026-07-30 21:45   ` Alejandro Jimenez
2026-05-11 12:39 ` [PATCH 4/8] acpi_build: Use IOMMU pci device to build IOMMU device ID Sairaj Kodilkar
2026-07-30 22:35   ` Alejandro Jimenez
2026-07-31  9:50   ` Michael S. Tsirkin
2026-07-31 12:32     ` Sairaj Kodilkar
2026-07-31 21:47       ` Alejandro Jimenez
2026-08-01  0:01         ` Michael S. Tsirkin
2026-08-04  5:01         ` Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 5/8] acpi_build: Introduce necessary macros and structs for AMD IOMMU IVRS Sairaj Kodilkar
2026-08-03 21:35   ` Alejandro Jimenez
2026-08-03 22:08   ` Michael S. Tsirkin [this message]
2026-05-11 12:39 ` [PATCH 6/8] acpi_build: Build IVRS feature report using extended feature register Sairaj Kodilkar
2026-05-19  8:43   ` Vasant Hegde
2026-05-11 12:39 ` [PATCH 7/8] acpi_build: Cleanup AMD IOMMU IVRS building Sairaj Kodilkar
2026-08-03 21:56   ` Michael S. Tsirkin
2026-08-03 22:10   ` Michael S. Tsirkin
2026-08-04  5:23     ` Sairaj Kodilkar
2026-05-11 12:39 ` [PATCH 8/8] tests/acpi: x86: update golden masters for IVRS Sairaj Kodilkar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260803175632-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=alejandro.j.jimenez@oracle.com \
    --cc=anisinha@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=imammedo@redhat.com \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sarunkod@amd.com \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=vasant.hegde@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.