_eptp, range);
> }
>
> spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
> diff --git a/arch/x86/kvm/vmx/vmx.h b/arch/x86/kvm/vmx/vmx.h
> index a2d143276603..9a25e83f8b96 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
@ void set_cr4_guest_host_mask(struct vcpu_vmx *vmx);
> void ept_save_pdptrs(struct kvm_vcpu *vcpu);
> void vmx_get_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int
> seg);
> void vmx_set_segment(struct kvm_vcpu *vcpu, struct kvm_segment *var, int
> seg);
> -u64 construct_eptp(struct kvm_vcpu *vcpu, unsigned long root_hpa,
> -int root_level);
> +u64 construct_eptp(struct kvm_vcpu *vcpu, hpa_t root_hpa, int root_level);
>
> void update_exception_bitmap(struct kvm_vcpu *vcpu);
> void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Alex Shi writes:
> This macro is useless, and could cause gcc warning:
> arch/x86/kernel/kvmclock.c:47:0: warning: macro "HV_CLOCK_SIZE" is not
> used [-Wunused-macros]
> Let's remove it.
>
> Signed-off-by: Alex Shi
> Cc: Paolo Bonzini
> Cc: Sean Christo
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 i
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
nvert 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 +--
arc
x27;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: x86: hyper-v: allow KVM_GET_SUPPORTED_HV_CPUID as a sys
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 rel
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
>
> Signed-off
"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 userspace
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
"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
; +
> + 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
ept_identity_map_addr;
>
> +#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
spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
> }
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
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 hv_tl
lush
> request. */
> - if (VALID_PAGE(to_vmx(vcpu)->ept_pointer))
> - ret |=
> hv_remote_flush_eptp(to_vmx(vcpu)->ept_pointer,
> - range);
> + ret |= hv_rem
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
> ---
> arch/x86/kvm/v
> - spin_unlock(&to_kvm_vmx(kvm)->ept_pointer_lock);
> + spin_unlock(&kvm_vmx->ept_pointer_lock);
> return ret;
> }
> static int hv_remote_flush_tlb(struct kvm *kvm)
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
m)->ept_pointer_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 earl
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: Vit
) is called
only once per 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.
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
) is called
only once per 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.
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.o
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.
&g
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 gu
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 co
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 a/arch/x86/kvm/cpuid.
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' even
hed to this new mechanism
exclusively 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 real
!KASAN
> # 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 empty we
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/x8
rch.cpuid_nent/cpuid_entries 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/
we
can't do 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: V
ended to feed my curiosity.
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.
Rep
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->a
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
ystem-wide 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 sh
nvert 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 +--
arc
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
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 user
() is 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.
>
&
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.
>
> Settin
work 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
nvert 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 in
e 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 (7):
KVM: x86: hyper-v: Mention SynDBG CPUID leaves in api.rst
KVM: x86:
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
stem ioctl, 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/kv
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/
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(+)
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 instru
mmu->root_pgd = 0;
> }
>
> - kvm_mmu_commit_zap_page(vcpu->kvm, &invalid_list);
> - spin_unlock(&vcpu->kvm->mmu_lock);
> + kvm_mmu_commit_zap_page(kvm, &invalid_list);
> + spin_unlock(&kvm->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 Christophe
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
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
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 Mu
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/x8
which accounts 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
ces 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
Vitaly Kuznetsov (2):
KVM: x86: allocate vcpu->arch.cpuid_entries dynamically
KVM: x86: bump KVM_MAX_CPUID_ENTRIES
arch/x86/include/asm/kvm_h
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:
>> >>
>> >> > When
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: Suni
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, res
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 ++
> arch/x86/include/asm/mshyperv
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
> S
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
> --- a/drivers/clocksource/hyperv
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 m
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
ter
Reported-by: Joerg Roedel
Reported-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/ar
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
* Wait no more than 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(&vmbus_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: ("Unini
fb2 ("KVM: X86: Fix 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..44a86f7f2
IT_NMI))
> kvm_after_interrupt(&svm->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
xit_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_inte
ich in the light of 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)
&g
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
>>
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
>>
(cr, val);
The 'default:' 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(&svm->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 a/arch/x86
other contexts but one of the 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-o
201 - 300 of 1368 matches
Mail list logo