On 11/19/20 12:58 PM, Olaf Hering wrote:
Am Mon, 16 Nov 2020 19:48:28 -0700
schrieb Jim Fehlig <jfehlig(a)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