[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 7bde6b: target/i386: Add CPU model versions s
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] 7bde6b: target/i386: Add CPU model versions supporting 'xs... |
|
Date: |
Wed, 02 Jun 2021 03:42:27 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: 7bde6b18575dd79c26ce1616e0c33151e83d9d7e
https://github.com/qemu/qemu/commit/7bde6b18575dd79c26ce1616e0c33151e83d9d7e
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: Add CPU model versions supporting 'xsaves'
Hyper-V 2016 refuses to boot on Skylake+ CPU models because they lack
'xsaves'/'vmx-xsaves' features and this diverges from real hardware. The
same issue emerges with AMD "EPYC" CPU model prior to version 3 which got
'xsaves' added. EPYC-Rome/EPYC-Milan CPU models have 'xsaves' enabled from
the very beginning so the comment blaming KVM to explain why other CPUs
lack 'xsaves' is likely outdated.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20210412073952.860944-1-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: fd1fd38b863abe4763097e2603762e1c067fa6a2
https://github.com/qemu/qemu/commit/fd1fd38b863abe4763097e2603762e1c067fa6a2
Author: Eduardo Habkost <ehabkost@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm-cpu.c
Log Message:
-----------
i386: Document when features can be added to kvm_default_props
It's very easy to mistakenly extend kvm_default_props to include
features that require a kernel version that's too recent. Add a
comment warning about that, pointing to the documentation file
where the minimum kernel version for KVM is documented.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20200925211021.4158567-1-ehabkost@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: e845de3851a135dd6537a650c2379ce7a6464ef1
https://github.com/qemu/qemu/commit/e845de3851a135dd6537a650c2379ce7a6464ef1
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386/cpu: Constify CPUCaches
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210503173524.833052-2-philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: e11fd68996fb27c040552320f01a7d30a15a7cc1
https://github.com/qemu/qemu/commit/e11fd68996fb27c040552320f01a7d30a15a7cc1
Author: Philippe Mathieu-Daudé <philmd@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386/cpu: Constify X86CPUDefinition
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210503173524.833052-3-philmd@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: f9c0322a5ff5dc28be41290a26d0133e86a6ea4c
https://github.com/qemu/qemu/commit/f9c0322a5ff5dc28be41290a26d0133e86a6ea4c
Author: Robert Hoo <robert.hu@linux.intel.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu-dump.c
Log Message:
-----------
i386/cpu_dump: support AVX512 ZMM regs dump
Since commit fa4518741e (target-i386: Rename struct XMMReg to ZMMReg),
CPUX86State.xmm_regs[] has already been extended to 512bit to support
AVX512.
Also, other qemu level supports for AVX512 registers are there for
years.
But in x86_cpu_dump_state(), still only dump XMM registers no matter
YMM/ZMM is enabled.
This patch is to complement this, let it dump XMM/YMM/ZMM accordingly.
Signed-off-by: Robert Hoo <robert.hu@linux.intel.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <1618986232-73826-1-git-send-email-robert.hu@linux.intel.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: b7c290177ce1f035db8cdd8abf97b94a44e27f8c
https://github.com/qemu/qemu/commit/b7c290177ce1f035db8cdd8abf97b94a44e27f8c
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M hw/i386/pc.c
M target/i386/cpu.c
Log Message:
-----------
i386: use better matching family/model/stepping for 'qemu64' CPU
The 'qemu64' CPUID currently reports a family/model/stepping that
approximately corresponds to an AMD K7 vintage architecture.
The K7 series predates the introduction of 64-bit support by AMD
in the K8 series. This has been reported to lead to LLVM complaints
about generating 64-bit code for a 32-bit CPU target
LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!
It appears LLVM looks at the family/model/stepping, despite qemu64
reporting it is 64-bit capable.
This patch changes 'qemu64' to report a CPUID with the family, model
and stepping taken from a
AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
which is one of the first 64-bit AMD CPUs.
Closes https://gitlab.com/qemu-project/qemu/-/issues/191
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210507133650.645526-2-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 40b3cc354a47d9017d280cb25efbe6f94d7575bb
https://github.com/qemu/qemu/commit/40b3cc354a47d9017d280cb25efbe6f94d7575bb
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
i386: use better matching family/model/stepping for 'max' CPU
The 'max' CPU under TCG currently reports a family/model/stepping that
approximately corresponds to an AMD K7 vintage architecture.
The K7 series predates the introduction of 64-bit support by AMD
in the K8 series. This has been reported to lead to LLVM complaints
about generating 64-bit code for a 32-bit CPU target
LLVM ERROR: 64-bit code requested on a subtarget that doesn't support it!
It appears LLVM looks at the family/model/stepping, despite qemu64
reporting it is 64-bit capable.
This patch changes 'max' to report a CPUID with the family, model
and stepping taken from a
AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
which is one of the first 64-bit AMD CPUs.
Closes https://gitlab.com/qemu-project/qemu/-/issues/191
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20210507133650.645526-3-berrange@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 4519259a345e60a0b177176117e72be1e310377c
https://github.com/qemu/qemu/commit/4519259a345e60a0b177176117e72be1e310377c
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu.c
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: keep hyperv_vendor string up-to-date
When cpu->hyperv_vendor is not set manually we default to "Microsoft Hv"
and in 'hv_passthrough' mode we get the information from the host. This
information is stored in cpu->hyperv_vendor_id[] array but we don't update
cpu->hyperv_vendor string so e.g. QMP's query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-2-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 0c321f14b0ef94309b5e94855a8a9bc27ecc3911
https://github.com/qemu/qemu/commit/0c321f14b0ef94309b5e94855a8a9bc27ecc3911
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: invert hyperv_spinlock_attempts setting logic with hv_passthrough
There is no need to have this special case: like all other Hyper-V
enlightenments we can just use kernel's supplied value in hv_passthrough
mode.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-3-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 01e5582136188249e748d9af87397076bf814562
https://github.com/qemu/qemu/commit/01e5582136188249e748d9af87397076bf814562
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: always fill Hyper-V CPUID feature leaves from X86CPU data
We have all the required data in X86CPU already and as we are about to
split hyperv_handle_properties() into hyperv_expand_features()/
hyperv_fill_cpuids() we can remove the blind copy. The functional change
is that QEMU won't pass CPUID leaves it doesn't currently know about
to the guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-4-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: c830015e85103790dc06c434c246f2e8f5d15046
https://github.com/qemu/qemu/commit/c830015e85103790dc06c434c246f2e8f5d15046
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu.h
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: stop using env->features[] for filling Hyper-V CPUIDs
As a preparatory patch to dropping Hyper-V CPUID leaves from
feature_word_info[] stop using env->features[] as a temporary
storage of Hyper-V CPUIDs, just build Hyper-V CPUID leaves directly
from kvm_hyperv_properties[] data.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-5-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 7682f857f49fdac2cd3094a634a606f6d6994cc3
https://github.com/qemu/qemu/commit/7682f857f49fdac2cd3094a634a606f6d6994cc3
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: introduce hyperv_feature_supported()
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported()
off it. No functional change intended.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-6-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: e1a66a1e27eee8b025954713d28b9e74d95a5271
https://github.com/qemu/qemu/commit/e1a66a1e27eee8b025954713d28b9e74d95a5271
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: introduce hv_cpuid_get_host()
As a preparation to implementing hv_cpuid_cache intro introduce
hv_cpuid_get_host(). No functional change intended.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-7-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 061817a7ccd9e1c028153f308c541c299a009ef8
https://github.com/qemu/qemu/commit/061817a7ccd9e1c028153f308c541c299a009ef8
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/cpu-sysemu.c
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: drop FEAT_HYPERV feature leaves
Hyper-V feature leaves are weird. We have some of them in
feature_word_info[] array but we don't use feature_word_info
magic to enable them. Neither do we use feature_dependencies[]
mechanism to validate the configuration as it doesn't allign
well with Hyper-V's many-to-many dependency chains. Some of
the feature leaves hold not only feature bits, but also values.
E.g. FEAT_HV_NESTED_EAX contains both features and the supported
Enlightened VMCS range.
Hyper-V features are already represented in 'struct X86CPU' with
uint64_t hyperv_features so duplicating them in env->features adds
little (or zero) benefits. THe other half of Hyper-V emulation features
is also stored with values in hyperv_vendor_id[], hyperv_limits[],...
so env->features[] is already incomplete.
Remove Hyper-V feature leaves from env->features[] completely.
kvm_hyperv_properties[] is converted to using raw CPUID func/reg
pairs for features, this allows us to get rid of hv_cpuid_get_fw()
conversion.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-8-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: a8439be6b76e7f1dd631a49662314bc58e6c4ee0
https://github.com/qemu/qemu/commit/a8439be6b76e7f1dd631a49662314bc58e6c4ee0
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: introduce hv_cpuid_cache
Just like with cpuid_cache, it makes no sense to call
KVM_GET_SUPPORTED_HV_CPUID more than once and instead of (ab)using
env->features[] and/or trying to keep all the code in one place, it is
better to introduce persistent hv_cpuid_cache and hv_cpuid_get_host()
accessor to it.
Note, hv_cpuid_get_fw() is converted to using hv_cpuid_get_host()
just to be removed later with Hyper-V specific feature words.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-9-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: f6e01ab5633da17d3c5e346bf07d01af12d39b9b
https://github.com/qemu/qemu/commit/f6e01ab5633da17d3c5e346bf07d01af12d39b9b
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: split hyperv_handle_properties() into
hyperv_expand_features()/hyperv_fill_cpuids()
The intention is to call hyperv_expand_features() early, before vCPUs
are created and use the acquired data later when we set guest visible
CPUID data.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-10-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: decb4f2013141906913b2c358f043337ab982d3e
https://github.com/qemu/qemu/commit/decb4f2013141906913b2c358f043337ab982d3e
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: move eVMCS enablement to hyperv_init_vcpu()
hyperv_expand_features() will be called before we create vCPU so
evmcs enablement should go away. hyperv_init_vcpu() looks like the
right place.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-11-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: f4a62495be47b0211359f3609aeaf04a4fd44368
https://github.com/qemu/qemu/commit/f4a62495be47b0211359f3609aeaf04a4fd44368
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: switch hyperv_expand_features() to using error_setg()
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-12-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 05c900ce7392ef2f0bc7647863c8680641e137df
https://github.com/qemu/qemu/commit/05c900ce7392ef2f0bc7647863c8680641e137df
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array size
SYNDBG leaves were recently (Linux-5.8) added to KVM but we haven't
updated the expected size of KVM_GET_SUPPORTED_HV_CPUID output in
KVM so we now make serveral tries before succeeding. Update the
default.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-13-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 2e905438cf65e8aa4fe720448e90b09eaac75f69
https://github.com/qemu/qemu/commit/2e905438cf65e8aa4fe720448e90b09eaac75f69
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one
KVM_GET_SUPPORTED_HV_CPUID was made a system wide ioctl which can be called
prior to creating vCPUs and we are going to use that to expand Hyper-V cpu
features early. Use it when it is supported by KVM.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-14-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 5aa9ef5e4bb8194e66c4b62d8fe7ef8392786a9f
https://github.com/qemu/qemu/commit/5aa9ef5e4bb8194e66c4b62d8fe7ef8392786a9f
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: 2021-05-31 (Mon, 31 May 2021)
Changed paths:
M target/i386/kvm/kvm.c
Log Message:
-----------
i386: use global kvm_state in hyperv_enabled() check
There is no need to use vCPU-specific kvm state in hyperv_enabled() check
and we need to do that when feature expansion happens early, before vCPU
specific KVM state is created.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20210422161130.652779-15-vkuznets@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 3ea1a80243d5b5ba23d8c2b7d3a86034ea0ade22
https://github.com/qemu/qemu/commit/3ea1a80243d5b5ba23d8c2b7d3a86034ea0ade22
Author: Brijesh Singh <brijesh.singh@amd.com>
Date: 2021-06-01 (Tue, 01 Jun 2021)
Changed paths:
M linux-headers/linux/kvm.h
M qapi/misc-target.json
M target/i386/monitor.c
M target/i386/sev-stub.c
M target/i386/sev.c
M target/i386/sev_i386.h
M target/i386/trace-events
Log Message:
-----------
target/i386/sev: add support to query the attestation report
The SEV FW >= 0.23 added a new command that can be used to query the
attestation report containing the SHA-256 digest of the guest memory
and VMSA encrypted with the LAUNCH_UPDATE and sign it with the PEK.
Note, we already have a command (LAUNCH_MEASURE) that can be used to
query the SHA-256 digest of the guest memory encrypted through the
LAUNCH_UPDATE. The main difference between previous and this command
is that the report is signed with the PEK and unlike the LAUNCH_MEASURE
command the ATTESATION_REPORT command can be called while the guest
is running.
Add a QMP interface "query-sev-attestation-report" that can be used
to get the report encoded in base64.
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Tom Lendacky <Thomas.Lendacky@amd.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Reviewed-by: James Bottomley <jejb@linux.ibm.com>
Tested-by: James Bottomley <jejb@linux.ibm.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Connor Kuehl <ckuehl@redhat.com>
Message-Id: <20210429170728.24322-1-brijesh.singh@amd.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: 5811b936bf4b0340a83fea8b5b574670d8c219c4
https://github.com/qemu/qemu/commit/5811b936bf4b0340a83fea8b5b574670d8c219c4
Author: Connor Kuehl <ckuehl@redhat.com>
Date: 2021-06-01 (Tue, 01 Jun 2021)
Changed paths:
M target/i386/sev.c
Log Message:
-----------
sev: use explicit indices for mapping firmware error codes to strings
This can help lower any margin for error when making future additions to
the list, especially if they're made out of order.
While doing so, make capitalization of ASID consistent with its usage in
the SEV firmware spec (Asid -> ASID).
Signed-off-by: Connor Kuehl <ckuehl@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210430134830.254741-2-ckuehl@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: d47b85502b92fe8015d38904cde54eb4d3364326
https://github.com/qemu/qemu/commit/d47b85502b92fe8015d38904cde54eb4d3364326
Author: Connor Kuehl <ckuehl@redhat.com>
Date: 2021-06-01 (Tue, 01 Jun 2021)
Changed paths:
M target/i386/sev.c
Log Message:
-----------
sev: add missing firmware error conditions
The SEV userspace header[1] exports a couple of other error conditions that
aren't listed in QEMU's SEV implementation, so let's just round out the
list.
[1] linux-headers/linux/psp-sev.h
Signed-off-by: Connor Kuehl <ckuehl@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20210430134830.254741-3-ckuehl@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Commit: dd2db39d78431ab5a0b78777afaab3d61e94533e
https://github.com/qemu/qemu/commit/dd2db39d78431ab5a0b78777afaab3d61e94533e
Author: Peter Maydell <peter.maydell@linaro.org>
Date: 2021-06-01 (Tue, 01 Jun 2021)
Changed paths:
M hw/i386/pc.c
M linux-headers/linux/kvm.h
M qapi/misc-target.json
M target/i386/cpu-dump.c
M target/i386/cpu-sysemu.c
M target/i386/cpu.c
M target/i386/cpu.h
M target/i386/kvm/kvm-cpu.c
M target/i386/kvm/kvm.c
M target/i386/monitor.c
M target/i386/sev-stub.c
M target/i386/sev.c
M target/i386/sev_i386.h
M target/i386/trace-events
Log Message:
-----------
Merge remote-tracking branch 'remotes/ehabkost-gl/tags/x86-next-pull-request'
into staging
x86 queue, 2021-06-01
Features:
* Add CPU model versions supporting 'xsaves' (Vitaly Kuznetsov)
* Support AVX512 ZMM regs dump (Robert Hoo)
Bug fixes:
* Use better matching family/model/stepping for generic CPUs
(Daniel P. Berrangé)
Cleanups:
* Hyper-V feature initialization cleanup (Vitaly Kuznetsov)
* SEV firmware error list touchups (Connor Kuehl)
* Constify CPUCaches and X86CPUDefinition (Philippe Mathieu-Daudé)
* Document when features can be added to kvm_default_props
(Eduardo Habkost)
# gpg: Signature made Tue 01 Jun 2021 19:08:33 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: (24 commits)
sev: add missing firmware error conditions
sev: use explicit indices for mapping firmware error codes to strings
target/i386/sev: add support to query the attestation report
i386: use global kvm_state in hyperv_enabled() check
i386: prefer system KVM_GET_SUPPORTED_HV_CPUID ioctl over vCPU's one
i386: adjust the expected KVM_GET_SUPPORTED_HV_CPUID array size
i386: switch hyperv_expand_features() to using error_setg()
i386: move eVMCS enablement to hyperv_init_vcpu()
i386: split hyperv_handle_properties() into
hyperv_expand_features()/hyperv_fill_cpuids()
i386: introduce hv_cpuid_cache
i386: drop FEAT_HYPERV feature leaves
i386: introduce hv_cpuid_get_host()
i386: introduce hyperv_feature_supported()
i386: stop using env->features[] for filling Hyper-V CPUIDs
i386: always fill Hyper-V CPUID feature leaves from X86CPU data
i386: invert hyperv_spinlock_attempts setting logic with hv_passthrough
i386: keep hyperv_vendor string up-to-date
i386: use better matching family/model/stepping for 'max' CPU
i386: use better matching family/model/stepping for 'qemu64' CPU
i386/cpu_dump: support AVX512 ZMM regs dump
...
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Compare: https://github.com/qemu/qemu/compare/52848929b70d...dd2db39d7843