qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 00c1b3: i386: clarify 'hv-passthrough' behavi


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 00c1b3: i386: clarify 'hv-passthrough' behavior
Date: Wed, 14 Jul 2021 04:06:37 -0700

  Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: 00c1b316edb33f2efb0775c2983bc5348c86529d
      
https://github.com/qemu/qemu/commit/00c1b316edb33f2efb0775c2983bc5348c86529d
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M docs/hyperv.txt

  Log Message:
  -----------
  i386: clarify 'hv-passthrough' behavior

Clarify the fact that 'hv-passthrough' only enables features which are
already known to QEMU and that it overrides all other 'hv-*' settings.

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210608120817.1325125-3-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: 07454e2ea84ee9be298c96d9730dc82abfb1488a
      
https://github.com/qemu/qemu/commit/07454e2ea84ee9be298c96d9730dc82abfb1488a
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M docs/hyperv.txt
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  i386: hardcode supported eVMCS version to '1'

Currently, the only eVMCS version, supported by KVM (and described in TLFS)
is '1'. When Enlightened VMCS feature is enabled, QEMU takes the supported
eVMCS version range (from KVM_CAP_HYPERV_ENLIGHTENED_VMCS enablement) and
puts it to guest visible CPUIDs. When (and if) eVMCS ver.2 appears a
problem on migration is expected: it doesn't seem to be possible to migrate
from a host supporting eVMCS ver.2 to a host, which only support eVMCS
ver.1.

Hardcode eVMCS ver.1 as the result of 'hv-evmcs' enablement for now. Newer
eVMCS versions will have to have their own enablement options (e.g.
'hv-evmcs=2').

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210608120817.1325125-4-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: d7652b772f302346c8f1043aa850a28c445e80d7
      
https://github.com/qemu/qemu/commit/d7652b772f302346c8f1043aa850a28c445e80d7
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  i386: make hyperv_expand_features() return bool

Return 'false' when hyperv_expand_features() sets an error.

No functional change intended.

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210608120817.1325125-5-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: 071ce4b03becf9e2df6b758fde9609be8ddf56f1
      
https://github.com/qemu/qemu/commit/071ce4b03becf9e2df6b758fde9609be8ddf56f1
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M target/i386/cpu.c
    M target/i386/kvm/kvm-stub.c
    M target/i386/kvm/kvm.c
    M target/i386/kvm/kvm_i386.h

  Log Message:
  -----------
  i386: expand Hyper-V features during CPU feature expansion time

To make Hyper-V features appear in e.g. QMP query-cpu-model-expansion we
need to expand and set the corresponding CPUID leaves early. Modify
x86_cpu_get_supported_feature_word() to call newly intoduced Hyper-V
specific kvm_hv_get_supported_cpuid() instead of
kvm_arch_get_supported_cpuid(). We can't use kvm_arch_get_supported_cpuid()
as Hyper-V specific CPUID leaves intersect with KVM's.

Note, early expansion will only happen when KVM supports system wide
KVM_GET_SUPPORTED_HV_CPUID ioctl (KVM_CAP_SYS_HYPERV_CPUID).

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210608120817.1325125-6-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: 5ce48fa354f2270731e20f81dbb7ff191630c321
      
https://github.com/qemu/qemu/commit/5ce48fa354f2270731e20f81dbb7ff191630c321
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  i386: kill off hv_cpuid_check_and_set()

hv_cpuid_check_and_set() does too much:
- Checks if the feature is supported by KVM;
- Checks if all dependencies are enabled;
- Sets the feature bit in cpu->hyperv_features for 'passthrough' mode.

To reduce the complexity, move all the logic except for dependencies
check out of it. Also, in 'passthrough' mode we don't really need to
check dependencies because KVM is supposed to provide a consistent
set anyway.

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210608120817.1325125-7-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: b26f68c36bf6edaaa224f8a6ab285394af4d0f8c
      
https://github.com/qemu/qemu/commit/b26f68c36bf6edaaa224f8a6ab285394af4d0f8c
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  i386: HV_HYPERCALL_AVAILABLE privilege bit is always needed

