junjiehua0...@gmail.com writes:
> From: Junjie Hua
>
> The current implementation of Hyper-V SynIC[1] request to deactivate
> APICv when SynIC is enabled, since the AutoEOI feature of SynIC is not
> compatible with APICv[2].
>
> Actually, windows doesn't use AutoEOI if deprecating AutoEOI bit
Vitaly Kuznetsov writes:
> When running KVM selftest in a Hyper-V VM they stumble upon
>
> Unexpected result from KVM_GET_MSRS, r: 14 (failed MSR was 0x309)
>
> MSR_ARCH_PERFMON_FIXED_CTR[0..3] along with MSR_CORE_PERF_FIXED_CTR_CTRL,
> MSR_CORE_PERF_GLOBAL_STATUS, MSR_COR
KVM_GET_SUPPORTED_HV_CPUID is now supported as both vCPU and VM ioctl,
test that.
Signed-off-by: Vitaly Kuznetsov
---
.../testing/selftests/kvm/include/kvm_util.h | 2 +
tools/testing/selftests/kvm/lib/kvm_util.c| 26 ++
.../selftests/kvm/x86_64/hyperv_cpuid.c | 87
KVM_GET_SUPPORTED_HV_CPUID to 'dual' system/vCPU ioctl with the
same meaning.
Signed-off-by: Vitaly Kuznetsov
---
Documentation/virt/kvm/api.rst | 16
arch/x86/kvm/hyperv.c | 6 ++---
arch/x86/kvm/hyperv.h | 4 +--
arch/x86/kvm/vmx/evmcs.c | 3 +--
arch/x86/kvm/x86.c
get in the output
(as Hyper-V CPUIDs intersect with KVM's). In QEMU, CPU feature expansion
happens before any KVM vcpus are created so KVM_GET_SUPPORTED_HV_CPUID
can't be used in its current shape.
Vitaly Kuznetsov (2):
KVM: x86: hyper-v: allow KVM_GET_SUPPORTED_HV_CPUID as a system ioctl
KVM
Peter Xu writes:
> kvm_msr_ignored_check() could trigger a null pointer reference
'dereference' but I'd also clarify that 'vcpu' is NULL.
> if ignore_msrs=Y
> and report_ignore_msrs=Y when try to fetch an invalid feature msr using the
> global KVM_GET_MSRS. Degrade the error report to not
Peter Xu writes:
> Try to fetch any supported featured msr. Currently it won't fail, so at least
> we can check against valid ones (which should be >0).
>
> This reproduces [1] too by trying to fetch one invalid msr there.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=209845
>
>
"Kirill A. Shutemov" writes:
> On Wed, Oct 21, 2020 at 04:46:48PM +0200, Vitaly Kuznetsov wrote:
>> "Kirill A. Shutemov" writes:
>>
>> > Maybe it would be cleaner to handle reboot in userspace? If we got the VM
>> > rebooted, just r
Paolo Bonzini writes:
> On 22/10/20 03:34, Wanpeng Li wrote:
>> From: Wanpeng Li
>>
>> Per KVM_GET_SUPPORTED_CPUID ioctl documentation:
>>
>> This ioctl returns x86 cpuid features which are supported by both the
>> hardware and kvm in its default configuration.
>>
>> A well-behaved
Sean Christopherson writes:
> On Wed, Oct 21, 2020 at 02:39:20PM +0200, Vitaly Kuznetsov wrote:
>> Sean Christopherson writes:
>>
>> > Drop the dedicated 'ept_pointers_match' field in favor of stuffing
>> > 'hv_tlb_eptp' with INVALID_PAGE to m
"Kirill A. Shutemov" writes:
> On Tue, Oct 20, 2020 at 09:46:11AM +0200, Vitaly Kuznetsov wrote:
>> "Kirill A. Shutemov" writes:
>>
>> > == Background / Problem ==
>> >
>> > There are a number of hardware features (MKTME, SEV) whic
gt; + if (ret && mismatch)
> + break;
> }
> if (mismatch)
> kvm_vmx->hv_tlb_eptp = INVALID_PAGE;
In case my suggestion on PATCH5 gets dismissed,
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
;
>
> +#if IS_ENABLED(CONFIG_HYPERV)
> hpa_t hv_tlb_eptp;
> spinlock_t ept_pointer_lock;
> +#endif
> };
>
> bool nested_vmx_allowed(struct kvm_vcpu *vcpu);
Assuming this compiles without CONFIG_HYPERV,
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
> to_vmx(vcpu)->ept_pointer = eptp;
> - to_kvm_vmx(kvm)->hv_tlb_eptp = INVALID_PAGE;
> + if (eptp != to_kvm_vmx(kvm)->hv_tlb_eptp)
> + to_kvm_vmx(kvm)->hv_tlb_eptp = INVALID_PAGE;
>
Sean Christopherson writes:
> Drop the dedicated 'ept_pointers_match' field in favor of stuffing
> 'hv_tlb_eptp' with INVALID_PAGE to mark it as invalid, i.e. to denote
> that there is at least one EPTP mismatch. Use a local variable to
> track whether or not a mismatch is detected so that
> request. */
> - if (VALID_PAGE(to_vmx(vcpu)->ept_pointer))
> - ret |=
> hv_remote_flush_eptp(to_vmx(vcpu)->ept_pointer,
> - range);
> + ret |= hv_remote_
Sean Christopherson writes:
> Fold check_ept_pointer_match() into hv_remote_flush_tlb_with_range() in
> preparation for combining the kvm_for_each_vcpu loops of the ==CHECK and
> !=MATCH statements.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson
> ---
>
spin_unlock(_kvm_vmx(kvm)->ept_pointer_lock);
> + spin_unlock(_vmx->ept_pointer_lock);
> return ret;
> }
> static int hv_remote_flush_tlb(struct kvm *kvm)
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
lock);
> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> index 5961cb897125..3d557a065c01 100644
> --- a/arch/x86/kvm/vmx/vmx.h
> +++ b/arch/x86/kvm/vmx/vmx.h
> @@ -301,6 +301,7 @@ struct kvm_vmx {
> bool ept_identity_pagetable_done;
> gpa_t ept_identity_map_addr;
>
> + hpa_t hv_tlb_eptp;
> enum ept_pointers_status ept_pointers_match;
> spinlock_t ept_pointer_lock;
> };
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Sean Christopherson writes:
> Clean up KVM's PV TLB flushing when running with EPT on Hyper-V, i.e. as
> a nested VMM.
The terminology we use is a bit confusing and I'd like to use the
opportunity to enlighten myself on how to call "PV TLB flushing"
properly :-)
Hyper-V supports two types of
"Kirill A. Shutemov" writes:
> == Background / Problem ==
>
> There are a number of hardware features (MKTME, SEV) which protect guest
> memory from some unauthorized host access. The patchset proposes a purely
> software feature that mitigates some of the same host-side read-only
> attacks.
>
>
Haiwei Li writes:
> And 'pv_ops.mmu.tlb_remove_table = tlb_remove_table' should not
> be set either.
AFAIU by looking at the commit which added it (48a8b97cfd80 "x86/mm:
Only use tlb_remove_table() for paravirt") it sholdn't hurt much. We
could've avoided the assignment but it happens much
lihaiwei.ker...@gmail.com writes:
> From: Haiwei Li
>
> check the allocation of per-cpu __pv_cpu_mask. Init
> 'send_IPI_mask_allbutself' only when successful and check the allocation
> of __pv_cpu_mask in 'kvm_flush_tlb_others'.
>
> Suggested-by: Vitaly Kuznetsov
>
CPU so we don't really need it to. Switch to checking
'enlightened_vmcs' instead, it is supposed to be in sync with
'enable_evmcs'.
Opportunistically make evmcs_sanitize_exec_ctrls '__init' and drop unneeded
extra newline from it.
Reported-by: Yang Weijiang
Signed-off-by: Vitaly Kuznetsov
PU PMU setup
depends on guest CPUIDs which can always be altered.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/x86.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ce856e0ece84..85d72b125fba 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x
CPU so we don't really need it to. Switch to checking
'enlightened_vmcs' instead, it is supposed to be in sync with
'enable_evmcs'.
Opportunistically make evmcs_sanitize_exec_ctrls '__init' and drop unneeded
extra newline from it.
Reported-by: Yang Weijiang
Signed-off-by: Vitaly Kuznetsov
Vitaly Kuznetsov writes:
> Changes since v2:
> - Keep vCPU version of the ioctl intact but make it 'deprecated' in
> api.rst [Paolo Bonzini]
> - First two patches of v2 series already made it to kvm/queue
>
> QEMU series using the feature:
> https://lists.gnu.org/archive
Sean Christopherson writes:
> On Tue, Oct 06, 2020 at 05:24:54PM +0200, Vitaly Kuznetsov wrote:
>> Vivek Goyal writes:
>> > So you will have to report token (along with -EFAULT) to user space. So
>> > this
>> > is basically the 3rd proposal which is exten
Vivek Goyal writes:
> On Tue, Oct 06, 2020 at 04:50:44PM +0200, Vitaly Kuznetsov wrote:
>> Vivek Goyal writes:
>>
>> > On Tue, Oct 06, 2020 at 04:05:16PM +0200, Vitaly Kuznetsov wrote:
>> >> Vivek Goyal writes:
>> >>
>> >>
Vivek Goyal writes:
> On Tue, Oct 06, 2020 at 04:05:16PM +0200, Vitaly Kuznetsov wrote:
>> Vivek Goyal writes:
>>
>> > A. Just exit to user space with -EFAULT (using kvm request) and don't
>> >wait for the accessing task to run on vcpu again.
>>
Vivek Goyal writes:
> A. Just exit to user space with -EFAULT (using kvm request) and don't
>wait for the accessing task to run on vcpu again.
What if we also save the required information (RIP, GFN, ...) in the
guest along with the APF token so in case of -EFAULT we can just 'crash'
the
Sean Christopherson writes:
> On Mon, Oct 05, 2020 at 05:29:47PM +0200, Vitaly Kuznetsov wrote:
>> Tianjia Zhang writes:
>>
>> > Original KVM_SET_CPUID has removed NX on non-NX hosts as it did
>> > before. but KVM_SET_CPUID2 does not. The two should be
Tianjia Zhang writes:
> Original KVM_SET_CPUID has removed NX on non-NX hosts as it did
> before. but KVM_SET_CPUID2 does not. The two should be consistent.
>
> Signed-off-by: Tianjia Zhang
> ---
> arch/x86/kvm/cpuid.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
Maxim Levitsky writes:
> On Thu, 2020-10-01 at 15:05 +0200, Vitaly Kuznetsov wrote:
>> As a preparatory step to allocating vcpu->arch.cpuid_entries dynamically
>> make kvm_check_cpuid() check work with an arbitrary 'struct kvm_cpuid_entry2'
>> array.
>>
>
Vitaly Kuznetsov writes:
> KVM was switched to interrupt-based mechanism for 'page ready' event
> delivery in Linux-5.8 (see commit 2635b5c4a0e4 ("KVM: x86: interrupt based
> APF 'page ready' event delivery")) and #PF (ab)use for 'page ready' event
> delivery was removed
xclusively in 5.9 (see commit b1d405751cd5 ("KVM: x86: Switch KVM guest to
using interrupts for page ready APF delivery")) so it is not possible to
get older KVM (APF mechanism won't be enabled). Update the comment in
exc_page_fault() to reflect the new reality.
Signed-off-by: Vitaly Kuznets
; # We use the dependency on !COMPILE_TEST to not be enabled
> # blindly in allmodconfig or allyesconfig configurations
> + depends on KVM
> depends on (X86_64 && !KASAN) || !COMPILE_TEST
> depends on EXPERT
> help
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Wei Liu writes:
> On Thu, Oct 01, 2020 at 11:40:04AM +0200, Vitaly Kuznetsov wrote:
>> Sasha Levin writes:
>>
>> > cpumask can change underneath us, which is generally safe except when we
>> > call into hv_cpu_number_to_vp_number(): if cpumask ends up em
ary value '256' as the new
limit.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 7d259e21ea04..f6d6df64e63a 100644
--- a/arch/x86/include/
ntries so
no changes are made in case the check fails.
Opportunistically remove unneeded 'out' labels from
kvm_vcpu_ioctl_set_cpuid()/kvm_vcpu_ioctl_set_cpuid2() and return
directly whenever possible.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kv
the same in kvm_vcpu_ioctl_set_cpuid() as we'll have to copy
'struct kvm_cpuid_entry' entries first. The change will be made when
vcpu->arch.cpuid_entries[] array becomes allocated dynamically.
Suggested-by: Sean Christopherson
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/
y.
Very mildly tested with selftests/kvm-unit-tests and nothing seems to
break. I also don't have access to the system where the original issue
was reported but chances we're fixing it are very good IMO as just the
second patch alone was reported to be sufficient.
Reported-by: Dr. David Alan Gilbert
Vital
Sean Christopherson writes:
> On Tue, Sep 15, 2020 at 05:43:05PM +0200, Vitaly Kuznetsov wrote:
>> The current limit for guest CPUID leaves (KVM_MAX_CPUID_ENTRIES, 80)
>> is reported to be insufficient but before we bump it let's switch to
>> allocating vcpu->arch.c
uot;x86/hyper-v: Use cheaper
> HVCALL_FLUSH_VIRTUAL_ADDRESS_{LIST,SPACE} hypercalls when possible")
> Cc: Vitaly Kuznetsov
> Cc: sta...@kernel.org
> Signed-off-by: Sasha Levin
> ---
> arch/x86/hyperv/mmu.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
KVM_GET_SUPPORTED_HV_CPUID is now supported as both vCPU and VM ioctl,
test that.
Signed-off-by: Vitaly Kuznetsov
---
.../testing/selftests/kvm/include/kvm_util.h | 2 +
tools/testing/selftests/kvm/lib/kvm_util.c| 26 ++
.../selftests/kvm/x86_64/hyperv_cpuid.c | 87
KVM_GET_SUPPORTED_CPUID/
KVM_GET_MSRS ioctls but Hyper-V specific features don't get in the output
(as Hyper-V CPUIDs intersect with KVM's). In QEMU, CPU feature expansion
happens before any KVM vcpus are created so KVM_GET_SUPPORTED_HV_CPUID
can't be used in its current shape.
Vitaly Kuznetsov (2
KVM_GET_SUPPORTED_HV_CPUID to 'dual' system/vCPU ioctl with the
same meaning.
Signed-off-by: Vitaly Kuznetsov
---
Documentation/virt/kvm/api.rst | 16
arch/x86/kvm/hyperv.c | 6 ++---
arch/x86/kvm/hyperv.h | 4 +--
arch/x86/kvm/vmx/evmcs.c | 3 +--
arch/x86/kvm/x86.c
lihaiwei.ker...@gmail.com writes:
> From: Haiwei Li
>
> check the allocation of per-cpu __pv_cpu_mask.
>
> Suggested-by: Vitaly Kuznetsov
> Signed-off-by: Haiwei Li
> ---
> v1 -> v2:
> * add CONFIG_SMP for kvm_send_ipi_mask_allbutself to prevent build error
Paolo Bonzini writes:
> On 29/09/20 12:36, Vitaly Kuznetsov wrote:
>>> Sorry for the late reply. I think this is making things worse. It's
>>> obviously okay to add a system KVM_GET_SUPPORTED_HV_CPUID, and I guess
>>> it makes sense to have bits in there that requ
Paolo Bonzini writes:
> On 24/09/20 16:57, Vitaly Kuznetsov wrote:
>> HV_STIMER_DIRECT_MODE_AVAILABLE is the last conditionally set feature bit
>> in KVM_GET_SUPPORTED_HV_CPUID but it doesn't have to be conditional: first,
>> this bit is only an indication to userspace
defined iff CONFIG_HYPERV!=n.
>
> Short term, the explicit check makes it more obvious why a non-NULL
> tlb_remote_flush() triggers EPTP shenanigans. Long term, this will
> allow TDX to define its own implementation of tlb_remote_flush() without
> running afoul of Hyper-V.
>
> C
Sean Christopherson writes:
> On Thu, Sep 24, 2020 at 02:34:14PM +0200, Vitaly Kuznetsov wrote:
>> Sean Christopherson writes:
>> > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>> > index 6f9a0c6d5dc5..810d46ab0a47 100644
>> > --- a/arch/x86/k
x10/0x10
> [69703.123035] ? sched_clock+0x5/0x10
> [69703.123044] ? ftrace_graph_caller+0x6b/0xa0
> [69703.123059] ? read_hv_clock_tsc_cs+0x10/0x10
> [69703.123068] ? sched_clock+0x5/0x10
Obviously we're seeing a recursion, we can trim this log a bit.
>
> Setting the
so no VMM should just blindly copy it to guest CPUIDs. Second,
lapic_in_kernel() is a must for SynIC. Expose the bit unconditionally.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/hyperv.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/x86/kvm/hyperv.c b/arch
KVM_GET_SUPPORTED_HV_CPUID to 'dual' system/vCPU ioctl with the
same meaning.
Signed-off-by: Vitaly Kuznetsov
---
Documentation/virt/kvm/api.rst | 4 ++--
arch/x86/kvm/x86.c | 43 --
include/uapi/linux/kvm.h | 3 ++-
3 files changed, 30 insertions(+), 20
put
(as Hyper-V CPUIDs intersect with KVM's). In QEMU, CPU feature expansion
happens before any KVM vcpus are created so KVM_GET_SUPPORTED_HV_CPUID
can't be used in its current shape.
Vitaly Kuznetsov (7):
KVM: x86: hyper-v: Mention SynDBG CPUID leaves in api.rst
KVM: x86: hyper-v: disal
We forgot to update KVM_GET_SUPPORTED_HV_CPUID's documentation in api.rst
when SynDBG leaves were added.
While on it, fix 'KVM_GET_SUPPORTED_CPUID' copy-paste error.
Fixes: f97f5a56f597 ("x86/kvm/hyper-v: Add support for synthetic debugger
interface")
Signed-off-by: Vitaly
, make
EVMCS feature bits work the same way as all other bits, nothing should break
(famous last words).
Signed-off-by: Vitaly Kuznetsov
---
Documentation/virt/kvm/api.rst| 3 --
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/hyperv.c
KVM_GET_SUPPORTED_HV_CPUID is now supported as both vCPU and VM ioctl,
test that.
Signed-off-by: Vitaly Kuznetsov
---
.../testing/selftests/kvm/include/kvm_util.h | 2 +
tools/testing/selftests/kvm/lib/kvm_util.c| 26 +++
.../selftests/kvm/x86_64/hyperv_cpuid.c | 46
kvm_vcpu_ioctl_get_hv_cpuid() doesn't use its vcpu parameter anymore,
drop it. Also, the function is now untied from vcpu, rename it accordingly.
No functional change intended.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/hyperv.c | 3 +--
arch/x86/kvm/hyperv.h | 3 +--
arch/x86/kvm/x86.c
Hyper-V Synthetic timers require SynIC but we don't seem to check that
upon HV_X64_MSR_STIMER[X]_CONFIG/HV_X64_MSR_STIMER0_COUNT writes. Make
the behavior match synic_set_msr().
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/hyperv.c | 11 +++
1 file changed, 11 insertions(+)
diff
Tom Lendacky writes:
> From: Tom Lendacky
>
> The INVD instruction intercept performs emulation. Emulation can't be done
> on an SEV guest because the guest memory is encrypted.
>
> Provide a dedicated intercept routine for the INVD intercept. Within this
> intercept routine just skip the
;
> - spin_unlock(>kvm->mmu_lock);
> + kvm_mmu_commit_zap_page(kvm, _list);
> + spin_unlock(>mmu_lock);
> }
> EXPORT_SYMBOL_GPL(kvm_mmu_free_roots);
What about kvm_mmu_get_page(), make_mmu_pages_available(),
mmu_alloc_root(), kvm_mmu_sync_roots(), direct_page_fault(),
kvm_mmu_pte_write() which seem to be using the same ugly pattern? :-)
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Sean Christopherson writes:
> Add support for KVM_REQ_VM_BUGG in x86, and replace a variety of WARNs
> with KVM_BUG() and KVM_BUG_ON(). Return -EIO if a KVM_BUG is hit to
> align with the common KVM behavior of rejecting iocts() with -EIO if the
> VM is bugged.
>
> Signed-off-by: Sean
Sunil Muthuswamy writes:
>>
>> On Tue, Sep 15, 2020 at 12:32:29PM +0200, Vitaly Kuznetsov wrote:
>> > Wei Liu writes:
>> >
>> > > When Linux is running as the root partition, the hypercall page will
>> > > have already been setup by Hyper
Haiwei Li writes:
> On 20/9/16 17:03, Vitaly Kuznetsov wrote:
>> The commit 0f990222108d ("KVM: Check the allocation of pv cpu mask") we
>> have in 5.9-rc5 has two issue:
>> 1) Compilation fails for !CONFIG_SMP, see:
>> https://bugzilla.kernel.org/show_bu
Wei Liu writes:
> On Tue, Sep 15, 2020 at 12:43:18PM +, Wei Liu wrote:
>> On Tue, Sep 15, 2020 at 12:16:58PM +0200, Vitaly Kuznetsov wrote:
>> > Wei Liu writes:
>> >
>> > > When Linux runs as the root partition, it will need to make hypercalls
>&
87y2lrnnyf@vitty.brq.redhat.com/
The allocation problem is likely a theoretical one, if we don't
have memory that early in boot process we're likely doomed anyway.
Let's solve it properly later.
This reverts commit 0f990222108d214a0924d920e6095b58107d7b59.
Signed-off-by: Vitaly Kuznetsov
---
Wei Huang writes:
> On 09/15 05:51, Dr. David Alan Gilbert wrote:
>> * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote:
>> > With QEMU and newer AMD CPUs (namely: Epyc 'Rome') the current limit for
>
> Could you elaborate on this limit? On Rome, I counted ~35 CPUID func
Wei Liu writes:
> Microsoft Hypervisor requires the root partition to make a few
> hypercalls to setup application processors before they can be used.
>
> Signed-off-by: Lillian Grassin-Drake
> Signed-off-by: Sunil Muthuswamy
> Co-Developed-by: Lillian Grassin-Drake
> Co-Developed-by: Sunil
Wei Liu writes:
> We will need to identify the device we want Microsoft Hypervisor to
> manipulate. Introduce the data structures for that purpose.
>
> They will be used in a later patch.
>
> Signed-off-by: Sunil Muthuswamy
> Co-Developed-by: Sunil Muthuswamy
> Signed-off-by: Wei Liu
> ---
>
ary value '256' as the new
limit.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/kvm_host.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 0c5f2ca3e838..c1d942c9eb58 100644
--- a/arch/x86/include/
for 1/4 of the whole 'struct kvm_vcpu_arch'
but having it pre-allocated (for all vCPUs which we also pre-allocate)
gives us no benefits.
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/cpuid.c| 55 -
arch/x86/k
ery good IMO as just the
second patch alone was reported to be sufficient.
Reported-by: Dr. David Alan Gilbert
Vitaly Kuznetsov (2):
KVM: x86: allocate vcpu->arch.cpuid_entries dynamically
KVM: x86: bump KVM_MAX_CPUID_ENTRIES
arch/x86/include/asm/kvm_host.h | 4 +--
arch/x86/kvm/c
Wei Liu writes:
> On Tue, Sep 15, 2020 at 01:02:08PM +0200, Vitaly Kuznetsov wrote:
>> Wei Liu writes:
>>
>> > On Tue, Sep 15, 2020 at 12:32:29PM +0200, Vitaly Kuznetsov wrote:
>> >> Wei Liu writes:
>> >>
>> >> >
Wei Liu writes:
> On Tue, Sep 15, 2020 at 12:32:29PM +0200, Vitaly Kuznetsov wrote:
>> Wei Liu writes:
>>
>> > When Linux is running as the root partition, the hypercall page will
>> > have already been setup by Hyper-V. Copy the content over to the
>>
Wei Liu writes:
> They are used to deposit pages into Microsoft Hypervisor and bring up
> logical and virtual processors.
>
> Signed-off-by: Lillian Grassin-Drake
> Signed-off-by: Sunil Muthuswamy
> Signed-off-by: Nuno Das Neves
> Co-Developed-by: Lillian Grassin-Drake
> Co-Developed-by:
Wei Liu writes:
> When Linux is running as the root partition, the hypercall page will
> have already been setup by Hyper-V. Copy the content over to the
> allocated page.
And we can't setup a new hypercall page by writing something different
to HV_X64_MSR_HYPERCALL, right?
>
> The suspend,
Wei Liu writes:
> We will need the partition ID for executing some hypercalls later.
>
> Signed-off-by: Lillian Grassin-Drake
> Co-Developed-by: Sunil Muthuswamy
> Signed-off-by: Wei Liu
> ---
> arch/x86/hyperv/hv_init.c | 26 ++
>
Wei Liu writes:
> When Linux runs as the root partition, it will need to make hypercalls
> which return data from the hypervisor.
>
> Allocate pages for storing results when Linux runs as the root
> partition.
>
> Signed-off-by: Lillian Grassin-Drake
> Co-Developed-by: Lillian Grassin-Drake
>
Wei Liu writes:
> Signed-off-by: Wei Liu
> ---
> drivers/clocksource/hyperv_timer.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/clocksource/hyperv_timer.c
> b/drivers/clocksource/hyperv_timer.c
> index 09aa44cb8a91..fe96082ce85e 100644
> ---
Joerg Roedel writes:
> From: Joerg Roedel
>
> The save and ctl pointers need to be initialized to NULL because there
> is a way through the function in which there is no memory allocated
> for the pointers but where they are freed in the end.
>
> This involves the 'goto out_set_gif' before the
The following commit has been merged into the x86/seves branch of tip:
Commit-ID: e6eb15c9ba3165698488ae5c34920eea20eaa38e
Gitweb:
https://git.kernel.org/tip/e6eb15c9ba3165698488ae5c34920eea20eaa38e
Author:Vitaly Kuznetsov
AuthorDate:Mon, 14 Sep 2020 15:37:25 +02:00
orted-by: Colin King
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/svm/nested.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
index 598a769f1961..67e6d053985d 100644
--- a/arch/x86/kvm/svm/nested.c
+++ b/arch/
Joerg Roedel writes:
> Hi Vitaly,
>
> On Mon, Sep 14, 2020 at 02:04:27PM +0200, Vitaly Kuznetsov wrote:
>> this was previously reported by Colin:
>> https://lore.kernel.org/kvm/2020090730.24238-1-colin.k...@canonical.com/
>>
>> the fix itself looks go
10 seconds so that the panic path can't get
> + * hung forever in case the response message isn't seen.
>*/
> - while (1) {
> + for (i = 0; i < 1000; i++) {
> if (completion_done(_connection.unload_event))
> break;
LGTM,
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Colin King writes:
> From: Colin Ian King
>
> Currently the error exit path to outt_set_gif will kfree on
> uninitialized
typo: out_set_gif
> pointers save and ctl. Fix this by ensuring these pointers are
> inintialized to NULL to avoid garbage pointer freeing.
>
> Addresses-Coverity:
async pf caused null-ptr-deref")
Reported-by: Dr. David Alan Gilbert
Signed-off-by: Vitaly Kuznetsov
---
arch/x86/kvm/x86.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index d39d6cf1d473..44a86f7f2397 100644
--- a/arch/x86
kvm_after_interrupt(>vcpu);
> @@ -3529,6 +3533,7 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct
> kvm_vcpu *vcpu)
> svm_handle_mce(svm);
>
> svm_complete_interrupts(svm);
> + exit_fastpath = svm_exit_handlers_fastpath(vcpu);
>
> vmcb_mark_all_clean(svm->vmcb);
> return exit_fastpath;
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
turn exit_fastpath;
> }
This seems to be the right thing to do, however, the amount of code
between kvm_x86_ops.run() and kvm_x86_ops.handle_exit() is non-trivial,
hope it won't blow up in testing...
Reviewed-by: Vitaly Kuznetsov
One more thing:
VMX version does
vmx_complete_interrupt
the whole seeries seems to be appropriate, so:
Reviewed-by: Vitaly Kuznetsov
>
> Reported-by: Paul K.
> Suggested-by: Sean Christopherson
> Cc: Paul K.
> Cc: # v5.8-rc1+
> Fixes: 404d5d7bff0d (KVM: X86: Introduce more exit_fastpath_completion enum
> values)
> Signed-off-by: Wa
Sean Christopherson writes:
> On Fri, Sep 04, 2020 at 09:29:05AM +0200, Gerd Hoffmann wrote:
>> Hi,
>>
>> > Unless I'm mistaken, microvm doesn't even support PCI, does it?
>>
>> Correct, no pci support right now.
>>
>> We could probably wire up ecam (arm/virt style) for pcie support, once
d iterate over all other devices linked to it and call
>> > kvm_iodevice_destructor() for them
>> >
>> > Reported-and-tested-by:
>> > syzbot+f196caa45793d6374...@syzkaller.appspotmail.com
>> > Link: https://syzkaller.appspot.com/bug?extid=f196caa45793d6374707
>>
efault:' case above does 'return 1;' so we won't get the trace but
I understand you put trace_kvm_cr_read() here so you can log the
returned 'val', #UD should be clearly visible.
> }
> return kvm_complete_insn_gp(>vcpu, err);
> }
> --
> 2.18.4
>
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Haiwei Li writes:
> On 20/9/3 18:39, Vitaly Kuznetsov wrote:
>> Haiwei Li writes:
>>
>>> From: Haiwei Li
>>>
>>> check the allocation of per-cpu __pv_cpu_mask. Initialize ops only when
>>> successful.
>>>
>>>
Haiwei Li writes:
> From: Haiwei Li
>
> check the allocation of per-cpu __pv_cpu_mask. Initialize ops only when
> successful.
>
> Signed-off-by: Haiwei Li
> ---
> arch/x86/kernel/kvm.c | 24
> 1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git
hunks changed
> nearby KVM_REQ_MMU_SYNC instead.
>
> The this patch changes it back.
>
> Link:
> https://lore.kernel.org/lkml/20200320212833.3507-26-sean.j.christopher...@intel.com/
> Cc: Sean Christopherson
> Cc: Vitaly Kuznetsov
> Signed-off-by: Lai Jiangshan
> ---
Peter Xu writes:
> On Tue, Sep 01, 2020 at 04:43:25PM +0200, Vitaly Kuznetsov wrote:
>> Peter Xu writes:
>>
>> > On Fri, Aug 07, 2020 at 04:12:29PM +0200, Vitaly Kuznetsov wrote:
>> >> When testing Linux kernel boot with QEMU q35 VM and direct kernel boot
&
_count; j++) {
if (j == i)
continue;
kvm_iodevice_destructor(bus->range[j].dev);
}
rcu_assign_pointer(kvm->buses[bus_idx], new_bus);
synchronize_srcu_expedited(>srcu);
kfree(bus);
return;
> }
None of the above should block the fix IMO, so:
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Vitaly Kuznetsov writes:
> KVM_GET_SUPPORTED_HV_CPUID was initially implemented as a vCPU ioctl but
> this is not very useful when VMM is just trying to query which Hyper-V
> features are supported by the host prior to creating VM/vCPUs. The data
> in KVM_GET_SUPPORTED_HV_CPUID is m
201 - 300 of 4372 matches
Mail list logo
