Re: [PATCH 04/11] tpm_crb: use a single read-as-mem/write-as-mmio mapping

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

On 7/13/23 11:34, Peter Maydell wrote:
> On Thu, 13 Jul 2023 at 16:28, Stefan Berger <stefanb@linux.ibm.com> wrote:
>>
>>
>>
>> On 7/13/23 10:50, Peter Maydell wrote:
>>> On Thu, 13 Jul 2023 at 15:18, Stefan Berger <stefanb@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?
> 
> Usually we say "fix the guest to not try to access hardware
> registers with silly load/store instruction types". The other
> option would be "put in a large amount of effort to support
> emulating those instructions in QEMU userspace when KVM/HVF/etc
> trap and punt them to us". For the last decade or so we have
> taken the first of these approaches :-)

Is Microsoft likely to react to use telling them "fix the guest"?

    Stefan

> 
> thanks
> -- PMM