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

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

On 7/14/23 14:22, Stefan Berger wrote:
> 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'?

I think the first goal should be for existing TPM CRB device not to change anything, they
keep their .read and .write behaivor as it.

If you need different .read behavior for the sysbus device due to AARCH64 then it may want to use its own MemoryRegionOps.

I am fairly sure that you could refactor the core of the existing tpm_crb_mmio_write() and have it work on s->regs and mmio regs.
The former would be used by existing code, the latter for CRB sysbus calling into this new function from a wrapper.

    Stefan