Re: [PATCH v2 3/3] tests: acpi: Add updated TPM related tables

[Michael S. Tsirkin]

On Tue, Nov 09, 2021 at 04:16:34PM +0000, Daniel P. Berrangé wrote:
> On Tue, Nov 09, 2021 at 11:05:28AM -0500, Michael S. Tsirkin wrote:
> > On Tue, Nov 09, 2021 at 02:29:26PM +0000, Daniel P. Berrangé wrote:
> > > On Tue, Nov 09, 2021 at 09:14:25AM -0500, Michael S. Tsirkin wrote:
> > > > On Tue, Nov 09, 2021 at 09:01:52AM -0500, Stefan Berger wrote:
> > > > > The updated TPM related tables have the following additions:
> > > > > 
> > > > >    Device (TPM)
> > > > >    {
> > > > >        Name (_HID, "MSFT0101" /* TPM 2.0 Security Device */)  // 
> > > > > _HID: Hardware ID
> > > > > +      Name (_STR, "TPM 2.0 Device")  // _STR: Description String
> > > > > +      Name (_UID, One)  // _UID: Unique ID
> > > > >        Name (_STA, 0x0F)  // _STA: Status
> > > > >        Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource 
> > > > > Settings
> > > > > 
> > > > > Cc: Michael S. Tsirkin <mst@redhat.com>
> > > > > Cc: Igor Mammedov <imammedo@redhat.com>
> > > > > Cc: Ani Sinha <ani@anisinha.ca>
> > > > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> > > > > ---
> > > > >  tests/data/acpi/q35/DSDT.tis.tpm12          | Bin 0 -> 8900 bytes
> > > > >  tests/data/acpi/q35/DSDT.tis.tpm2           | Bin 0 -> 8921 bytes
> > > > >  tests/data/acpi/q35/TCPA.tis.tpm12          | Bin 0 -> 50 bytes
> > > > >  tests/data/acpi/q35/TPM2.tis.tpm2           | Bin 0 -> 76 bytes
> > > > >  tests/qtest/bios-tables-test-allowed-diff.h |  11 -----------
> > > > >  5 files changed, 11 deletions(-)
> > > > 
> > > > A disadvantage to doing it like this is that git thinks
> > > > it's ok to replace any empty file with this, so if acpi
> > > > changed in any way git will happily resolve it
> > > > replacing it with this version.
> > > 
> > > Do we actually need to be storing these binary files in git
> > > at all ?
> > > 
> > > IIUC, the test will do two things
> > > 
> > >  - memcmp the expected binary we store, against the new binary
> > >    we generated.
> > >  - if they differ, then disassemble both and report the
> > >    differences in a user friendly-ish way
> > 
> > Second if iasl is installed.
> > 
> > > What if we only stored the sha256 checksum of the binary
> > 
> > Hmm, point being? Same some space?
> > 
> > > *and*
> > > the dissasembled output in git, never the full binary.
> > 
> > We used to. The issue is that dissasembled output depends
> > very much on the disassembler. Disassembling both
> > with the same tool is one way to address this.
> 
> Oh, so new isal releases can change the format, that's
> annoying :-(

Well iasl never promised to generate exactly the same output
for the same input. For example, at some point they
started adding comments documenting the output.
How stable it's been recently/on platforms we care about - I don't know.
I'm fine with adding the disassembled files and seeing
where does it lead us.

> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|