Disabling KASLR from the command line is implemented as a feature
override. Repaint it slightly so that it can further be used as
more generic infrastructure for SW override purposes.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/cpufeature.h | 4
arch/arm64/kernel/cpufeature.c
n a M1 box, with no measurable change in
performance.
Thanks,
M.
[1]
https://www.youtube.com/watch?v=1F_Mf2j9eIo=PLbzoR-pLrL6qWL3v2KOcvwZ54-w0z5uXV=11
Marc Zyngier (17):
arm64: Turn kaslr_feature_override into a generic SW feature override
arm64: Add KVM_HVHE capability and has_hvhe()
Expose a capability keying the hVHE feature as well as a new
predicate testing it. Nothing is so far using it, and nothing
is enabling it yet.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/cpufeature.h | 1 +
arch/arm64/include/asm/virt.h | 8
arch/arm64/kernel
-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_hyp.h | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index 461fc0dc4a70..e45215a62b43 100644
--- a/arch/arm64/include/asm/kvm_hyp.h
+++ b/arch/arm64
When HCR_EL2.E2H is set, the CPTR_EL2 register takes the CPACR_EL1
format. Yes, this is good fun.
Hack the bits of startup code that assume E2H=0 while setting up
CPTR_EL2 to make them grok the CPTR_EL1 format.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/el2_setup.h | 11
In the VHE hypervisor code, we should be using the remapped VHE
accessors, no ifs, no buts. No need to generate any alternative.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_hyp.h | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/arch
as __always_inline, which it really should be.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/virt.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index b11a1c8c8b36..5f84a87a6a2d 100644
--- a/arch/arm64/include
To initialise the timer access from EL2 when HCR_EL2.E2H is set,
we must make use the CNTHCTL_EL2 formap used is appropriate.
This amounts to shifting the timer/counter enable bits by 10
to the left.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/el2_setup.h | 5 +
1 file changed
If the OVERRIDE_HVHE SW override is set (as a precursor of
the KVM_HVHE capability), do not enable VHE for the kernel
and drop to EL1 as if VHE was either disabled or unavailable.
Further changes will enable VHE at EL2 only, with the kernel
still running at EL1.
Signed-off-by: Marc Zyngier
For VHE-specific hypervisor code, kern_hyp_va() is a NOP.
Actually, it is a whole range of NOPs. It'd be much better if
this code simply didn't exist. Let's just do that.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_mmu.h | 4
1 file changed, 4 insertions(+)
diff --git
On Mon, 10 Oct 2022 06:56:31 +0100,
Ganapatrao Kulkarni wrote:
>
> Hi Marc,
>
> Any review comments on this series?
Not yet. So far, the NV stuff is put on ice until I can source some
actual HW to make the development less painful.
M.
--
Without deviation from the norm, progress is
On Fri, 14 Oct 2022 11:45:32 -0700, Denis Nikitin wrote:
> Kernel build with clang and KCFLAGS=-fprofile-sample-use= fails with:
>
> error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: Unexpected SHT_REL
> section ".rel.llvm.call-graph-profile"
>
> Starting from 13.0.0 llvm can generate SHT_REL
On Thu, 13 Oct 2022 17:42:31 +0100,
Eric Auger wrote:
>
> Hi Eric,
>
> On 10/12/22 20:33, Marc Zyngier wrote:
> > Hi Eric,
> >
> > Before I comment on this patch, a couple of things that need
> > addressing:
> >
> >> "Cc: marc.zyng.
[Reposting this, as it has been almost two weeks since the initial
announcement and we're still at sub-10% of the users having
subscribed to the new list]
Hi all,
As you probably all know, the kvmarm mailing has been hosted on
Columbia's machines for as long as the project existed (over 13
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 while. We may have to find another solution
when (and if) we
On Thu, 13 Oct 2022 14:30:20 +0800, Gavin Shan wrote:
> It's required by vm_userspace_mem_region_add() that memory size
> should be aligned to host page size. However, one guest page is
> provided by memslot_modification_stress_test. It triggers failure
> in the scenario of 64KB-page-size-host and
On Tue, 11 Oct 2022 03:15:36 +0100,
Denis Nikitin wrote:
>
> On Sat, Oct 8, 2022 at 7:22 PM Marc Zyngier wrote:
> >
> > On Thu, 06 Oct 2022 17:28:17 +0100,
> > Denis Nikitin wrote:
> > >
> > > Hi Mark,
> >
> > s/k/c/
> >
> >
Hi Eric,
Before I comment on this patch, a couple of things that need
addressing:
> "Cc: marc.zyng...@arm.com, cd...@linaro.org"
None of these two addresses are valid anymore, and haven't been for
several years.
Please consult the MAINTAINERS file for up-to-date addresses for
current
On Tue, 11 Oct 2022 19:48:39 +0100,
Oliver Upton wrote:
>
> On Tue, Oct 11, 2022 at 05:54:00PM +0100, Marc Zyngier wrote:
> > The kernel has an awfully complicated boot sequence in order to cope
> > with the various EL2 configurations, including those that "enhanced"
EL2 hacker.
Address it by fixing up the boot mode at the point the host gets
deprivileged. is_hyp_mode_available() and co already have a static
branch to deal with this, making it pretty safe.
Reported-by: Vincent Donnefort
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arm.c | 11 +
On Sun, 9 Oct 2022 11:31:31 +0800, Zenghui Yu wrote:
> Commit 98f94ce42ac6 ("KVM: selftests: Move KVM_CREATE_DEVICE_TEST code to
> separate helper") wrongly converted a "real" GIC device creation to
> __kvm_test_create_device() and caused the test failure on my D05 (which
> supports v2 emulation).
On Thu, 06 Oct 2022 17:28:17 +0100,
Denis Nikitin wrote:
>
> Hi Mark,
s/k/c/
>
> This problem currently blocks the PGO roll on the ChromeOS kernel and
> we need some kind of a solution.
I'm sorry, but I don't feel constrained by your internal deadlines. I
have my own...
> Could you please
On Fri, 7 Oct 2022 23:41:49 +, Oliver Upton wrote:
> Continuing with MMU patches to post, a small series fixing some soft
> lockups caused by stage2_apply_range(). Depending on the paging setup,
> we could walk a very large amount of memory before dropping the lock and
> rescheduling.
>
>
On Tue, 04 Oct 2022 22:02:40 +0100,
Oliver Upton wrote:
>
> Hey Paolo,
>
> Just wanted to give you a heads up about a build failure on kvm/next.
> Marc pulled some of the sysreg refactoring updates from core arm64 to
> resolve a conflict, which resulted in:
>
>
On Tue, 04 Oct 2022 05:26:23 +0100,
Gavin Shan wrote:
[...]
> > Why another capability? Just allowing dirty logging to be enabled
> > before we saving the GIC state should be enough, shouldn't it?
> >
>
> The GIC state would be just one case where no vcpu can be used to push
> dirty page
: Standardise naming for ID_AA64MMFR1_EL1 fields
arm64/sysreg: Convert ID_AA64MMFR1_EL1 to automatic generation
Marc Zyngier (12):
Merge branch kvm-arm64/aarch32-raz-idregs into kvmarm-master/next
Merge remote-tracking branch 'arm64/for-next/sysreg' into
kvmarm-master/next
Merge
On Sat, 1 Oct 2022 10:12:45 +0100, Marc Zyngier wrote:
> As announced on the kvmarm list, we're moving the mailing list over
> to kvm...@lists.linux.dev:
>
>
> As you probably all know, the kvmarm mailing has been hosted on
> Columbia's machines for as long as the projec
://subspace.kernel.org/lists.linux.dev.html
Signed-off-by: Marc Zyngier
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 589517372408..f29f27717de4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11124,7 +11124,8 @@ R
Hi all,
As you probably all know, the kvmarm mailing has been hosted on
Columbia's machines for as long as the project existed (over 13
years). After all this time, the university has decided to retire the
list infrastructure and asked us to find a new hosting.
A new mailing list has been
On Thu, 29 Sep 2022 15:32:03 +0100,
Peter Xu wrote:
>
> > If I'm correct, Marc may be talking about SMMU, which is emulated in host
> > instead of QEMU. In this case, the DMA target pages are similar to those
> > pages for vgic/its tables. Both sets of pages are invisible from QEMU.
>
> OK, I'm
On Thu, 29 Sep 2022 12:31:34 +0100,
Gavin Shan wrote:
>
> I've had the following PATCH[v5 3/7] to reuse bitmap for these particular
> cases. KVM_GET_DIRTY_LOG and KVM_CLEAR_DIRTY_LOG ioctls are used to visit
> the bitmap. The new capability is advertised by KVM_CAP_DIRTY_LOG_RING_BITMAP.
> Note
On Thu, 29 Sep 2022 10:50:12 +0100,
Gavin Shan wrote:
>
> Hi Marc and Peter,
>
> On 9/29/22 12:52 AM, Peter Xu wrote:
> > On Wed, Sep 28, 2022 at 09:25:34AM +0100, Marc Zyngier wrote:
> >> On Wed, 28 Sep 2022 00:47:43 +0100,
> >> Gavin Shan wrote:
> >
On Wed, 28 Sep 2022 15:52:00 +0100,
Peter Xu wrote:
>
> On Wed, Sep 28, 2022 at 09:25:34AM +0100, Marc Zyngier wrote:
> > Hi Gavin,
> >
> > On Wed, 28 Sep 2022 00:47:43 +0100,
> > Gavin Shan wrote:
> >
> > > I have rough idea as below. I
On Thu, 29 Sep 2022 12:28:39 +0800, Wei-Lin Chang wrote:
> Fix the comment of __hyp_vgic_restore_state() from saying VEH to VHE,
> also change the underscore to a dash to match the comment
> above __hyp_vgic_save_state().
Applied to next, thanks!
[1/1] KVM: arm64: Fix comment typo in
On Mon, 26 Sep 2022 15:51:14 +0100, Marc Zyngier wrote:
> [Same distribution list as Gavin's dirty-ring on arm64 series]
>
> This is an update on the initial series posted as [0].
>
> As Gavin started posting patches enabling the dirty-ring infrastructure
> on arm64 [1],
On Fri, 19 Aug 2022 16:21:00 +, Oliver Upton wrote:
> Fix the comment to accurately describe the test and recently added
> SYSTEM_SUSPEND test case.
>
> What was once psci_cpu_on_test was renamed and extended to squeeze in a
> test case for PSCI SYSTEM_SUSPEND. Nonetheless, the author of
On Tue, 27 Sep 2022 15:43:10 -0400,
Oliver Upton wrote:
>
> Hi Marc,
>
> On Tue, Sep 27, 2022 at 07:34:22AM -0400, Marc Zyngier wrote:
>
> [...]
>
> > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > > index c9a13e487187..5d05bb92e129
Mingwei,
On Tue, 27 Sep 2022 13:48:52 -0400,
Mingwei Zhang wrote:
>
> >
> > Honestly, I'd refrain from such changes *unless* they enable something
> > else. The current code is well understood by people hacking on it, and
> > although I don't mind revamping it, it has to be for a good reason.
>
Hi Gavin,
On Wed, 28 Sep 2022 00:47:43 +0100,
Gavin Shan wrote:
> I have rough idea as below. It's appreciated if you can comment before I'm
> going a head for the prototype. The overall idea is to introduce another
> dirty ring for KVM (kvm-dirty-ring). It's updated and visited separately
> to
On Tue, 27 Sep 2022 12:02:52 -0400,
Peter Xu wrote:
>
> On Tue, Sep 27, 2022 at 08:54:36AM +0800, Gavin Shan wrote:
> > Enable ring-based dirty memory tracking on arm64 by selecting
> > CONFIG_HAVE_KVM_DIRTY_RING_ACQ_REL and providing the ring buffer's
> > physical page offset
On Mon, 26 Sep 2022 18:21:45 -0400,
Oliver Upton wrote:
>
> Presently stage2_apply_range() works on a batch of memory addressed by a
> stage 2 root table entry for the VM. Depending on the IPA limit of the
> VM and PAGE_SIZE of the host, this could address a massive range of
> memory. Some
+ Sean
On Mon, 26 Sep 2022 20:54:33 -0400,
Gavin Shan wrote:
>
> This series enables the ring-based dirty memory tracking for ARM64.
> The feature has been available and enabled on x86 for a while. It
> is beneficial when the number of dirty pages is small in a checkpointing
> system or live
is softly full on its entrance.
>
> The event is checked and handled in the newly introduced helper
> kvm_dirty_ring_check_request(). With this, kvm_dirty_ring_soft_full()
> becomes a private function.
>
> Suggested-by: Marc Zyngier
> Signed-off-by: Gavin Shan
> ---
On Tue, 27 Sep 2022 01:14:16 -0400,
Oliver Upton wrote:
>
> Hi Mingwei,
>
> On Tue, Sep 27, 2022 at 12:27:15AM +, Mingwei Zhang wrote:
> > Cleanup __get_fault_info() to take out the code that checks HPFAR. The
> > conditions in __get_fault_info() that checks if HPFAR contains a valid IPA
>
architectures (arm64)
Suggested-by: Paolo Bonzini
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/Kconfig | 2 +-
include/uapi/linux/kvm.h | 1 +
virt/kvm/Kconfig | 14 ++
virt/kvm/kvm_main.c | 9 -
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git
Pick KVM_CAP_DIRTY_LOG_RING_ACQ_REL if exposed by the kernel.
Signed-off-by: Marc Zyngier
---
tools/testing/selftests/kvm/dirty_log_test.c | 3 ++-
tools/testing/selftests/kvm/lib/kvm_util.c | 5 -
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm
Since x86 is TSO (give or take), allow it to advertise the new
ACQ_REL version of the dirty ring capability. No other change is
required for it.
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
Now that the kernel can expose to userspace that its dirty ring
management relies on explicit ordering, document these new requirements
for VMMs to do the right thing.
Signed-off-by: Marc Zyngier
---
Documentation/virt/kvm/api.rst | 17 +++--
1 file changed, 15 insertions(+), 2
drift past
the entry invalidation
This is only a partial fix as the userspace side also need upgrading.
Signed-off-by: Marc Zyngier
---
virt/kvm/dirty_ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c
index f4c2a6eb1666
%2Fl7O23aw5aaO@xz-m1.local/T/
[2] https://lore.kernel.org/r/20220922003214.276736-1-gs...@redhat.com
Marc Zyngier (6):
KVM: Use acquire/release semantics when accessing dirty ring GFN state
KVM: Add KVM_CAP_DIRTY_LOG_RING_ACQ_REL capability and config option
KVM: x86: Select
In order to preserve ordering, make sure that the flag accesses
in the dirty log are done using acquire/release accessors.
Signed-off-by: Marc Zyngier
---
tools/testing/selftests/kvm/dirty_log_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tools/testing
On Tue, 20 Sep 2022 12:06:58 -0700, Elliot Berman wrote:
> Ignore kvm-arm.mode if !is_hyp_mode_available(). Specifically, we want
> to avoid switching kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is
> not available. This prevents "Protected KVM" cpu capability being
> reported when Linux is
On Fri, 23 Sep 2022 14:54:47 +0800, Gavin Shan wrote:
> The ITS collection is guranteed to be !NULL when update_affinity_collection()
> is called. So we needn't check ITE's collection with NULL because the
> check has been included to the later one.
>
> Remove the duplicate check in
On Mon, 26 Sep 2022 00:21:08 +0100,
Gavin Shan wrote:
>
> Hi Marc,
>
> On 9/24/22 9:56 PM, Marc Zyngier wrote:
> > Side note: please make sure you always Cc all the KVM/arm64 reviewers
> > when sending patches (now added).
> >
>
> Sure. The
On Thu, 22 Sep 2022 01:32:11 +0100,
Gavin Shan wrote:
>
> This enables the ring-based dirty memory tracking on ARM64. The
> feature is configured by CONFIG_HAVE_KVM_DIRTY_RING, detected and
> enabled by KVM_CAP_DIRTY_LOG_RING. A ring buffer is created on every
> VCPU when the feature is enabled.
On Thu, 22 Sep 2022 01:32:10 +0100,
Gavin Shan wrote:
>
> Not all architectures like ARM64 need to override the function. Move
> its declaration to kvm_dirty_ring.h to avoid the following compiling
> warning on ARM64 when the feature is enabled.
>
>
On Sat, 24 Sep 2022 14:22:32 +0100,
Peter Xu wrote:
>
> On Sat, Sep 24, 2022 at 12:26:53PM +0100, Marc Zyngier wrote:
> > On Sat, 24 Sep 2022 09:51:39 +0100,
> > Marc Zyngier wrote:
> > >
> > > I'm happy to bikeshed, but please spell it out for me. If we
Gavin,
Side note: please make sure you always Cc all the KVM/arm64 reviewers
when sending patches (now added).
On Fri, 23 Sep 2022 07:54:47 +0100,
Gavin Shan wrote:
>
> The ITS collection is guranteed to be !NULL when update_affinity_collection()
> is called. So we needn't check ITE's
On Sat, 24 Sep 2022 09:51:39 +0100,
Marc Zyngier wrote:
>
> On Fri, 23 Sep 2022 19:26:18 +0100,
> Peter Xu wrote:
> >
> > On Fri, Sep 23, 2022 at 03:28:34PM +0100, Marc Zyngier wrote:
> > > On Thu, 22 Sep 2022 22:48:19 +0100,
> > > Peter Xu wrote:
>
On Fri, 23 Sep 2022 19:26:18 +0100,
Peter Xu wrote:
>
> On Fri, Sep 23, 2022 at 03:28:34PM +0100, Marc Zyngier wrote:
> > On Thu, 22 Sep 2022 22:48:19 +0100,
> > Peter Xu wrote:
> > >
> > > On Thu, Sep 22, 2022 at 06:01:29PM +0100, Marc Zyngier wrote:
>
On Fri, 23 Sep 2022 23:46:40 +0100,
Peter Xu wrote:
>
> On Thu, Sep 22, 2022 at 06:01:30PM +0100, Marc Zyngier wrote:
> > Since x86 is TSO (give or take), allow it to advertise the new
> > ORDERED version of the dirty ring capability. No other change is
> > required for
On Thu, 22 Sep 2022 22:38:58 +0100,
Paolo Bonzini wrote:
>
> 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() whe
On Fri, 23 Sep 2022 00:46:58 +0100,
Gavin Shan wrote:
>
> Hi Peter,
>
> On 9/23/22 7:38 AM, Peter Xu wrote:
> > On Thu, Sep 22, 2022 at 06:01:28PM +0100, Marc Zyngier wrote:
> >> The current implementation of the dirty ring has an implicit requirement
> >>
On Thu, 22 Sep 2022 22:48:19 +0100,
Peter Xu wrote:
>
> On Thu, Sep 22, 2022 at 06:01:29PM +0100, Marc Zyngier wrote:
> > In order to differenciate between architectures that require no extra
> > synchronisation when accessing the dirty ring and those who do,
> &
On Thu, 22 Sep 2022 22:38:33 +0100,
Peter Xu wrote:
>
> Marc,
>
> On Thu, Sep 22, 2022 at 06:01:28PM +0100, Marc Zyngier wrote:
> > The current implementation of the dirty ring has an implicit requirement
> > that stores to the dirty ring from userspace must be:
> &
/r/20220922003214.276736-1-gs...@redhat.com
Marc Zyngier (6):
KVM: Use acquire/release semantics when accessing dirty ring GFN state
KVM: Add KVM_CAP_DIRTY_LOG_RING_ORDERED capability and config option
KVM: x86: Select CONFIG_HAVE_KVM_DIRTY_RING_ORDERED
KVM: Document weakly ordered
Pick KVM_CAP_DIRTY_LOG_RING_ORDERED if exposed by the kernel.
Signed-off-by: Marc Zyngier
---
tools/testing/selftests/kvm/dirty_log_test.c | 3 ++-
tools/testing/selftests/kvm/lib/kvm_util.c | 5 -
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm
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
---
tools/testing/selftests/kvm/dirty_log_test.c | 3 ++-
1 file changed, 2 insertions(+), 1
Since x86 is TSO (give or take), allow it to advertise the new
ORDERED version of the dirty ring capability. No other change is
required for it.
Signed-off-by: Marc Zyngier
---
arch/x86/kvm/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
drift past
the entry invalidation
This is only a partial fix as the userspace side also need upgrading.
Signed-off-by: Marc Zyngier
---
virt/kvm/dirty_ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/dirty_ring.c b/virt/kvm/dirty_ring.c
index f4c2a6eb1666
Now that the kernel can expose to userspace that its dirty ring
management relies on explicit ordering, document these new requirements
for VMMs to do the right thing.
Signed-off-by: Marc Zyngier
---
Documentation/virt/kvm/api.rst | 16 +---
1 file changed, 13 insertions(+), 3
most only advertise the ORDERED version.
Suggested-by: Paolo Bonzini
Signed-off-by: Marc Zyngier
---
include/linux/kvm_dirty_ring.h | 6 +++---
include/uapi/linux/kvm.h | 1 +
virt/kvm/Kconfig | 14 ++
virt/kvm/Makefile.kvm | 2 +-
virt/kvm/kvm_main.c
by: Paolo Bonzini
> Signed-off-by: Sean Christopherson
Acked-by: Marc Zyngier
M.
--
Without deviation from the norm, progress is not possible.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Thu, 22 Sep 2022 06:31:45 +0100,
Denis Nikitin wrote:
>
> Kernel build with clang and KCFLAGS=-fprofile-sample-use fails with:
>
> error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: Unexpected SHT_REL
> section ".rel.llvm.call-graph-profile"
>
> Starting from 13.0.0 llvm can generate SHT_REL
On Tue, 20 Sep 2022 19:32:49 +0100,
Mark Brown wrote:
>
> [1 ]
> On Tue, Sep 20, 2022 at 06:52:59PM +0100, Marc Zyngier wrote:
> > On Mon, 15 Aug 2022 23:55:25 +0100,
> > Mark Brown wrote:
>
> > > enum fp_state {
> > > + FP_STATE_TASK, /*
On Tue, 20 Sep 2022 21:21:33 +0100,
Mark Brown wrote:
>
> [1 ]
> On Tue, Sep 20, 2022 at 05:44:01PM +0100, Marc Zyngier wrote:
> > Mark Brown wrote:
>
> > > void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> > > {
> > > BUG_ON(!current-
On Wed, 21 Sep 2022 07:02:50 +0100,
Denis Nikitin wrote:
>
> Adding a few more comments...
>
> On Tue, Sep 20, 2022 at 5:08 PM Denis Nikitin wrote:
> >
> > Hi Mark,
> >
> > Thank you for a quick response.
> >
> > On Tue, Sep 20, 2022 at 2
git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 584a5bab3af3..05cf94013f02 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -4447,7 +4447,6 @@ static long kvm_vm_ioctl_check_extension_generic(struct
> kvm *kvm, long arg)
> #endif
> #ifdef CONFIG_HAV
On Tue, 20 Sep 2022 22:46:21 +0100,
Alexey Kardashevskiy wrote:
>
>
>
> On 21/09/2022 02:08, Marc Zyngier wr
> ote:
> > On Tue, 20 Sep 2022 13:51:43 +0100,
> > Alexey Kardashevskiy wrote:
> >>
> >> When introduced, IRQFD resampling worked on POW
On Tue, 20 Sep 2022 19:09:15 +0100,
Mark Brown wrote:
>
> [1 ]
> On Tue, Sep 20, 2022 at 06:14:13PM +0100, Marc Zyngier wrote:
> > Mark Brown wrote:
>
> > > When we save the state for the floating point registers this can be done
> > > in the form visible t
On Mon, 15 Aug 2022 23:55:27 +0100,
Mark Brown wrote:
>
> Now that we are recording the type of floating point register state we
> are saving when we save it we can use that information when we load to
> decide which register state is required and bring the TIF_SVE state into
> sync with the
On Mon, 15 Aug 2022 23:55:26 +0100,
Mark Brown wrote:
>
> Now that we are explicitly telling the host FP code which register state
> it needs to save we can remove the manipulation of TIF_SVE from the KVM
> code, simplifying it and allowing us to optimise our handling of normal
> tasks. Remove
On Mon, 15 Aug 2022 23:55:25 +0100,
Mark Brown wrote:
>
> In order to avoid needlessly saving and restoring the guest registers KVM
> relies on the host FPSMID code to save the guest registers when we context
> switch away from the guest. This is done by binding the KVM guest state to
> the CPU
On Mon, 15 Aug 2022 23:55:24 +0100,
Mark Brown wrote:
>
> When we save the state for the floating point registers this can be done
> in the form visible through either the FPSIMD V registers or the SVE Z and
> P registers. At present we track which format is currently used based on
> TIF_SVE and
On Mon, 15 Aug 2022 23:55:23 +0100,
Mark Brown wrote:
>
> Since 8383741ab2e773a99 (KVM: arm64: Get rid of host SVE tracking/saving)
> KVM has not tracked the host SVE state, relying on the fact that we
> currently disable SVE whenever we perform a syscall. This may not be true
> in future since
On Tue, 20 Sep 2022 16:39:47 +0100,
Catalin Marinas wrote:
>
> On Mon, Sep 19, 2022 at 07:12:53PM +0100, Marc Zyngier wrote:
> > On Mon, 05 Sep 2022 18:01:55 +0100,
> > Catalin Marinas wrote:
> > > Peter, please let me know if you want to pick this series up togethe
On Tue, 20 Sep 2022 13:51:43 +0100,
Alexey Kardashevskiy wrote:
>
> When introduced, IRQFD resampling worked on POWER8 with XICS. However
> KVM on POWER9 has never implemented it - the compatibility mode code
> ("XICS-on-XIVE") misses the kvm_notify_acked_irq() call and the native
> XIVE mode
Hi Denis,
On Tue, 20 Sep 2022 09:20:05 +0100,
Denis Nikitin wrote:
>
> Kernel build with -fprofile-sample-use raises the following failure:
>
> error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: Unexpected SHT_REL
> section ".rel.llvm.call-graph-profile"
How is this flag provided? I don't see any
On Mon, 05 Sep 2022 18:01:55 +0100,
Catalin Marinas wrote:
>
> On Thu, Sep 01, 2022 at 06:59:23PM +0100, Catalin Marinas wrote:
> > On Thu, Aug 11, 2022 at 03:16:08PM +0800, kernel test robot wrote:
> > > Thank you for the patch! Perhaps something to improve:
> > >
> > > [auto build test
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 1c23f9e627a7b412978b4e852793c5e3c3efc555:
Linux 6.0-rc2 (2022-08-21 17:32:54 -0700)
are available in the Git repository at:
On Mon, 19 Sep 2022 17:38:14 +0100,
Sean Christopherson wrote:
>
> On Mon, Sep 19, 2022, Marc Zyngier wrote:
> > On Tue, 6 Sep 2022 18:09:17 +, Ricardo Koller wrote:
> > > This series adds a new aarch64 selftest for testing stage 2 fault
> > > handling
On Tue, 6 Sep 2022 18:09:17 +, Ricardo Koller wrote:
> This series adds a new aarch64 selftest for testing stage 2 fault handling for
> various combinations of guest accesses (e.g., write, S1PTW), backing sources
> (e.g., anon), and types of faults (e.g., read on hugetlbfs with a hole, write
>
KVM: arm64: selftests: Add a test case for KVM_GUESTDBG_SINGLESTEP
commit: b18e4d4aeb05810ceb2f73d7f72afcd11b41
Cheers,
M.
--
Marc Zyngier
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
On Sat, 17 Sep 2022 02:06:00 +0100,
Reiji Watanabe wrote:
>
> Add a test case for KVM_GUESTDBG_SINGLESTEP to the debug-exceptions test.
> The test enables single-step execution from userspace, and check if the
> exit to userspace occurs for each instruction that is stepped.
> Set the default
On Mon, 19 Sep 2022 00:58:10 +0100,
Gavin Shan wrote:
>
> On 9/18/22 7:00 PM, Marc Zyngier wrote:
> > On Fri, 16 Sep 2022 19:09:52 +0100,
> > Peter Xu wrote:
> >>
> >> On Fri, Sep 16, 2022 at 12:51:31PM +0800, Gavin Shan wrote:
> >>> This a
VCPU is enforced to exit when the request is raised and its
> > dirty ring is softly full on its entrance.
> >
> > Suggested-by: Marc Zyngier
> > Signed-off-by: Gavin Shan
> > ---
> > arch/x86/kvm/x86.c | 5 +++--
> > include/linux/kvm_host.h |
RAZ/WI on 64bit-only system
commit: d5efec7ed826b3b29c6847bf59383d8d07347a4e
[7/7] KVM: selftests: Add test for AArch32 ID registers
commit: 797b84517c190053597e3f7e03ead15da872e04d
Cheers,
M.
--
Marc Zyngier
___
kvmarm mailing list
k
On Wed, 14 Sep 2022 07:13:04 +0100,
Reiji Watanabe wrote:
>
> Hi Marc,
>
> Thank you for the review!
>
> On Sat, Sep 10, 2022 at 3:36 AM Marc Zyngier wrote:
> >
> > On Fri, 09 Sep 2022 05:46:34 +0100,
> > Reiji Watanabe wrote:
> > >
> >
On Wed, 10 Aug 2022 20:30:32 +0100,
Peter Collingbourne wrote:
>
> Certain VMMs such as crosvm have features (e.g. sandboxing) that depend
> on being able to map guest memory as MAP_SHARED. The current restriction
> on sharing MAP_SHARED pages with the guest is preventing the use of
> those
On Sat, 10 Sep 2022 14:43:44 +0100,
Will Deacon wrote:
>
> On Sat, Sep 10, 2022 at 10:09:31AM +0100, Marc Zyngier wrote:
> > On Fri, 09 Sep 2022 18:55:18 +0100,
> > Elliot Berman wrote:
> > >
> > >
> > >
> > > On 9/9/2022 10:28 AM, Catali
201 - 300 of 7764 matches
Mail list logo
