On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
> > > On Thu, Nov 05, 2020 at 12:56:55PM +, Andre Przywara wrote:
> > That said, I'm
On Thu, Nov 05, 2020 at 02:29:49PM +, Mark Brown wrote:
> On Thu, Nov 05, 2020 at 02:03:22PM +0000, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 01:41:42PM +, Mark Brown wrote:
>
> > > It isn't obvious to me why we don't fall through to trying the SM
On Thu, Nov 05, 2020 at 03:34:01PM +0100, Ard Biesheuvel wrote:
> On Thu, 5 Nov 2020 at 15:30, Mark Rutland wrote:
> > On Thu, Nov 05, 2020 at 03:04:57PM +0100, Ard Biesheuvel wrote:
> > > On Thu, 5 Nov 2020 at 15:03, Mark Rutland wrote:
> >
> > > > That sa
ional impact.
|
| For clarity, use write_to_read_only() rather than ignore_write(). If a trap
| is unexpectedly taken to EL2 in violation of the architecture, this will
| WARN_ONCE() and inject an undef into the guest.
With that:
Reviewed-by: Mark Rutland
Mark.
> Reviewed-by: Reiji Wa
On Tue, Dec 14, 2021 at 05:28:08PM +, Oliver Upton wrote:
> An upcoming change to KVM will context switch the OS Lock status between
> guest/host. Add OSLSR_EL1 to the cpu context and handle guest reads
> using the stored value.
The "context switch" wording is stale here, since later patches e
On Tue, Dec 14, 2021 at 05:28:09PM +, Oliver Upton wrote:
> Allow writes to OSLAR and forward the OSLK bit to OSLSR. Do nothing with
> the value for now.
>
> Reviewed-by: Reiji Watanabe
> Signed-off-by: Oliver Upton
> ---
> arch/arm64/include/asm/sysreg.h | 9
> arch/arm64/kvm/sys
On Wed, Dec 15, 2021 at 01:09:28PM +, Oliver Upton wrote:
> Hi Mark,
>
> On Wed, Dec 15, 2021 at 11:39:58AM +0000, Mark Rutland wrote:
> > Hi Oliver,
> >
> > On Tue, Dec 14, 2021 at 05:28:07PM +, Oliver Upton wrote:
> > > Any valid implementation of
On Fri, Dec 17, 2021 at 12:51:57PM +0100, Nicolas Saenz Julienne wrote:
> Hi All,
Hi,
> arm64's guest entry code does the following:
>
> int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> {
> [...]
>
> guest_enter_irqoff();
>
> ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu);
On Fri, Dec 17, 2021 at 03:15:29PM +0100, Nicolas Saenz Julienne wrote:
> On Fri, 2021-12-17 at 13:21 +0000, Mark Rutland wrote:
> > On Fri, Dec 17, 2021 at 12:51:57PM +0100, Nicolas Saenz Julienne wrote:
> > > Hi All,
> >
> > Hi,
> >
> > >
On Mon, Dec 20, 2021 at 05:10:14PM +0100, Frederic Weisbecker wrote:
> On Fri, Dec 17, 2021 at 01:21:39PM +0000, Mark Rutland wrote:
> > On Fri, Dec 17, 2021 at 12:51:57PM +0100, Nicolas Saenz Julienne wrote:
> > > Hi All,
> >
> > Hi,
> >
> > >
On Fri, Dec 17, 2021 at 04:54:22PM +0100, Paolo Bonzini wrote:
> On 12/17/21 15:38, Mark Rutland wrote:
> > For example kvm_guest_enter_irqoff() calls guest_enter_irq_off() which calls
> > vtime_account_guest_enter(), but kvm_guest_exit_irqoff() doesn't call
> > guest_e
On Tue, Jan 11, 2022 at 12:32:38PM +0100, Nicolas Saenz Julienne wrote:
> Hi Mark,
>
> On Tue, 2022-01-04 at 16:39 +0000, Mark Rutland wrote:
> > On Fri, Dec 17, 2021 at 04:54:22PM +0100, Paolo Bonzini wrote:
> > > On 12/17/21 15:38, Mark Rutland wrote:
> > > >
On Tue, Feb 22, 2022 at 08:51:06AM -0800, Kalesh Singh wrote:
> From: Quentin Perret
>
> The asm entry code in the kernel uses a trick to check if VMAP'd stacks
> have overflowed by aligning them at THREAD_SHIFT * 2 granularity and
> checking the SP's THREAD_SHIFT bit.
>
> Protected KVM will soo
On Tue, Feb 22, 2022 at 08:51:02AM -0800, Kalesh Singh wrote:
> hyp_alloc_private_va_range() can be used to reserve private VA ranges
> in the nVHE hypervisor. Also update __create_hyp_private_mapping()
> to allow specifying an alignment for the private VA mapping.
>
> These will be used to imple
On Tue, Feb 22, 2022 at 08:51:05AM -0800, Kalesh Singh wrote:
> Maps the stack pages in the flexible private VA range and allocates
> guard pages below the stack as unbacked VA space. The stack is aligned
> to twice its size to aid overflow detection (implemented in a subsequent
> patch in the seri
s a number of system register accesses and other barriers
> if we exited for any other reason (such as a trap, for example).
>
> Signed-off-by: Marc Zyngier
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/kvm/arm.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletio
Hi Kalesh,
Sorry for the radiosilence.
I see that in v7 you've dropped the stacktrace bits for now; I'm just
commenting here fot future reference.
On Thu, Mar 31, 2022 at 12:22:05PM -0700, Kalesh Singh wrote:
> Hi everyone,
>
> There has been expressed interest in having hypervisor stack unwind
On Tue, Apr 19, 2022 at 10:37:56AM -0700, Kalesh Singh wrote:
> On Wed, Apr 13, 2022 at 6:59 AM Mark Rutland wrote:
> > I'm fine with the concept of splitting the unwind and logging steps; this is
> > akin to doing:
> >
> &
On Thu, Oct 13, 2022 at 04:09:20PM +0100, Marc Zyngier wrote:
> [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]
FWIW, I didn't subscribe until just now because there weren't clear
instr
On Sun, Jul 07, 2019 at 11:39:46PM -0400, Jon Masters wrote:
> Hi all,
Hi Jon,
[adding Marc and the kvm-arm list]
> TLDR: We think $subject may be a hardware errata and we are
> investigating. I was asked to drop a note to share my initial analysis
> in case others have been experiencing similar
[Adding Marc for real this time]
On Mon, Jul 08, 2019 at 08:16:25AM -0400, Jon Masters wrote:
> On 7/8/19 7:47 AM, Mark Rutland wrote:
> > On Sun, Jul 07, 2019 at 11:39:46PM -0400, Jon Masters wrote:
> >> TLDR: We think $subject may be a hardware errata and we are
> >>
trying to wake up a vcpu.
>
> When overflow handler is called by an NMI, defer the vcpu waking in an
> irq_work queue.
>
> Signed-off-by: Julien Thierry
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> Cc: Will Deacon
> Cc: Mark Rutland
> Cc: James Mors
On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote:
> On Sat, Jul 13, 2019 at 05:53:57PM +0800, Guoheyi wrote:
> > Hi folks,
> >
> > Do it make sense to implement virtual SDEI in qemu? So that we can have the
> > standard way for guest to handle NMI watchdog, RAS events and something else
On Mon, Jul 15, 2019 at 03:26:39PM +0100, James Morse wrote:
> On 15/07/2019 14:48, Mark Rutland wrote:
> > On Mon, Jul 15, 2019 at 02:41:00PM +0100, Dave Martin wrote:
> >> One option (suggested to me by James Morse) would be to allow userspace
> >> to disable in the in
mappings, I-cache maintenance cannot be necessary on VMID rollover for
PIPT or VIPT I-caches.
This patch removes the maintenance on rollover for VIPT and PIPT
I-caches. At the same time, the unnecessary colons are removed from the
asm statement to make it more legible.
Signed-off-by: Mark Rutland
Cc
dbeb ("arm64: KVM: Skip MMIO insn after emulation")
> Signed-off-by: Andrew Jones
Ouch; sorry about this!
I haven't dug too deeply, but from the commit message, the below makes
sense to me. FWIW:
Acked-by: Mark Rutland
Mark.
> ---
> v2: move mmio_needed use closer to o
On Wed, Aug 28, 2019 at 02:38:19PM +0100, Alexandru Elisei wrote:
> When a guest tries to execute code from MMIO memory, KVM injects an
> external abort into that guest. We have now fixed the psci test to not
> fetch instructions from the I/O region, and it's not that often that a
> guest misbehave
On Wed, Aug 28, 2019 at 02:38:29PM +0100, Alexandru Elisei wrote:
> Add a function to disable VHE and another one to re-enable VHE. Both
> functions work under the assumption that the CPU had VHE mode enabled at
> boot.
>
> Minimal support to run with VHE has been added to the TLB invalidate
> fun
On Thu, Aug 29, 2019 at 09:18:35AM +0100, Alexandru Elisei wrote:
> On 8/28/19 3:09 PM, Mark Rutland wrote:
> > On Wed, Aug 28, 2019 at 02:38:19PM +0100, Alexandru Elisei wrote:
> >> + /*
> >> + * AArch64 treats all regions writable at EL0 as PXN.
> > I didn
On Tue, Oct 15, 2019 at 06:48:17PM +0800, Jianyong Wu wrote:
> If arm_smccc_1_1_invoke used in modules, psci_ops.conduit should
> be export.
>
> Signed-off-by: Jianyong Wu
I have a patch queued [1] in the arm64 tree which adds
arm_smccc_1_1_get_conduit() for this purpose.
Please use that, addin
e2_flush_vm() walks all the stage 2 tables, and calls
> __kvm_flush-dcache_pte, which on a system with S2FWD does ... absolutely
> nothing.
>
> We can avoid that whole song and dance, and simply not set TVM when
> creating a VM on a systme that has S2FWB.
Typo: s/systme/system/
he stage 2 tables, and calls
> __kvm_flush-dcache_pte, which on a system with S2FWD does ... absolutely
> nothing.
>
> We can avoid that whole song and dance, and simply not set TVM when
> creating a VM on a system that has S2FWB.
>
> Signed-off-by: Christoffer Dall
> Reviewed-b
On Mon, Oct 28, 2019 at 04:19:55PM +, Marc Zyngier wrote:
> On Mon, 28 Oct 2019 15:12:39 +,
> Alexandru Elisei wrote:
> > On 10/28/19 1:05 PM, Christoffer Dall wrote:
> > > diff --git a/arch/arm64/include/asm/kvm_emulate.h
> > > b/arch/arm64/include/asm/kvm_emulate.h
> > > index d69c1efc6
hether there's going
> to be any conflicts between VHE/NVHE. I'll prototype this and see how
> ugly it is.
>
> > - Or even better, you just ammend the documentation to say that 1165522
> > also covers the newly found A55 one (just like we have for A57/A72)
>
> We
We don't intend to support IMPLEMENATION DEFINED system registers, but
have to trap them (and emulate them as UNDEFINED). These traps aren't
interesting to the system administrator or to the KVM developers, so
let's not bother logging when we do so.
Signed-off-by: Mark Rutland
which isn't all that useful.
Let's ensure that both are consistently printed together and
ratelimited, by refactoring print_sys_reg_instr() so that some callers
can provide it with an arbitrary format string.
Signed-off-by: Mark Rutland
Cc: Alexandru Elisei
Cc: James Morse
Cc: Julien Th
iding logging for IMPLEMENTATION DEFINED registers.
Mark.
Mark Rutland (2):
kvm/arm64: sanely ratelimit sysreg messages
kvm/arm64: don't log IMP DEF sysreg traps
arch/arm64/kvm/sys_regs.c | 20 ++--
arch/arm64/kvm/sys_regs.h | 17 +++--
2 files changed, 29 insert
On Fri, Dec 06, 2019 at 07:35:56PM +, Marc Zyngier wrote:
> On Thu, 05 Dec 2019 18:06:52 +,
> Mark Rutland wrote:
> >
> > We don't intend to support IMPLEMENATION DEFINED system registers, but
> > have to trap them (and emulate them as UNDEFINED). These tr
On Thu, Dec 12, 2019 at 03:44:23PM +0530, Anshuman Khandual wrote:
> +#define ID_ISAR6_JSCVT_SHIFT 0
> +#define ID_ISAR6_DP_SHIFT4
> +#define ID_ISAR6_FHM_SHIFT 8
> +#define ID_ISAR6_SB_SHIFT12
> +#define ID_ISAR6_SPECRES_SHIFT 16
> +#define I
On Thu, Dec 12, 2019 at 03:22:13PM +, Suzuki Kuruppassery Poulose wrote:
> On 12/12/2019 14:46, Mark Rutland wrote:
> > On Thu, Dec 12, 2019 at 03:44:23PM +0530, Anshuman Khandual wrote:
> > > +#define ID_ISAR6_JSCVT_SHIFT 0
> > > +#define ID_ISAR
page C5-426.
Signed-off-by: Mark Rutland
Cc: Alexandru Elisei
Cc: Drew Jones
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Peter Maydell
Cc: Suzuki K Poulose
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
arch/arm/include/asm/kvm_emulate.h | 12
arch/arm64/include/asm/ptr
M DDI 0487E.a page C5-429.
Signed-off-by: Mark Rutland
Cc: Alexandru Elisei
Cc: Drew Jones
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Peter Maydell
Cc: Suzuki K Poulose
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
arch/arm64/include/uapi/asm/ptrace.h | 1 +
arch/arm6
ernel tree.
Signed-off-by: Mark Rutland
Cc: Alexandru Elisei
Cc: Drew Jones
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Peter Maydell
Cc: Suzuki K Poulose
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
arch/arm/include/asm/kvm_emulate.h | 5 +
arch/arm64/include/asm/kvm
all cases, which is
liable to cause issues in future. Given that, and that the patches are fairly
self-contained, I've marked all three patches for stable.
All three patches can be found on my kvm/exception-state branch [1].
Thanks,
Mark.
[1]
https://git.kernel.org/pub/scm/linux/kernel/g
On Fri, Dec 20, 2019 at 03:36:47PM +, Marc Zyngier wrote:
> On 2019-12-20 15:05, Mark Rutland wrote:
> > +static inline unsigned long host_spsr_to_spsr32(unsigned long spsr)
> > +{
> > + const unsigned long overlap = BIT(24) | BIT(21);
> > + unsigned long dit =
Hi Andrew,
On Fri, Dec 20, 2019 at 02:30:07PM +, Andrew Murray wrote:
> This series implements support for allowing KVM guests to use the Arm
> Statistical Profiling Extension (SPE).
>
> It has been tested on a model to ensure that both host and guest can
> simultaneously use SPE with valid d
On Fri, Dec 20, 2019 at 02:30:16PM +, Andrew Murray wrote:
> From: Sudeep Holla
>
> Now that we can save/restore the full SPE controls, we can enable it
> if SPE is setup and ready to use in KVM. It's supported in KVM only if
> all the CPUs in the system supports SPE.
>
> However to support
On Fri, Dec 20, 2019 at 02:30:18PM +, Andrew Murray wrote:
> As we now save/restore the profiler state there is no need to trap
> accesses to the statistical profiling controls. Let's unset the
> _TPMS bit.
>
> Signed-off-by: Andrew Murray
> ---
> arch/arm64/kvm/debug.c | 2 --
> 1 file chan
On Fri, Dec 20, 2019 at 02:30:22PM +, Andrew Murray wrote:
> A side effect of supporting the SPE in guests is that we prevent the
> host from collecting data whilst inside a guest thus creating a black-out
> window. This occurs because instead of emulating the SPE, we share it
> with our guests
Hi Alex,
On Fri, Dec 27, 2019 at 01:01:57PM +, Alexandru Elisei wrote:
> On 12/20/19 3:05 PM, Mark Rutland wrote:
> > When KVM injects an exception into a guest, it generates the PSTATE
> > value from scratch, configuring PSTATE.{M[4:0],DAIF}, and setting all
> &g
On Sun, Dec 29, 2019 at 03:17:40PM +, Marc Zyngier wrote:
> On Fri, 27 Dec 2019 13:01:57 +,
> Alexandru Elisei wrote:
> > On 12/20/19 3:05 PM, Mark Rutland wrote:
> > > + // PSTATE.PAN is unchanged unless overridden by SCTLR_ELx.SPAN
> > > + // See
On Fri, Dec 27, 2019 at 03:42:34PM +, Alexandru Elisei wrote:
> Hi,
>
> On 12/20/19 3:05 PM, Mark Rutland wrote:
> > When KVM injects an exception into a guest, it generates the CPSR value
> > from scratch, configuring CPSR.{M,A,I,T,E}, and setting all other
> >
SPAN polarity; tested with a modified arm64 guest
* Fix DIT preservation on 32-bit hosts
* Add Alex's Reviewed-by to patch 3
Thanks,
Mark.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=kvm/exception-state
Mark Rutland (3):
KVM: arm64: correct PSTATE on exception
M DDI 0487E.a page C5-429.
Signed-off-by: Mark Rutland
Cc: Alexandru Elisei
Cc: Drew Jones
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Peter Maydell
Cc: Suzuki K Poulose
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
arch/arm64/include/uapi/asm/ptrace.h | 1 +
arch/arm6
ernel tree.
Signed-off-by: Mark Rutland
Reviewed-by: Alexandru Elisei
Cc: Drew Jones
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Peter Maydell
Cc: Suzuki K Poulose
Cc: Will Deacon
Cc: sta...@vger.kernel.org
---
arch/arm/include/asm/kvm_emulate.h | 5 +
arch/arm64/i
page C5-426.
Note that this code is used by both arm and arm64, and is intended to
fuction with the SPSR_EL2 and SPSR_HYP layouts.
Signed-off-by: Mark Rutland
Cc: Alexandru Elisei
Cc: Drew Jones
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Peter Maydell
Cc: Suzuki K Poulose
Cc:
On Wed, Jan 08, 2020 at 01:43:21PM +, Mark Rutland wrote:
> Since v1 [2]:
> * Fix host_spsr_to_spsr32() bit preservation
> * Fix SPAN polarity; tested with a modified arm64 guest
> * Fix DIT preservation on 32-bit hosts
> * Add Alex's Reviewed-by to patch 3
>
&g
On Wed, Jan 08, 2020 at 02:41:04PM +, Alexandru Elisei wrote:
> On 1/8/20 1:43 PM, Mark Rutland wrote:
> > When KVM injects an exception into a guest, it generates the CPSR value
> > from scratch, configuring CPSR.{M,A,I,T,E}, and setting all other
> > bits to zero.
>
Hi Andrew,
On Thu, Jan 09, 2020 at 05:25:12PM +, Andrew Murray wrote:
> On Mon, Dec 23, 2019 at 12:10:42PM +, Andrew Murray wrote:
> > On Mon, Dec 23, 2019 at 12:05:12PM +, Marc Zyngier wrote:
> > > On 2019-12-23 11:56, Andrew Murray wrote:
> > > > My original concern in the cover lett
used. The
32-bit stub for kvm_vcpu_run_vhe() is left as-is.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: James Morse
Cc: Julien Thierry
Cc: Marc Zyngier
Cc: Suzuki K Poulose
Cc: Will Deacon
Cc: kvmarm@lists.cs.columbi
o use this as part of the entry.S -> entry-common.c
conversion, and there are other places in arm64 that could potentially
use this today.
Thanks,
Mark.
Mark Rutland (2):
arm64: cpufeature: add cpus_have_final_cap()
arm64: kvm: hyp: use cpus_have_final_cap()
arch/arm64/include/asm/cpuf
un in hyp context.
This patch migrate the KVM hyp code to cpus_have_final_cap(), avoiding
this redundant code generation, and making it possible to detect if we
accidentally invoke this code too early. In the latter case, the BUG()
in cpus_have_final_cap() will cause a hyp panic.
Signed-off-by:
n hyp context, BUG() will result in a hyp panic, but the specific BUG()
instance will not be identified in the usual way.
Comments are added to the various cpus_have_*_cap() helpers to describe
the constraints on when they can be used. For clarity cpus_have_cap() is
moved above the other helpers.
Si
On Mon, Feb 10, 2020 at 04:37:53PM +, Suzuki Kuruppassery Poulose wrote:
> On 10/02/2020 12:27, Mark Rutland wrote:
> > When cpus_have_const_cap() was originally introduced it was intended to
> > be safe in hyp context, where it is not safe to access the cpu_hwcaps
> > a
On Tue, Feb 11, 2020 at 05:48:13PM +, Marc Zyngier wrote:
> From: Jintack Lim
>
> Support injecting exceptions and performing exception returns to and
> from virtual EL2. This must be done entirely in software except when
> taking an exception from vEL0 to vEL2 when the virtual HCR_EL2.{E2H,
On Tue, Feb 11, 2020 at 05:48:16PM +, Marc Zyngier wrote:
> Some EL2 system registers immediately affect the current execution
> of the system, so we need to use their respective EL1 counterparts.
> For this we need to define a mapping between the two.
>
> These helpers will get used in subseq
On Tue, Feb 11, 2020 at 05:48:19PM +, Marc Zyngier wrote:
> SPSR_EL2 needs special attention when running nested on ARMv8.3:
>
> If taking an exception while running at vEL2 (actually EL1), the
> HW will update the SPSR_EL1 register with the EL1 mode. We need
> to track this in order to make s
On Tue, Feb 11, 2020 at 05:48:35PM +, Marc Zyngier wrote:
> From: Christoffer Dall
>
> So far we were flushing almost the entire universe whenever a VM would
> load/unload the SCTLR_EL1 and the two versions of that register had
> different MMU enabled settings. This turned out to be so slow
On Tue, Feb 11, 2020 at 05:48:36PM +, Marc Zyngier wrote:
> As there is a number of features that we either can't support,
> or don't want to support right away with NV, let's add some
> basic filtering so that we don't advertize silly things to the
> EL2 guest.
>
> Signed-off-by: Marc Zyngier
Similarly the helpers are updated to use
system_capabilities_finalized() consistently, and this is made
__always_inline as required by its new callers.
Signed-off-by: Mark Rutland
Reviewed-by: Marc Zyngier
Reviewed-by: Suzuki K Poulose
Cc: Catalin Marinas
Cc: Will Deacon
---
arch/arm64/incl
i
[1]
https://lore.kernel.org/linux-arm-kernel/20200210122708.38826-1-mark.rutl...@arm.com/
Thanks,
Mark.
Mark Rutland (2):
arm64: cpufeature: add cpus_have_final_cap()
arm64: kvm: hyp: use cpus_have_final_cap()
arch/arm64/include/asm/cpufeature.h | 58 ++---
arch/
un in hyp context.
This patch migrate the KVM hyp code to cpus_have_final_cap(), avoiding
this redundant code generation, and making it possible to detect if we
accidentally invoke this code too early. In the latter case, the BUG()
in cpus_have_final_cap() will cause a hyp panic.
Signed-off-by:
On Mon, Jan 27, 2020 at 11:44:28AM +, Andrew Murray wrote:
> We currently expose the PMU version of the host to the guest via
> emulation of the DFR0_EL1 and AA64DFR0_EL1 debug feature registers.
> However many of the features offered beyond PMUv3 for 8.1 are not
> supported in KVM. Examples of
On Fri, Feb 28, 2020 at 04:51:22PM +, Mark Rutland wrote:
> On Mon, Jan 27, 2020 at 11:44:28AM +, Andrew Murray wrote:
> > We currently expose the PMU version of the host to the guest via
> > emulation of the DFR0_EL1 and AA64DFR0_EL1 debug feature registers.
> >
emains) 64-bits.
Signed-off-by: Andrew Murray
Reviewed-by: Suzuki K Poulose
[Mark: fix ID field names, compare with 8.5 value]
Signed-off-by: Mark Rutland
---
arch/arm64/include/asm/perf_event.h | 3 +-
arch/arm64/include/asm/sysreg.h | 4 ++
arch/arm64/kernel/perf_event.c
fields]
Signed-off-by: Mark Rutland
---
arch/arm64/include/asm/cpufeature.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 92ef9539874a..186f4e19207e 100644
--- a/arch/arm64/include/a
NED PMU,
and our cap is below 0xF, we can treat these fields as unsigned when
applying the cap.
Signed-off-by: Andrew Murray
Reviewed-by: Suzuki K Poulose
[Mark: make field names consistent, use perfmon cap]
Signed-off-by: Mark Rutland
---
arch/arm64/include/asm/sysreg.h | 6 ++
arch/
This is a respin of Andrew Murray's series to enable support for 64-bit
counters as introduced in ARMv8.5.
I've given this a spin on (ARMv8.2) hardware, to test that there are no
regressions, but I have not had the chance to test in an ARMv8.5 model (which I
beleive Andrew had previously tested).
On Mon, Mar 02, 2020 at 06:17:49PM +, Mark Rutland wrote:
> This is a respin of Andrew Murray's series to enable support for 64-bit
> counters as introduced in ARMv8.5.
>
> I've given this a spin on (ARMv8.2) hardware, to test that there are no
> regressions, but I h
On Thu, Mar 12, 2020 at 11:40:02AM +0200, Rémi Denis-Courmont wrote:
> From: Remi Denis-Courmont
>
> This datum is not referenced from .idmap.text: it does not need to be
> mapped in idmap. Lets move it to .rodata as it is never written to after
> early boot of the primary CPU.
> (Maybe .data.ro_
it was already converted to mov_q
> by 95b3f74bec203804658e17f86fe20755bb8abcb9.
>
> Signed-off-by: Remi Denis-Courmont
FWIW:
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/kernel/cpu-reset.S | 2 +-
> arch/arm64/kernel/hyp-stub.S| 2 +-
> arch/arm64/kernel
On Tue, Mar 17, 2020 at 11:14:31PM +, Will Deacon wrote:
> On Mon, Mar 02, 2020 at 06:17:49PM +0000, Mark Rutland wrote:
> > This is a respin of Andrew Murray's series to enable support for 64-bit
> > counters as introduced in ARMv8.5.
> >
> > I've given
Peter, it looks like this series is blocked on the below now; what would you
prefer out of:
(a) Take this as is, and look add adding additional validation on top.
(b) Add some flag to indicate a PMU driver supports config3, and have the core
code check that, but leave the existing fields as-i
On Tue, Jan 03, 2023 at 02:27:59PM +, Alexandru Elisei wrote:
> Hi,
>
> Gentle ping regarding this.
Hi Alexandru,
Sorry for the delay; things were a bit hectic at the end of last year, and this
is still on my queue of things to look at.
> Thanks,
> Alex
>
> On Wed, Nov 23, 2022 at 11:40:45
On Wed, Jan 04, 2023 at 11:04:41AM +, Alexandru Elisei wrote:
> Hi Mark,
>
> Thank you for having a look!
>
> On Wed, Jan 04, 2023 at 09:19:25AM +0000, Mark Rutland wrote:
> > On Tue, Jan 03, 2023 at 02:27:59PM +, Alexandru Elisei wrote:
> > > Hi,
> >
On Fri, Feb 05, 2016 at 10:23:53AM +0100, Andrew Jones wrote:
> On Thu, Feb 04, 2016 at 06:51:06PM +, Marc Zyngier wrote:
> What would the benefit of defining a "socket"?
>
> That's a good lead in for my next question. While I don't believe
> there needs to be any relationship between socket
On Mon, Feb 08, 2016 at 04:04:46PM +, Catalin Marinas wrote:
> On Wed, Feb 03, 2016 at 06:00:16PM +, Marc Zyngier wrote:
> > Having both VHE and non-VHE capable CPUs in the same system
> > is likely to be a recipe for disaster.
> >
> > If the boot CPU has VHE, but a secondary is not, we wo
cating a multiple of sizeof(unsigned long),
as we do elsewhere in the vgic code.
Signed-off-by: Mark Rutland
Cc: Marc Zyngier
Cc: Christoffer Dall
---
virt/kvm/arm/vgic.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 7a2f449.
On Wed, Mar 02, 2016 at 06:07:21PM +0300, Yury Norov wrote:
> ubuntu@arm64:~$ uname -a
> Linux arm64 4.5.0-rc5-00019-g3e330b9 #76 SMP PREEMPT Wed Mar 2 17:46:57 MSK
> 2016 aarch64 aarch64 aarch64 GNU/Linux
>
> ubuntu@arm64:~$ cat /proc/cpuinfo
> processor : 0-47
> BogoMIPS: 200.00
>
On Mon, Mar 14, 2016 at 04:53:03PM +, Suzuki K Poulose wrote:
> kvm_pmd_huge doesn't have any dependency on the page table
> where the pmd lives (i.e, hyp vs. stage2). So, rename it to
> huge_pmd() to make it explicit.
>
> kvm_p.d_* wrappers will be used for helpers which differ
> across hyp v
On Wed, Apr 20, 2016 at 07:08:39AM -0700, Ashok Kumar wrote:
> For guests with NUMA configuration, Node ID needs to
> be recorded in the respective affinity byte of MPIDR_EL1.
The MPIDR.Aff* fields are effectively arbitrary, and do not encode NUMA
topology information. They may describe some level
he current code doesn't respect this, directly writing the new
> entry and only then invalidating TLBs. Let's fix it up.
>
> Signed-off-by: Marc Zyngier
FWIW, this looks correct to me.
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm/kvm/mmu.c | 17 +++-
value in a consistent fashion.
Existing open-coded extractions in core arm64 code are moved over to the
new helper. KVM code is left as-is for the moment.
Signed-off-by: Mark Rutland
Tested-by: Huang Shijie
Cc: Catalin Marinas
Cc: Dave P Martin
Cc: James Morse
Cc: Marc Zyngier
Cc: Will
result is only used in another boolean expression.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Dave P Martin
Cc: Huang Shijie
Cc: James Morse
Cc: Marc Zyngier
Cc: Will Deacon
---
arch/arm64/kernel/entry.S | 2 +-
arch/arm64/mm/fault.c | 13 -
2 files changed, 9
Now that we have a helper to extract the EC from an ESR_ELx value, make
use of this in the arm64 KVM code for simplicity and consistency. There
should be no functional changes as a result of this patch.
Signed-off-by: Mark Rutland
Cc: Catalin Marinas
Cc: Christoffer Dall
Cc: Dave P Martin
Cc
s,
Mark.
[1]
https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/entry-deasm
Mark Rutland (3):
arm64: add macro to extract ESR_ELx.EC
arm64/kvm: use ESR_ELx_EC to extract EC
arm64: kill ESR_LNX_EXEC
arch/arm64/include/asm/esr.h | 1 +
arch/arm64/include/asm/kvm_emu
On Thu, Jun 02, 2016 at 07:21:47PM +0100, Will Deacon wrote:
> On Tue, May 31, 2016 at 05:53:11PM +0100, Catalin Marinas wrote:
> > On Tue, May 31, 2016 at 12:33:00PM +0100, Mark Rutland wrote:
> > > Mark Rutland (3):
> > > arm64: add macro to extract ESR_ELx.EC
> &
On Mon, Jun 06, 2016 at 05:22:49PM +0100, Alex Bennée wrote:
> Andrew Jones writes:
> > +#define MPIDR_LEVEL_SHIFT(level) \
> > + (((1 << level) >> 1) << 3)
> > +#define MPIDR_AFFINITY_LEVEL(mpidr, level) \
> > + ((mpidr >> MPIDR_LEVEL_SHIFT(level)) & 0xff)
>
> Doesn't Aff3 break this little
On Mon, Jun 13, 2016 at 03:00:48PM +0100, Marc Zyngier wrote:
> There should be no reason for mapping the HYP text read/write.
>
> As such, let's have a new set of flags (PAGE_HYP_EXEC) that allows
> execution, but makes the page as read-only, and update the two call
> sites that deal with mapping
Hi,
Nit: typo in subject "excutable" is missing an 'e'.
Mark.
On Mon, Jun 13, 2016 at 03:00:49PM +0100, Marc Zyngier wrote:
> Structures that can be generally written to don't have any requirement
> to be executable (quite the opposite). This includes the kvm and vcpu
> structures, as well as th
401 - 500 of 517 matches
Mail list logo