According to TLFS, Hyper-V guest is supposed to check
HV_HYPERCALL_AVAILABLE privilege bit before accessing
HV_X64_MSR_GUEST_OS_ID/HV_X64_MSR_HYPERCALL MSRs but at least some
Windows versions ignore that. As KVM is very permissive and allows
accessing these MSRs unconditionally, no issue is observed. We may,
however, want to tighten the checks eventually. Conforming to the
spec is probably also a good idea.

Enable HV_HYPERCALL_AVAILABLE bit unconditionally.

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210608120817.1325125-8-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: cce087f628c651e905f5e2097d9bb9f678689669
      
https://github.com/qemu/qemu/commit/cce087f628c651e905f5e2097d9bb9f678689669
  Author: Vitaly Kuznetsov <vkuznets@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M target/i386/kvm/hyperv-proto.h
    M target/i386/kvm/kvm.c

  Log Message:
  -----------
  i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS privileges

When Hyper-V SynIC is enabled, we may need to allow Windows guests to make
hypercalls (POST_MESSAGES/SIGNAL_EVENTS). No issue is currently observed
because KVM is very permissive, allowing these hypercalls regarding of
guest visible CPUid bits.

Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210608120817.1325125-9-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: a7a0da844d299971bdbf99665bd63398668dde83
      
https://github.com/qemu/qemu/commit/a7a0da844d299971bdbf99665bd63398668dde83
  Author: Michael Roth <michael.roth@amd.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M hw/i386/pc.c
    M target/i386/cpu.c
    M target/i386/cpu.h

  Log Message:
  -----------
  target/i386: suppress CPUID leaves not defined by the CPU vendor

Currently all built-in CPUs report cache information via CPUID leaves 2
and 4, but these have never been defined for AMD. In the case of
SEV-SNP this can cause issues with CPUID enforcement. Address this by
allowing CPU types to suppress these via a new "x-vendor-cpuid-only"
CPU property, which is true by default, but switched off for older
machine types to maintain compatibility.

Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: zhenwei pi <pizhenwei@bytedance.com>
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-Id: <20210708003623.18665-1-michael.roth@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: 760746ac533dd770a56340b1376e7b3fb1693562
      
https://github.com/qemu/qemu/commit/760746ac533dd770a56340b1376e7b3fb1693562
  Author: zhenwei pi <pizhenwei@bytedance.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  target/i386: Fix cpuid level for AMD

A AMD server typically has cpuid level 0x10(test on Rome/Milan), it
should not be changed to 0x1f in multi-dies case.

* to maintain compatibility with older machine types, only implement
  this change when the CPU's "x-vendor-cpuid-only" property is false

Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Richard Henderson <richard.henderson@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: zhenwei pi <pizhenwei@bytedance.com>
Fixes: a94e1428991 (target/i386: Add CPUID.1F generation support for multi-dies 
PCMachine)
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Signed-off-by: Michael Roth <michael.roth@amd.com>
Message-Id: <20210708170641.49410-1-michael.roth@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: f74d339c86d4460f1d7a644e965170c03518a737
      
https://github.com/qemu/qemu/commit/f74d339c86d4460f1d7a644e965170c03518a737
  Author: Michal Privoznik <mprivozn@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M hw/core/machine.c

  Log Message:
  -----------
  numa: Report expected initiator

When setting up NUMA with HMAT enabled there's a check performed
in machine_set_cpu_numa_node() that reports an error when a NUMA
node has a CPU but the node's initiator is not itself. The error
message reported contains only the expected value and not the
actual value (which is different because an error is being
reported). Report both values in the error message.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Message-Id: 
<ebdf871551ea995bafa7a858899a26aa9bc153d3.1625662776.git.mprivozn@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: 294aa0437b7f6a3e94653ef661310ef621859c87
      
https://github.com/qemu/qemu/commit/294aa0437b7f6a3e94653ef661310ef621859c87
  Author: Michal Privoznik <mprivozn@redhat.com>
  Date:   2021-07-13 (Tue, 13 Jul 2021)

  Changed paths:
    M hw/core/numa.c

  Log Message:
  -----------
  numa: Parse initiator= attribute before cpus= attribute

