qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v3 0/9] tests: Add test cases for TPM 1.2 ACPI tables


From: Igor Mammedov
Subject: Re: [PATCH v3 0/9] tests: Add test cases for TPM 1.2 ACPI tables
Date: Mon, 19 Jul 2021 15:38:37 +0200

On Thu, 15 Jul 2021 07:49:13 +0200
Markus Armbruster <armbru@redhat.com> wrote:

> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> 
> > On 7/14/21 4:43 PM, Markus Armbruster wrote:  
> >> Philippe Mathieu-Daudé <philmd@redhat.com> writes:
> >>   
> >>> +Markus  
> 
> [...]
> 
> >>> IMO the "right" solution is to check via QMP if TMP is supported
> >>> or not. This is now doable since commit caff255a546 ("tpm: Return
> >>> QMP error when TPM is disabled in build").
> >>>
> >>> Long term we'd like to decouple the tests/ build from the various
> >>> QEMU configurations, and build the tests once.  
> >> 
> >> This argument applies only to macros from target-specific headers like
> >> $TARGET-config-target.h, not to macros from config-host.h.  #ifdef
> >> CONFIG_TPM should be fine, shouldn't it?  
> >
> > Some definitions depend on the host (OS, libraries installed, ...),
> > others depend on the --enable/--disable ./configure options.
> >
> > IMO it would be nice if we could get qtests independent of the latter.  
> 
> Why?

In another mail-thread Philippe mentioned that there is desire
to use qtest out of tree to test other QEMU binaries.

However, just probing for features at runtime aren't going
to help with the goal as tests are tailored for the latest
CLI/QMP/ABI. To make it work we would have practically
introduce versioned tests.

So I wonder why one external acceptance-tests suite is not
sufficient, that we would want to hijack relatively simple
internal qtest at expense of increased resources needed to
run/write unit tests.

> > I suppose config-host.h holds both kinds.  
> 
> Yes.
> 
> 




reply via email to

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