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.coop...@citrix.com> > 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.coop...@citrix.com> > Acked-by: Wei Liu <w...@xen.org>
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