When parsing cpus= attribute of -numa object couple of checks
is performed, such as correct initiator setting (see the if()
statement at the end of for() loop in
machine_set_cpu_numa_node()).

However, with the current code cpus= attribute is parsed before
initiator= attribute and thus the check may fail even though it
is not obvious why. But since parsing the initiator= attribute
does not depend on the cpus= attribute we can swap the order of
the two.

It's fairly easy to reproduce with the following command line
(snippet of an actual cmd line):

  -smp 4,sockets=4,cores=1,threads=1 \
  -object 
'{"qom-type":"memory-backend-ram","id":"ram-node0","size":2147483648}' \
  -numa node,nodeid=0,cpus=0-1,initiator=0,memdev=ram-node0 \
  -object 
'{"qom-type":"memory-backend-ram","id":"ram-node1","size":2147483648}' \
  -numa node,nodeid=1,cpus=2-3,initiator=1,memdev=ram-node1 \
  -numa 
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5
 \
  -numa 
hmat-lb,initiator=0,target=0,hierarchy=first-level,data-type=access-latency,latency=10
 \
  -numa 
hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-latency,latency=5
 \
  -numa 
hmat-lb,initiator=1,target=1,hierarchy=first-level,data-type=access-latency,latency=10
 \
  -numa 
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=204800K
 \
  -numa 
hmat-lb,initiator=0,target=0,hierarchy=first-level,data-type=access-bandwidth,bandwidth=208896K
 \
  -numa 
hmat-lb,initiator=1,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=204800K
 \
  -numa 
hmat-lb,initiator=1,target=1,hierarchy=first-level,data-type=access-bandwidth,bandwidth=208896K
 \
  -numa 
hmat-cache,node-id=0,size=10K,level=1,associativity=direct,policy=write-back,line=8
 \
  -numa 
hmat-cache,node-id=1,size=10K,level=1,associativity=direct,policy=write-back,line=8
 \

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: 
<b27a6a88986d63e3f610a728c845e01ff8d92e2e.1625662776.git.mprivozn@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>


  Commit: 4aa2454d94cca99d86aa32e71bd7c8159df91c59
      
https://github.com/qemu/qemu/commit/4aa2454d94cca99d86aa32e71bd7c8159df91c59
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2021-07-14 (Wed, 14 Jul 2021)

  Changed paths:
    M docs/hyperv.txt
    M hw/core/machine.c
    M hw/core/numa.c
    M hw/i386/pc.c
    M target/i386/cpu.c
    M target/i386/cpu.h
    M target/i386/kvm/hyperv-proto.h
    M target/i386/kvm/kvm-stub.c
    M target/i386/kvm/kvm.c
    M target/i386/kvm/kvm_i386.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/ehabkost-gl/tags/x86-next-pull-request' 
into staging

x86 queue, 2021-07-13

Bug fixes:
* numa: Parse initiator= attribute before cpus= attribute
  (Michal Privoznik)
* Fix CPUID level for AMD (Zhenwei Pi)
* Suppress CPUID leaves not defined by the CPU vendor
  (Michael Roth)

Cleanup:
* Hyper-V feature handling cleanup (Vitaly Kuznetsov)

# gpg: Signature made Tue 13 Jul 2021 17:09:01 BST
# gpg:                using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6
# gpg:                issuer "ehabkost@redhat.com"
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF  D1AA 2807 936F 984D C5A6

* remotes/ehabkost-gl/tags/x86-next-pull-request:
  numa: Parse initiator= attribute before cpus= attribute
  numa: Report expected initiator
  target/i386: Fix cpuid level for AMD
  target/i386: suppress CPUID leaves not defined by the CPU vendor
  i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS privileges
  i386: HV_HYPERCALL_AVAILABLE privilege bit is always needed
  i386: kill off hv_cpuid_check_and_set()
  i386: expand Hyper-V features during CPU feature expansion time
  i386: make hyperv_expand_features() return bool
  i386: hardcode supported eVMCS version to '1'
  i386: clarify 'hv-passthrough' behavior

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>


Compare: https://github.com/qemu/qemu/compare/4598b0735025...4aa2454d94cc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]