This will be addressed in the next major release.

So QEMU correctly reports topoext as disabled in the expansion of "host" CPU
model and libvirt therefore does not explicitly ask QEMU to enable topoext.
However, topoext may still be enabled when QEMU starts...

For example, on a host with AMD EPYC 7401 24-Core Processor virsh
domcapabilities will show

    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-IBPB</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='perfctr_core'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='disable' name='monitor'/>
    </mode>

and a domain with host-model CPU will be started with

    -cpu EPYC-IBPB,\
         x2apic=on,\
         tsc-deadline=on,\
         hypervisor=on,\
         tsc_adjust=on,\
         arch-capabilities=on,\
         cmp_legacy=on,\
         perfctr_core=on,\
         virt-ssbd=on,\
         monitor=off

which exactly matches the host-model CPU definition from domcapabilities. But
once QEMU is started, the live domain definition will change to

  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='tsc-deadline'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='perfctr_core'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='disable' name='monitor'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='topoext'/>
  </cpu>

where you can see topoext is actually enabled.

The problem is a difference between libvirt's definition of EPYC-IBPB (I'll be
ignoring the -IBPB suffix further on as the difference is irrelevant) CPU
model and the definition used by QEMU. While libvirt's EPYC CPU model does not
contain topoext feature, the EPYC CPU model is defined in QEMU as follows
(most irrelevant parts were removed):

    {
        .name = "EPYC",
        .level = 0xd,
        .vendor = CPUID_VENDOR_AMD,
        .family = 23,
        .model = 1,
        .stepping = 2,
        ...
        .features[FEAT_8000_0001_ECX] =
            CPUID_EXT3_OSVW | CPUID_EXT3_3DNOWPREFETCH |
            CPUID_EXT3_MISALIGNSSE | CPUID_EXT3_SSE4A | CPUID_EXT3_ABM |
            CPUID_EXT3_CR8LEG | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM |
            CPUID_EXT3_TOPOEXT,
        ...
    },

In other words, "-cpu EPYC" will implicitly enable topoext, which is detected
by libvirt after starting QEMU and thus the feature is added into the live
definition.

If libvirt's version of EPYC contained topoext, the host-model would
explicitly disable topoext, but since libvirt thinks topoext is not enabled
implcitly by the model, there's no need to explicitly disable it.

Ironically enough, topoext is listed in .no_autoenable_flags in QEMU an yet
some CPU models enable it without explicit request. This looks like a QEMU bug
to me. But if QEMU is correct, libvirt will need to do something to fix this.

Having enabled by EPYC implicitly but not by "-cpu host" is done on purpose: the feature is supposed to be hidden behind the CPU model because it is more complex than a boolean on/off option.

In retrospect, making the feature directly configurable in the command line was a mistake: on all cases it works, the feature is already enabled implicitly.

Now, to the current situation:

If "host-model" never includes topoext out of the box, this is correct.
If the domain XML is updated to include topoext because QEMU did enable the feature implicitly, this makes the config redudant but also correct.

So, it looks like everything is working as expected?

Ah so you're saying QEMU will implicitly enable topoext only if it can be
safely enabled, right?

