qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Igor Mammedov
Subject: Re: [PATCH v5 2/3] acpi: tpm: Add missing device identification objects
Date: Thu, 6 Jan 2022 17:55:47 +0100

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>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]