On 12/28/22 12:22, Marc Zyngier wrote:
Queued, thanks. I will leave this in kvm/queue after testing everything
else and moving it to kvm/next; this way, we can wait for test results
on other architectures.
Can you please make this a topic branch, and if possible based
on a released -rc? It
On 12/28/22 12:22, Marc Zyngier wrote:
Queued, thanks. I will leave this in kvm/queue after testing everything
else and moving it to kvm/next; this way, we can wait for test results
on other architectures.
Can you please make this a topic branch, and if possible based
on a released -rc? It
Queued, thanks. I will leave this in kvm/queue after testing everything
else and moving it to kvm/next; this way, we can wait for test results
on other architectures.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 12/13/22 01:16, Sean Christopherson wrote:
Use $(wildcard ...) to find the library source files instead of manually
defining the inputs, which is a maintenance burden and error prone.
No, please don't. This leads to weird errors, for example when "git
checkout" is interrupted with ^C. I
On 12/13/22 01:16, Sean Christopherson wrote:
Include lib.mk before consuming $(CC) and document that lib.mk overwrites
$(CC) unless make was invoked with -e or $(CC) was specified after make
(which apparently makes the environment override the Makefile?!?!).
Yes, it does. In projects that
On 12/13/22 01:16, Sean Christopherson wrote:
Explicitly disable the compiler's builtin memcmp(), memcpy(), and
memset(). Because only lib/string_override.c is built with -ffreestanding,
the compiler reserves the right to do what it wants and can try to link the
non-freestanding code to its own
On 12/13/22 01:16, Sean Christopherson wrote:
-ifeq ($(ARCH),riscv)
- UNAME_M := riscv
+ifeq ($(ARCH),x86)
+ ARCH_DIR := x86_64
+else ifeq ($(ARCH),arm64)
+ ARCH_DIR := aarch64
+else ifeq ($(ARCH),s390)
+ ARCH_DIR := s390x
+else ifeq ($(ARCH),riscv)
+ ARCH_DIR :=
On 12/13/22 00:26, Sean Christopherson wrote:
I would strongly be in favor of discarding the shadow paging residue if
x86 folks are willing to part ways with it
Yes, absolutely. Something like to_shadow_page->to_mmu_data, sp->md,
spt->hpt, spte->spte, sptep->hptep.
"host" will be confusing
On 12/8/22 20:38, David Matlack wrote:
Invert the meaning of sp->tdp_mmu_page and rename it accordingly. This
allows the TDP MMU code to not care about this field, which will be used
in a subsequent commit to move the TDP MMU to common code.
No functional change intended.
Let's use a bit of
On 12/8/22 20:38, David Matlack wrote:
+/*
+ * kvm_mmu_page_role tracks the properties of a shadow page (where shadow page
+ * also includes TDP pages) to determine whether or not a page can be used in
+ * the given MMU context.
+ */
+union kvm_mmu_page_role {
+ u32 word;
+ struct {
On 12/9/22 20:07, Oliver Upton wrote:
- Naming. This series does not change the names of any existing code.
So all the KVM/x86 Shadow MMU-style terminology like
"shadow_page"/"sp"/"spte" persists. Should we keep that style in
common code or move toward something less
On 12/12/22 18:39, Sean Christopherson wrote:
The notion of address spaces is already existing architecture-neutral
concept in KVM (e.g. see uses of KVM_ADDRESS_SPACE_NUM in
virt/kvm/kvm_main.c), although SMM is the only use-case I'm aware of.
Yes, SMM is currently the only use-case.
It's
On 12/8/22 20:38, David Matlack wrote:
This commit increases the size of struct kvm_mmu_page by 64 bytes on
x86_64 (184 bytes -> 248 bytes). The size of this struct can be reduced
in future commits by moving TDP MMU root fields into a separate struct
and by dynamically allocating fields only
On 12/8/22 20:38, David Matlack wrote:
+
+ /* Derived from mmu and global state. */
+ const bool is_tdp;
I think this could stay in the architecture-independent part.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 12/9/22 22:03, Sean Christopherson wrote:
From: Sean Christopherson
Date: Fri, 9 Dec 2022 12:55:44 -0800
Subject: [PATCH] KVM: selftests: Use magic value to signal ucall_alloc()
failure
Use a magic value to signal a ucall_alloc() failure instead of simply
doing GUEST_ASSERT().
On 12/9/22 02:52, Oliver Upton wrote:
The combination of the pool-based ucall implementation + page_fault_test
resulted in some 'fun' bugs. As has always been the case, KVM selftests
is a house of cards.
Small series to fix up the issues on kvm/queue. Patches 1-2 can probably
be squashed into
On 12/9/22 02:53, Oliver Upton wrote:
@@ -268,17 +305,17 @@ struct kvm_vm *vm_create(enum vm_guest_mode mode)
#ifdef __aarch64__
if (vm->pa_bits != 40)
vm->type = KVM_VM_TYPE_ARM_IPA_SIZE(vm->pa_bits);
+
+ /* selftests use TTBR0 only, meaning there is a single
On Fri, Dec 9, 2022 at 6:05 PM Oliver Upton wrote:
> Mind dumping what I had in v1 and applying this instead?
>
> https://lore.kernel.org/kvm/20221209015307.1781352-1-oliver.up...@linux.dev/
Ouch, five minutes too late... I can take care of the difference but
it'll have to wait for Monday.
On 12/7/22 22:51, Oliver Upton wrote:
I haven't pushed to kvm/next yet to give you time to check, so the
merge is currently in kvm/queue only.
Have a look at this series, which gets things building and actually
passing again:
On 12/7/22 08:49, Marc Zyngier wrote:
On Tue, 06 Dec 2022 21:43:43 +,
Paolo Bonzini wrote:
On 12/6/22 19:20, Mark Brown wrote:
I almost suggested doing that on multiple occasions this cycle, but ultimately
decided not to because it would effectively mean splitting series that touch KVM
On 12/6/22 19:20, Mark Brown wrote:
I almost suggested doing that on multiple occasions this cycle, but ultimately
decided not to because it would effectively mean splitting series that touch KVM
and selftests into different trees, which would create a different kind of
dependency hell. Or
On 12/5/22 16:58, Marc Zyngier wrote:
- There is a lot of selftest conflicts with your own branch, see:
https://lore.kernel.org/r/20221201112432.4cb9a...@canb.auug.org.au
https://lore.kernel.org/r/20221201113626.438f1...@canb.auug.org.au
On 11/19/22 02:34, Sean Christopherson wrote:
For obvious reasons I'd like to route the this through Paolo's tree.
In theory, taking just patch 5 through tip would work, but creating a
topic branch seems like the way to go, though maybe I'm being overly
paranoid. The current tip/perf/core
On 11/3/22 19:58, Sean Christopherson wrote:
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 3e508f239098..ebe617ab0b37 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -191,6 +191,8 @@ static void default_init(struct cpuinfo_x86 *c)
On 11/4/22 08:17, Isaku Yamahata wrote:
On Wed, Nov 02, 2022 at 11:18:27PM +,
Sean Christopherson wrote:
Non-x86 folks, please test on hardware when possible. I made a _lot_ of
mistakes when moving code around. Thankfully, x86 was the trickiest code
to deal with, and I'm fairly
On 11/3/22 19:35, Sean Christopherson wrote:
It's technically required. IA32_FEAT_CTL and thus KVM_INTEL depends on any of
CPU_SUP_{INTEL,CENATUR,ZHAOXIN}, but init_ia32_feat_ctl() is invoked if and only
if the actual CPU type matches one of the aforementioned CPU_SUP_*.
E.g. running a kernel
On 11/3/22 18:44, Sean Christopherson wrote:
Do compatibility checks when enabling hardware to effectively add
compatibility checks when onlining a CPU. Abort enabling, i.e. the
online process, if the (hotplugged) CPU is incompatible with the known
good setup.
This paragraph is not true with
On 11/3/22 13:08, Christian Borntraeger wrote:
There are bug fixes throughout this series. They are more scattered than
I would usually prefer, but getting the sequencing correct was a gigantic
pain for many of the x86 fixes due to needing to fix common code in order
for the x86 fix to have any
On 11/3/22 00:19, Sean Christopherson wrote:
+- kvm_lock is taken outside kvm->mmu_lock
Not surprising since one is a mutex and one is an rwlock. :) You can
drop this hunk as well as the "Opportunistically update KVM's locking
documentation" sentence in the commit message.
-
On 11/3/22 00:19, Sean Christopherson wrote:
From: Chao Gao
Do compatibility checks when enabling hardware to effectively add
compatibility checks when onlining a CPU. Abort enabling, i.e. the
online process, if the (hotplugged) CPU is incompatible with the known
good setup.
This paragraph
On 11/3/22 00:19, Sean Christopherson wrote:
+ if (!boot_cpu_has(X86_FEATURE_MSR_IA32_FEAT_CTL) ||
+ !boot_cpu_has(X86_FEATURE_VMX)) {
+ pr_err("VMX not enabled in MSR_IA32_FEAT_CTL\n");
+ return false;
I think the reference to the BIOS should remain
On Thu, Nov 3, 2022 at 3:01 PM Paolo Bonzini wrote:
>
> On 11/3/22 00:18, Sean Christopherson wrote:
> > +static void hv_cleanup_evmcs(void)
>
> This needs to be __init.
Error: brain temporarily disconnected.
Paolo
___
kvmarm m
On 11/3/22 00:18, Sean Christopherson wrote:
+static void hv_cleanup_evmcs(void)
This needs to be __init.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Thu, Oct 20, 2022 at 12:02 PM Marc Zyngier wrote:
>
> Paolo,
>
> Here's a couple of additional fixes for 6.1. The ITS one is pretty
> annoying as it prevents a VM from being restored if it has a
> convoluted device topology. Definitely a stable candidate.
>
> Note that I can't see that you
On Thu, Oct 13, 2022 at 3:28 PM Marc Zyngier wrote:
> Paolo,
>
> Here's the first set of fixes for 6.1. The most interesting bit is
> Oliver's fix limiting the S2 invalidation batch size the the largest
> block mapping, solving (at least for now) the RCU stall problems we
> have been seeing for a
Pulled, thanks!
Paolo
On Sun, Oct 2, 2022 at 2:42 PM Marc Zyngier wrote:
>
> Paolo,
>
> Please find below the rather small set of KVM/arm64 updates
> for 6.1. This is mostly a set of fixes for existing features,
> the most interesting one being Reiji's really good work tracking
> an annoying
Il ven 23 set 2022, 20:26 Peter Xu ha scritto:
>
> > Someone will show up with an old userspace which probes for the sole
> > existing capability, and things start failing subtly. It is quite
> > likely that the userspace code is built for all architectures,
>
> I didn't quite follow here. Since
On Fri, Sep 23, 2022 at 4:20 PM Marc Zyngier wrote:
> > > This is only a partial fix as the userspace side also need upgrading.
> >
> > Paolo has one fix 4802bf910e ("KVM: dirty ring: add missing memory
> > barrier", 2022-09-01) which has already landed.
>
> What is this commit? It doesn't exist
On Thu, Sep 22, 2022 at 7:02 PM Marc Zyngier wrote:
> To make sure that all the writes to the log marking the entries
> as being in need of reset are observed in order, use a
> smp_store_release() when updating the log entry flags.
>
> Signed-off-by: Marc Zyngier
You also need a load-acquire on
Pulled, thanks.
Paolo
On Mon, Sep 19, 2022 at 7:19 PM Marc Zyngier wrote:
>
> Paolo,
>
> Here's the last KVM/arm64 pull request for this cycle, with
> a small fix for pKVM and kmemleak.
>
> Please pull,
>
> M.
>
> The following changes since commit
On 8/30/22 16:42, Peter Xu wrote:
Marc,
I thought we won't hit this as long as we properly take care of other
orderings of (a) gfn push, and (b) gfn collect, but after a second thought
I think it's indeed logically possible that with a reversed ordering here
we can be reading some garbage gfn
Il ven 26 ago 2022, 17:50 Marc Zyngier ha scritto:
> userspace has no choice. It cannot order on its own the reads that the
> kernel will do to *other* rings.
>
> The problem isn't on CPU0 The problem is that CPU1 does observe
> inconsistent data on arm64, and I don't think this difference in
>
On 8/26/22 17:49, Marc Zyngier wrote:
Agreed, but that's a problem for userspace to solve. If userspace
wants to reset the fields in different CPUs, it has to synchronize
with its own invoking of the ioctl.
userspace has no choice. It cannot order on its own the reads that the
kernel will do
On 8/23/22 22:35, Marc Zyngier wrote:
Heh, yeah I need to get that out the door. I'll also note that Gavin's
changes are still relevant without that series, as we do write unprotect
in parallel at PTE granularity after commit f783ef1c0e82 ("KVM: arm64:
Add fast path to handle permission
On 8/24/22 00:47, Marc Zyngier wrote:
I definitely don't think I 100% understand all the ordering things since
they're complicated.. but my understanding is that the reset procedure
didn't need memory barrier (unlike pushing, where we have explicit wmb),
because we assumed the userapp is not
On 8/19/22 21:01, Oliver Upton wrote:
While I'm still at Google, I've since switched to a linux.dev account
for working upstream.
Add an alias to the new address.
Signed-off-by: Oliver Upton
Queued, thanks.
Paolo
___
kvmarm mailing list
Pulled, thanks.
Paolo
On Thu, Aug 18, 2022 at 4:09 PM Marc Zyngier wrote:
>
> Paolo,
>
> Here's a small set of KVM/arm64 fixes for 6.0, the most visible thing
> being a better handling of systems with asymmetric AArch32 support.
>
> Please pull,
>
> M.
>
> The following changes since
On 8/10/22 14:29, Mathieu Desnoyers wrote:
- By design, selftests/rseq and selftests/kvm are parallel. It's going to
introduce
unnecessary dependency for selftests/kvm to use selftests/rseq/librseq.so. To
me,
it makes the maintainability even harder.
In terms of build system, yes,
On 8/10/22 14:22, Mathieu Desnoyers wrote:
/*
* Create and run a dummy VM that immediately exits to userspace via
@@ -256,7 +244,7 @@ int main(int argc, char *argv[])
*/
smp_rmb();
cpu = sched_getcpu();
-
On 8/10/22 14:17, Mathieu Desnoyers wrote:
Indeed, this hack seems to be a good approach to immediately fix things without
moving around all source files and headers. In the longer term, I'd prefer
Sean's
proposal to move rseq.c to tools/lib/ (and to move rseq headers to
tools/include/rseq/).
On 8/9/22 14:21, Mathieu Desnoyers wrote:
For kvm/selftests, there are 3 architectures involved actually. So we
just need consider 4 cases: aarch64, x86, s390 and other. For other
case, we just use __builtin_thread_pointer() to maintain code's
integrity, but it's not called at all.
I think
On 7/29/22 10:43, Marc Zyngier wrote:
Paolo,
Here's the bulk of the KVM/arm64 updates for 5.20. Major feature is
the new unwinder for the nVHE modes. The rest is mostly rewriting some
unloved aspects of the arm64 port (sysregs, flags). Further details in
the tag description.
Note that this PR
On 7/19/22 04:08, Gavin Shan wrote:
In rseq_test, there are two threads, which are vCPU thread and migration
worker separately. Unfortunately, the test has the wrong PID passed to
sched_setaffinity() in the migration worker. It forces migration on the
migration worker because zeroed PID
On 7/14/22 17:35, Sean Christopherson wrote:
Can you check that smp_rmb() and smp_wmb() generate correct instructions on
arm64?
That seems like the most likely scenario (or a kernel bug), I distinctly
remember
the barriers provided by tools/ being rather bizarre.
Maybe we should bite the
On 7/14/22 10:06, Gavin Shan wrote:
In rseq_test, there are two threads created. Those two threads are
'main' and 'migration_thread' separately. We also have the assumption
that non-migration status on 'migration-worker' thread guarantees the
same non-migration status on 'main' thread.
On 7/14/22 10:06, Gavin Shan wrote:
In rseq_test, there are two threads created. Those two threads are
'main' and 'migration_thread' separately. We also have the assumption
that non-migration status on 'migration-worker' thread guarantees the
same non-migration status on 'main' thread.
On 6/24/22 15:12, Marc Zyngier wrote:
- as far as I know, the core Linux/arm64 maintainers have no plan to
support APF. Without it, this is a pointless exercise. And even with
it, this introduces a Linux specific behaviour in an otherwise
architectural hypervisor (something I'm quite
Queued, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On 6/23/22 09:41, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.19-2
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
in riscv and arm64 to use designated
initializers.
No functional change intended.
Reviewed-by: Marc Zyngier
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-22-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/arm64/kvm/mmu.c | 2 +-
arch/riscv/kvm
by David Matlack.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 22681931921f..79c6a821ea0d 100644
--- a/arch/x86/kvm/mmu/mmu.c
if the shadow page
already existed. This is a bit more verbose, but clearer than
NULL.
Now that the drop_large_spte() name is not taken anymore,
remove the two underscores in front of __drop_large_spte().
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 43
Matlack
Message-Id: <20220516232138.1783324-17-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index a8cdbe2958d9..7cca28d89a85 100644
--- a/arch/x
-Id: <20220516232138.1783324-23-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
.../admin-guide/kernel-parameters.txt | 3 +-
arch/x86/include/asm/kvm_host.h | 22 ++
arch/x86/kvm/mmu/mmu.c| 261 +-
3 files changed, 277 i
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index fab417e7bf6c..c5a88e8d1b53 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -2056,7 +
-by: David Matlack
Message-Id: <20220516232138.1783324-18-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/include/asm/kvm_host.h | 2 +-
arch/x86/kvm/mmu/mmu.c | 85 +++--
arch/x86/kvm/mmu/mmu_internal.h | 17 ++-
arch/x86/kvm/mmu/paging_
.
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-19-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/spte.c| 15 +++
arch/x86/kvm/mmu/spte.h| 4 ++--
arch/x86/kvm/mmu/tdp_mmu.c | 2 +-
3 files changed, 10 insertions(+), 11 del
page splitting to bail early.
No functional change intended.
Reviewed-by: Peter Xu
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-20-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 21 ++---
1 file changed, 14 insertions
ed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index a7748c5a2385..45a4e85c0b2c 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -1556,7 +1556,7 @@ stati
, which allocates direct
shadow pages from the context of a VM ioctl without access to a vCPU
pointer.
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-14-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 10 ++
1 file changed, 10 inse
.
No functional change intended.
Reviewed-by: Sean Christopherson
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-7-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 52 +++---
1 file changed, 39 insertions(+), 13 del
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-16-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 47 ++
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/k
ean Christopherson
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-10-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mm
Matlack
Message-Id: <20220516232138.1783324-11-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 2602c3
David Matlack
Message-Id: <20220516232138.1783324-9-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 8b84cdd8c6cd..bd45364bf465 100644
--- a/a
138.1783324-4-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 844b58ddb3bb..2e30398fe59f 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/
t;
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index c5a88e8d1b53..88b3f3c2c8b1 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/
still
must be overridden for PAE page directories, when shadowing 32-bit
guest page tables with PAE page tables.
No functional change intended.
Reviewed-by: Peter Xu
Signed-off-by: David Matlack
Message-Id: <20220516232138.1783324-5-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch
atl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 39 +--
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index a59fe860da29..8b84cdd8c6cd 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++
86/mmu: Extend Eager Page Splitting to nested MMUs
Paolo Bonzini (2):
KVM: x86/mmu: pull call to drop_large_spte() into __link_shadow_page()
KVM: x86/mmu: Avoid unnecessary flush on eager page split
.../admin-guide/kernel-parameters.txt | 3 +-
arch/arm64/kvm/mmu.c
id Matlack
Message-Id: <20220516232138.1783324-3-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index c0afb4f1c8ae..844b58ddb3bb 100644
--- a/
Matlack
Message-Id: <20220516232138.1783324-6-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index fd1b479bf7fc..f4e7978a6c6a
.1783324-2-dmatl...@google.com>
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/mmu/mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 27b2a5603496..c0afb4f1c8ae 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/m
On 6/22/22 18:13, Paolo Bonzini wrote:
Even better, drop_large_spte() is always called right before
kvm_mmu_get_child_sp(), so:
Actually, we can even include the call from eager page splitting if
__link_shadow_page() is the one that takes care of dropping the large
SPTE:
From
sh when the SPTE is large.
Even better, drop_large_spte() is always called right before
kvm_mmu_get_child_sp(), so:
From 86a9490972a1e959a4df114678719494b5475720 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
Date: Wed, 22 Jun 2022 12:11:44 -0400
Subject: [PATCH] KVM: MMU: pull drop_large_spte into kvm_mmu
On 6/17/22 17:28, Sean Christopherson wrote:
On Mon, May 16, 2022, David Matlack wrote:
Allow @vcpu to be NULL in kvm_mmu_find_shadow_page() (and its only
caller __kvm_mmu_get_shadow_page()). @vcpu is only required to sync
indirect shadow pages, so it's safe to pass in NULL when looking up
On 6/16/22 20:47, Sean Christopherson wrote:
The argument @direct is vcpu->arch.mmu->root_role.direct, so just use
that.
It's worth calling out that, unlike non-root page tables, it's impossible to
have
a direct root in an indirect MMU. I.e. provide a hint as to why there's a need
to
pass
On 6/16/22 14:45, Andrew Jones wrote:
+#define __GUEST_ASSERT(_condition, _condstr, _nargs, _args...) do {\
+ if (!(_condition)) \
+ ucall(UCALL_ABORT, GUEST_ASSERT_BUILTIN_NARGS + _nargs,
\
+
On 6/18/22 02:16, Sean Christopherson wrote:
Consolidate the code for making and getting ucalls. All architectures pass
the ucall struct via memory, so filling and copying the struct is 100%
generic. The only per-arch code is sending and receiving the address of
said struct.
Tested on x86 and
On 6/17/22 12:33, Andrew Jones wrote:
I don't see the change for commit 38f703663d4c as of an upstream pull
right now
$ git show 47700948a4ab:arch/arm64/kvm/mmu.c | grep -A4 'void
kvm_flush_remote_tlbs'
void kvm_flush_remote_tlbs(struct kvm *kvm)
{
On 6/17/22 09:28, Andrew Jones wrote:
On Thu, Jun 16, 2022 at 09:54:16PM +, David Laight wrote:
From: oliver.up...@linux.dev
Sent: 16 June 2022 19:45
June 16, 2022 11:48 AM, "David Laight" wrote:
No wonder I was confused.
It's not surprising the compiler optimises it all away.
It
Queued, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On 6/9/22 16:17, Marc Zyngier wrote:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git
tags/kvmarm-fixes-5.19-1
Pulled, thanks.
Paolo
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
On 5/19/22 11:27, Marc Zyngier wrote:
Hi Paolo,
Here's the bulk of the KVM/arm64 updates for 5.19. Major features are
guard pages for the EL2 stacks, save/restore of the guest-visible
hypercall configuration and PSCI suspend support. Further details in
the tag description.
Note that this PR
Signed-off-by: Paolo Bonzini
---
Documentation/virt/kvm/api.rst | 52 +-
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index 3201933e52d9..6890c04ccde2 100644
--- a/Documentation
On 5/16/22 14:51, Marc Zyngier wrote:
Paolo,
Here's the third (and hopefully final) set of fixes for 5.18. Two
rather simple patches: one addressing a userspace-visible change in
behaviour with GICv3, and a fix for pKVM in combination with CPUs
affected by Spectre-v3a.
Please pull,
M.
On 5/11/22 14:05, Guo Zhengkui wrote:
Fix the following coccicheck warnings:
tools/testing/selftests/kvm/lib/s390x/ucall.c:25:15-17: WARNING
opportunity for min()
tools/testing/selftests/kvm/lib/x86_64/ucall.c:27:15-17: WARNING
opportunity for min()
On 5/5/22 14:04, Marc Zyngier wrote:
diff --git a/arch/arm64/include/uapi/asm/kvm.h
b/arch/arm64/include/uapi/asm/kvm.h
index e523bb6eac67..3cde9f958eee 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -342,6 +342,10 @@ struct kvm_arm_copy_mte_tags {
On 4/29/22 17:36, Marc Zyngier wrote:
Paolo,
Here's a trio of fixes for 5.18. Nothing terribly interesting, but
nonetheless important fixes (two of the bugs are related to AArch32).
Cool, will pull soon. Please take a quick look at the flags->data ABI
fix, it's one patch on top of 5.18 as
On 4/21/22 18:30, Ben Gardon wrote:
Completely agree. I'm surprised that ARM doesn't have a need for a
metadata structure associated with each page of the stage 2 paging
structure, but if you don't need it, that definitely makes things
simpler.
The uses of struct kvm_mmu_page in the TDP MMU
1 - 100 of 627 matches
Mail list logo
