All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sairaj Kodilkar <sarunkod@amd.com>
To: Alejandro Jimenez <alejandro.j.jimenez@oracle.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: Wed, 26 Nov 2025 17:43:33 +0530	[thread overview]
Message-ID: <3a372c3b-7edf-4e11-9258-7f61c3cdb670@amd.com> (raw)
In-Reply-To: <40b36c5f-5e47-48a4-bd39-667040f53a05@oracle.com>



On 11/26/2025 4:34 AM, Alejandro Jimenez wrote:
> 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),

Hi Alejandro,

I don't think adding a VMSTATE_BOOL directly is a good idea because 
it'll break backward
compatibility (kernel running on older qemu won't be able to migrate on 
newer qemu because
change in the stream length of the migration data). In this case we will 
have to increment
the min_version_number to stop migration from older qemu
I am thinking to add a new subsection as it'll not break the 
compatibility. Let me know what
do you think about this.

Something like this...

static const VMStateDescription vmstate_xt = {
       .name = "amd-iommu-xt",
       .version_id = 1,
       .minimum_version_id = 1,
       .fields = (VMStateField[]) {
           VMSTATE_BOOL(xten, AMDVIState),
       }
};

static const VMStateDescription vmstate_amdvi_sysbus_migratable = {
     ....
     .subsections = (const VMStateDescription *const []) {
                    &vmstate_xt,
                    NULL
     }
};

I have tested above code.

Thanks
Sairaj


  parent reply	other threads:[~2025-11-26 12:14 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
2025-11-26  5:12     ` Sairaj Kodilkar
2025-11-26 12:13     ` Sairaj Kodilkar [this message]
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=3a372c3b-7edf-4e11-9258-7f61c3cdb670@amd.com \
    --to=sarunkod@amd.com \
    --cc=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=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.