On Fri, Jun 04, 2021 at 09:35:27AM +0200, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Thu, Jun 03, 2021 at 01:48:34PM +0200, Vitaly Kuznetsov wrote:
> >> When Hyper-V SynIC is enabled, we may need to allow Windows guests to make
> >> hypercalls (PO
cpu_instance_init as post_init"),
> commit ("i386: reorder call to cpu_exec_realizefn"),
>
> Cc: Eduardo Habkost
> Cc: Vitaly Kuznetsov
> Cc: Paolo Bonzini
> Signed-off-by: Claudio Fontana
I think basic OVMF boot regression testing is still welcome, but
woul
On Fri, Jun 04, 2021 at 09:28:15AM +0200, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Thu, Jun 03, 2021 at 01:48:29PM +0200, Vitaly Kuznetsov wrote:
> >> Currently, the only eVMCS version, supported by KVM (and described in TLFS)
> >> is '1
igration-test',
> 'test-x86-cpuid-compat',
> - 'numa-test']
> + 'numa-test',
> + 'hyperv-test']
>
> dbus_daemon = find_program('dbus-daemon', required: false)
> if dbus_daemon.found() and config_host.has_key('GDBUS_CODEGEN')
> --
> 2.31.1
>
--
Eduardo
_only check needed?
Is the hyperv_synic_kvm_only check the only reason this was done
here and not at kvm_hyperv_properties?
> +}
> +
> /* Not exposed by KVM but needed to make CPU hotplug in Windows work */
> c->edx |= HV_CPU_DYNAMIC_PARTITIONING_AVAILABLE;
>
> --
> 2.31.1
>
--
Eduardo
y: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
--
Eduardo
d_features(cpu, &local_err)) {
> error_report_err(local_err);
> return -ENOSYS;
> }
> diff --git a/target/i386/kvm/kvm_i386.h b/target/i386/kvm/kvm_i386.h
> index dc725083891c..54667b35f09c 100644
> --- a/target/i386/kvm/kvm_i386.h
> +++ b/target/i386/kvm/kvm_i386.h
> @@ -47,6 +47,7 @@ bool kvm_has_x2apic_api(void);
> bool kvm_has_waitpkg(void);
>
> bool kvm_hv_vpindex_settable(void);
> +bool kvm_hyperv_expand_features(X86CPU *cpu, Error **errp);
>
> uint64_t kvm_swizzle_msi_ext_dest_id(uint64_t address);
Reviewed-by: Eduardo Habkost
--
Eduardo
On Thu, Jun 03, 2021 at 01:48:30PM +0200, Vitaly Kuznetsov wrote:
> Return 'false' when hyperv_expand_features() sets an error.
>
> No functional change intended.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
--
Eduardo
vmcs_version) {
error_setg(...);
return;
}
cpu->hyperv_nested[0] = vcpu_evmcs_version;
> +error_report("Hyper-V %s verson 1 is not supported by kernel",
> + kvm_hyperv_properties[HYPERV_FEAT_EVMCS].desc);
> return ret;
> }
> -
> -cpu->hyperv_nested[0] = evmcs_version;
> +cpu->hyperv_nested[0] = (1 << 8) | 1;
> }
>
> return 0;
> --
> 2.31.1
>
--
Eduardo
On Thu, Jun 03, 2021 at 01:48:28PM +0200, Vitaly Kuznetsov wrote:
> Clarify the fact that 'hv-passthrough' only enables features which are
> already known to QEMU and that it overrides all other 'hv-*' settings.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
--
Eduardo
On Thu, Jun 03, 2021 at 01:48:27PM +0200, Vitaly Kuznetsov wrote:
> While this is very unlikely to change, let's avoid hardcoding '12' as
> 'hyperv_vendor_id' length.
>
> No functional change intended.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
--
Eduardo
al)?
I'm queueing this series by now, but we truly need somebody to
volunteer as maintainer of the SEV code.
--
Eduardo
On Tue, Jun 01, 2021 at 04:17:41PM -0400, Eduardo Habkost wrote:
> Signed-off-by: Eduardo Habkost
> ---
> KVM_RUN_X86_BUS_LOCK is a requirement for:
> [PATCH v4] i386: Add ratelimit for bus locks acquired in guest
> Message-Id: <20210521043820.29678-1-chenyi.qi...@intel.com
On Thu, Jun 03, 2021 at 10:13:30AM +0200, Claudio Fontana wrote:
> On 6/1/21 8:48 PM, Eduardo Habkost wrote:
> > +Vitaly
> >
> > On Sat, May 29, 2021 at 11:13:12AM +0200, Claudio Fontana wrote:
> >> we need to expand features first, before we attempt to check them
&g
Is there a default value of ecx for when it is not provided by the
> user but needed by the leaf? Or is it an error if ecx is omitted in
> that case? Similarly, is it an error if ecx is provided but not
> needed?
What does "not provided by the user" mean here? This is not
describing the input to a QMP command, but the input to the CPUID
instruction.
--
Eduardo
te-linux-headers patches always consist of 100%
automated changes. This patch would require a manual update of
target/i386/sev.c to be included in the same commit as
the header update.
> >
> > #define SEV_FW_MAX_ERROR ARRAY_SIZE(sev_fw_errlist)
> >
> > @@ -160,6 +162,7 @@ fw_error_to_str(int code)
> > if (code < 0 || code >= SEV_FW_MAX_ERROR) {
> > return "unknown error";
> > }
> > +assert(sev_fw_errlist[code]);
> >
> > return sev_fw_errlist[code];
> > }
> >
>
--
Eduardo
CPU.
> > +# The KVM CPUID table defines the response to the CPUID
> > +# instruction when executed by the guest operating system.
>
> What is specific to KVM here?
>
> What about 'query-accel-cpuid' or 'query-vm-cpu-id'?
The implementation is KVM-specific. I believe it's a reasonable
compromise because the implementation is trivial, and a raw copy
of the KVM CPUID table makes it a more useful (KVM-specific)
debugging/testing mechanism.
I don't really mind how the command is called, but I would prefer
to add a more complex abstraction only if maintainers of other
accelerators are interested and volunteer to provide similar
functionality. I don't want to introduce complexity for use
cases that may not even exist.
>
> > +#
> > +# Returns: a list of CpuidEntry
> > +#
> > +# Since: 6.1
> > +##
> > +{ 'command': 'query-kvm-cpuid',
> > + 'returns': ['CpuidEntry'],
> > + 'if': 'defined(TARGET_I386) && defined(CONFIG_KVM)' }
> ...
> > diff --git a/tests/qtest/qmp-cmd-test.c b/tests/qtest/qmp-cmd-test.c
> > index c98b78d033..48add3ada1 100644
> > --- a/tests/qtest/qmp-cmd-test.c
> > +++ b/tests/qtest/qmp-cmd-test.c
> > @@ -46,6 +46,7 @@ static int query_error_class(const char *cmd)
> > { "query-balloon", ERROR_CLASS_DEVICE_NOT_ACTIVE },
> > { "query-hotpluggable-cpus", ERROR_CLASS_GENERIC_ERROR },
> > { "query-vm-generation-id", ERROR_CLASS_GENERIC_ERROR },
> > +{ "query-kvm-cpuid", ERROR_CLASS_GENERIC_ERROR },
> > { NULL, -1 }
> > };
> > int i;
> >
>
--
Eduardo
On Tue, Jun 01, 2021 at 02:18:37PM -0400, Eduardo Habkost wrote:
> On Mon, May 31, 2021 at 01:14:54PM +0800, Chenyi Qiang wrote:
> >
> >
> > On 5/28/2021 5:19 AM, Eduardo Habkost wrote:
> > > On Fri, May 21, 2021 at 12:38:20PM +0800, Chenyi Qiang wrote:
> >
u_type_info = {
> .parent = TYPE_CPU,
> .instance_size = sizeof(X86CPU),
> .instance_init = x86_cpu_initfn,
> +.instance_post_init = x86_cpu_post_initfn,
> +
> .abstract = true,
> .class_size = sizeof(X86CPUClass),
> .class_init = x86_cpu_common_class_init,
> --
> 2.26.2
>
--
Eduardo
interrupt even if host does not have the capability
> */
> +cpu->mwait.ecx |= CPUID_MWAIT_EMX | CPUID_MWAIT_IBE;
> +
The dependency between those lines and cpu_exec_realizefn() is
completely unclear here. What can we do to make this clearer and
less fragile?
Note that this is not a comment on this fix, specifically, but on
how the initialization ordering is easy to break here.
> /* For 64bit systems think about the number of physical bits to present.
> * ideally this should be the same as the host; anything other than
> matching
> * the host can cause incorrect guest behaviour.
> --
> 2.26.2
>
--
Eduardo
udé
Message-Id: <20210430134830.254741-3-cku...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/sev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/target/i386/sev.c b/target/i386/sev.c
index 5467407ee1d..83df8c09f6a 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -110,6 +
From: Vitaly Kuznetsov
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
Reviewed-by: Eduardo Habkost
Message-Id
From: Vitaly Kuznetsov
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
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-10-vkuzn...@redhat.
From: Vitaly Kuznetsov
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
Reviewed-by: Eduardo Ha
From: Vitaly Kuznetsov
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-12-vkuzn...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/kvm/kvm.c
m_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
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-8-vkuzn...@redhat.com>
Signed-off-by: Eduardo Habk
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
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-9-vkuzn...@redhat.com>
Signed-off-by: Eduardo Habkost
--
On Mon, May 31, 2021 at 01:14:54PM +0800, Chenyi Qiang wrote:
>
>
> On 5/28/2021 5:19 AM, Eduardo Habkost wrote:
> > On Fri, May 21, 2021 at 12:38:20PM +0800, Chenyi Qiang wrote:
> > [...]
> > > @@ -4222,6 +4247,15 @@ void kvm_arch_pre_run(CPUState *c
From: Vitaly Kuznetsov
As a preparation to implementing hv_cpuid_cache intro introduce
hv_cpuid_get_host(). No functional change intended.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-7-vkuzn...@redhat.com>
Signed-off-by: Eduardo H
From: Vitaly Kuznetsov
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
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-11-vkuzn...@redhat.
Reviewed-by: Connor Kuehl
Message-Id: <20210429170728.24322-1-brijesh.si...@amd.com>
Signed-off-by: Eduardo Habkost
---
linux-headers/linux/kvm.h | 8 +
target/i386/sev_i386.h| 2 ++
qapi/misc-target.json | 38 ++
target/i386/monitor.c | 6
target/i386
From: Vitaly Kuznetsov
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
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-3-vkuzn...@re
From: Vitaly Kuznetsov
Clean up hv_cpuid_check_and_set() by separating hyperv_feature_supported()
off it. No functional change intended.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-6-vkuzn...@redhat.com>
Signed-off-by: Eduardo H
From: Vitaly Kuznetsov
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
Reviewed-by: Eduardo Habkost
ith 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é
Message-Id: <20210507133650.645526-3-berra...@redhat.com>
ently know about
to the guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-4-vkuzn...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/kvm/kvm.c | 9 -
1 file changed, 9 deletions(-)
dif
dor string so e.g. QMP's query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
Message-Id: <20210422161130.652779-2-vkuzn...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 19 +--
target/i
ith 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é
Reviewed-by: Eduardo Habkost
Message-Id: <20210507133650.645526-2-ber
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20210503173524.833052-3-phi...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/target/i386/cpu.c b/targe
iewed-by: Philippe Mathieu-Daudé
Message-Id: <20210430134830.254741-2-cku...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/sev.c | 46 +++---
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/target/i386/sev.c b/target/i3
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
Acked
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
Reviewed-by: Richard Henderson
Message-Id: <1618986232-73826-1-git-send-email-robert...@linux.intel.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu-
-by: Eduardo Habkost
Message-Id: <20210422161130.652779-5-vkuzn...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.h | 1 +
target/i386/kvm/kvm.c | 80 +++
2 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/target/i38
From: Philippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé
Message-Id: <20210503173524.833052-2-phi...@redhat.com>
Signed-off-by: Eduardo Habkost
---
target/i386/cpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386
or Kuehl)
* Constify CPUCaches and X86CPUDefinition (Philippe Mathieu-Daudé)
* Document when features can be added to kvm_default_props
(Eduardo Habkost)
Brijesh Singh (1):
target/i386/sev: add support to query the attestation report
Con
ed. 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
Message-Id: <20210412073952.860944-1-vkuzn...@redhat.co
On Mon, May 31, 2021 at 04:01:16PM -0400, Eduardo Habkost wrote:
> On Thu, Apr 29, 2021 at 12:07:28PM -0500, Brijesh Singh wrote:
> > 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
>
t; 1 file changed, 25 insertions(+), 23 deletions(-)
I'm queueing this on x86-next, apologies for the delay.
--
Eduardo
r_setg(errp, "SEV: mnonce must be %ld bytes (got %ld)",
> +sizeof(input.mnonce), len);
This breaks the build on i386. Failed CI job:
https://gitlab.com/ehabkost/qemu/-/jobs/1300032082
I'm applying the following fixup.
Signed-off-by: Eduardo Habkost
---
diff -
break;
> +case KVM_EXIT_X86_BUS_LOCK:
> +/* already handled in kvm_arch_post_run */
> +ret = 0;
> +break;
> default:
> fprintf(stderr, "KVM: unknown exit reason %d\n", run->exit_reason);
> ret = -1;
> --
> 2.17.1
>
--
Eduardo
On Tue, May 18, 2021 at 10:53:51AM +0800, Ziqiao Kong wrote:
> On Tue, May 18, 2021 at 4:16 AM Eduardo Habkost wrote:
> >
> > On Fri, May 07, 2021 at 04:00:56PM +0800, Ziqiao Kong wrote:
> > > Move the float translation case to a new block by a new pair of braces.
> &
t removing this
> feature flag in this patch and leaving a TODO in the comment? Thus I
> can issue another patch
> to complete the feature later.
Sounds better to me. Otherwise you'll be just adding dead code
(because the flag will is impossible to be enabled if it's not
present in TCG_*_FEATURES).
--
Eduardo
no Larsen (billionai)
Acked-by: Eduardo Habkost
--
Eduardo
Cc: Paolo Bonzini
> Cc: k...@vger.kernel.org
> Reviewed-by: James Bottomley
> Tested-by: James Bottomley
> Signed-off-by: Brijesh Singh
Queued, thanks!
--
Eduardo
On Thu, May 27, 2021 at 09:39:02AM +0200, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Thu, Apr 22, 2021 at 06:11:11PM +0200, Vitaly Kuznetsov wrote:
> >> Vitaly Kuznetsov (19):
> >> i386: keep hyperv_vendor string up-to-date
> >> i386:
On Thu, May 27, 2021 at 09:37:59AM +0200, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Mon, May 24, 2021 at 02:22:47PM +0200, Vitaly Kuznetsov wrote:
> >> Eduardo Habkost writes:
> >>
> >> > On Thu, Apr 22, 2021 at 06:11:28PM +0200, Vi
On Thu, May 27, 2021 at 09:27:01AM +0200, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Mon, May 24, 2021 at 02:00:37PM +0200, Vitaly Kuznetsov wrote:
> > [...]
> >> >> @@ -1455,6 +1454,21 @@ static
ries[KVM_MAX_CPUID_ENTRIES];
> -} cpuid_data;
> /*
> * The kernel defines these structs with padding fields so there
> * should be no extra padding in our cpuid_data struct.
> */
> +struct CPUIDEntriesInfo cpuid_data;
> QEMU_BUILD_BUG_ON(sizeof(cpuid_data) !=
>sizeof(struct kvm_cpuid2) +
>sizeof(struct kvm_cpuid_entry2) *
> KVM_MAX_CPUID_ENTRIES);
> @@ -1833,6 +1866,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
> if (r) {
> goto fail;
> }
> +if (!cpuid_data_cached) {
> +cpuid_data_cached = g_malloc0(sizeof(cpuid_data));
> +memcpy(cpuid_data_cached, &cpuid_data, sizeof(cpuid_data));
You are going to copy more entries than necessary, but on the
other hand I like the simplicity of not having to calculate the
struct size before allocating.
> +}
Now I'm wondering if we want to cache the CPUID tables for all
VCPUs (not just the first one).
Being a debugging command, maybe it's an acceptable compromise to
copy the data only from one VCPU. If the need to return data for
other VCPUs arise, we can extend the command later.
>
> if (has_xsave) {
> env->xsave_buf = qemu_memalign(4096, sizeof(struct kvm_xsave));
> diff --git a/tests/qtest/qmp-cmd-test.c b/tests/qtest/qmp-cmd-test.c
> index c98b78d033..f5a926b61b 100644
> --- a/tests/qtest/qmp-cmd-test.c
> +++ b/tests/qtest/qmp-cmd-test.c
> @@ -46,6 +46,7 @@ static int query_error_class(const char *cmd)
> { "query-balloon", ERROR_CLASS_DEVICE_NOT_ACTIVE },
> { "query-hotpluggable-cpus", ERROR_CLASS_GENERIC_ERROR },
> { "query-vm-generation-id", ERROR_CLASS_GENERIC_ERROR },
> +{ "query-cpu-model-cpuid", ERROR_CLASS_GENERIC_ERROR },
> { NULL, -1 }
> };
> int i;
> --
> 2.17.1
>
--
Eduardo
t; i386: HV_HYPERCALL_AVAILABLE privilege bit is always needed
> i386: Hyper-V SynIC requires POST_MESSAGES/SIGNAL_EVENTS priviliges
> qtest/hyperv: Introduce a simple hyper-v test
--
Eduardo
On Fri, May 07, 2021 at 02:36:48PM +0100, Daniel P. Berrangé wrote:
[...]
> Daniel P. Berrangé (2):
> i386: use better matching family/model/stepping for 'qemu64' CPU
> i386: use better matching family/model/stepping for 'max' CPU
Queued, thanks!
--
Eduardo
m/qemu-project/qemu/-/issues/191
> Signed-off-by: Daniel P. Berrangé
Reviewed-by: Eduardo Habkost
--
Eduardo
uot;, "6" },
> +{ "qemu64" "-" TYPE_X86_CPU, "model", "6" },
> +{ "qemu64" "-" TYPE_X86_CPU, "stepping", "3" },
I wish we could have done this using a new CPU model version, but
the new version
On Mon, May 24, 2021 at 02:22:47PM +0200, Vitaly Kuznetsov wrote:
> Eduardo Habkost writes:
>
> > On Thu, Apr 22, 2021 at 06:11:28PM +0200, Vitaly Kuznetsov wrote:
> >> According to TLFS, Hyper-V guest is supposed to check
> >> HV_HYPERCALL_AVAILABLE
I'm afraid
> > this second call will hide bugs in query-cpu-model-expansion.
> >
>
> The first expansion will do nothing if KVM_CAP_SYS_HYPERV_CPUID is not
> supported, calling it here allows us to proceed. The series makes
> 'query-cpu-model-expansion' output correct only with
> KVM_CAP_SYS_HYPERV_CPUID, without it we don't seem to be able to do much
> (unless we decide to create a 'scratch' CPU or something like that).
Oh, I see. I suggest adding a comment explaining that.
Developers might be tempted to delete it and not notice it breaks
under older kernels.
--
Eduardo
ts" section in the docs, or it should be
moved to the supported build platforms section.
We have a clear policy on supported build platforms
[https://qemu-project.gitlab.io/qemu/system/build-platforms.html],
but not a clear policy for KVM kernel dependencies.
There's a table with Python and GCC versions at
[https://wiki.qemu.org/Supported_Build_Platforms].
Maybe it could include kernel version information as well.
--
Eduardo
able
> KVM_CAP_HYPERV_ENLIGHTENED_VMCS, and bail out if this fails. Propagate
> the the acquired evmcs version to 'cpu->hyperv_nested[]' otherwise.
This will be visible to the guest at CPUID[0x400A].EAX,
correct? You are initializing CPUID data with a value that
change depending on the host.
What is supposed to happen if live migrating to to a host with a
different evmcs_version?
--
Eduardo
_FREQUENCY_MSRS},
> {.func = HV_CPUID_FEATURES, .reg = R_EDX,
> .bits = HV_FREQUENCY_MSRS_AVAILABLE}
> }
> @@ -888,7 +890,8 @@ static struct {
> .desc = "reenlightenment MSRs (hv-reenlightenment)",
> .flags = {
> {.func = HV_CPUID_FEATURES, .reg = R_EAX,
> - .bits = HV_ACCESS_REENLIGHTENMENTS_CONTROL}
> + .bits = HV_HYPERCALL_AVAILABLE |
> + HV_ACCESS_REENLIGHTENMENTS_CONTROL}
> }
> },
> [HYPERV_FEAT_TLBFLUSH] = {
> --
> 2.30.2
>
--
Eduardo
* Mark feature as enabled in 'cpu->hyperv_features' as
> + * hv_build_cpuid_leaf() uses this info to build guest CPUIDs.
> + */
> +for (feat = 0; feat < ARRAY_SIZE(kvm_hyperv_properties); feat++) {
> +if (hyperv_feature_supp
a/target/i386/kvm/kvm_i386.h
> +++ b/target/i386/kvm/kvm_i386.h
> @@ -47,6 +47,7 @@ bool kvm_has_x2apic_api(void);
> bool kvm_has_waitpkg(void);
>
> bool kvm_hv_vpindex_settable(void);
> +void kvm_hyperv_expand_features(X86CPU *cpu, Error **errp);
>
> uint64_t kvm_swizzle_msi_ext_dest_id(uint64_t address);
>
> --
> 2.30.2
>
--
Eduardo
tsov
Reviewed-by: Eduardo Habkost
--
Eduardo
VM_CAP_HYPERV_ENLIGHTENED_VMCS) > 0) {
Oh, this conditional replaces the comment I suggested in patch
10/19. It makes it obvious that the hack can be deleted if we
remove support for the VCPU ioctl.
So, when exactly will we be able to delete the VCPU ioctl code
and support only the system ioctl?
Reviewed-by: Eduardo Habkost
> for (i = 0; i < cpuid->nent; i++) {
> if (cpuid->entries[i].function == HV_CPUID_ENLIGHTMENT_INFO) {
> --
> 2.30.2
>
--
Eduardo
.
>
> Signed-off-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
--
Eduardo
kvm_hyperv_properties[HYPERV_FEAT_SYNIC].desc,
> + kvm_hyperv_properties[HYPERV_FEAT_VPINDEX].desc);
> }
> -
> -return 0;
> }
>
> /*
> @@ -1527,9 +1547,10 @@ int kvm_arch_init_vcpu(CPUState *cs)
> env->apic_bus_freq = KVM_APIC_BUS_FREQUENCY;
>
> /* Paravirtualization CPUIDs */
> -r = hyperv_expand_features(cs);
> -if (r < 0) {
> -return r;
> +hyperv_expand_features(cs, &local_err);
> +if (local_err) {
> +error_report_err(local_err);
> +return -ENOSYS;
> }
>
> if (hyperv_enabled(cpu)) {
I don't want to block this series because of the suggestions above, so:
Reviewed-by: Eduardo Habkost
But I still encourage you to implement those suggestions, anyway.
--
Eduardo
ntries);
> kvm_base = KVM_CPUID_SIGNATURE_NEXT;
> has_msr_hv_hypercall = true;
> @@ -1868,11 +1887,6 @@ int kvm_arch_init_vcpu(CPUState *cs)
>
> kvm_init_msrs(cpu);
>
> -r = hyperv_init_vcpu(cpu);
> -if (r) {
> -goto fail;
> -}
> -
> return 0;
I would move the two hunks above to a separate patch, but not a
big deal. The guest ABI issue is existing, and the comment
suggestion can be done in a follow up patch, so:
Reviewed-by: Eduardo Habkost
>
> fail:
> --
> 2.30.2
>
--
Eduardo
On Thu, Apr 22, 2021 at 06:11:20PM +0200, Vitaly Kuznetsov wrote:
> 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
Reviewed-by:
duce 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
Reviewed-by: Eduardo Habkost
--
Eduardo
> conversion.
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> target/i386/cpu.c | 90 +--
> target/i386/cpu.h | 5 --
> target/i386/kvm/kvm.c | 108 ++--------
> 3 files changed, 37 insertions(+), 166 deletions(-)
Nice diffstat!
Reviewed-by: Eduardo Habkost
--
Eduardo
> +entry = cpuid_find_entry(cpuid, func, 0);
> +if (!entry) {
> +return 0;
One possible difference here is that leaves not supported by the
host will now be zeroed out.
...which I expected to be the correct behavior of hv-passthrough,
so:
Reviewed-by: Eduardo Habkost
> +
eature_supported(cpuid, feature)) {
> +if (hyperv_feat_enabled(cpu, feature)) {
> +fprintf(stderr,
> +"Hyper-V %s is not supported by kernel\n",
> +kvm_hyperv_properties[feature].desc);
> +return 1;
> +} else {
> +return 0;
The reason for returning prematurely here when
!hyperv_feat_enabled() is not clear to me, but you are keeping
the existing behavior, so:
Reviewed-by: Eduardo Habkost
> }
> }
>
> --
> 2.30.2
>
--
Eduardo
On Fri, Apr 30, 2021 at 08:34:40PM -0400, Eduardo Habkost wrote:
> On Thu, Apr 22, 2021 at 06:11:15PM +0200, Vitaly Kuznetsov wrote:
> > As a preparatory patch to dropping Hyper-V CPUID leaves from
> > feature_word_info[] stop using env->features[] as a temporary
> > s
On Wed, May 19, 2021 at 06:00:18PM +0800, Chenyi Qiang wrote:
>
>
> On 5/18/2021 3:46 AM, Eduardo Habkost wrote:
> > +Stefan
> >
> > I have a question about ratelimit_set_speed() below:
> >
> > On Fri, Apr 30, 2021 at 06:33:05PM +0800, Chenyi Qiang wrot
gt; goto unknown_op;
> }
> }
> +
> +if (update_fip) {
> +tcg_gen_ld32u_tl(s->T0, cpu_env,
> +offsetof(CPUX86State, segs[R_CS].selector));
> +tcg_gen_st16_tl(s->T0, cpu_env, offsetof(CPUX86State, fpcs));
> +
> +tcg_gen_movi_tl(s->T0, pc_start - s->cs_base);
> +tcg_gen_st_tl(s->T0, cpu_env, offsetof(CPUX86State, fpip));
> +}
> +
> +if (update_fdp) {
> +if (s->override >= 0) {
> +last_seg = s->override;
> +}
> +tcg_gen_ld32u_tl(s->T0, cpu_env,
> + offsetof(CPUX86State,
> + segs[last_seg].selector));
> +tcg_gen_st16_tl(s->T0, cpu_env, offsetof(CPUX86State, fpds));
> +
> +tcg_gen_st_tl(last_addr, cpu_env, offsetof(CPUX86State,
> fpdp));
> +}
> }
> break;
> //
> --
> 2.25.1
>
--
Eduardo
gen_helper_fmov_FT0_STN(cpu_env, tcg_const_i32(opreg));
> +gen_helper_fucom_ST0_FT0(cpu_env);
> +break;
> +case 0x2d: /* fucomp st(i) */
> + gen_helper_fmov_FT0_STN(cpu_env, tcg_const_i32(opreg));
> +gen_helper_fucom_ST0_FT0(cpu_env);
> +gen_helper_fpop(cpu_env);
> +break;
> +case 0x33: /* de/3 */
> +switch (rm) {
> +case 1: /* fcompp */
> +gen_helper_fmov_FT0_STN(cpu_env, tcg_const_i32(1));
> +gen_helper_fcom_ST0_FT0(cpu_env);
> +gen_helper_fpop(cpu_env);
> +gen_helper_fpop(cpu_env);
> +break;
> +default:
> +goto unknown_op;
> +}
> +break;
> +case 0x38: /* ffreep sti, undocumented op */
> +gen_helper_ffree_STN(cpu_env, tcg_const_i32(opreg));
> +gen_helper_fpop(cpu_env);
> +break;
> +case 0x3c: /* df/4 */
> +switch (rm) {
> +case 0:
> +gen_helper_fnstsw(s->tmp2_i32, cpu_env);
> +tcg_gen_extu_i32_tl(s->T0, s->tmp2_i32);
> +gen_op_mov_reg_v(s, MO_16, R_EAX, s->T0);
> +break;
> +default:
> +goto unknown_op;
> +}
> +break;
> +case 0x3d: /* fucomip */
> +if (!(s->cpuid_features & CPUID_CMOV)) {
> +goto illegal_op;
> +}
> +gen_update_cc_op(s);
> +gen_helper_fmov_FT0_STN(cpu_env, tcg_const_i32(opreg));
> +gen_helper_fucomi_ST0_FT0(cpu_env);
> +gen_helper_fpop(cpu_env);
> +set_cc_op(s, CC_OP_EFLAGS);
> +break;
> +case 0x3e: /* fcomip */
> +if (!(s->cpuid_features & CPUID_CMOV)) {
> +goto illegal_op;
> +}
> +gen_update_cc_op(s);
> +gen_helper_fmov_FT0_STN(cpu_env, tcg_const_i32(opreg));
> +gen_helper_fcomi_ST0_FT0(cpu_env);
> +gen_helper_fpop(cpu_env);
> +set_cc_op(s, CC_OP_EFLAGS);
> +break;
> +case 0x10 ... 0x13: /* fcmovxx */
> +case 0x18 ... 0x1b:
> +{
> +int op1;
> +TCGLabel *l1;
> +static const uint8_t fcmov_cc[8] = {
> +(JCC_B << 1),
> +(JCC_Z << 1),
> +(JCC_BE << 1),
> +(JCC_P << 1),
> +};
> +
> +if (!(s->cpuid_features & CPUID_CMOV)) {
> +goto illegal_op;
> +}
> +op1 = fcmov_cc[op & 3] | (((op >> 3) & 1) ^ 1);
> +l1 = gen_new_label();
> +gen_jcc1_noeob(s, op1, l1);
> +gen_helper_fmov_ST0_STN(cpu_env,
> tcg_const_i32(opreg));
> +gen_set_label(l1);
> +}
> +break;
> +default:
> +goto unknown_op;
> }
> -break;
> -default:
> -goto unknown_op;
> }
> }
> break;
> --
> 2.25.1
>
--
Eduardo
On Mon, May 17, 2021 at 03:18:56PM -0400, Eduardo Habkost wrote:
> CCing Build system architecture maintainer (Daniel).
Oops, I was misled by the subsection title. Daniel is
responsible only for the build system documentation.
Do we have any volunteers willing to be listed as reviewers
et-extensions-programming-reference.html
>
> Signed-off-by: Chenyi Qiang
>
> ---
> Changes from v2:
> - do some rename work (bus-lock-ratelimit and BUS_LOCK_TIME_SLICE).
> (Eduardo)
> - change to register a class property at the x86_machine_class_init()
>
3 +++
> hw/riscv/Kconfig | 5 +
> hw/riscv/meson.build | 2 +-
> 12 files changed, 20 insertions(+), 7 deletions(-)
>
> --
> 2.26.3
>
>
>
--
Eduardo
S_MASK | \
> + XSTATE_BNDCSR_MASK | XSTATE_OPMASK_MASK | \
> + XSTATE_ZMM_Hi256_MASK | \
> + XSTATE_Hi16_ZMM_MASK | XSTATE_PKRU_MASK)
> +
> +/* CPUID feature bits available in XSS */
> +#define CPUID_XSTATE_XSS_MASK0
Do you expect this to be used outside target/i386/cpu.c? If not,
maybe it could be moved close to the x86_ext_save_areas[]
definition, as any updates to x86_ext_save_areas will require an
update to these macros.
> +
> /* CPUID feature words */
> typedef enum FeatureWord {
> FEAT_1_EDX, /* CPUID[1].EDX */
> @@ -541,6 +551,8 @@ typedef enum FeatureWord {
> FEAT_VMX_EPT_VPID_CAPS,
> FEAT_VMX_BASIC,
> FEAT_VMX_VMFUNC,
> +FEAT_XSAVE_XSS_LO, /* CPUID[EAX=0xd,ECX=1].ECX */
> +FEAT_XSAVE_XSS_HI, /* CPUID[EAX=0xd,ECX=1].EDX */
> FEATURE_WORDS,
> } FeatureWord;
>
> --
> 2.26.2
>
>
--
Eduardo
On Thu, Apr 29, 2021 at 01:26:58PM +0200, David Hildenbrand wrote:
> v4 has been floating around for a while. Let's see if we can find someone
> to merge this; or at least give some more feedback ... all patches have
> at least one RB.
Acked-by: Eduardo Habkost
David Gilbert:
t; 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
> Reviewed-by: Richard Henderson
Queued, thanks!
--
Eduardo
on
Queued, thanks!
--
Eduardo
to v5.
I don't understand what "target-specific poisoning of accelerator
definitions" means.
>
> Reviewed-by: Eric Blake
> Reviewed-by: Alex Bennée
> Tested-by: Alex Bennée
> Signed-off-by: Philippe Mathieu-Daudé
Sorry for not even reviewing this before, but still:
Acked-by: Eduardo Habkost
--
Eduardo
ferring to:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg804015.html
>
> Then these aren't required:
> - tests: restrict TCG-only arm-cpu-features tests to TCG builds
> - tests: device-introspect-test: cope with ARM TCG-only devices
>
> These could be reworked to us
On Tue, May 04, 2021 at 03:32:55PM +0100, Stefan Hajnoczi wrote:
> On Thu, Apr 29, 2021 at 02:03:52PM -0400, Eduardo Habkost wrote:
> > On Thu, Apr 29, 2021 at 04:52:21PM +0100, Stefan Hajnoczi wrote:
> > > Live migrating old guests from an old QEMU with the SCSI feature bit
c->eax = env->features[FEAT_HV_RECOMM_EAX];
[Line2]
> +c->eax = hv_build_cpuid_leaf(cs, FEAT_HV_RECOMM_EAX);
[Line3]
> c->ebx = cpu->hyperv_spinlock_attempts;
>
> +if (cpu->hyperv_no_nonarch_cs == ON_OFF_AUTO_ON) {
> +c->eax |= HV_NO_NONARCH_CORESHARING;
> +} else if (cpu->hyperv_no_nonarch_cs == ON_OFF_AUTO_AUTO) {
> +c2 = cpuid_find_entry(cpuid, HV_CPUID_ENLIGHTMENT_INFO, 0);
> +if (c2) {
> +c->eax |= c2->eax & HV_NO_NONARCH_CORESHARING;
> +}
> +}
> +
> c = &cpuid_ent[cpuid_i++];
> c->function = HV_CPUID_IMPLEMENT_LIMITS;
> c->eax = cpu->hv_max_vps;
> @@ -1358,7 +1362,7 @@ static int hyperv_handle_properties(CPUState *cs,
>
> c = &cpuid_ent[cpuid_i++];
> c->function = HV_CPUID_NESTED_FEATURES;
> -c->eax = env->features[FEAT_HV_NESTED_EAX];
> +c->eax = cpu->hyperv_nested[0];
> }
> r = cpuid_i;
>
> --
> 2.30.2
>
--
Eduardo
eventually make hv-passthrough supported in production when
live migration support isn't required.
I'll trust your judgement here and assume this is really a good
change, but maybe this should be documented more explicitly in
the hv-passthrough section at docs/hyperv.txt?
Anyway:
Revie
expecting all properties set explicitly to override
hv-passthrough.
Reviewed-by: Eduardo Habkost
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> target/i386/kvm/kvm.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/target/i386/kvm/kvm.c b/target/
; + sizeof(cpu->hyperv_vendor_id) +
> 1);
> +memcpy(cpu->hyperv_vendor, cpu->hyperv_vendor_id,
> + sizeof(cpu->hyperv_vendor_id));
> +cpu->hyperv_vendor[sizeof(cpu->hyperv_vendor_id)] = 0;
I don't like having to do manual g_realloc() + memcpy() here
(calling object_property_set_str() would be simpler), but I
believe it will be easier to clean this up after this whole
series is applied.
Reluctantly:
Reviewed-by: Eduardo Habkost
> }
>
> c = cpuid_find_entry(cpuid, HV_CPUID_INTERFACE, 0);
> --
> 2.30.2
>
--
Eduardo
ot;lbr-fmt=0xff" is a "valid" lbr-fmt
> and it may enable guest LBR (depend on the "migratable" flag).
You are correct, lbr-fmt=0xff will be synonymous to "use default
lbr-fmt", but this won't be obvious.
You can avoid this by validating the user-provided value in a
property setter. Or you could just document that 0xff has a
special meaning, to avoid a custom setter. I believe custom
setters are more likely to cause us problems in the future than
users fiddling with obviously an invalid lbr-fmt value.
--
Eduardo
version 1 of those CPU models). In future QEMU
> versions, aliases will point to newer CPU model versions
> depending on the machine type, so management software must
> resolve CPU model aliases before starting a virtual machine.
libvirt had no time to adapt to this yet. As far as I
understand, they need the following series to be merged first so
they can more easily resolve the unversioned CPU model name
aliases:
https://lore.kernel.org/qemu-devel/20201013230457.150630-1-ehabk...@redhat.com
I need to rebase that series and resubmit.
--
Eduardo
5_len = G_N_ELEMENTS(hw_compat_2_5);
>
> GlobalProperty hw_compat_2_4[] = {
> -/* Optional because the 'scsi' property is Linux-only */
> -{ "virtio-blk-device", "scsi", "true", .optional = true },
> { "e1000", "extra_mac_registers", "off" },
> { "virtio-pci", "x-disable-pcie", "on" },
> { "virtio-pci", "migrate-extra", "off" },
--
Eduardo
201 - 300 of 11868 matches
Mail list logo