(In reply to Jiri Denemark from comment #5)
> Ah so you're saying QEMU will implicitly enable topoext only if it can be
> safely enabled, right?

Correct.

OK, everything works right then, no libvirt work needed.

Verify this bug on libvirt-4.5.0-30.module+el8.1.0+3574+3a63752b.x86_64.

Other components:
kernel-4.18.0-120.el8.x86_64
qemu-kvm-2.12.0-82.module+el8.1.0+3738+0d8c0249.x86_64

Other ENV info:
On physical host:
# lscpu
Model name:          AMD EPYC 7251 8-Core Processor

# virsh domcapabilities
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-IBPB</model>
      <vendor>AMD</vendor>
...

S1: When starting VM with "host-passthrough" CPU conf; VM can start successfully. NO topoext info in active dumpxml or qemu cmd line of VM; and NO topoext cpu flag in guest OS.

S2： When starting VM with "host-model" conf as "virsh domcapabilities" shows; topoext flag and CPU feature will be displayed in guest OS and dumpxml/qemu cmd line of VM.
# virsh dumpxml topoext |grep "<cpu" -A20
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <vendor>AMD</vendor>
    ...
    <feature policy='require' name='topoext'/>
    ...
  </cpu>

# ps -ef |grep topoext
-cpu EPYC-IBPB,x2apic=on,tsc-deadline=on,hypervisor=on,tsc_adjust=on,cmp_legacy=on, ** topoext=on  **,perfctr_core=on,virt-ssbd=on,monitor=off,svm=off,invtsc=on

# virsh console topoext
(In guest) # lscpu |grep topo
Flags:               ... topoext

The test result is expected, move this bug to be verified.

Hi Jiri https://bugzilla.redhat.com/show_bug.cgi?id=1619798#c8
In this comment, if topoext is enabled when VM started successfully, should this flag also is displayed in the output of "virsh domcapabilities" originally?

# rpm -qa libvirt qemu-kvm kernel
qemu-kvm-2.12.0-88.module+el8.1.0+4233+bc44be3f.x86_64
kernel-4.18.0-147.el8.x86_64
libvirt-4.5.0-35.module+el8.1.0+4227+b2722cb3.x86_64

# virsh domcapabilities |grep "<mode name='host-model'" -A15
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>EPYC-IBPB</model>
      <vendor>AMD</vendor>
      <feature policy='require' name='x2apic'/>
      <feature policy='require' name='tsc-deadline'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='tsc_adjust'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='cmp_legacy'/>
      <feature policy='require' name='perfctr_core'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='require' name='virt-ssbd'/>
      <feature policy='require' name='skip-l1dfl-vmentry'/>
      <feature policy='disable' name='monitor'/>
      <feature policy='disable' name='svm'/>     *** No topoext here ***
    </mode>

# virsh domstate avocado-vt-vm1
shut off

# virsh dumpxml avocado-vt-vm1 --inactive |grep "<cpu" -A3
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>

# virsh start avocado-vt-vm1
Domain avocado-vt-vm1 started

# virsh dumpxml avocado-vt-vm1 |grep "<cpu" -A15
  <cpu mode='custom' match='exact' check='full'>
    <model fallback='forbid'>EPYC-IBPB</model>
    <vendor>AMD</vendor>
    <feature policy='require' name='x2apic'/>
    <feature policy='require' name='tsc-deadline'/>
    <feature policy='require' name='hypervisor'/>
    <feature policy='require' name='tsc_adjust'/>
    <feature policy='require' name='arch-capabilities'/>
    <feature policy='require' name='cmp_legacy'/>
    <feature policy='require' name='perfctr_core'/>
    <feature policy='require' name='virt-ssbd'/>
    <feature policy='require' name='skip-l1dfl-vmentry'/>
    <feature policy='disable' name='monitor'/>
    <feature policy='disable' name='svm'/>
    <feature policy='require' name='topoext'/>  *** Topoext is enabled here ***
  </cpu>

However, If I test the following cmd, "virsh hypervisor-cpu-compare" will raise the following info: "CPU described in avocado-vt-vm1.xml is incompatible with the CPU provided by hypervisor on the host".

# virsh dumpxml avocado-vt-vm1 >> avocado-vt-vm1.xml 

# virsh hypervisor-cpu-compare avocado-vt-vm1.xml 
CPU described in avocado-vt-vm1.xml is incompatible with the CPU provided by hypervisor on the host

Since VM can start successfully on this host, I think the CPU conf should not be incompatible. Or should this info change?

Track the issue in comment 9 in Bug 1765445 - Cmd "virsh Hypervisor-cpu-compare" outputs wrong result with VM's active dumpxml as input because of topoext

Given that this bug is VERIFIED and RHEL AV 8.1.0 shipped (went GA) on 11 Nov 2019, I am closing this bug report.