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
> >> hypercall
el_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'.
> - '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
f-by: Vitaly Kuznetsov
Reviewed-by: Eduardo Habkost
--
Eduardo
r_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
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
s 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
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
= 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
: <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 +110,8 @@ static
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 Habkost
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
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 Habkost
---
target/i386/cpu
sor 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.
ngh
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...@redhat.
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
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>
Signed-off-by: Eduardo H
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(-)
diff --git a/
.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/i386/kvm/kvm.c | 5 +
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-berra...@redhat.com>
Sign
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
wed-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/i386/se
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-by: Paolo
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-
wed-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
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
Connor Kuehl (2):
sev
odels 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.com>
Signed-off-by: Eduardo Habkost
---
target/
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 --git
T_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
rsen (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,
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
UState *cs)
> if (r) {
> goto fail;
> }
> +if (!cpuid_data_cached) {
> +cpuid_data_cached = g_malloc0(sizeof(cpuid_data));
> +memcpy(cpuid_data_cached, _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
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
issues/191
> Signed-off-by: Daniel P. Berrangé
Reviewed-by: Eduardo Habkost
--
Eduardo
t; +{ "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 wouldn't be very useful
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
l 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
ection 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
PERV_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
{.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
led 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_supported(cs, feat)) {
> +
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
_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, _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
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
t; 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
> +
upported(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
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
v_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 review
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()
>
nfig | 5 +
> hw/riscv/meson.build | 2 +-
> 12 files changed, 20 insertions(+), 7 deletions(-)
>
> --
> 2.26.3
>
>
>
--
Eduardo
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:
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
> Reviewed-by: Richard Henderson
Queued, thanks!
--
Eduardo
on
Queued, thanks!
--
Eduardo
d 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
ml
>
> 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 use qtest_has_accel() instead of the
> /* XXX */ comments:
> - tests: do not r
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
d_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 = _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 = _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
y 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:
Reviewed-by: Eduardo Habk
cting 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/i386/
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
r-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
ime 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
= 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 11839 matches
Mail list logo
