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
---
target/i386/kvm/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions
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
---
target/i386/kvm/kvm.c | 60 ++-
1 file changed, 37 insertions(+), 23
ote, 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
---
target/i386/kvm/kvm.c | 109 ++
1 file changed, 56 insertions(+), 53 deletions(-)
diff --git a/target/i386/
tion.
Introduce a simple 'hv-default=on' CPU flag enabling all currently supported
Hyper-V enlightenments. Later, when new enlightenments get implemented,
compat_props mechanism will be used to disable them for legacy machine types,
this will keep 'hv-default=on' configurations
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).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c
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
---
target/i386/kvm/kvm.c | 34 --
1 file changed, 24 insertions(+), 10
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
---
target/i386/kvm/kvm.c | 17 +
1 file
For the beginning, just test 'hv-default', 'hv-passthrough' and a couple
of custom Hyper-V enlightenments configurations through QMP. Later, it
would be great to complement this by checking CPUID values from within the
guest.
Signed-off-by: Vitaly Kuznetsov
---
MAINTAINERS
Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for
an interrupt instead of VMBus message). This new capability is only
announced in KVM_GET_SUPPORTED_HV_CPUID.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 10 ++
target/i386/cpu.c | 1
r-V synthetic timers
enlightenment is only exposed through KVM_GET_SUPPORTED_HV_CPUID ioctl.
Take the opportunity and re-implement the way we handle Hyper-V
enlightenments in QEMU, add support for hv-stimer-direct and 'hv-all'
pass-through mode, add missing dependencies between enlightenments.
Vitaly
Synthetic timers operate in hv-time time and Windows won't use these
without SynIC.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 9edf76e473..524ee28e9c 100644
--- a/target/i386/
properties structure
defining Hyper-V features, get_supported_hv_cpuid()/
get_supported_hv_cpuid_legacy() returning the supported CPUID set and
a bit over-engineered hv_cpuid_check_and_set() which we will also be
used to set cpu->hyperv_* properties for 'hv-all' mode.
Signed-off-by: Vitaly
Currently, there is no doc describing hv-* CPU flags, people are
encouraged to get the information from Microsoft Hyper-V Top Level
Functional specification (TLFS). There is, however, a bit of QEMU
specifics.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 180
want to check them later (and we actually do for hv_runtime,
hv_synic,...).
'hv-all' is a development only feature, a migration blocker is added to
prevent issues while migrating between hosts with different feature sets.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 10
Enlightened VMCS is enabled by writing to a field in VP assist page and
these require virtual APIC.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index af45241adb..9edf76e473
The corresponding hypercalls require using VP indexes.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 524ee28e9c..976c1d570f 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
Let's consolidate Hyper-V features handling in hyperv_handle_properties().
The change is necessary to support pass-through 'hv-all' mode as we'll be
just copying CPUIDs from KVM instead of filling them in.
Signed-off-by: Vitaly Kuznetsov
---
tar
"Dr. David Alan Gilbert" writes:
> Yep, that's probably safest; although if you recorded the features used
> in the migration stream you could check for those on the destination and
> if they mismatch complain then.
>
There is no clear use-case for hv-all other than development at this
moment; a
y
irq delivery duringeoi broadcast") which describes a very similar issue.
Steal the idea from the above mentioned commit for IOAPIC implementation in
QEMU. SUCCESSIVE_IRQ_MAX_COUNT, delay and the comment are borrowed as well.
Signed-off-by: Vitaly Kuznetsov
---
hw/intc/ioapic.c
Paolo Bonzini writes:
> On 01/04/19 15:36, Vitaly Kuznetsov wrote:
...
>> static void ioapic_set_irq(void *opaque, int vector, int level)
>> {
>> IOAPICCommonState *s = opaque;
>> @@ -227,7 +236,28 @@ void ioapic_eoi_broadcast(int vector)
>>
Liran Alon writes:
>> On 1 Apr 2019, at 16:36, Vitaly Kuznetsov wrote:
>>
>> It was found that Hyper-V 2016 on KVM in some configurations (q35 machine +
>> piix4-usb-uhci) hangs on boot. Trace analysis led us to the conclusion that
>> it is mishandling level-trig
Liran Alon writes:
>> On 1 Apr 2019, at 18:58, Vitaly Kuznetsov wrote:
>>
>> Liran Alon writes:
>>
>>>> On 1 Apr 2019, at 16:36, Vitaly Kuznetsov wrote:
>>>>
>>>> It was found that Hyper-V 2016 on KVM in some configurations (q35
ngeoi broadcast") which describes a very similar issue.
Steal the idea from the above mentioned commit for IOAPIC implementation in
QEMU. SUCCESSIVE_IRQ_MAX_COUNT, delay and the comment are borrowed as well.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- timer_mod() -> timer_m
Roman Kagan writes:
> On Fri, Mar 29, 2019 at 03:18:27PM +0100, Vitaly Kuznetsov wrote:
>> Currently, there is no doc describing hv-* CPU flags, people are
>> encouraged to get the information from Microsoft Hyper-V Top Level
>> Functional specification (TLFS). There is, h
Roman Kagan writes:
> On Fri, Mar 29, 2019 at 03:18:28PM +0100, Vitaly Kuznetsov wrote:
>> In many case we just want to give Windows guests all currently supported
>> Hyper-V enlightenments and that's where this new mode may come handy. We
>> pass th
Roman Kagan writes:
> On Fri, May 17, 2019 at 04:19:17PM +0200, Vitaly Kuznetsov wrote:
>> KVM now supports reporting supported Hyper-V features through CPUID
>> (KVM_GET_SUPPORTED_HV_CPUID ioctl). Going forward, this is going to be
>> the only way to announce new funct
Roman Kagan writes:
> On Mon, May 27, 2019 at 06:39:53PM +0200, Vitaly Kuznetsov wrote:
>> Roman Kagan writes:
>> > On Fri, May 17, 2019 at 04:19:17PM +0200, Vitaly Kuznetsov wrote:
>> >> +static struct kvm_cpuid2 *try_get_hv_cpuid(CPUState *cs, int max)
>>
Thomas, Albert, David,
I'm having hard times trying to reproduce the issue in my environment;
could you please provide your qemu command lines for both L0 and L1? It
would also be great if you could try to come up with some 'minimal'
configuration (my guess is that in L1 having just "qemu-system-x
Thank you David, I see the issue now.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1813165
Title:
KVM internal error. Suberror: 1 emulation failure
Status in QEMU:
New
Bug description:
Hello
I sent a patch which is supposed to fix the issue:
https://marc.info/?l=kvm&m=155085391830663&w=2
it would be great if someone could give it a spin!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1813
no-re...@patchew.org writes:
> === OUTPUT BEGIN ===
> 1/8 Checking commit 345a0718e21e (Update linux headers (5.0-rc2))
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #1646:
> new file mode 100644
>
> ERROR: code indent should never use tabs
> #3980: FILE: scripts/u
Synthetic timers operate in hv-time time and Windows won't use these
without SynIC.
Add .dependencies field to kvm_hyperv_properties[] and a generic mechanism
to check dependencies between features.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 23 +++
1
oduced Direct Mode for Hyper-V synthetic timers
enlightenment is only exposed through KVM_GET_SUPPORTED_HV_CPUID ioctl.
Take the opportunity and re-implement the way we handle Hyper-V
enlightenments in QEMU, add support for hv-stimer-direct and 'hv-all'
pass-through mode, add missing depe
The corresponding hypercalls require using VP indexes.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index d8b83031a5..7fc97b749e 100644
--- a/target/i386/kvm.c
+++ b/target
Let's consolidate Hyper-V features handling in hyperv_handle_properties().
The change is necessary to support 'hv-passthrough' mode as we'll be just
copying CPUIDs from KVM instead of filling them in.
Signed-off-by: Vitaly Kuznetsov
---
tar
properties structure
defining Hyper-V features, get_supported_hv_cpuid()/
get_supported_hv_cpuid_legacy() returning the supported CPUID set and
a bit over-engineered hv_cpuid_check_and_set() which we will also be
used to set cpu->hyperv_* properties for 'hv-all' mode.
Signed-off-by: Vitaly
Representing Hyper-V properties as bits will allow us to check features
and dependencies between them in a natural way.
Suggested-by: Roman Kagan
Signed-off-by: Vitaly Kuznetsov
---
hw/i386/pc.c | 3 +-
target/i386/cpu.c | 44 +++
target/i386/cpu.h | 37
want to check them later (and we actually do for hv_runtime,
hv_synic,...).
'hv-passthrough' is a development only feature, a migration blocker is
added to prevent issues while migrating between hosts with different
feature sets.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt |
Enlightened VMCS is enabled by writing to a field in VP assist page and
these require virtual APIC.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 7fc97b749e..7ae2f63f72
Currently, there is no doc describing hv-* CPU flags, people are
encouraged to get the information from Microsoft Hyper-V Top Level
Functional specification (TLFS). There is, however, a bit of QEMU
specifics.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt | 181
Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for
an interrupt instead of VMBus message). This new capability is only
announced in KVM_GET_SUPPORTED_HV_CPUID.
Signed-off-by: Vitaly Kuznetsov
---
docs/hyperv.txt| 10 ++
target/i386/cpu.c | 2
5 and EPYC/EPYC-IBPB cpu models.
Signed-off-by: Vitaly Kuznetsov
---
Changes since v1:
- add npt=off,nrip-save=off to pc_compat_3_1 [Eduardo Habkost]
---
hw/i386/pc.c | 8
target/i386/cpu.c | 8
2 files changed, 16 insertions(+)
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
Signed-off-by: Vitaly Kuznetsov
---
include/standard-headers/drm/drm_fourcc.h | 63 +
include/standard-headers/linux/ethtool.h | 19 +-
.../linux/input-event-codes.h | 19 +
include/standard-headers/linux/pci_regs.h |1 +
.../standard-headers/linux
want to check them later (and we actually do for hv_runtime,
hv_synic,...).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 1 +
target/i386/cpu.h | 1 +
target/i386/kvm.c | 133 --
3 files changed, 107 insertions(+), 28 deletions(-)
diff
The corresponding hypercalls require using VP indexes.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 7461bf05dd..14d74ca9c7 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
Synthetic timers operate in hv-time time and Windows won't use these
without SynIC.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 674c5dc185..7461bf05dd 100644
--- a/target/i386/
could've kept QEMU filling in signature, vendor,...
but we take CPUIDs passed by KVM 'as-is'.
Vitaly Kuznetsov (8):
Update linux headers (5.0-rc2)
i386/kvm: add support for KVM_GET_SUPPORTED_HV_CPUID
i386/kvm: move Hyper-V CPUID filling to hyperv_handle_properties()
i386/kvm: Im
properties structure
defining Hyper-V features, get_supported_hv_cpuid()/
get_supported_hv_cpuid_legacy() returning the supported CPUID set and
a bit over-engineered hv_cpuid_check_and_set() which we will also be
used to set cpu->hyperv_* properties for 'hv-all' mode.
Signed-off-by: Vitaly
Let's consolidate Hyper-V features handling in hyperv_handle_properties().
The change is necessary to support pass-through 'hv-all' mode as we'll be
just copying CPUIDs from KVM instead of filling them in.
Signed-off-by: Vitaly Kuznetsov
---
tar
Enlightened VMCS is enabled by writing to a field in VP assist page and
these require virtual APIC.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index b373b4ac06..674c5dc185
Hyper-V on KVM can only use Synthetic timers with Direct Mode (opting for
an interrupt instead of VMBus message). This new capability is only
announced in KVM_GET_SUPPORTED_HV_CPUID.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 1 +
target/i386/cpu.h | 1 +
target
Roman Kagan writes:
> On Fri, Jan 25, 2019 at 12:41:51PM +0100, Vitaly Kuznetsov wrote:
>> In many case we just want to give Windows guests all currently supported
>> Hyper-V enlightenments and that's where this new mode may come handy. We
>> pass th
Roman Kagan writes:
> On Fri, Jan 25, 2019 at 02:46:42PM +0100, Vitaly Kuznetsov wrote:
>> Roman Kagan writes:
>>
>> > On Fri, Jan 25, 2019 at 12:41:51PM +0100, Vitaly Kuznetsov wrote:
>> >> In many case we just want to give Windows guests all currently su
Eduardo Habkost writes:
>
> If libvirt is involved, it's much simpler and safer to use
> something like , which generates a
> migration-safe CPU configuration based on the current host. Live
> migration support with "-cpu host" is only useful for experiments
> and carefully controlled environmen
"Dr. David Alan Gilbert" writes:
> I'm not sure what the equivalent bear traps are in the Hyper-V world,
> but I'd be surprised if there weren't any; for example what happens
> when someone upgrades one of their hosts to some minor version that
> adds/removes a feature?
Here we're talking about
"KVM: x86:
Switch KVM guest to using interrupts for page ready APF delivery").
The feature has a new KVM_FEATURE_ASYNC_PF_INT bit assigned and
the interrupt vector is set in MSR_KVM_ASYNC_PF_INT MSR. Support this
in QEMU.
Signed-off-by: Vitaly Kuznetsov
---
- Note, Linux-5.9-rc4 is curre
Paolo Bonzini writes:
> On 12/09/20 08:02, Paolo Bonzini wrote:
>> @@ -4209,6 +4209,7 @@ static PropValue kvm_default_props[] = {
>> { "kvmclock", "on" },
>> { "kvm-nopiodelay", "on" },
>> { "kvm-asyncpf", "on" },
>> +{ "kvm-asyncpf-int", "on" },
>> { "kvm-steal-time", "on
"Dr. David Alan Gilbert" writes:
> cc'ing in Vitaly who knows about the hv stuff.
>
cc'ing Marcelo who knows about clocksources :-)
> * Antoine Damhet (antoine.dam...@blade-group.com) wrote:
>> Hi,
>>
>> We are experiencing timestamp rollbacks during live-migration of
>> Windows 10 guests
Are
Antoine Damhet writes:
> On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote:
>> cc'ing in Vitaly who knows about the hv stuff.
>
> Thanks
>
>>
>> * Antoine Damhet (antoine.dam...@blade-group.com) wrote:
>> > Hi,
>> >
>> > We are experiencing timestamp rollbacks during live-m
Vitaly Kuznetsov writes:
> Antoine Damhet writes:
>
>> On Wed, Sep 16, 2020 at 12:29:56PM +0100, Dr. David Alan Gilbert wrote:
>>> cc'ing in Vitaly who knows about the hv stuff.
>>
>> Thanks
>>
>>>
>>> * Antoine Damhet (antoin
Paolo Bonzini writes:
> On 16/09/20 13:29, Dr. David Alan Gilbert wrote:
>>> I have tracked the bug to the fact that `kvmclock` is not exposed and
>>> disabled from qemu PoV but is in fact used by `hv-time` (in KVM).
>>>
>>> I think we should enable the `kvmclock` (qemu device) if `hv-time` is
>>
before MSR_KVM_ASYNC_PF_INT is set
and this violates the check in KVM.
Re-order MSR_KVM_ASYNC_PF_EN/MSR_KVM_ASYNC_PF_INT setting (and
kvm_get_msrs() for consistency) and fix the typo.
Signed-off-by: Vitaly Kuznetsov
---
This fixes queued but not yet pushed to git commit
"target/i386: su
eck instead of CPUID feature bits.
Reported-by: Antoine Damhet
Suggested-by: Paolo Bonzini
Signed-off-by: Vitaly Kuznetsov
---
hw/i386/kvm/clock.c| 6 +-
target/i386/kvm.c | 5 +
target/i386/kvm_i386.h | 1 +
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/hw/i386/k
no-re...@patchew.org writes:
> Patchew URL:
> https://patchew.org/QEMU/20200917111306.819263-1-vkuzn...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> N/A. Internal error while reading log file
error: copy-fd: write
Antoine Damhet writes:
> On Thu, Sep 17, 2020 at 01:13:06PM +0200, Vitaly Kuznetsov wrote:
>> QEMU's kvmclock device is only created when KVM PV feature bits for
>> kvmclock (KVM_FEATURE_CLOCKSOURCE/KVM_FEATURE_CLOCKSOURCE2) are
>> exposed to the guest. With 'kvm=
"Dr. David Alan Gilbert" writes:
> * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote:
>> Antoine Damhet writes:
>>
>> > On Thu, Sep 17, 2020 at 01:13:06PM +0200, Vitaly Kuznetsov wrote:
>> >> QEMU's kvmclock device is only
Eduardo Habkost writes:
> On Fri, Sep 04, 2020 at 04:54:12PM +0200, Vitaly Kuznetsov wrote:
>> As a preparation to expanding Hyper-V CPU features early, move
>> hyperv_vendor_id initialization to x86_cpu_realizefn().
>>
>> Signed-off-by: Vitaly Kuznetsov
>&g
Eduardo Habkost writes:
> On Fri, Sep 04, 2020 at 04:54:18PM +0200, Vitaly Kuznetsov wrote:
>> As a preparation to expanding Hyper-V CPU features early, add
>> reserved FEAT_HYPERV_ECX CPUID leaf.
>>
>> Signed-off-by: Vitaly Kuznetsov
>> ---
>> targ
Eduardo Habkost writes:
> On Fri, Sep 04, 2020 at 04:54:21PM +0200, Vitaly Kuznetsov wrote:
>> 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 remov
Eduardo Habkost writes:
> On Fri, Sep 04, 2020 at 04:54:31PM +0200, Vitaly Kuznetsov wrote:
>> 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
Eduardo Habkost writes:
> On Fri, Sep 04, 2020 at 04:54:31PM +0200, Vitaly Kuznetsov wrote:
>> 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
"Dr. David Alan Gilbert" writes:
> * Antoine Damhet (antoine.dam...@blade-group.com) wrote:
>> On Thu, Sep 17, 2020 at 06:44:10PM +0100, Dr. David Alan Gilbert wrote:
>>
>> [...]
>>
>> > > >> >
>> > > >> > Shouldn't the old check used when machine type <= 5.1 in order to
>> > > >> > avoid
>> >
eck instead of CPUID feature bits.
Reported-by: Antoine Damhet
Suggested-by: Paolo Bonzini
Signed-off-by: Vitaly Kuznetsov
---
hw/i386/kvm/clock.c| 7 +--
hw/i386/microvm.c | 2 +-
hw/i386/pc.c | 1 +
hw/i386/pc_piix.c | 7 +--
hw/i386/pc_q35.c | 5 -
Eduardo Habkost writes:
> This addresses the following crash when running Linux v5.8
> with kernel-irqchip=off:
>
> qemu-system-x86_64: error: failed to set MSR 0x4b564d02 to 0x0
> qemu-system-x86_64: ../target/i386/kvm.c:2714: kvm_buf_set_msrs: Assertion
> `ret == cpu->kvm_msr_buf->nmsrs' f
Eduardo Habkost writes:
> On Tue, Sep 22, 2020 at 05:38:12PM +0200, Vitaly Kuznetsov wrote:
>> Eduardo Habkost writes:
>>
>> > This addresses the following crash when running Linux v5.8
>> > with kernel-irqchip=off:
>> >
>> > qemu-system
Peter Xu writes:
> Vitaly,
>
> On Mon, Oct 26, 2020 at 09:49:16AM +0100, Vitaly Kuznetsov wrote:
>> Currently, KVM doesn't provide an API to make atomic updates to memmap when
>> the change touches more than one memory slot, e.g. in case we'd like to
>
Peter Xu writes:
> On Wed, Nov 04, 2020 at 07:09:02PM +0100, Laszlo Ersek wrote:
>> On 11/03/20 17:37, Peter Xu wrote:
>> > On Tue, Nov 03, 2020 at 02:07:09PM +0100, Vitaly Kuznetsov wrote:
>> >> In case it is a normal access from the guest, yes, but AFAIR here
&g
ctl as the existing
vCPU version can't be used that early. This is what KVM part does. With
that done, we can make early Hyper-V feature expansion (this series).
Vitaly Kuznetsov (19):
WIP: update linux/headers
i386: fill in FEAT_HYPERV_EDX from edx instead of eax
i386: drop x86_cp
KVM_CAP_SYS_HYPERV_CPUID definition is needed for this series.
Signed-off-by: Vitaly Kuznetsov
---
linux-headers/asm-x86/kvm.h | 20
linux-headers/linux/kvm.h | 27 ---
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/linux-headers
There was a typo which went unnoticed.
Fixes: e48ddcc6ce13 ("i386/kvm: implement 'hv-passthrough' mode")
Signed-off-by: Vitaly Kuznetsov
---
- Similar fix h
We only use x86_cpu_get_supported_feature_word() after its implementation,
no forward declaration needed.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 3ffd877dd51f..ca713bef5eaf 100644
7;s query-cpu-model-expansion output
is incorrect.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 20 ++--
target/i386/kvm.c | 4
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index d657590ab55d..8ec0af0a6d
As a preparation to expanding Hyper-V CPU features early, move
hyperv_interface_id initialization to x86_cpu_realizefn().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 6 ++
target/i386/cpu.h | 1 +
target/i386/kvm.c | 18 --
3 files changed, 19 insertions(+), 6
As a preparation to expanding Hyper-V CPU features early, move
hyperv_vendor_id initialization to x86_cpu_realizefn(). Introduce
x86_cpu_hyperv_realize() to not not pollute x86_cpu_realizefn()
itself.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 23 ++-
target
ote, 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
---
target/i386/kvm.c | 213 +++---
1 file changed, 106 insertions(+), 107 deletions(-)
diff --git a/target/i
guest but arguably this is a good change.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 94e2195acb36..a9823d4af7cb 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1221,9 +1221,6
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
---
target/i386/cpu.c | 90 +--
target/i386/cpu.h | 6 +-
target/i386/kvm.c | 181 ++---
As a preparation to expanding Hyper-V CPU features early, move
hyperv_version_id initialization to x86_cpu_realizefn().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 4
target/i386/cpu.h | 1 +
target/i386/kvm.c | 14 --
3 files changed, 17 insertions(+), 2
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
---
target/i386/kvm.c | 60 +--
1 file changed, 37 insertions(+), 23
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
---
target/i386/kvm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/target/i386/kv
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
---
target/i386/kvm.c | 3 ++-
1 file chang
As a preparation to expanding Hyper-V CPU features early, move
hyperv_limits initialization to x86_cpu_realizefn().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 5 +
target/i386/cpu.h | 1 +
target/i386/kvm.c | 13 -
3 files changed, 18 insertions(+), 1 deletion
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).
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c
Use standard error_setg() mechanism in hyperv_expand_features().
Signed-off-by: Vitaly Kuznetsov
---
target/i386/kvm.c | 101 --
1 file changed, 61 insertions(+), 40 deletions(-)
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 181e034da701
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
---
target/i386/kvm.c | 34 --
1 file changed, 24 insertions(+), 10 deletions
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
---
target/i386/kvm.c | 17 +
1 file changed
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
---
target/i386/kvm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
Eduardo Habkost writes:
> On Wed, Sep 30, 2020 at 03:40:20PM +0200, Vitaly Kuznetsov wrote:
>> 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_d
Eduardo Habkost writes:
> On Fri, Oct 09, 2020 at 02:18:42PM +0200, Vitaly Kuznetsov wrote:
>> Enabling Hyper-V emulation for a Windows VM is a tiring experience as it
>> requires listing all currently supported enlightenments ("hv_*" CPU
>> features) explicitl
As a preparation to expanding Hyper-V CPU features early, move
hyperv_vendor_id initialization to x86_cpu_realizefn(). Introduce
x86_cpu_hyperv_realize() to not not pollute x86_cpu_realizefn()
itself.
Signed-off-by: Vitaly Kuznetsov
---
target/i386/cpu.c | 23 ++-
target
401 - 500 of 529 matches
Mail list logo
