On 11/19/20 12:58 PM, Olaf Hering wrote:
Am Mon, 16 Nov 2020 19:48:28 -0700
schrieb Jim Fehlig <jfeh...@suse.com>:
Adjust the code to parse this as <emulator>.
You also have to adjust all the failing {xl,xm}configtests.
It seems one has to run 'ninja test'.
Yes. See https://libvirt.org/hacking.html
Can this be done via _multibuild in a libvirt-testsuite pkg in an isolated VM?
I suppose. Currently it is done in the downstream OBS package in %check
VIR_TEST_DEBUG=1 %meson_test -t 5 --no-suite syntax-check
Correct. It is selected based on the specified <emulator> and not modeled in
domXML. Does it need to be exposed to the user? AFAIK those are the only two
values we care about, and it is possible to determine which to use based on the
<emulator>.
I think 'device_model_version' can be ignored.
I think we need to take a closer look. It is not explicitly set in
libxl_domain_build_info_init(), hence would be set to
LIBXL_DEVICE_MODEL_VERSION_UNKNOWN. The only thing interesting from a quick grep
in $xensrc/tools/libxl/ is
libxl_domain.c: assert(version != LIBXL_DEVICE_MODEL_VERSION_UNKNOWN);
In current xen.git support for "qemu-xen-traditional" was declared for stubdom
only.
It is unrealistic that some HVM domUs with qemu-dm are still running out there.
In case they really exist, they were likely not started with libvirt.
Or by "ignored" do you mean removing the logic and unconditionally setting it to
LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN?
Regards,
Jim
