[PATCH v2 4/4] qemu: Generate command line for tb-cache feature

Peter Krempa pkrempa at redhat.com
Mon Nov 22 09:41:30 UTC 2021


On Fri, Nov 05, 2021 at 10:35:20 +0100, Michal Privoznik wrote:
> Alright, here's the deal: to enable tb-cache one has to use
> '-accel tcg,tb-size=' which then conflicts with '-machine
> accel=tcg'. But sure, we can use the old -accel in this specific
> case.

The above is all wrong after the refactors.

> But because of how the tb-size argument is defined in QEMU
> there's no way for us to have a capability check. The feature was
> introduced in QEMU commit of v5.0.0-rc0~175^2~62 and is tied to
> TCG only. Therefore, I think we can live without capability
> check. Worst case scenario, QEMU fails to start.
> 
> Resolves: https://gitlab.com/libvirt/libvirt/-/issues/229
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> Tested-by: Kashyap Chamarthy <kchamart at redhat.com>
> ---
>  src/qemu/qemu_command.c                       |  5 +++
>  ...efault-cpu-tcg-features.x86_64-latest.args | 40 +++++++++++++++++++
>  tests/qemuxml2argvtest.c                      |  1 +
>  3 files changed, 46 insertions(+)
>  create mode 100644 tests/qemuxml2argvdata/x86_64-default-cpu-tcg-features.x86_64-latest.args
> 
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index 0257b86a0d..17ee3c5d3a 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -7271,6 +7271,11 @@ qemuBuildAccelCommandLine(virCommand *cmd,
>      switch ((virDomainVirtType)def->virtType) {
>      case VIR_DOMAIN_VIRT_QEMU:
>          virBufferAddLit(&buf, "tcg");
> +
> +        if (def->features[VIR_DOMAIN_FEATURE_TCG] == VIR_TRISTATE_SWITCH_ON) {

Similarly to previous commit. It's not extensible when adding new tcg
features. This would set the cache to 0 if a new feature is added and
tb-cache is not used.

> +            virBufferAsprintf(&buf, ",tb-size=%llu",
> +                              def->tcg_features->tb_cache >> 10);

Okay, so input in libvirt is kiB, output is MiB. This means we are
truncating precision. In this case I don't think it's worth adding
checks, but at least the docs should mention what's going on.

> +        }
>          break;




More information about the libvir-list mailing list