Re: [PATCH v5 2/3] acpi: tpm: Add missing device identification objects

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

On 1/6/22 11:55, Igor Mammedov wrote:
> On Thu, 6 Jan 2022 09:01:36 -0500
> Stefan Berger <stefanb@linux.ibm.com> wrote:
>
>> On 1/6/22 08:56, Michael S. Tsirkin wrote:
>>> On Thu, Jan 06, 2022 at 08:53:00AM -0500, Stefan Berger wrote:
>>>> On 1/6/22 03:36, Igor Mammedov wrote:
>>>>> On Tue,  4 Jan 2022 12:58:05 -0500
>>>>> Stefan Berger <stefanb@linux.ibm.com> wrote:
>>>>>   
>>>>>> Add missing TPM device identification objects _STR and _UID. They will
>>>>>> appear as files 'description' and 'uid' under Linux sysfs.
>>>>>>
>>>>>> Following inspection of sysfs entries for hardware TPMs we chose
>>>>>> uid '1'.
>>>>> My guess would be that buy default (in case of missing UID), OSPM
>>>>> will start enumerate from 0. So I think 0 is more safer choice
>>>>> when it comes to compatibility.
>>>>>
>>>>> Can you smoke test TPM with Windows, and check if adding UID doesn't
>>>>> break anything if VM actually uses TMP (though I'm not sure how to
>>>>> check it on Windows, maybe install Windows 11 without this patch
>>>>> and then see if it still boots pre-installed VM and nothing is broken
>>>>> after this patch)?
>>>>>   
>>>> I smoke tested it with the posted patches applied to v6.2.0 and started 3
>>>> VMs with it:
>>>>
>>>> - Linux shows uid = 1 and the description "TPM 2.0 Device" in sysfs
>>>>
>>>> - Win 10 and Win 11 tpm.msc tool are both showing that the TPM is 'ready for
>>>> use'
>>>>
>>>>       Stefan
>>>>   
>>> Just to make sure, what Igor was concerned about is issues like
>>> we had with e.g. network devices, when changing UID makes
>>> windows think it's a new device and lose configuration
>>> created on old qemu on boot with a new qemu.
>>> Not sure what can be configured with a TPM device though ...
>> The VMs were all created on an old qemu and booted into the patched
>> qemu. They hadn't seen the new ACPI entries before, for sure not when
>> they were installed.
> In that case I would not bother with compat machinery
>
> (my stance on APCI and compat knobs haven't changed and it
> is avoid it if possible, sometimes that backfires but overall
> keeps code simpler, otherwise it would be unreadable mess
> (it's already complex enough))
>
> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
>
Another test I did was to remove the TPM 2, boot the win 10 and 11 VMs 
ran tpm.msc (no TPM there), shut them down, added the TPM 2 and ran 
tpm.msc again. Same result: TPM is 'ready for use'.