In an effort to clarify and simplify the annotation of assembly functions
in the kernel new macros have been introduced. These replace ENTRY and
ENDPROC with separate annotations for standard C callable functions,
data and code with different calling conventions. Update the more
straightforward
On Fri, Feb 14, 2020 at 02:19:18PM +, Marc Zyngier wrote:
> On 2020-02-14 11:40, Mark Brown wrote:
> > On Thu, Feb 13, 2020 at 09:36:56PM +, Marc Zyngier wrote:
> > > On 2020-02-13 15:38, Mark Brown wrote:
> > > > .align 11
> > > > -ENTRY(__bp_harden_hyp_vecs_start)
> > > >
On Fri, Feb 14, 2020 at 02:19:18PM +, Marc Zyngier wrote:
> > > > .align 11
> > > > -ENTRY(__bp_harden_hyp_vecs_start)
> > > > +SYM_CODE_START_NOALIGN(__bp_harden_hyp_vecs)
> > > > +SYM_INNER_LABEL(__bp_harden_hyp_vecs_start, SYM_L_GLOBAL)
> > > Why isn't SYM_CODE_START_NOALIGN
On Fri, 14 Feb 2020 at 04:23, Anshuman Khandual
wrote:
>
>
>
> On 01/28/2020 06:09 PM, Anshuman Khandual wrote:
> > This series is primarily motivated from an adhoc list from Mark Rutland
> > during our ID_ISAR6 discussion [1]. Besides, it also includes a patch
> > which does macro replacement
One of the new features of GICv4.1 is to allow virtual SGIs to be
directly signaled to a VPE. For that, the ITS has grown a new
64kB page containing only a single register that is used to
signal a SGI to a given VPE.
Add a second mapping covering this new 64kB range, and take this
opportunity to
Tell KVM that we support v4.1. Nothing uses this information so far.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 9 -
drivers/irqchip/irq-gic-v3.c | 2 ++
include/linux/irqchip/arm-gic-common.h | 2 ++
3 files changed, 12 insertions(+), 1
As for VLPIs, there is a number of configuration bits that cannot
be directly communicated through the normal irqchip API, and we
have to use our good old friend set_vcpu_affinity.
This is used to configure group and priority for a given vSGI.
Signed-off-by: Marc Zyngier
---
This (now shorter) series expands the existing GICv4 support to deal
with the new GICv4.1 architecture, which comes with a set of major
improvements compared to v4.0:
- One architectural doorbell per vcpu, instead of one doorbell per VLPI
- Doorbell entirely managed by the HW, with an "at most
Since GICv4.1 has the capability to inject 16 SGIs into each VPE,
and that I'm keen not to invent too many specific interfaces to
manupulate these interrupts, let's pretend that each of these SGIs
is an actual Linux interrupt.
For that matter, let's introduce a minimal irqchip and irqdomain
setup
Implement mask/unmask for virtual SGIs by calling into the
configuration helper.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index
On Fri, 7 Feb 2020 17:34:20 +
Alexandru Elisei wrote:
Hi Alex,
many thanks for having a look!
> I'm going to do my best to review your patch :) I'll do it in chunks, because
> it's
> pretty large, and definitely not trivial.
OK, replying here, and having it mostly fixed already.
Will
The GICv4.1 architecture gives the hypervisor the option to let
the guest choose whether it wants the good old SGIs with an
active state, or the new, HW-based ones that do not have one.
For this, plumb the configuration of SGIs into the GICv3 MMIO
handling, present the GICD_TYPER2.nASSGIcap to
Allocate per-VPE SGIs when initializing the GIC-specific part of the
VPE data structure.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v4.c | 68 +-
include/linux/irqchip/arm-gic-v4.h | 2 +
2 files changed, 69 insertions(+), 1 deletion(-)
diff
The vgic-state debugfs file could do with showing the pending state
of the HW-backed SGIs. Plug it into the low-level code.
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgic/vgic-debug.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git
In order to let a guest buy in the new, active-less SGIs, we
need to be able to switch between the two modes.
Handle this by stopping all guest activity, transfer the state
from one mode to the other, and resume the guest.
Signed-off-by: Marc Zyngier
---
include/kvm/arm_vgic.h | 3 ++
Each time a Group-enable bit gets flipped, the state of these bits
needs to be forwarded to the hardware. This is a pretty heavy
handed operation, requiring all vcpus to reload their GICv4
configuration. It is thus implemented as a new request type.
Of course, we only support Group-1 for now...
Add the SGI configuration entry point for KVM to use.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v4.c | 13 +
include/linux/irqchip/arm-gic-v4.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
Most of the GICv3 emulation code that deals with SGIs now has to be
aware of the v4.1 capabilities in order to benefit from it.
Add such support, keyed on the interrupt having the hw flag set and
being a SGI.
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgic/vgic-mmio-v3.c | 15 +-
In order to hide some of the differences between v4.0 and v4.1, move
the doorbell management out of the KVM code, and into the GICv4-specific
layer. This allows the calling code to ask for the doorbell when blocking,
and otherwise to leave the doorbell permanently disabled.
This matches the v4.1
Now that we have HW-accelerated SGIs being delivered to VPEs, it
becomes required to map the VPEs on all ITSs instead of relying
on the lazy approach that we would use when using the ITS-list
mechanism.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-gic-v3-its.c | 39
As GICv4.1 understands the life cycle of doorbells (instead of
just randomly firing them at the most inconvenient time), just
enable them at irq_request time, and be done with it.
Signed-off-by: Marc Zyngier
---
virt/kvm/arm/vgic/vgic-v4.c | 9 -
1 file changed, 8 insertions(+), 1
It is at times necessary to prevent a guest from being able to sample
certain events if multiple CPUs share resources such as a cache level.
In this case, it would be interesting if the VMM could simply prevent
certain events from being counted instead of simply not exposing a PMU.
Given that
Add a small blurb describing how the event filtering API gets used.
Signed-off-by: Marc Zyngier
---
Documentation/virt/kvm/devices/vcpu.txt | 28 +
1 file changed, 28 insertions(+)
diff --git a/Documentation/virt/kvm/devices/vcpu.txt
It can be desirable to expose a PMU to a guest, and yet not want the
guest to be able to count some of the implemented events (because this
would give information on shared resources, for example.
For this, let's extend the PMUv3 device API, and offer a way to setup a
bitmap of the allowed events
Hi Marc,
On 2020-02-14 6:36 pm, Marc Zyngier wrote:
[...]
@@ -585,6 +585,14 @@ static void kvm_pmu_create_perf_event(struct kvm_vcpu
*vcpu, u64 select_idx)
pmc->idx != ARMV8_PMU_CYCLE_IDX)
return;
+ /*
+* If we have a filter in place and that the event
Hi Drew,
On 2020/2/13 17:32, Andrew Jones wrote:
Let's bail out of the wait loop if we see the expected state
to save over six seconds of run time. Make sure we wait a bit
before reading the registers and double check again after,
though, to somewhat mitigate the chance of seeing the expected
On Sat, Feb 15, 2020 at 11:41:46AM +0800, Zenghui Yu wrote:
> Hi Drew,
>
> On 2020/2/13 17:32, Andrew Jones wrote:
> > Let's bail out of the wait loop if we see the expected state
> > to save over six seconds of run time. Make sure we wait a bit
> > before reading the registers and double check
On 2020-02-14 11:40, Mark Brown wrote:
On Thu, Feb 13, 2020 at 09:36:56PM +, Marc Zyngier wrote:
On 2020-02-13 15:38, Mark Brown wrote:
> -ENTRY(__kvm_call_hyp)
> +SYM_FUNC_START(__kvm_call_hyp)
I'm not convinced by this particular change. _kvm_call_hyp is called
directly from
C, and
To allow the direct injection of SGIs into a guest, the GICv4.1
architecture has to sacrifice the Active state so that SGIs look
a lot like LPIs (they are injected by the same mechanism).
In order not to break existing software, the architecture gives
offers guests OSs the choice: SGIs with or
The GICv4.1 ITS has yet another new command (VSGI) which allows
a VPE-targeted SGI to be configured (or have its pending state
cleared). Add support for this command and plumb it into the
activate irqdomain callback so that it is ready to be used.
Signed-off-by: Marc Zyngier
---
To implement the get/set_irqchip_state callbacks (limited to the
PENDING state), we have to use a particular set of hacks:
- Reading the pending state is done by using a pair of new redistributor
registers (GICR_VSGIR, GICR_VSGIPENDR), which allow the 16 interrupts
state to be retrieved.
-
In a system that is only sparsly populated with CPUs, we can end-up with
redistributors structures that are not initialized. Let's make sure we
don't try and access those when iterating over them (in this case when
checking we have a L2 VPE table).
Fixes: 4e6437f12d6e ("irqchip/gic-v4.1: Ensure
Just like for VLPIs, it is beneficial to avoid trapping on WFI when the
vcpu is using the GICv4.1 SGIs.
Add such a check to vcpu_clear_wfx_traps().
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_emulate.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Hi,
On 2/14/20 1:47 PM, Andre Przywara wrote:
> On Fri, 7 Feb 2020 17:34:20 +
> Alexandru Elisei wrote:
>
> Hi Alex,
>
> many thanks for having a look!
>
>> I'm going to do my best to review your patch :) I'll do it in chunks,
>> because it's
>> pretty large, and definitely not trivial.
>
On Mon, 25 Nov 2019 10:55:01 +
Marc Zyngier wrote:
Hi Marc,
dug this out of my inbox, sorry for warming this up.
> On 2019-11-22 18:51, Andre Przywara wrote:
> > Hi Marc,
> >
> > this is still a bit rough, and only briefly tested, but I wanted to
> > hear your opinion on the general
On Thu, Feb 13, 2020 at 09:36:56PM +, Marc Zyngier wrote:
> On 2020-02-13 15:38, Mark Brown wrote:
> > -ENTRY(__kvm_call_hyp)
> > +SYM_FUNC_START(__kvm_call_hyp)
> I'm not convinced by this particular change. _kvm_call_hyp is called
> directly from
> C, and behaves almost like a normal
36 matches
Mail list logo
