From: Joao Martins <joao.m.martins@oracle.com>
To: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>,
qemu-devel@nongnu.org
Cc: pbonzini@redhat.com, mtosatti@redhat.com, mst@redhat.com,
marcel.apfelbaum@gmail.com, jon.grimm@amd.com,
santosh.shukla@amd.com, vasant.hegde@amd.com, Wei.Huang2@amd.com,
Ruihui.Dian@amd.com, bsd@redhat.com, berrange@redhat.com
Subject: Re: [PATCH] hw/i386/amd_iommu: Allow migration
Date: Thu, 21 Nov 2024 11:42:23 +0000 [thread overview]
Message-ID: <cae2e18a-a090-4bdc-b3b9-cf72393436b0@oracle.com> (raw)
In-Reply-To: <20241120073114.20774-1-suravee.suthikulpanit@amd.com>
On 20/11/2024 07:31, Suravee Suthikulpanit wrote:
> Add migration support for AMD IOMMU model by saving necessary AMDVIState
> parameters for MMIO registers, device table, command buffer, and event
> buffers.
>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> hw/i386/amd_iommu.c | 36 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
> index 13af7211e1..3d2bb9d81e 100644
> --- a/hw/i386/amd_iommu.c
> +++ b/hw/i386/amd_iommu.c
> @@ -1673,7 +1673,41 @@ static Property amdvi_properties[] = {
>
> static const VMStateDescription vmstate_amdvi_sysbus = {
> .name = "amd-iommu",
> - .unmigratable = 1
> + .version_id = 1,
> + .minimum_version_id = 1,
> + .priority = MIG_PRI_IOMMU,
> + .fields = (VMStateField[]) {
> + /* Updated in amdvi_handle_control_write() */
> + VMSTATE_BOOL(enabled, AMDVIState),
no xtsup ? I guess you are relying on the dest command line having xtsup=on
like intel-iommu
> + VMSTATE_BOOL(ga_enabled, AMDVIState),
> + VMSTATE_BOOL(ats_enabled, AMDVIState),
> + VMSTATE_BOOL(cmdbuf_enabled, AMDVIState),
> + VMSTATE_BOOL(completion_wait_intr, AMDVIState),
> + VMSTATE_BOOL(evtlog_enabled, AMDVIState),
> + VMSTATE_BOOL(evtlog_intr, AMDVIState),
> + /* Updated in amdvi_handle_devtab_write() */
> + VMSTATE_UINT64(devtab, AMDVIState),
> + VMSTATE_UINT64(devtab_len, AMDVIState),
> + /* Updated in amdvi_handle_cmdbase_write() */
> + VMSTATE_UINT64(cmdbuf, AMDVIState),
> + VMSTATE_UINT64(cmdbuf_len, AMDVIState),
> + /* Updated in amdvi_handle_cmdhead_write() */
> + VMSTATE_UINT32(cmdbuf_head, AMDVIState),
> + /* Updated in amdvi_handle_cmdtail_write() */
> + VMSTATE_UINT32(cmdbuf_tail, AMDVIState),
> + /* Updated in amdvi_handle_evtbase_write() */
> + VMSTATE_UINT64(evtlog, AMDVIState),
> + VMSTATE_UINT32(evtlog_len, AMDVIState),
> + /* Updated in amdvi_handle_evthead_write() */
> + VMSTATE_UINT32(evtlog_head, AMDVIState),
> + /* Updated in amdvi_handle_evttail_write() */
> + VMSTATE_UINT32(evtlog_tail, AMDVIState),
Are we missing:
ppr_log
pprlog_len
pprlog_head
pprlog_tail
?
Although perhaps excluding it was deliberate given that these aren't actually
fed with PPR log entries, only register initialization. Given no PPR entries are
generated it's doing nothing useful.
Out of correctness this is guest initialized data, so perhaps it should be
included such that it doesn't suddenly see different values on destination. In
theory you 'just' need to wire in qemu a VF generating PPR log entries for page
requests, so the log will eventually be what you need to migrate anyhow like the
event log...?
> + /* MMIO registers */
> + VMSTATE_UINT8_ARRAY(mmior, AMDVIState, AMDVI_MMIO_SIZE),
> + VMSTATE_UINT8_ARRAY(romask, AMDVIState, AMDVI_MMIO_SIZE),
> + VMSTATE_UINT8_ARRAY(w1cmask, AMDVIState, AMDVI_MMIO_SIZE),
> + VMSTATE_END_OF_LIST()
> + }
> };
>
> static void amdvi_sysbus_instance_init(Object *klass)
next prev parent reply other threads:[~2024-11-21 11:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 7:31 [PATCH] hw/i386/amd_iommu: Allow migration Suravee Suthikulpanit
2024-11-21 11:42 ` Joao Martins [this message]
2024-11-28 17:14 ` Joao Martins
2024-12-18 9:48 ` Vasant Hegde
2025-02-05 2:45 ` Suthikulpanit, Suravee
2025-02-05 10:20 ` Joao Martins
2025-02-05 2:17 ` Suthikulpanit, Suravee
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=cae2e18a-a090-4bdc-b3b9-cf72393436b0@oracle.com \
--to=joao.m.martins@oracle.com \
--cc=Ruihui.Dian@amd.com \
--cc=Wei.Huang2@amd.com \
--cc=berrange@redhat.com \
--cc=bsd@redhat.com \
--cc=jon.grimm@amd.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=santosh.shukla@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 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).