Re: [PATCH v2 11/11] tpm_crb: support restoring older vmstate

[Joelle van Dyne]

On Fri, Jul 14, 2023 at 7:51 AM Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>
>
> On 7/14/23 10:05, Stefan Berger wrote:
> >
> >
> > On 7/14/23 03:09, Joelle van Dyne wrote:
> >> When we moved to a single mapping and modified TPM CRB's VMState, it
> >> broke restoring of VMs that were saved on an older version. This
> >> change allows those VMs to gracefully migrate to the new memory
> >> mapping.
> >
> > Thanks. This has to be in 4/11 though.
> >
>
> After applying the whole series and trying to resume state taken with current 
> git
> master I cannot restore it but it leads to this error here. I would just 
> leave it
> completely untouched in 4/11.
>
> 2023-07-14T14:46:34.547550Z qemu-system-x86_64: Unknown ramblock 
> "tpm-crb-cmd", cannot accept migration
> 2023-07-14T14:46:34.547799Z qemu-system-x86_64: error while loading state for 
> instance 0x0 of device 'ram'
> 2023-07-14T14:46:34.547835Z qemu-system-x86_64: load of migration failed: 
> Invalid argument
>
>     Stefan

To be clear, you are asking to back out of 4/11? That patch changes
how the registers are mapped so it's impossible to support the old
style register mapping. This patch attempts to fix that with a
migration path but I realized that I missed the "tpm-crb-cmd"
ramblock. It can be added to v3 for this patch. Similar to the logic
to have `legacy_regs` we will add a `legacy_cmdmem` memory region that
is not registered with the system bus but only exists to migrate the
data. Would that work? Also open to better ideas on migrating legacy
saved state.

If we back out of 4/11 (the split mapping), then the proposed way for
working on Apple Silicon would not be available and we would have to
go down the path of emulating AArch64 instruction in HVF backend (or
decide not to support Apple Silicon).