On Wed, Apr 10, 2024 at 11:30 PM Andrew Morton
wrote:
> On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> > Please review! Also feel free to take the KVM patches through the mm
> > tree, as I don't expect any conflicts.
>
> It's mainly a KVM thing and the MM changes
On Mon, Apr 8, 2024 at 3:56 PM Peter Xu wrote:
> Paolo,
>
> I may miss a bunch of details here (as I still remember some change_pte
> patches previously on the list..), however not sure whether we considered
> enable it? Asked because I remember Andrea used to have a custom tree
> maintaining
With the demise of the .change_pte() MMU notifier callback, there is no
notification happening in set_pte_at_notify(). It is a synonym of
set_pte_at() and can be replaced with it.
Signed-off-by: Paolo Bonzini
---
include/linux/mmu_notifier.h | 2 --
kernel/events/uprobes.c | 5 ++---
mm
ks,
Paolo
Paolo Bonzini (4):
KVM: delete .change_pte MMU notifier callback
KVM: remove unused argument of kvm_handle_hva_range()
mmu_notifier: remove the .change_pte() callback
mm: replace set_pte_at_notify() with just set_pte_at()
arch/arm64/kvm/mmu.c | 34 -
set_pte_at_notify() even though it is just a synonym for set_pte_at().
Signed-off-by: Paolo Bonzini
---
include/linux/mmu_notifier.h | 46 ++--
mm/mmu_notifier.c| 17 -
2 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/include/linux
t, because KVM unmaps the sPTEs during .invalidate_range_start()
and therefore .change_pte() has no hope of finding a sPTE to change.
Drop the generic KVM code that dispatches to kvm_set_spte_gfn(), as
well as all the architecture specific implementations.
Signed-off-by: Paolo Bonzini
---
arch
The only user was kvm_mmu_notifier_change_pte(), which is now gone.
Signed-off-by: Paolo Bonzini
---
virt/kvm/kvm_main.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 2fcd9979752a..970111ad 100644
--- a/virt/kvm
On Wed, Oct 11, 2023 at 1:46 AM Sean Christopherson wrote:
> > > The DRM_I915_WERROR config depends on EXPERT and !COMPILE_TEST, and to
> > > my knowledge this has never caused issues outside of i915 developers and
> > > CI.
> >
> > Ack, I think you do it right. I was trying to establish a
On 20/04/21 22:16, Sean Christopherson wrote:
On Tue, Apr 20, 2021, Sean Christopherson wrote:
On Tue, Apr 20, 2021, Paolo Bonzini wrote:
In this particular case, if userspace sets the bit in CPUID2 but doesn't
handle KVM_EXIT_HYPERCALL, the guest will probably trigger some kind of
assertion
On 20/04/21 20:51, Borislav Petkov wrote:
Hey Paolo,
On Tue, Apr 20, 2021 at 01:11:31PM +0200, Paolo Bonzini wrote:
I have queued patches 1-6.
For patches 8 and 10 I will post my own version based on my review and
feedback.
can you pls push that tree up to here to a branch somewhere so
On 20/04/21 19:31, Sean Christopherson wrote:
+ case KVM_HC_PAGE_ENC_STATUS: {
+ u64 gpa = a0, npages = a1, enc = a2;
+
+ ret = -KVM_ENOSYS;
+ if (!vcpu->kvm->arch.hypercall_exit_enabled)
I don't follow, why does the hypercall need to be gated by
On 20/04/21 17:15, Sean Christopherson wrote:
On Tue, Apr 20, 2021, Paolo Bonzini wrote:
Do not return the SEV-ES bit from KVM_GET_SUPPORTED_CPUID unless
the corresponding module parameter is 1, and clear the memory encryption
leaf completely if SEV is disabled.
Impeccable timing, I
On 20/04/21 17:32, Peter Xu wrote:
On Tue, Apr 20, 2021 at 10:37:39AM -0400, Peter Xu wrote:
On Tue, Apr 20, 2021 at 04:16:14AM -0400, Paolo Bonzini wrote:
The main thread could start to send SIG_IPI at any time, even before signal
blocked on vcpu thread. Therefore, start the vcpu thread
On 20/04/21 15:10, Peter Xu wrote:
On Tue, Apr 20, 2021 at 10:07:16AM +0200, Paolo Bonzini wrote:
On 18/04/21 14:43, Peter Xu wrote:
8<-
diff --git a/tools/testing/selftests/kvm/dirty_log_test.c
b/tools/testing/selftests/kvm/dirty_log_test.c
index 25230e799bc4..d3050d1c2cd0 100
| 48 +++
include/uapi/linux/kvm.h | 1 +
include/uapi/linux/kvm_para.h | 1 +
12 files changed, 110 insertions(+), 1 deletion(-)
--
2.26.2
>From 547d4d4edcd05fdfac6ce650d65db1d42bcd2807 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
D
On 15/04/21 17:52, Ashish Kalra wrote:
From: Ashish Kalra
The series add support for AMD SEV guest live migration commands. To protect the
confidentiality of an SEV protected guest memory while in transit we need to
use the SEV commands defined in SEV API spec [1].
SEV guest VMs have the
ble the capability and set the
CPUID bit if it wants.
The reason is that userspace could pass KVM_GET_SUPPORTED_CPUID to
KVM_SET_CPUID2 and the hypercall then would break the guest.
Paolo
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: Joerg Roedel
Cc: Borisl
.
Signed-off-by: Paolo Bonzini
---
Documentation/virt/kvm/cpuid.rst | 3 ++-
Documentation/virt/kvm/msr.rst | 10 ++
arch/x86/include/uapi/asm/kvm_para.h | 3 +++
arch/x86/kvm/x86.c | 14 ++
4 files changed, 29 insertions(+), 1 deletion(-)
diff
On 15/04/21 18:01, Ashish Kalra wrote:
From: Ashish Kalra
The guest support for detecting and enabling SEV Live migration
feature uses the following logic :
- kvm_init_plaform() invokes check_kvm_sev_migration() which
checks if its booted under the EFI
- If not EFI,
i) check
On 20/04/21 01:06, Sean Christopherson wrote:
diff --git a/arch/x86/include/uapi/asm/kvm_para.h
b/arch/x86/include/uapi/asm/kvm_para.h
index 950afebfba88..f6bfa138874f 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -33,6 +33,7 @@
#define
On 20/04/21 10:48, Wanpeng Li wrote:
I was thinking of something simpler:
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 9b8e30dd5b9b..455c648f9adc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3198,10 +3198,9 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *me, bool
On 15/04/21 17:58, Ashish Kalra wrote:
From: Ashish Kalra
Add new KVM_FEATURE_SEV_LIVE_MIGRATION feature for guest to check
for host-side support for SEV live migration. Also add a new custom
MSR_KVM_SEV_LIVE_MIGRATION for guest to enable the SEV live migration
feature.
MSR is handled by
mas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel.org
Cc: k...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Steve Rutherford
Reviewed-by: Venu Busireddy
Signed-off-by: Brijesh Sing
Signed-off-by: Paolo Bonzini
---
Documentation/virt/kvm/amd-memory-encryption.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst
b/Documentation/virt/kvm/amd-memory-encryption.rst
index 469a6308765b..34ce2d1fcb89 100644
On 20/04/21 10:38, Paolo Bonzini wrote:
On 15/04/21 17:54, Ashish Kalra wrote:
+ }
+
+ sev->handle = start->handle;
+ sev->fd = argp->sev_fd;
These two lines are spurious, I'll delete them.
And this is wrong as well. My apologies.
Paolo
On 15/04/21 17:53, Ashish Kalra wrote:
From: Brijesh Singh
The command is used to create an outgoing SEV guest encryption context.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Paolo Bonzini
Cc: Joerg Roedel
Cc: Borislav Petkov
Cc: Tom Lendacky
Cc: x...@kernel
On 20/04/21 10:40, Paolo Bonzini wrote:
On 15/04/21 17:55, Ashish Kalra wrote:
+ if (!guest_page)
+ goto e_free;
+
Missing unpin on error (but it won't be needed with Sean's patches that
move the data block to the stack, so I can fix this too).
No, sorry---the initialization
On 15/04/21 17:55, Ashish Kalra wrote:
+ if (!guest_page)
+ goto e_free;
+
Missing unpin on error (but it won't be needed with Sean's patches that
move the data block to the stack, so I can fix this too).
Paolo
On 15/04/21 17:54, Ashish Kalra wrote:
+ }
+
+ sev->handle = start->handle;
+ sev->fd = argp->sev_fd;
These two lines are spurious, I'll delete them.
Paolo
slower than main).
Reported-by: Peter Xu
Cc: sta...@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
tools/testing/selftests/kvm/dirty_log_test.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/dirty_log_test.c
b/tools/testing/selftests
the dirty_log_test could fail directly
on receiving a SIG_USR1 without a handler (when vcpu runs far slower than main).
Signed-off-by: Peter Xu
This should be a better way to do the same:
--- 8<
From: Paolo Bonzini
Subject: [PATCH] KVM: selftests: Wait for vcpu thread bef
On 18/04/21 14:43, Peter Xu wrote:
8<-
diff --git a/tools/testing/selftests/kvm/dirty_log_test.c
b/tools/testing/selftests/kvm/dirty_log_test.c
index 25230e799bc4..d3050d1c2cd0 100644
--- a/tools/testing/selftests/kvm/dirty_log_test.c
+++ b/tools/testing/selftests/kvm/dirty_log_test.c
On 20/04/21 08:08, Wanpeng Li wrote:
On Tue, 20 Apr 2021 at 14:02, Wanpeng Li wrote:
On Tue, 20 Apr 2021 at 00:59, Paolo Bonzini wrote:
On 19/04/21 18:32, Sean Christopherson wrote:
If false positives are a big concern, what about adding another pass to the loop
and only yielding
On 20/04/21 07:45, Shivank Garg wrote:
Hi,
I'm learning about qemu KVM, looking into code and experimenting on
it. I have the following doubts regarding it, I would be grateful if
you help me to get some idea on them.
1. I observe that KVM allocates memory to guests when it needs it but
doesn't
aolo
From daefeeb229ba8be5bd819a51875bc1fd5e74fc85 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
Date: Mon, 19 Apr 2021 09:01:46 -0400
Subject: [PATCH] KVM: avoid "deadlock" between install_new_memslots and MMU
notifier
Wanpeng Li is
and be saddled with the work of
tearing down an entire paging structure. This issue will be resolved in
a later commit.
Signed-off-by: Ben Gardon
Message-Id: <20210401233736.638171-13-bgar...@google.com>
[Move the loop to tdp_mmu.c, otherwise compilation fails on 32-bit. - Paolo]
Signed-off-by:
On 19/04/21 19:14, Linus Torvalds wrote:
On Mon, Apr 19, 2021 at 2:36 AM Peter Zijlstra wrote:
I also don't see how this is better than seq_cst.
But yes, not broken, but also very much not optimal.
I continue to feel like kernel people should just entirely ignore the
C++ memory ordering
On 19/04/21 18:32, Sean Christopherson wrote:
If false positives are a big concern, what about adding another pass to the loop
and only yielding to usermode vCPUs with interrupts in the second full pass?
I.e. give vCPUs that are already in kernel mode priority, and only yield to
handle an
On 19/04/21 10:49, Wanpeng Li wrote:
I saw this splatting:
==
WARNING: possible circular locking dependency detected
5.12.0-rc3+ #6 Tainted: G OE
--
qemu-system-x86/3069
On 19/04/21 11:36, Peter Zijlstra wrote:
On Mon, Apr 19, 2021 at 11:02:12AM +0200, Paolo Bonzini wrote:
void writer(void)
{
atomic_store_explicit(, seq+1, memory_order_relaxed);
atomic_thread_fence(memory_order_acquire);
This needs to be memory_order_release. The only change
On 19/04/21 10:26, Peter Zijlstra wrote:
On Mon, Apr 19, 2021 at 09:53:06AM +0200, Paolo Bonzini wrote:
On 19/04/21 09:32, Peter Zijlstra wrote:
On Sat, Apr 17, 2021 at 04:51:58PM +0200, Paolo Bonzini wrote:
On 16/04/21 09:09, Peter Zijlstra wrote:
Well, the obvious example would be seqlocks
On 19/04/21 09:32, Peter Zijlstra wrote:
On Sat, Apr 17, 2021 at 04:51:58PM +0200, Paolo Bonzini wrote:
On 16/04/21 09:09, Peter Zijlstra wrote:
Well, the obvious example would be seqlocks. C11 can't do them
Sure it can. C11 requires annotating with (the equivalent of) READ_ONCE all
reads
On 16/04/21 17:58, Theodore Ts'o wrote:
Another fairly common use case is a lockless, racy test of a
particular field, as an optimization before we take the lock before we
test it for realsies. In this particular case, we can't allocate
memory while holding a spinlock, so we check to see
On 16/04/21 09:09, Peter Zijlstra wrote:
Well, the obvious example would be seqlocks. C11 can't do them
Sure it can. C11 requires annotating with (the equivalent of) READ_ONCE
all reads of seqlock-protected fields, but the memory model supports
seqlocks just fine.
Simlar thing for RCU;
On 30/03/21 10:08, Yanan Wang wrote:
In addition to function of CLOCK_MONOTONIC, flag CLOCK_MONOTONIC_RAW can
also shield possiable impact of NTP, which can provide more robustness.
Suggested-by: Vitaly Kuznetsov
Signed-off-by: Yanan Wang
Reviewed-by: Ben Gardon
Reviewed-by: Andrew Jones
I'm
On 06/04/21 05:05, wangyanan (Y) wrote:
Kindly ping...
Hi Paolo,
Will this series be picked up soon, or is there any other work for me to
do?
Regards,
Yanan
On 2021/3/30 16:08, Yanan Wang wrote:
Hi,
This v6 series can mainly include two parts.
Rebased on kvm queue branch:
On 09/04/21 04:24, lihaiwei.ker...@gmail.com wrote:
From: Haiwei Li
Add compile-time assertions in vmcs_check32() to disallow accesses to
64-bit and 64-bit high fields via vmcs_{read,write}32(). Upper level KVM
code should never do partial accesses to VMCS fields. KVM handles the
split
On 13/04/21 00:20, Sean Christopherson wrote:
Fix two bugs that are exposed if unregistered a device on an I/O bus fails
due to OOM. Tack on opportunistic cleanup in the related code.
Sean Christopherson (3):
KVM: Destroy I/O bus devices on unregister failure _after_ sync'ing
SRCU
On 16/04/21 05:08, Wanpeng Li wrote:
From: Wanpeng Li
Both lock holder vCPU and IPI receiver that has halted are condidate for
boost. However, the PLE handler was originally designed to deal with the
lock holder preemption problem. The Intel PLE occurs when the spinlock
waiter is in kernel
On 13/04/21 23:36, Peter Xu wrote:
This patch closes this race by allowing the main thread to give the vcpu thread
chance to do a VMENTER to complete that write operation. It's done by adding a
vcpu loop counter (must be defined as volatile as main thread will do read
loop), then the main
On 16/03/21 18:08, Emanuele Giuseppe Esposito wrote:
KVM_X86_SET_MSR_FILTER is a capability, not an ioctl.
Therefore move it from section 4.97 to the new 8.31 (other capabilities).
Here and in the subject I think KVM_X86_SET_MSR_FILTER should be
replaced by KVM_CAP_PPC_MULTITCE.
Otherwise
On 06/04/21 08:35, Keqian Zhu wrote:
kvm_mmu_slot_largepage_remove_write_access() is decared but not used,
just remove it.
Signed-off-by: Keqian Zhu
---
arch/x86/include/asm/kvm_host.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h
On 06/04/21 19:18, Sean Christopherson wrote:
Belated code review for the vmcb changes that are queued for 5.13.
Sean Christopherson (4):
KVM: SVM: Don't set current_vmcb->cpu when switching vmcb
KVM: SVM: Drop vcpu_svm.vmcb_pa
KVM: SVM: Add a comment to clarify what vcpu_svm.vmcb
On 07/04/21 00:49, Sean Christopherson wrote:
This series teaches __sev_do_cmd_locked() to gracefully handle vmalloc'd
command buffers by copying _all_ incoming data pointers to an internal
buffer before sending the command to the PSP. The SEV driver and KVM are
then converted to use the stack
On 07/04/21 19:34, Borislav Petkov wrote:
On Wed, Apr 07, 2021 at 05:05:07PM +, Sean Christopherson wrote:
I used memset() to defer initialization until after the various sanity
checks,
I'd actually vote for that too - I don't like doing stuff which is not
going to be used. I.e., don't
On 07/04/21 07:20, Christophe Leroy wrote:
+ struct sev_data_init data;
struct sev_data_init data = {0, 0, 0, 0};
Having to count the number of items is suboptimal. The alternative
could be {} (which however is technically not standard C), {0} (a bit
mysterious, but it works) and
On 07/04/21 00:49, Sean Christopherson wrote:
For commands with small input/output buffers, use the local stack to
"allocate" the structures used to communicate with the PSP. Now that
__sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
reason to avoid using the stack, e.g.
On 09/04/21 06:18, Wanpeng Li wrote:
From: Wanpeng Li
Enable PV TLB shootdown when !CONFIG_SMP doesn't make sense. Let's
move it inside CONFIG_SMP. In addition, we can avoid define and
alloc __pv_cpu_mask when !CONFIG_SMP and get rid of 'alloc' variable
in kvm_alloc_cpumask.
Signed-off-by:
On 16/04/21 14:38, Christian Borntraeger wrote:
On 16.04.21 14:27, Stephen Rothwell wrote:
Hi all,
In commit
c3171e94cc1c ("KVM: s390: VSIE: fix MVPG handling for prefixing and
MSO")
Fixes tag
Fixes: bdf7509bbefa ("s390/kvm: VSIE: correctly handle MVPG when in
VSIE")
has these
On 16/04/21 15:26, Christian Borntraeger wrote:
On 16.04.21 15:00, Masahiro Yamada wrote:
Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler"), some kselftests fail to build.
The tools/ directory opted out Kbuild, and went in a different
direction.
On 16/04/21 10:36, Vitaly Kuznetsov wrote:
- Create a dedicated set of files, e.g. 'kvmonhyperv.[ch]' (I also
thought about 'hyperv_host.[ch]' but then I realized it's equally
misleading as one can read this as 'KVM is acting as Hyper-V host').
Personally, I'd vote for the later. Besides
ntation/atomic_t.txt
.. [memory-barriers] Documentation/memory-barriers.txt
.. [lwn-mb] https://lwn.net/Articles/573436/
Acked-by: Paolo Bonzini
On 07/04/21 20:00, Tom Lendacky wrote:
For the series:
Acked-by: Tom Lendacky
Shall I take this as a request (or permission, whatever :)) to merge it
through the KVM tree?
Paolo
On 15/04/21 10:04, Masahiro Yamada wrote:
On Thu, Apr 15, 2021 at 4:40 PM Paolo Bonzini wrote:
I think it would make sense to add try-run, cc-option and
.DELETE_ON_ERROR to tools/build/Build.include?
To be safe, I just copy-pasted what the makefiles need.
If someone wants to refactor
On 15/04/21 09:27, Masahiro Yamada wrote:
Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler"), some kselftests fail to build.
The tools/ directory opted out Kbuild, and went in a different
direction. They copy any kind of files to the tools/ directory
On 15/04/21 02:59, Lai Jiangshan wrote:
The next call to inject_pending_event() will reach here AT FIRST with
vcpu->arch.exception.injected==false and vcpu->arch.exception.pending==false
... if (!vcpu->arch.exception.pending) {
if (vcpu->arch.nmi_injected) {
On 14/04/21 04:28, Lai Jiangshan wrote:
On Tue, Apr 13, 2021 at 8:15 PM Paolo Bonzini wrote:
On 13/04/21 13:03, Lai Jiangshan wrote:
This patch claims that it has a place to
stash the IRQ when EFLAGS.IF=0, but inject_pending_event() seams to ignore
EFLAGS.IF and queues the IRQ to the guest
Linus,
The following changes since commit 315f02c60d9425b38eb8ad7f21b8a35e40db23f9:
KVM: x86/mmu: preserve pending TLB flush across calls to kvm_tdp_mmu_zap_sp
(2021-04-08 07:48:18 -0400)
are available in the Git repository at:
https://git.kernel.org/pub/scm/virt/kvm/kvm.git
On 13/04/21 23:20, Jonathan Corbet wrote:
Emanuele Giuseppe Esposito writes:
KVM_X86_SET_MSR_FILTER is a capability, not an ioctl.
Therefore move it from section 4.97 to the new 8.31 (other capabilities).
To fill the gap, move KVM_X86_SET_MSR_FILTER (was 4.126) to
4.97, and shifted
On 13/04/21 13:03, Lai Jiangshan wrote:
This patch claims that it has a place to
stash the IRQ when EFLAGS.IF=0, but inject_pending_event() seams to ignore
EFLAGS.IF and queues the IRQ to the guest directly in the first branch
of using "kvm_x86_ops.set_irq(vcpu)".
This is only true for
On 12/04/21 23:43, Sean Christopherson wrote:
where kvm_arch_interrupt_allowed() checks EFLAGS.IF (and an edge case related to
nested virtualization). KVM also captures EFLAGS.IF in vcpu->run->if_flag.
For whatever reason, QEMU checks both vcpu->run flags before injecting an IRQ,
maybe to
On 09/04/21 03:18, James Bottomley wrote:
If you want to share ASIDs you have to share the firmware that the
running VM has been attested to. Once the VM moves from LAUNCH to
RUNNING, the PSP won't allow the VMM to inject any more firmware or do
any more attestations.
I think Steve is
On 08/04/21 18:27, Sean Christopherson wrote:
For your approach, can we put the out label after the success path? Setting
mmu->root_pgd isn't wrong per se, but doing so might mislead future readers into
thinking that it's functionally necessary.
Indeed, thanks for the speedy review. I'll get
On 08/04/21 18:05, Sean Christopherson wrote:
Add compile-time assertions in vmcs_check32() to disallow accesses to
64-bit and 64-bit high fields via vmcs_{read,write}32(). Upper level
KVM code should never do partial accesses to VMCS fields. KVM handles
the split accesses
On 08/04/21 18:04, Tom Lendacky wrote:
+ if (!err || !sev_es_guest(vcpu->kvm) || !WARN_ON_ONCE(svm->ghcb))
This should be WARN_ON_ONCE(!svm->ghcb), otherwise you'll get the right
result, but get a stack trace immediately.
Doh, yep.
Actually, because of the "or's", this needs to be:
if
On 08/04/21 17:48, Sean Christopherson wrote:
Freaking PDPTRs. I was really hoping we could keep the lock and
pages_available()
logic outside of the helpers. What if kvm_mmu_load() reads the PDPTRs and
passes them into mmu_alloc_shadow_roots()? Or is that too ugly?
The patch I have posted
On 08/04/21 17:40, Siddharth Chandrasekaran wrote:
Although the Hyper-v TLFS mentions that a guest cannot use this feature
unless the hypervisor advertises support for it, some hypercalls which
we plan on upstreaming in future uses them anyway.
No, please don't do this. Check the feature bit(s)
On 07/04/21 16:41, Vineeth Pillai wrote:
+#if IS_ENABLED(CONFIG_HYPERV)
+static inline void hv_vmcb_dirty_nested_enlightenments(struct kvm_vcpu *vcpu)
+{
+ struct vmcb *vmcb = to_svm(vcpu)->vmcb;
+
+ /*
+* vmcb can be NULL if called during early vcpu init.
+* And
On 07/04/21 16:41, Vineeth Pillai wrote:
+#define VMCB_ALL_CLEAN_MASK (__CLEAN_MASK | (1U <<
VMCB_HV_NESTED_ENLIGHTENMENTS))
+#else
+#define VMCB_ALL_CLEAN_MASK __CLEAN_MASK
+#endif
I think this should depend on whether KVM is running on top of Hyper-V;
not on whether KVM is *compiled* with
On 08/04/21 17:28, Wei Liu wrote:
Although the Hyper-v TLFS mentions that a guest cannot use this feature
unless the hypervisor advertises support for it, some hypercalls which
we plan on upstreaming in future uses them anyway.
No, please don't do this. Check the feature bit(s) before you
On 08/04/21 14:01, Vitaly Kuznetsov wrote:
Also, we can probably defer kvm_hv_hypercall_read_xmm() until we know
how many regs we actually need to not read them all (we will always
need xmm[0] I guess so we can as well read it here).
The cost is get/put FPU, so I think there's not much to
On 08/04/21 14:00, Marcelo Tosatti wrote:
KVM_REQ_MCLOCK_INPROGRESS is only needed to kick running vCPUs out of the
execution loop;
We do not want vcpus with different system_timestamp/tsc_timestamp
pair:
* To avoid that problem, do not allow visibility of distinct
*
a backport to
stable versions.
Paolo Bonzini (1):
KVM: x86/mmu: preserve pending TLB flush across calls to
kvm_tdp_mmu_zap_sp
arch/x86/kvm/mmu/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On 08/04/21 13:15, Wanpeng Li wrote:
I saw this splatting:
BUG: sleeping function called from invalid context at
arch/x86/kvm/kvm_cache_regs.h:115
kvm_pdptr_read+0x20/0x60 [kvm]
kvm_mmu_load+0x3bd/0x540 [kvm]
There is a might_sleep() in kvm_pdptr_read(), however, the original
commit
On 06/04/21 21:07, Sean Christopherson wrote:
Use GFP_KERNEL_ACCOUNT when allocating vCPUs to make it more obvious that
that the allocations are accounted, to make it easier to audit KVM's
allocations in the future, and to be consistent with other cache usage in
KVM.
When using SLAB/SLUB, this
r the new follow_pte()
function.
Cc: 3...@google.com
Cc: Jann Horn
Cc: Paolo Bonzini
Cc: Jason Gunthorpe
Cc: Cornelia Huck
Cc: Peter Xu
Cc: Alex Williamson
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc:
On 07/04/21 19:40, Marcelo Tosatti wrote:
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fe806e894212..0a83eff40b43 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2562,10 +2562,12 @@ static void kvm_gen_update_masterclock(struct kvm *kvm)
On 06/04/21 21:44, Sasha Levin wrote:
On Tue, Apr 06, 2021 at 08:28:27PM +0200, Paolo Bonzini wrote:
If a patch doesn't (more or less trivially) apply, the maintainer
should take action. Distro maintainers can also jump in and post the
backport to subsystem mailing lists. If the stable
On 06/04/21 20:25, Greg KH wrote:
On Tue, Apr 06, 2021 at 12:25:50PM -0400, Paolo Bonzini wrote:
Right now, if a call to kvm_tdp_mmu_zap_sp returns false, the caller
will skip the TLB flush, which is wrong. There are two ways to fix
it:
- since kvm_tdp_mmu_zap_sp will not yield and therefore
On 06/04/21 20:01, Sasha Levin wrote:
On Tue, Apr 06, 2021 at 05:48:50PM +0200, Paolo Bonzini wrote:
On 06/04/21 15:49, Sasha Levin wrote:
Yup. Is there anything wrong with those patches?
The big issue, and the one that you ignoredz every time we discuss
this topic, is that this particular
NX zapping")
Cc: # 5.10.x: 048f49809c: KVM: x86/mmu: Ensure TLBs
are flushed for TDP MMU during NX zapping
Cc: # 5.10.x: 33a3164161: KVM: x86/mmu: Don't allow
TDP MMU to yield when recovering NX pages
Cc:
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 2 +-
1 file change
On 06/04/21 15:49, Sasha Levin wrote:
On Tue, Apr 06, 2021 at 08:09:26AM +0200, Paolo Bonzini wrote:
Whoa no, you have included basically a whole new feature, except for
the final patch that actually enables the feature. The whole new MMU
Right, we would usually grab dependencies rather
On 05/04/21 20:27, Steve Rutherford wrote:
On Mon, Apr 5, 2021 at 8:17 AM Peter Gonda wrote:
Could this patch set include support for the SEND_CANCEL command?
That's separate from this patchset. I sent up an implementation last week.
And I was going to queue it today.
Paolo
On 06/04/21 15:26, Ashish Kalra wrote:
It's a little unintuitive to see KVM_MSR_RET_FILTERED here, since
userspace can make this happen on its own without having an entry in
this switch statement (by setting it in the msr filter bitmaps). When
using MSR filters, I would only expect to get MSR
On 06/04/21 13:39, Thomas Bogendoerfer wrote:
On Tue, Apr 06, 2021 at 08:05:40AM +0200, Paolo Bonzini wrote:
On 06/04/21 03:36, Huacai Chen wrote:
I tried the merge and it will be enough for Linus to remove
arch/mips/kvm/trap_emul.c. So I will leave it as is, but next time I'd
prefer KVM MIPS
threads attempt to modify the same SPTE.
Reviewed-by: Peter Feiner
Signed-off-by: Ben Gardon
Message-Id: <20210202185734.1680553-21-bgar...@google.com>
[Document new locking rules. - Paolo]
Signed-off-by: Paolo Bonzini
Signed-off-by: Sasha Levin
---
Documentation/virt/kvm/locking.rst
On 06/04/21 03:36, Huacai Chen wrote:
I tried the merge and it will be enough for Linus to remove
arch/mips/kvm/trap_emul.c. So I will leave it as is, but next time I'd
prefer KVM MIPS changes to go through either my tree or a common topic
branch.
Emmm, the TE removal series is done by Thomas,
On 03/04/21 04:31, Huacai Chen wrote:
Hi, Paolo,
TE mode has been removed in the MIPS tree, can we also remove it in
KVM tree before this rework?
I tried the merge and it will be enough for Linus to remove
arch/mips/kvm/trap_emul.c. So I will leave it as is, but next time I'd
prefer KVM
On 03/04/21 04:31, Huacai Chen wrote:
Hi, Paolo,
TE mode has been removed in the MIPS tree, can we also remove it in
KVM tree before this rework?
Fortunately I can pull the exact commit that was applied to the MIPS
tree, as it was the first patch that was applied to the tree, but next
time
On 01/04/21 15:54, Maxim Levitsky wrote:
Hi!
I would like to publish two debug features which were needed for other stuff
I work on.
One is the reworked lx-symbols script which now actually works on at least
gdb 9.1 (gdb 9.2 was reported to fail to load the debug symbols from the kernel
for
1 - 100 of 12102 matches
Mail list logo
