On 2020-11-19 16:25, David Brazdil wrote:
The arm64 kernel also supports packing of relocation data using the
RELR
format. Implement a parser of RELR data and fixup the relocations using
the same infra as RELA relocs.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/va_layout.c | 41
On 2020-11-19 16:25, David Brazdil wrote:
KVM nVHE code runs under a different VA mapping than the kernel, hence
so far it relied only on PC-relative addressing to avoid accidentally
using a relocated kernel VA from a constant pool (see hyp_symbol_addr).
So as to reduce the possibility of a
On 2020-11-24 12:43, Maulik Shah wrote:
Hi Marc,
On 11/24/2020 4:45 PM, Marc Zyngier wrote:
On 2020-11-24 10:37, Maulik Shah wrote:
[...]
static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev,
unsigned function,
unsigned group)
{
struct
On 2020-11-24 10:37, Maulik Shah wrote:
[...]
static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev,
unsigned function,
unsigned group)
{
struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
+ struct
On 2020-11-24 05:20, Jianyong Wu wrote:
Hi Marc,
[...]
> +/* ptp_kvm counter type ID */
> +#define ARM_PTP_VIRT_COUNTER 0
> +#define ARM_PTP_PHY_COUNTER 1
> +#define ARM_PTP_NONE_COUNTER 2
The architecture definitely doesn't
Jianyong,
On 2020-11-24 05:37, Jianyong Wu wrote:
Hi Marc,
[...]
> +
arm_smccc_1_1_invoke(ARM_SMCCC_VENDOR_HYP_KVM_PTP_FU
NC_ID,
> + ARM_PTP_NONE_COUNTER, _res);
I really don't see the need to use a non-architectural counter ID.
Using the virtual counter ID
On 2020-11-24 00:01, Douglas Anderson wrote:
We have a problem if we use gpio-keys and configure wakeups such that
we only want one edge to wake us up. AKA:
wakeup-event-action = ;
wakeup-source;
Specifically we end up with a phantom interrupt that blocks suspend if
the line was already
On 2020-11-24 08:10, Shenming Lu wrote:
On 2020/11/23 17:27, Marc Zyngier wrote:
On 2020-11-23 06:54, Shenming Lu wrote:
From: Zenghui Yu
When setting the forwarding path of a VLPI, it is more consistent to
I'm not sure it is more consistent. It is a *new* behaviour, because
it only
On 2020-11-24 07:40, Shenming Lu wrote:
On 2020/11/23 17:18, Marc Zyngier wrote:
On 2020-11-23 06:54, Shenming Lu wrote:
After pausing all vCPUs and devices capable of interrupting, in order
^
See my comment below about this.
to save the information of all interrupts
On 2020-11-24 07:38, Shenming Lu wrote:
On 2020/11/23 17:01, Marc Zyngier wrote:
On 2020-11-23 06:54, Shenming Lu wrote:
From: Zenghui Yu
Up to now, the irq_get_irqchip_state() callback of its_irq_chip
leaves unimplemented since there is no architectural way to get
the VLPI's pending state
Hi David,
On Mon, 16 Nov 2020 20:42:54 +,
David Brazdil wrote:
>
> As we progress towards being able to keep guest state private to the
> host running nVHE hypervisor, this series allows the hypervisor to
> install itself on newly booted CPUs before the host is allowed to run
> on them.
>
On Mon, 16 Nov 2020 20:43:02 +,
David Brazdil wrote:
>
> Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
> EL3 and propagate the result back to EL1. This is done in preparation
> for validating host SMCs in KVM nVHE protected mode.
>
> The implementation assumes that
On Mon, 16 Nov 2020 20:43:06 +,
David Brazdil wrote:
>
> Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
> with the version used by the host's PSCI driver and the function IDs it
> was configured with. If the SMC function ID matches one of the
> configured PSCI calls
On Mon, 16 Nov 2020 20:43:17 +,
David Brazdil wrote:
>
> While protected nVHE KVM is installed, start trapping all host SMCs.
> By default, these are simply forwarded to EL3, but PSCI SMCs are
> validated first.
>
> Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of HCR
>
On Mon, 16 Nov 2020 20:43:15 +,
David Brazdil wrote:
>
> Add an early parameter that allows users to opt into protected KVM mode
> when using the nVHE hypervisor. In this mode, guest state will be kept
> private from the host. This will primarily involve enabling stage-2
> address
Adding Lorenzo and Sudeep to this one in particular, as there is a bit
of a corner case below.
On Mon, 16 Nov 2020 20:43:14 +,
David Brazdil wrote:
>
> Add a handler of CPU_SUSPEND host PSCI SMCs. The SMC can either enter
> a sleep state indistinguishable from a WFI or a deeper sleep state
On Mon, 16 Nov 2020 20:43:13 +,
David Brazdil wrote:
>
> Add a handler of the CPU_ON PSCI call from host. When invoked, it looks
> up the logical CPU ID corresponding to the provided MPIDR and populates
> the state struct of the target CPU with the provided x0, pc. It then
> calls CPU_ON
sm/el2_setup.h
> @@ -0,0 +1,185 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier
> + */
> +
> +#ifndef __ARM_KVM_INIT_H__
> +#define __ARM_KVM_INIT_H__
> +
> +#ifndef __ASSEMBLY__
> +#error Assembly-only
On Mon, 16 Nov 2020 20:43:01 +,
David Brazdil wrote:
>
> Small refactor so that nVHE's handle_trap uses a switch on the Exception
> Class value of ESR_EL2 in preparation for adding a handler of SMC32/64.
nit: SMC32 seems to be a leftover from the previous version.
>
> Signed-off-by: David
On Mon, 16 Nov 2020 20:43:00 +,
David Brazdil wrote:
>
> Once we start initializing KVM on newly booted cores before the rest of
> the kernel, parameters to __do_hyp_init will need to be provided by EL2
> rather than EL1. At that point it will not be possible to pass its four
> arguments
On 2020-11-23 14:03, Jerome Brunet wrote:
On Fri 20 Nov 2020 at 10:42, Marc Zyngier wrote:
The HDMI driver request clocks early, but never disable them, leaving
the clocks on even when the driver is removed.
Fix it by slightly refactoring the clock code, and register a devm
action
On Mon, 16 Nov 2020 20:42:58 +,
David Brazdil wrote:
>
> KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
> preparation for initializing MAIR_EL2 before MAIR_EL1, move the constant
> into a shared header file. Since it is used for EL1 and EL2, rename to
> MAIR_ELx_SET.
>
>
On Mon, 16 Nov 2020 20:42:56 +,
David Brazdil wrote:
>
> Function IDs used by PSCI are configurable for v0.1 via DT/APCI. If the
> host is using PSCI v0.1, KVM's host PSCI proxy needs to use the same IDs.
> Expose the array holding the information with a read-only accessor.
>
>
On Mon, 16 Nov 2020 20:42:54 +,
David Brazdil wrote:
>
> As we progress towards being able to keep guest state private to the
> host running nVHE hypervisor, this series allows the hypervisor to
> install itself on newly booted CPUs before the host is allowed to run
> on them.
>
> All
Hi John,
On 2020-11-23 12:54, John Garry wrote:
Hi Marc,
Right, but if the driver is removed then the interrupts should be
deallocated, right?
When removing the driver we just call free_irq(), which removes the
handler and disables the interrupt.
But about the irq_desc, this is created
On 2020-11-23 10:44, Marc Zyngier wrote:
On 2020-11-11 06:22, Jianyong Wu wrote:
ptp_kvm will get this service through SMCC call.
The service offers wall time and cycle count of host to guest.
The caller must specify whether they want the host cycle count
or the difference between host cycle
On 2020-11-11 06:22, Jianyong Wu wrote:
PTP_KVM implementation depends on hypercall using SMCCC. So we
introduce a new SMCCC service ID. This doc explains how does the
ID define and how does PTP_KVM works on arm/arm64.
Signed-off-by: Jianyong Wu
---
Documentation/virt/kvm/api.rst | 9
On 2020-11-11 06:22, Jianyong Wu wrote:
Currently, there is no mechanism to keep time sync between guest and
host
in arm/arm64 virtualization environment. Time in guest will drift
compared
with host after boot up as they may both use third party time sources
to correct their time respectively.
On 2020-11-11 06:22, Jianyong Wu wrote:
ptp_kvm will get this service through SMCC call.
The service offers wall time and cycle count of host to guest.
The caller must specify whether they want the host cycle count
or the difference between host cycle count and cntvoff.
Signed-off-by: Jianyong
On 2020-11-23 06:54, Shenming Lu wrote:
From: Zenghui Yu
When setting the forwarding path of a VLPI, it is more consistent to
I'm not sure it is more consistent. It is a *new* behaviour, because it
only
matters for migration, which has been so far unsupported.
also transfer the pending
On 2020-11-23 06:54, Shenming Lu wrote:
After pausing all vCPUs and devices capable of interrupting, in order
^
See my comment below about this.
to save the information of all interrupts, besides flushing the pending
states in kvm’s vgic, we also try to flush the
On 2020-11-23 06:54, Shenming Lu wrote:
From: Zenghui Yu
Up to now, the irq_get_irqchip_state() callback of its_irq_chip
leaves unimplemented since there is no architectural way to get
the VLPI's pending state before GICv4.1. Yeah, there has one in
v4.1 for VLPIs.
With GICv4.1, after
Hi Thomas,
Here a couple of patches from the irqchip department: a fix for a typo
leading to incorrect trigger information being used on the Exiu
driver, and another for save/restore with the GICv3 ITS.
Please pull,
M.
The following changes since commit
On Fri, 20 Nov 2020 14:17:12 +,
Thomas Gleixner wrote:
Thomas,
> So with the pre 5.8 scheduler IPI we had scheduler_ipi() doing wonderful
> things
[... tons of interesting and helpful stuff ...]
> Hope that clarifies it.
It does in a way, as it maps some of the low-level x86 things onto
On Fri, 20 Nov 2020 11:52:09 +,
John Garry wrote:
>
> Hi Thomas,
>
> >> Just mentioning a couple of things here, which could be a clue to what
> >> is going on:
> >> - the device is behind mbigen secondary irq controller
> >> - the flow in the LLDD is to allocate all 128 interrupts during
On Tue, 17 Nov 2020 11:20:15 +0800, Chen Baozi wrote:
> Since fwspec->param_count of ACPI node is two, the index of IRQ type
> in fwspec->param[] should be 1 rather than 2.
Applied to irq/irqchip-next, thanks!
[1/1] irqchip/exiu: Fix the index of fwspec for IRQ type
commit:
On Sat, 7 Nov 2020 10:42:26 +, Xu Qiang wrote:
> On my platform, ITS_FLAGS_SAVE_SUSPEND_STATE is not set,thus do nothing
> in its suspend and resuse function.On the other hand,firmware stores
> GITS_CTRL,GITS_CBASER,GITS_CWRITER and GITS_BASER in the suspend,
> and restores these registers in
On 2020-11-20 23:53, Nick Desaulniers wrote:
On Fri, Nov 20, 2020 at 3:30 PM Ard Biesheuvel wrote:
On Fri, 20 Nov 2020 at 21:19, Nick Desaulniers
wrote:
>
> On Fri, Nov 20, 2020 at 2:30 AM Ard Biesheuvel wrote:
> >
> > On Thu, 19 Nov 2020 at 00:42, Nick Desaulniers
wrote:
> > >
> > >
of the above is that it has
an adverse effect on the entropy pool.
Acked-by: Marc Zyngier
M.
--
Jazz is not dead. It just smells funny...
On 2020-11-20 10:54, Guillaume Tucker wrote:
On 20/11/2020 09:42, Marc Zyngier wrote:
Instead of moving meson_dw_hdmi_init() around which breaks existing
platform, let's enable the clock meson_dw_hdmi_init() depends on.
This means we don't have to worry about this clock being enabled
On 2020-11-20 09:26, Neil Armstrong wrote:
On 19/11/2020 19:35, Marc Zyngier wrote:
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 7f8eea494147..52af8ba94311 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson
On 2020-11-20 09:50, Steven Price wrote:
On 19/11/2020 19:11, Marc Zyngier wrote:
Does this sound reasonable?
I'll clean up the set_pte_at() change and post a v6 later today.
Please hold on. I still haven't reviewed your v5, nor have I had time
to read your reply to my comments on v4
On 2020-11-20 09:09, Vladimir Murzin wrote:
On 11/20/20 8:56 AM, Marc Zyngier wrote:
On 2020-11-20 04:30, Neeraj Upadhyay wrote:
Hi,
For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
AA64PFR0[47:44] field is not set, and AMU does not get enabled for
them.
Can you please
nsure that clocks are enabled before
touching the TOP registers")
Reported-by: Guillaume Tucker
Tested-by: Guillaume Tucker
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
.
Marc Zyngier (2):
drm/meson: dw-hdmi: Disable clocks on driver teardown
drm/meson: dw-hdmi: Enable the iahb clock early enough
drivers/gpu/drm/meson/meson_dw_hdmi.c | 51 ++-
1 file changed, 35 insertions(+), 16 deletions(-)
--
2.28.0
The HDMI driver request clocks early, but never disable them, leaving
the clocks on even when the driver is removed.
Fix it by slightly refactoring the clock code, and register a devm
action that will eventually disable/unprepare the enabled clocks.
Signed-off-by: Marc Zyngier
---
drivers/gpu
[+ Mark who has been hacking in the same area lately]
Hi Thomas,
On 2020-11-03 20:32, Thomas Gleixner wrote:
On Sun, Nov 01 2020 at 13:14, Marc Zyngier wrote:
Vincent recently reported [1] that 5.10-rc1 showed a significant
regression when running "perf bench sched pipe"
On 2020-11-20 04:30, Neeraj Upadhyay wrote:
Hi,
For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
AA64PFR0[47:44] field is not set, and AMU does not get enabled for
them.
Can you please provide support for these CPUs in cpufeature.c?
If that was the case, that'd be an
On 2020-11-19 18:42, Andrew Jones wrote:
On Thu, Nov 19, 2020 at 03:45:40PM +, Peter Maydell wrote:
On Thu, 19 Nov 2020 at 15:39, Steven Price
wrote:
> This series adds support for Arm's Memory Tagging Extension (MTE) to
> KVM, allowing KVM guests to make use of it. This builds on the
On 2020-11-19 18:13, Jerome Brunet wrote:
On Thu 19 Nov 2020 at 19:04, Guillaume Tucker
wrote:
Hi Marc,
On 19/11/2020 11:58, Marc Zyngier wrote:
On 2020-11-19 10:26, Neil Armstrong wrote:
On 19/11/2020 11:20, Marc Zyngier wrote:
On 2020-11-19 08:50, Guillaume Tucker wrote:
Please see
On 2020-11-19 10:26, Neil Armstrong wrote:
On 19/11/2020 11:20, Marc Zyngier wrote:
On 2020-11-19 08:50, Guillaume Tucker wrote:
Please see the automated bisection report below about some kernel
errors on meson-gxbb-p200.
Reports aren't automatically sent to the public while we're
trialing
On 2020-11-19 10:26, Neil Armstrong wrote:
On 19/11/2020 11:20, Marc Zyngier wrote:
On 2020-11-19 08:50, Guillaume Tucker wrote:
Please see the automated bisection report below about some kernel
errors on meson-gxbb-p200.
Reports aren't automatically sent to the public while we're
trialing
On 2020-11-19 08:50, Guillaume Tucker wrote:
Please see the automated bisection report below about some kernel
errors on meson-gxbb-p200.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org, however this one
looks valid.
The bisection
On 2020-11-16 16:24, Gregory CLEMENT wrote:
This patch extends irqchip driver for oceleot to be used with an other
vcoreiii base platform: Luton.
Based on a larger patch from Lars Povlsen
Signed-off-by: Gregory CLEMENT
---
drivers/irqchip/irq-mscc-ocelot.c | 145
Hi Chen,
On top of Bjorn's comments:
On 2020-11-17 13:42, Chen Baozi wrote:
Some PCIe designs require software to do extra acknowledgements for
legacy INTx interrupts. If the driver is written only for device tree,
things are simple. In that case, a new driver can be written under
Naresh,
On 2020-11-18 06:11, Naresh Kamboju wrote:
On Tue, 13 Oct 2020 at 11:09, Naresh Kamboju
wrote:
On stable rc 5.8.15 the following kernel warning was noticed once
while boot and this is hard to reproduce.
This is now reproduciable on arm64 NXP ls2088 device
How reproducible? On
Hi Steven,
On 2020-10-26 15:57, Steven Price wrote:
Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
for a VM. This exposes the feature to the guest and automatically tags
memory pages touched by the VM as PG_mte_tagged (and clears the tags
storage) to ensure that the guest
Hi Steven,
These patches unfortunately don't apply to -rc4 anymore, as we repainted
quite a bit while working on fixes. I'd be grateful if you could rebase
them.
A few other things though:
On 2020-10-26 15:57, Steven Price wrote:
Define the new system registers that MTE introduces and
On Tue, 17 Nov 2020 23:16:29 +0800, Zenghui Yu wrote:
> It was recently reported that if GICR_TYPER is accessed before the RD base
> address is set, we'll suffer from the unset @rdreg dereferencing. Oops...
>
> gpa_t last_rdist_typer = rdreg->base + GICR_TYPER +
>
On 2020-11-17 09:59, Auger Eric wrote:
Hi Marc,
On 11/17/20 9:49 AM, Marc Zyngier wrote:
Hi Zenghui,
On 2020-11-16 14:57, Zenghui Yu wrote:
Hi Marc,
On 2020/11/16 22:10, Marc Zyngier wrote:
My take is that only if the "[Re]Distributor base address" is
specified
in the system
Hi Neil,
On 2020-11-17 08:49, Neil Armstrong wrote:
Hi Marc,
On 16/11/2020 21:07, Marc Zyngier wrote:
Hi all,
Having recently moved over to a top-of-the-tree u-boot on one of my
VIM3L systems in order to benefit from unrelated improvements
(automatic PCIe detection, EFI...), I faced
Hi Zenghui,
On 2020-11-16 14:57, Zenghui Yu wrote:
Hi Marc,
On 2020/11/16 22:10, Marc Zyngier wrote:
My take is that only if the "[Re]Distributor base address" is
specified
in the system memory map, will the user-provided
kvm_device_attr.offset
make sense. And we can then handle
.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_drv.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 8b9c8dd788c4..324fa489f1c4 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
in the connectors being torn down.
Call drm_atomic_helper_shutdown() and component_unbind_all() to safely
tear the module down.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_drv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/meson
display. Total dedication.
Feedback much appreciated.
M.
Marc Zyngier (4):
drm/meson: Free RDMA resources after tearing down DRM
drm/meson: Unbind all connectors on module removal
drm/meson: dw-hdmi: Register a callback to disable the regulator
drm/meson: dw-hdmi: Ensure that clocks
are not always
enabled by the time we enter meson_dw_hdmi_init(). Moving this call
*after* dw_hdmi_probe() ensures that the clocks are enabled.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
is still enabled on release.
In order to address this, register a callback that will deal with
the disabling when the driver is unbound, solving the problem.
Signed-off-by: Marc Zyngier
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu
On 2020-11-16 13:09, Zenghui Yu wrote:
Hi Marc,
On 2020/11/16 1:04, Marc Zyngier wrote:
Hi Zenghui,
On 2020-11-13 14:28, Zenghui Yu wrote:
It's expected that users will access registers in the redistributor
*if*
the RD has been initialized properly. Unfortunately userspace can be
bogus
On 2020-11-16 11:49, David Brazdil wrote:
> #ifdef CONFIG_CPU_PM
>DEFINE(CPU_CTX_SP, offsetof(struct cpu_suspend_ctx, sp));
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> index 1697d25756e9..f999a35b2c8c 100644
> ---
On 2020-11-13 14:02, Thomas Gleixner wrote:
irq_cpustat_t is exactly the same as the asm-generic one. Define
ack_bad_irq so the generic header does not emit the generic version of
it.
Signed-off-by: Thomas Gleixner
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Marc Zyngier
Cc: linux-arm-ker
Hi Zenghui,
On 2020-11-13 14:28, Zenghui Yu wrote:
It's expected that users will access registers in the redistributor
*if*
the RD has been initialized properly. Unfortunately userspace can be
bogus
enough to access registers before setting the RD base address, and KVM
implicitly allows it
On 2020-11-14 03:37, Alexey Kardashevskiy wrote:
What is the easiest way to get irq-hierarchical hardware?
I have a bunch of powerpc boxes (no good) but also a raspberry pi,
a bunch of 32/64bit orange pi's, an "armada" arm box,
thinkpads - is any of this good for the task?
If your HW doesn't
calling one dispose per one mapping. Except (at least) PPC/pseries
which needs https://lkml.org/lkml/2020/10/27/259
Cc: Cédric Le Goater
Cc: Marc Zyngier
Cc: Michael Ellerman
Cc: Qian Cai
Cc: Rob Herring
Cc: Frederic Barrat
Cc: Michal Suchánek
Cc: Thomas Gleixner
Signed-off-by: Alexey
On 2020-11-12 21:34, Thomas Gleixner wrote:
On Thu, Nov 12 2020 at 20:15, Thomas Gleixner wrote:
The recent changes to store the MSI irqdomain pointer in struct device
missed that Intel DMAR does not register virtual function devices.
Due to
that a VF device gets the plain PCI-MSI domain
On 2020-11-12 14:40, Lorenzo Pieralisi wrote:
On Thu, Nov 12, 2020 at 09:36:10AM +, Marc Zyngier wrote:
Hi Lorenzo,
On 2020-11-11 16:28, Lorenzo Pieralisi wrote:
> GIC CPU interfaces versions predating GIC v4.1 were not built to
> accommodate vINTID within the vSGI range; as re
accordingly.
Signed-off-by: Lorenzo Pieralisi
Cc: Will Deacon
Cc: Catalin Marinas
Cc: Marc Zyngier
---
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/kernel/cpufeature.c | 10 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/cpucaps.h
b/arch
ise that it actually works.
In the meantime, to the meat of the change:
Check the GIC CPUIF version through the arm64 capabilities
infrastructure and disable vSGIs if a CPUIF version < 4.1 is
detected to prevent using vSGIs on systems where they may
misbehave.
Signed-off-by: Lorenzo Pier
Hi David,
On 2020-11-09 11:32, David Brazdil wrote:
As we progress towards being able to keep guest state private to the
host running nVHE hypervisor, this series allows the hypervisor to
install itself on newly booted CPUs before the host is allowed to run
on them.
All functionality described
On 2020-11-11 14:09, Linus Walleij wrote:
On Tue, Nov 10, 2020 at 3:19 PM Marc Zyngier wrote:
On 2020-11-10 14:02, Linus Walleij wrote:
>> Probably nothing more than setting the callback to
>> irq_chip_set_affinity_parent,
>
> Hm, is this something all GPIO irqchips u
On 2020-11-11 13:45, David Brazdil wrote:
On Wed, Nov 11, 2020 at 01:29:29PM +, Marc Zyngier wrote:
On 2020-11-11 13:03, David Brazdil wrote:
> > > +/*
> > > + * nVHE copy of data structures tracking available CPU cores.
> > > + * Only entries for CPUs t
On 2020-11-09 11:32, David Brazdil wrote:
Add a host-initialized constant to KVM nVHE hyp code for converting
between EL2 linear map virtual addresses and physical addresses.
Also add `__hyp_pa` macro that performs the conversion.
Signed-off-by: David Brazdil
---
arch/arm64/kvm/arm.c
On 2020-11-11 13:03, David Brazdil wrote:
> +/*
> + * nVHE copy of data structures tracking available CPU cores.
> + * Only entries for CPUs that were online at KVM init are populated.
> + * Other CPUs should not be allowed to boot because their features were
> + * not checked against the
On 2020-11-09 11:32, David Brazdil wrote:
Add a handler of PSCI SMCs in nVHE hyp code. The handler is initialized
with the version used by the host's PSCI driver and the function IDs it
was configured with. If the SMC function ID matches one of the
configured PSCI calls (for v0.1) or falls into
On 2020-11-11 12:32, David Brazdil wrote:
> +
> + cpu_base_array = kern_hyp_va(_arm_hyp_percpu_base[0]);
There is no guarantee that this will not generate a PC relative
addressing, resulting in kern_hyp_va() being applied twice.
Consider using hyp_symbol_addr() instead, which always does the
On 2020-11-09 11:32, David Brazdil wrote:
Add handler of host SMCs in KVM nVHE trap handler. Forward all SMCs to
EL3 and propagate the result back to EL1. This is done in preparation
for validating host SMCs in KVM nVHE protected mode.
Signed-off-by: David Brazdil
---
On 2020-11-09 11:32, David Brazdil wrote:
When nVHE hyp starts interception host's PSCI CPU_ON SMCs, it will need
to install KVM on the newly booted CPU before returning to the host.
Add
an entry point which expects the same kvm_nvhe_init_params struct as
the
__kvm_hyp_init HVC in the CPU_ON
On 2020-11-10 18:22, Thierry Reding wrote:
On Tue, Nov 10, 2020 at 06:08:31PM +, Marc Zyngier wrote:
On 2020-11-10 17:36, Thierry Reding wrote:
> On Tue, Oct 13, 2020 at 10:58:51AM +0100, Marc Zyngier wrote:
> > Add the description of CPU PMUs for both the Denver and A57 clusters,
On 2020-11-10 17:36, Thierry Reding wrote:
On Tue, Oct 13, 2020 at 10:58:51AM +0100, Marc Zyngier wrote:
Add the description of CPU PMUs for both the Denver and A57 clusters,
which enables the perf subsystem.
Signed-off-by: Marc Zyngier
[...]
+ pmu_denver
On 2020-11-09 11:32, David Brazdil wrote:
When the a CPU is booted in EL2, the kernel checks for VHE support and
initializes the CPU core accordingly. For nVHE it also installs the
stub
vectors and drops down to EL1.
Once KVM gains the ability to boot cores without going through the
kernel
On 2020-11-09 11:32, David Brazdil wrote:
Once we start initializing KVM on newly booted cores before the rest of
the kernel, parameters to __do_hyp_init will need to be provided by EL2
rather than EL1. At that point it will not be possible to pass its four
arguments directly because PSCI_CPU_ON
On 2020-11-09 11:32, David Brazdil wrote:
When KVM starts validating host's PSCI requests, it will need to map
MPIDR back to the CPU ID. To this end, copy cpu_logical_map into nVHE
hyp memory when KVM is initialized.
Only copy the information for CPUs that are online at the point of KVM
On 2020-11-09 11:32, David Brazdil wrote:
When compiling with __KVM_NVHE_HYPERVISOR__ redefine per_cpu_offset()
to
__hyp_per_cpu_offset() which looks up the base of the nVHE per-CPU
region of the given cpu and computes its offset from the
.hyp.data..percpu section.
This enables use of
On 2020-11-09 11:32, David Brazdil wrote:
KVM currently initializes MAIR_EL2 to the value of MAIR_EL1. In
preparation for initializing MAIR_EL2 before MAIR_EL1, move the
constant
into a shared header file.
Signed-off-by: David Brazdil
---
arch/arm64/include/asm/memory.h | 13 +
On 2020-11-09 11:32, David Brazdil wrote:
The version of PSCI that the kernel should use to communicate with
firmware is typically obtained from probing PSCI_VERSION. However, that
doesn't work for PSCI v0.1 where the host gets the information from
DT/ACPI, or if PSCI is not supported / was
On 2020-11-10 14:02, Linus Walleij wrote:
On Thu, Nov 5, 2020 at 4:43 PM Marc Zyngier wrote:
On 2020-11-05 15:23, Daniel Palmer wrote:
> On Thu, 5 Nov 2020 at 21:08, Marc Zyngier wrote:
> > I see that msc313_gpio_irqchip doesn't have a
>> .irq_set_affinity callback. Is this
On 2020-11-10 10:15, Christoph Hellwig wrote:
On Mon, Nov 09, 2020 at 11:32:09AM +, David Brazdil wrote:
As we progress towards being able to keep guest state private to the
host running nVHE hypervisor, this series allows the hypervisor to
install itself on newly booted CPUs before the
On 2020-11-09 11:32, David Brazdil wrote:
While protected nVHE KVM is installed, start trapping all host SMCs.
By default, these are simply forwarded to EL3, but PSCI SMCs are
validated first.
Create new constant HCR_HOST_NVHE_PROTECTED_FLAGS with the new set of
HCR
flags to use while the
On 2020-11-10 01:35, Kefeng Wang wrote:
On 2020/11/10 1:23, Mark Brown wrote:
On Mon, Nov 09, 2020 at 07:58:16PM +0800, Kefeng Wang wrote:
syscon_config.name in of_syscon_register is allocated using
kasprintf,
which should be freed when it is not used after regmap_set_name, fix
the following
On 2020-11-09 16:59, Quentin Perret wrote:
Hey David,
On Monday 09 Nov 2020 at 11:32:26 (+), David Brazdil wrote:
Add helper macro for computing the PA of a kernel symbol in nVHE hyp
code. This will be useful for computing the PA of a PSCI CPU_ON entry
point.
Signed-off-by: David Brazdil
On 2020-11-09 03:05, xuqiang (M) wrote:
在 2020/11/8 0:54, Marc Zyngier 写道:
[dropping Jason, whose email address has been bouncing for weeks now]
On 2020-11-07 10:42, Xu Qiang wrote:
On my platform, ITS_FLAGS_SAVE_SUSPEND_STATE is not set,thus do
nothing
Which platform?
Hisi Ascend platform
701 - 800 of 9391 matches
Mail list logo
