On 20/01/2023 12.18, Philippe Mathieu-Daudé wrote:
On 20/1/23 11:26, Thomas Huth wrote:
On 19/01/2023 13.05, Thomas Huth wrote:
On 19/01/2023 12.30, Philippe Mathieu-Daudé wrote:
On 19/1/23 12:24, Thomas Huth wrote:
On 19/01/2023 11.05, Philippe Mathieu-Daudé wrote:
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
---
RFC: CONFIG_HVF is poisoned.
We could pass host config definitions to qtest using:
diff --git a/meson.build b/meson.build
@@ -2547,6 +2547,7 @@ foreach target : target_dirs
accel_kconfig = []
foreach sym: accelerators
+ config_host_data.set(sym + '_QTEST', '')
if sym == 'CONFIG_TCG' or target in
accelerator_targets.get(sym, [])
config_target += { sym: 'y' }
config_all += { sym: 'y' }
Then test for CONFIG_HVF_QTEST ...
I don't think that would really work well. The qtests are build once
for all targets, and HVF is only available in the target that matches
the host architecture. It's poisoned on purpose.
The TCG accelerator is special, since we have it in either none or in
all targets, that's why we can use CONFIG_TCG there.
The kvm part is also rather a hack... we should maybe rather
additionally use the "query-kvm" QAPI command to check whether it is
really available...?
To fix this properly for HVF, I think you'd need a way to query the
available accelerators via QMP, too... Hmmm, weren't there some patches
for something like that in the past ... can't remember right now ...
https://lore.kernel.org/qemu-devel/20210505125806.1263441-3-phi...@redhat.com/
:(
Ah, right, and we ended up with the competing patch from Igor since we
could not quite settle on the QAPI extensions?
Hmm, what happens if you execute "query-qmp-schema" on a HVF-enabled host
these days? Is there a "hvf"-related entry somewhere in the response?
Alternative idea: execute QEMU once with "-accel help" via
g_spawn_command_line_sync() or g_spawn_sync() once and look for the
accelerator in the standard output.
There is no stability guaranty with the help output.
Sure, it's rather meant as a temporary solution until a proper QMP method is
in place. We also have the advantage here that it is internal to the QEMU
repository only - it's not like libvirt or some other upper layers are
trying to parse the output here.
QMP is a stable API, we should really rely on it here IMO.
I agree, QMP should certainly be the final goal.
Thomas