Daniel,
On 2/6/2025 4:01 PM, Daniel P. Berrangé wrote:
On Thu, Feb 06, 2025 at 05:18:56AM +0000, 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.suthikulpa...@amd.com>
---
Changes from v1:
(https://lore.kernel.org/all/9ecffa7a-f4c6-45a5-
a066-84826ccb5...@amd.com/T/)
* Include ppr_log, pprlog_len, pprlog_head, pprlog_tail per Joao.
hw/i386/amd_iommu.c | 43 ++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
index 13af7211e1..a1940a0ab3 100644
--- a/hw/i386/amd_iommu.c
+++ b/hw/i386/amd_iommu.c
@@ -1673,7 +1673,48 @@ static Property amdvi_properties[] = {
static const VMStateDescription vmstate_amdvi_sysbus = {
.name = "amd-iommu",
- .unmigratable = 1
+ .version_id = 1,
IMHO we should not remove the 'unmigratable = 1' setting, until we
have fixed the design problem with this device, to split the creation
of the 'AMDVI-PCI' device off from the 'amd-iommu' device, so that the
former is user creatable.
As it stands now, there's no mechanism to guarantee that the internally
created 'AMDVI-PCI' device gets the same PCI address properties on every
boot. Thus it isn't safe to claim this device is migratable yet IMHO.
I'll send out v3 including the change you suggested, where we split the
creation of AMDVI-PCI device to allow fix enumeration of amd-iommu device.
Thanks,
Suravee
