Bug 1439736

+++ This bug was initially created as a clone of Bug #1439424 +++

Description of problem:
Using the vendor_id option for hyperv in the domain xml prevents VM startup due to unknown cpu feature.

Version-Release number of selected component (if applicable):
3.2.0

How reproducible:
always

Steps to Reproduce:
1. Create a new VM. (e.g. for Windows 10)
2. Edit the domain xml and add "<vendor_id state='on' value='whatever'/>" into the hyperv section.
3. Try to start the VM.

Actual results:
Virt-manager returns the following error and the VM is stopped:
Error starting domain: internal error: unknown CPU feature __kvm_hv_vendor_id


Expected results:
The VM starting and hv_vendor_id being passed to the cpu argument for QEMU. 


--- Additional comment from Jiri Denemark on 2017-04-06 12:38:41 UTC ---

Fixed by

commit ae102b5d7bccd29bc6015a3e0acefeaa90d097ac
Refs: v3.2.0-53-gae102b5d7
Author:     Jiri Denemark <jdenemar>
AuthorDate: Thu Apr 6 13:52:30 2017 +0200
Commit:     Jiri Denemark <jdenemar>
CommitDate: Thu Apr 6 14:32:00 2017 +0200

    qemu: Fix regression when hyperv/vendor_id feature is used

    qemuProcessVerifyHypervFeatures is supposed to check whether all
    requested hyperv features were actually honored by QEMU/KVM. This is
    done by checking the corresponding CPUID bits reported by the virtual
    CPU. In other words, it doesn't work for string properties, such as
    VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We
    could theoretically check all 96 bits corresponding to the vendor
    string, but luckily we don't have to check the feature at all. If QEMU
    is too old to support hyperv features, the domain won't even start.
    Otherwise, it is always supported.

    Without this patch, libvirt refuses to start a domain which contains

      <features>
       	<hyperv>
          <vendor_id state='on' value='...'/>
       	</hyperv>
      </features>

    reporting internal error: "unknown CPU feature __kvm_hv_vendor_id.

    This regression was introduced by commit v3.1.0-186-ge9dbe7011, which
    (by fixing the virCPUDataCheckFeature condition in
    qemuProcessVerifyHypervFeatures) revealed an old bug in the feature
    verification code. It's been there ever since the verification was
    implemented by commit v1.3.3-rc1-5-g95bbe4bf5, which effectively did not
    check VIR_DOMAIN_HYPERV_VENDOR_ID at all.

    https://bugzilla.redhat.com/show_bug.cgi?id=1439424

    Signed-off-by: Jiri Denemark <jdenemar>