On 7/13/23 10:50, Peter Maydell wrote:
On Thu, 13 Jul 2023 at 15:18, Stefan Berger <stef...@linux.ibm.com> wrote:
On 7/12/23 23:51, Joelle van Dyne wrote:
On Apple Silicon, when Windows performs a LDP on the CRB MMIO space,
the exception is not decoded by hardware and we cannot trap the MMIO
read. This led to the idea from @agraf to use the same mapping type as
ROM devices: namely that reads should be seen as memory type and
writes should trap as MMIO.
+++ b/hw/tpm/tpm_crb.c
@@ -68,7 +68,6 @@ static const VMStateDescription vmstate_tpm_crb_none = {
.name = "tpm-crb",
.pre_save = tpm_crb_none_pre_save,
.fields = (VMStateField[]) {
- VMSTATE_UINT32_ARRAY(state.regs, CRBState, TPM_CRB_R_MAX),
This has to stay here otherwise we cannot restart VMs from saved state once
QEMU is upgraded.
2023-07-13T14:15:43.997718Z qemu-system-x86_64: Unknown ramblock "tpm-crb-cmd",
cannot accept migration
2023-07-13T14:15:43.997813Z qemu-system-x86_64: error while loading state for
instance 0x0 of device 'ram'
2023-07-13T14:15:43.997841Z qemu-system-x86_64: load of migration failed:
Invalid argument
More generally, for migration compatibility in the other
direction you need to use memory_region_init_rom_device_nomigrate()
and make sure you keep migrating the data via this, not
via the MemoryRegion.
I'm not a super-fan of hacking around the fact that LDP
to hardware registers isn't supported in specific device
models, though...
What does this mean for this effort here?
Stefan
thanks
-- PMM
