On Tue, May 05, 2020 at 12:16:07PM +0100, Mark Rutland wrote:
> On Tue, May 05, 2020 at 12:12:41PM +0100, Will Deacon wrote:
> > On Sat, May 02, 2020 at 07:03:53PM +0530, Anshuman Khandual wrote:
> > > This adds basic building blocks required for ID_PFR2 CPU register wh
> > interpreted along with ID_PFR0 and ID_PFR1 CPU registers. This is added
> > per ARM DDI 0487F.a specification.
> >
> > Cc: Catalin Marinas
> > Cc: Will Deacon
> > Cc: Marc Zyngier
> > Cc: Mark Rutland
> > Cc: James Morse
> > Cc: Suzuki
Marc Zyngier
Makes sense to me in principle, but I haven't reviewed the code in
detail:
Acked-by: Mark Rutland
Mark.
> ---
> arch/arm64/kvm/hyp/entry.S | 23 +++
> arch/arm64/kvm/hyp/sysreg-sr.c | 17 +++--
> 2 files changed, 26 insertions(+), 14 dele
On Tue, Apr 28, 2020 at 07:14:52AM +0100, Jianyong Wu wrote:
> On 2020/4/24 6:39 PM, Mark Rutland wrote:
> > On Fri, Apr 24, 2020 at 03:50:22AM +0100, Jianyong Wu wrote:
> >> On 2020/4/21 5:57 PM, Mark Rutland wrote:
> >>> On Tue, Apr 21, 2020 at 11:23:00AM +0800,
Hi,
On Sun, Apr 26, 2020 at 06:02:23AM +0100, Jianyong Wu wrote:
>
>
>
>
>
Please fix your mail client to reply in plain text rather than HTML;
it's much more painful than necessary to review and have a conversation
when mails revert to HTML.
It would be very helpful if you could resend
On Fri, Apr 24, 2020 at 03:50:22AM +0100, Jianyong Wu wrote:
> On 2020/4/21 5:57 PM, Mark Rutland wrote:
> > On Tue, Apr 21, 2020 at 11:23:00AM +0800, Jianyong Wu wrote:
> >> diff --git a/virt/kvm/arm/hypercalls.c b/virt/kvm/arm/hypercalls.c
> >> index 550dfa
On Tue, Apr 21, 2020 at 11:23:00AM +0800, Jianyong Wu wrote:
> ptp_kvm modules will get this service through smccc call.
> The service offers real time and counter cycle of host for guest.
> Also let caller determine which cycle of virtual counter or physical counter
> to return.
>
>
d an in-tree module uses
this, so:
Acked-by: Mark Rutland
Mark.
> ---
> drivers/firmware/psci/psci.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
> index 2937d44b5df4..fd3c88f21b6a 100644
> --- a/dri
Hi Fuad,
On Fri, Apr 17, 2020 at 02:57:58PM +0100, Fuad Tabba wrote:
> From: Will Deacon
>
> CONFIG_KVM_ARM_HOST is just a proxy for CONFIG_KVM, so remove it in favour
> of the latter.
>
> Signed-off-by: Will Deacon
As a general thing, when sending patches written by others, you must
append
On Thu, Apr 16, 2020 at 05:59:33PM +1000, Gavin Shan wrote:
> On 4/14/20 9:05 PM, Mark Rutland wrote:
> > On Tue, Apr 14, 2020 at 03:39:56PM +1000, Gavin Shan wrote:
> > > On 4/10/20 10:52 PM, Marc Zyngier wrote:
> > > > On 2020-04-10 09:58, Gavin Shan wrote
Hi Gavin,
On Tue, Apr 14, 2020 at 03:39:56PM +1000, Gavin Shan wrote:
> On 4/10/20 10:52 PM, Marc Zyngier wrote:
> > On 2020-04-10 09:58, Gavin Shan wrote:
> > > In order to fulfil the control flow and convey signals between host
> > > and guest. A IMPDEF system register (SYS_ASYNC_PF_EL1) is
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 this a
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 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
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 have not
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).
nd 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/arm64/kvm/
-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 | 86
ds]
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/asm/cp
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.
&
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
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: Mark
tps://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/arm64/kvm/
imilarly 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/include/a
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
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: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
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
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
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
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/cpufeatur
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: Mark
In 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.
Signed-
. 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.columbia.edu
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
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.
>
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
>
> Th
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
.
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/include/asm
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/arm64/kvm
* 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 entry
KVM: arm/arm64: correct CPSR on exception entry
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 o
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
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 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
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
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
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
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 =
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/git/mark/linux.git/log/?h=kvm/exception-state
Mark
.
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_emulate.h
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/arm64/kvm
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/ptrace.h
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
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
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 trap
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 insertions(+), 8
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
Cc: Alexandru
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 Thierry
Cc: Marc
re'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)
>
> Well Mark Rutland disl
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
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
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/
&g
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,
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 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
>
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
t;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 other mmio state
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: Christoffer D
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
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
t; 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
[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
> >>
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
On Tue, Feb 26, 2019 at 12:33:22PM +, Dave Martin wrote:
> On Tue, Feb 26, 2019 at 12:31:45PM +0000, Mark Rutland wrote:
> > On Tue, Feb 26, 2019 at 12:06:16PM +, Dave Martin wrote:
> > > On Wed, Feb 20, 2019 at 03:23:50PM +, Mark Rutland wrote:
>
> [
On Tue, Feb 26, 2019 at 12:06:16PM +, Dave Martin wrote:
> On Wed, Feb 20, 2019 at 03:23:50PM +0000, Mark Rutland wrote:
> > On Mon, Feb 18, 2019 at 07:52:18PM +, Dave Martin wrote:
> > > kvm_host.h uses DECLARE_BITMAP() to declare the features member of
>
W:
Reviewed-by: Mark Rutland
Mark.
> ---
> arch/arm64/include/asm/kvm_arm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/kvm_arm.h
> b/arch/arm64/include/asm/kvm_arm.h
> index 6f602af5263c..d945a787f36e 100644
> --- a/arch
On Fri, Feb 22, 2019 at 04:23:23PM +0800, Leo Yan wrote:
> Use macro for ID_AA64MMFR1_EL1.VH bits shift instead of 8 directly.
>
> Signed-off-by: Leo Yan
It's always nice to get rid of magic numbers, and this is correct
AFAICT. FWIW:
Reviewed-by: Mark Rutland
Mark.
> ---
&
eter instead of creating a new API.
>
> A new register is not created to pass this parameter via
> SET/GET_ONE_REG interface as just a flag (KVM_ARM_VCPU_PTRAUTH)
> supplied is enough to enable this feature.
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Mark Rutland
> Cc:
On Tue, Feb 19, 2019 at 02:54:28PM +0530, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When pointer authentication is supported, a guest may wish to use it.
> This patch adds the necessary KVM infrastructure for this to work, with
> a semi-lazy context switch of the poi
tored in struct kvm_cpu_context as
> both host and guest can now use this field in a common way.
>
> Signed-off-by: Amit Daniel Kachhap
> Cc: Marc Zyngier
> Cc: Mark Rutland
> Cc: Christoffer Dall
> Cc: kvmarm@lists.cs.columbia.edu
> ---
> arch/arm/include/asm/kvm
Hi,
On Tue, Feb 19, 2019 at 02:54:26PM +0530, Amit Daniel Kachhap wrote:
> From: Mark Rutland
>
> When restoring HCR_EL2 for the host, KVM uses HCR_HOST_VHE_FLAGS, which
> is a constant value. This works today, as the host HCR_EL2 value is
> always the same, but this will
On Mon, Feb 18, 2019 at 07:52:27PM +, Dave Martin wrote:
> -static bool __hyp_text __hyp_switch_fpsimd(struct kvm_vcpu *vcpu)
> +/* Check for an FPSIMD/SVE trap and handle as appropriate */
> +static bool __hyp_text __hyp_handle_fpsimd(struct kvm_vcpu *vcpu)
> {
> - struct
On Mon, Feb 18, 2019 at 07:52:25PM +, Dave Martin wrote:
> Some optional features of the Arm architecture add new system
> registers that are not present in the base architecture.
>
> Where these features are optional for the guest, the visibility of
> these registers may need to depend on
On Mon, Feb 18, 2019 at 07:52:18PM +, Dave Martin wrote:
> kvm_host.h uses DECLARE_BITMAP() to declare the features member of
> struct vcpu_arch, but the corresponding #include for this is
> missing.
>
> This patch adds a suitable #include for . Although
> the header builds without it today,
On Tue, Jan 29, 2019 at 11:54:13AM +, Peter Maydell wrote:
> On Tue, 29 Jan 2019 at 11:46, Mark Rutland wrote:
> > On Tue, Jan 29, 2019 at 11:08:19AM +, Alex Bennée wrote:
> > > The -cpu max enabled a cortex-a57 + whatever extra features we've
> > > enabled in
nd as you would expect the system boots fine with -cpu cortex-a57
>
> On the kernel side it breaks at:
>
> commit 04ca3204fa09f5f55c8f113b0072004a7b364ff4
> Author: Mark Rutland
> Date: Fri Dec 7 18:39:30 2018 +
>
> arm64: enable pointer authentication
&
On Fri, Jan 04, 2019 at 10:33:40AM +0100, Pavel Machek wrote:
> On Fri 2019-01-04 09:21:30, Marc Zyngier wrote:
> > On 03/01/2019 20:29, Pavel Machek wrote:
> > > On Fri 2018-12-07 18:39:25, Kristina Martsenko wrote:
> > >> From: Mark Rutland
> > >
On Wed, Nov 28, 2018 at 02:45:15PM +, Steven Price wrote:
> This series add support for paravirtualized time for Arm64 guests and
> KVM hosts following the specification in Arm's document DEN 0057A:
>
> https://developer.arm.com/docs/den0057/a
>
> It implements support for Live Physical Time
On Wed, Nov 28, 2018 at 02:45:21PM +, Steven Price wrote:
> Provide a method for a guest to derive a paravirtualized counter/timer
> which isn't dependent on the host's counter frequency. This allows a
> guest to be migrated onto a new host which doesn't have the same
> frequency without the
On Wed, Nov 28, 2018 at 02:45:20PM +, Steven Price wrote:
> This provides a mechanism for querying which paravirtualized features
> are available in this hypervisor.
>
> Also add the header file which defines the ABI for the paravirtualized
> clock features we're about to add.
>
>
On Wed, Nov 28, 2018 at 02:45:18PM +, Steven Price wrote:
> SMCCC 1.1 calls may use either HVC or SMC depending on the PSCI
> conduit. Rather than coding this in every call site provide a macro
> which uses the correct instruction. The macro also handles the case
> where no PSCI conduit is
gt; In any case armv8pmu_enable_event_counter is always called with the
> PMU stopped. Starting the PMU with armv8pmu_start results in an isb
> instruction being issued.
>
> Let's remove the unnecessary isb instruction.
>
> Signed-off-by: Andrew Murray
Acked-by: Mark Rutland
... though it
On Sat, Nov 17, 2018 at 10:58:37AM +0800, peng.h...@zte.com.cn wrote:
> >On 16/11/18 00:23, peng.h...@zte.com.cn wrote:
> >>> Hi,
> When virtual machine starts, hang up.
> >>>
> >>> I take it you mean the *guest* hangs? Because it doesn't get a timer
> >>> interrupt?
> >>>
> The kernel
On Tue, Nov 13, 2018 at 05:09:00PM -0600, Kees Cook wrote:
> On Tue, Nov 13, 2018 at 10:17 AM, Kristina Martsenko
> wrote:
> > When the PAC authentication fails, it doesn't actually generate an
> > exception, it just flips a bit in the high-order bits of the pointer,
> > making the pointer
state machine when stepping the guest.
Otherwise, it's not clear to me if we can shadow this correctly within the
kernel.
Thanks,
Mark.
Mark Rutland (2):
kvm/arm: skip MMIO insn after emulation
kvm/arm: consistently advance singlestep when emulating instructions
arch/arm/include/asm
, and it prevents us from being able to fail
an MMIO instruction with a synchronous exception.
Clean this up by only advancing the CPU state *after* the effects of the
instruction are emulated.
Signed-off-by: Mark Rutland
Cc: Alex Bennée
Cc: Christoffer Dall
Cc: Marc Zyngier
Cc: Peter Maydell
---
virt
the HW
singlestep state machine when we skip an instruction. Thus we can rely
on the hardware to generate the singlestep exception for us, and never
need to explicitly check for an active-pending step, nor do we need to
fake a debug exception from the guest.
Signed-off-by: Mark Rutland
Cc: Alex
On Fri, Nov 09, 2018 at 12:56:54PM +, Peter Maydell wrote:
> On 9 November 2018 at 12:49, Mark Rutland wrote:
> > I'm not saying anything about *decisions*. I'm saying that we can make
> > the state consistent by advancing the singlestep state in the same way
> > that HW
On Fri, Nov 09, 2018 at 12:24:41PM +, Alex Bennée wrote:
> Mark Rutland writes:
> > On Thu, Nov 08, 2018 at 02:38:43PM +, Peter Maydell wrote:
> >> On 8 November 2018 at 14:28, Alex Bennée wrote:
> >> >
> >> > Mark Rutland writes:
> >
101 - 200 of 469 matches
Mail list logo
