qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alejandro Jimenez <alejandro.j.jimenez@oracle.com>
To: Sairaj Kodilkar <sarunkod@amd.com>, qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, richard.henderson@linaro.org,
	eduardo@habkost.net, mst@redhat.com, marcel.apfelbaum@gmail.com,
	Vasant Hegde <vasant.hegde@amd.com>
Subject: Re: [PATCH 2/3] amd_iommu: Turn on XT support only when guest has enabled it
Date: Tue, 25 Nov 2025 18:04:01 -0500	[thread overview]
Message-ID: <40b36c5f-5e47-48a4-bd39-667040f53a05@oracle.com> (raw)
In-Reply-To: <20251118082403.3455-3-sarunkod@amd.com>

Hi Sairaj,

I have a couple of suggestions, and one addition I believe is needed in 
the code, but overall looks good.

On 11/18/25 3:24 AM, Sairaj Kodilkar wrote:
> Current code uses 32 bit cpu destination irrespective of the fact that

s/"32 bit cpu destination"/"32-bit destination ID"

I think it fits the language used by the spec slightly better.

> guest has enabled xt support through control register[XTEn] and

a guest has enabled x2APIC support ...

I think it is better to replace "xt" above with "x2APIC", which 
describes what the XT feature is/does.

> completely depends on command line parameter xtsup=on. This is not a
> correct hardware behaviour and can cause problems in the guest which has
> not enabled XT mode.
> 
> Introduce new flag "xten", which is enabled when guest writes 1 to the
> control register bit 50 (XTEn).
> 
> Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com>
> ---
>   hw/i386/amd_iommu.c | 3 ++-
>   hw/i386/amd_iommu.h | 4 +++-
>   2 files changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> index a9ee7150ef17..7f08fc31111a 100644
> --- a/hw/i386/amd_iommu.c
> +++ b/hw/i386/amd_iommu.c
> @@ -1548,6 +1548,7 @@ static void amdvi_handle_control_write(AMDVIState *s)
>       s->cmdbuf_enabled = s->enabled && !!(control &
>                           AMDVI_MMIO_CONTROL_CMDBUFLEN);
>       s->ga_enabled = !!(control & AMDVI_MMIO_CONTROL_GAEN);
> +    s->xten = !!(control & AMDVI_MMIO_CONTROL_XTEN) && s->xtsup;
>   

I think we should also include a new xten field in 
vmstate_amdvi_sysbus_migratable, to ensure the remapping behavior stays 
consistent after migration. i.e.

diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 9bf36ef608..5940011ef1 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -2452,6 +2452,7 @@ static const VMStateDescription 
vmstate_amdvi_sysbus_migratable = {
        /* Updated in  amdvi_handle_control_write() */
        VMSTATE_BOOL(enabled, AMDVIState),
        VMSTATE_BOOL(ga_enabled, AMDVIState),
+      VMSTATE_BOOL(xten, AMDVIState),
        /* bool ats_enabled is obsolete */
        VMSTATE_UNUSED(1), /* was ats_enabled */
        VMSTATE_BOOL(cmdbuf_enabled, AMDVIState),

There is more work to do there, but this seems straightforward.

>       /* update the flags depending on the control register */
>       if (s->cmdbuf_enabled) {
> @@ -2020,7 +2021,7 @@ static int amdvi_int_remap_ga(AMDVIState *iommu,
>       irq->vector = irte.hi.fields.vector;
>       irq->dest_mode = irte.lo.fields_remap.dm;
>       irq->redir_hint = irte.lo.fields_remap.rq_eoi;
> -    if (iommu->xtsup) {
> +    if (iommu->xten) {
>           irq->dest = irte.lo.fields_remap.destination |
>                       (irte.hi.fields.destination_hi << 24);
>       } else {
> diff --git a/hw/i386/amd_iommu.h b/hw/i386/amd_iommu.h
> index 302ccca5121f..32467d0bc241 100644
> --- a/hw/i386/amd_iommu.h
> +++ b/hw/i386/amd_iommu.h
> @@ -106,6 +106,7 @@
>   #define AMDVI_MMIO_CONTROL_COMWAITINTEN   (1ULL << 4)
>   #define AMDVI_MMIO_CONTROL_CMDBUFLEN      (1ULL << 12)
>   #define AMDVI_MMIO_CONTROL_GAEN           (1ULL << 17)
> +#define AMDVI_MMIO_CONTROL_XTEN           (1ULL << 50)
>   
>   /* MMIO status register bits */
>   #define AMDVI_MMIO_STATUS_CMDBUF_RUN  (1 << 4)
> @@ -418,7 +419,8 @@ struct AMDVIState {
>   
>       /* Interrupt remapping */
>       bool ga_enabled;
> -    bool xtsup;
> +    bool xtsup;     /* xtsup=on command line */
> +    bool xten;      /* Enable x2apic */
>   

I'd reword the comment to indicate this what the guest toggles for 
enabling x2apic. e.g.

bool xten;      /* guest controlled, x2apic mode enabled */

I am aware that other fields that are also "guest controlled" don't have 
similar comments. My idea is to highlight that the xten is "toggled" at 
runtime, and is different from xtsup, which is a capability inherent to 
the hardware being emulated and set during initialization.

Thank you,
Alejandro

>       /* DMA address translation */
>       bool dma_remap;




  reply	other threads:[~2025-11-25 23:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18  8:24 [PATCH 0/3] amd_iommu: Support Generation of IOMMU XT interrupts Sairaj Kodilkar
2025-11-18  8:24 ` [PATCH 1/3] amd_iommu: Use switch case to determine mmio register name Sairaj Kodilkar
2025-11-20  1:36   ` Alejandro Jimenez
2025-11-20  4:43     ` Sairaj Kodilkar
2025-11-20 13:31       ` Alejandro Jimenez
2025-11-21  5:20         ` Sairaj Kodilkar
2025-11-21 16:36           ` Alejandro Jimenez
2025-11-18  8:24 ` [PATCH 2/3] amd_iommu: Turn on XT support only when guest has enabled it Sairaj Kodilkar
2025-11-25 23:04   ` Alejandro Jimenez [this message]
2025-11-26  5:12     ` Sairaj Kodilkar
2025-11-26 12:13     ` Sairaj Kodilkar
2025-11-26 22:16       ` Alejandro Jimenez
2025-11-27  6:18         ` Sairaj Kodilkar
2025-11-18  8:24 ` [PATCH 3/3] amd_iommu: Generate XT interrupts when xt support is enabled Sairaj Kodilkar
2025-12-03 18:09   ` Alejandro Jimenez
2025-12-04  8:17     ` Sairaj Kodilkar
2025-11-19 10:38 ` [PATCH 0/3] amd_iommu: Support Generation of IOMMU XT interrupts Vasant Hegde

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=40b36c5f-5e47-48a4-bd39-667040f53a05@oracle.com \
    --to=alejandro.j.jimenez@oracle.com \
    --cc=eduardo@habkost.net \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sarunkod@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).