Re: [xen-unstable-smoke bisection] complete test-amd64-amd64-libvirt

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/10/2020 03:22, osstest service owner wrote:
> *** Found and reproduced problem changeset ***
>
>   Bug is in tree:  xen git://xenbits.xen.org/xen.git
>   Bug introduced:  bfcc97c08c2258316d1cd92c23a441d97ad6ff4e
>   Bug not present: 50a5215f30e964a6f16165ab57925ca39f31a849
>   Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/155282/
>
>
>   commit bfcc97c08c2258316d1cd92c23a441d97ad6ff4e
>   Author: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>   Date:   Tue Sep 29 14:48:52 2020 +0100
>   
>       tools/cpuid: Plumb nested_virt down into xc_cpuid_apply_policy()
>       
>       Nested Virt is the final special case in legacy CPUID handling.  Pass 
> the
>       (poorly named) nested_hvm setting down into xc_cpuid_apply_policy() to 
> break
>       the semantic dependency on HVM_PARAM_NESTEDHVM.
>       
>       No functional change.
>       
>       Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>       Acked-by: Wei Liu <wl@xxxxxxx>

This is totally bizarre.

From
http://logs.test-lab.xenproject.org/osstest/logs/155282/test-amd64-amd64-libvirt/huxelrebe1---var-log-libvirt-libvirtd.log.gz
we get a bunch of:

debug : libvirt_vmessage:71 : libvirt_vmessage: context='libxl'
format='%s%s%s%s%s%s'

lines, which I suspect means that libxl has tried logging and error, and
its not been rendered correctly.


The only possible change in libxl is side effects from the extra call to
libxl_defbool_val() which asserts that the boolean isn't in its default
form.

However, by this point in booting, libxl__domain_build_info_setdefault()
should have already forced it to true or false.

~Andrew, still very much confused