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

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

  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 2 Oct 2020 12:55:03 +0100
  • Authentication-results: esa4.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Jim Fehlig <jfehlig@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>
  • Delivery-date: Fri, 02 Oct 2020 11:55:14 +0000
  • Ironport-sdr: v2PcWNnaYGcL/ylgiJ3SMF2nrZ44JYoMXlYVj3UarFnixThafqGqEEWseMMnGXf+XwtVbQYWQ9 sGPKR0C8Nke/DPgivMhCWS7EW6yXLyYIWYZXu+2giWQ0snUzsu+ieZ3wgdcXx5XeYVVojn7ZI2 cqsuIe7yoCdZu61wI4pikQizba81ZR0uXfQ+zcrbum6Q5tOX6MIXHgbq1vy9Bf/Ud5NZIGlgEL 2j6cvqFxONdjP14C9gl0EKtB0Zfr4AZspRObN/m6BbKmNe2nRoLklthcV7Fw0kd0W0ae9FO4FC x68=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.

we get a bunch of:

debug : libvirt_vmessage:71 : libvirt_vmessage: context='libxl'

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.