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

[Stefan Berger <stefanb@linux.ibm.com>]

On 7/14/23 13:04, Joelle van Dyne wrote:
> 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

Why can we not keep the old style register mapping as 'secondary mapping'?

The expectation is that old VM state / CRB state can be used by the new QEMU and
also new QEMU CRB state should be readable by old QEMU. So in a way the old 'secondary'
mmaping has to hold the true value of the registers so that the latter works.


> 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).