On 2020-02-17 14:54, Tomasz Nowicki wrote:
This small series contains two fixes which were found while testing
Marc's ARM NV patch set, where we are going to have at most 4 timers
and the two are purely emulated.
What are these patches fixing? the NV series? or mainline?
Thanks,
M.
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: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
We still need to schedule software timer if the line goes down
(should_fire == 0 && should_fire != ctx->irq.level) and
there is still some time to expire again.
Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a
timer_map")
Signed-off-by: Tomasz Nowicki
---
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
This small series contains two fixes which were found while testing
Marc's ARM NV patch set, where we are going to have at most 4 timers
and the two are purely emulated.
First patch cancels hrtimer when the timer should fire and there is no
change in irq line level which suppresses timer
The emulated timer needs no further software timer if the timer should fire
now and there is no change in irq line level: (should_fire == 1 &&
should_fire == ctx->irq.level). In that case htimer should be simply
canceled.
Fixes: bee038a674875 ("KVM: arm/arm64: Rework the timer code to use a
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
Hi Mark,
Congratulations, you will now be CC'd on all the subsequent postings
of this series! Yes, I'm that nice! ;-)
On 2020-02-17 14:56, Mark Rutland wrote:
On Tue, Feb 11, 2020 at 05:48:16PM +, Marc Zyngier wrote:
Some EL2 system registers immediately affect the current execution
of
On 15/02/2020 10:28 am, Marc Zyngier wrote:
On Fri, 14 Feb 2020 22:01:01 +,
Robin Murphy wrote:
Hi Robin,
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
Sean Christopherson writes:
> On Fri, Feb 07, 2020 at 07:53:34PM -0500, Peter Xu wrote:
>> On Fri, Feb 07, 2020 at 04:42:33PM -0800, Sean Christopherson wrote:
>> > On Fri, Feb 07, 2020 at 07:18:32PM -0500, Peter Xu wrote:
>> > > On Fri, Feb 07, 2020 at 11:45:32AM -0800, Sean Christopherson
Sean Christopherson writes:
> +Vitaly for HyperV
>
> On Thu, Feb 06, 2020 at 04:41:06PM -0500, Peter Xu wrote:
>> On Thu, Feb 06, 2020 at 01:21:20PM -0800, Sean Christopherson wrote:
>> > On Thu, Feb 06, 2020 at 03:02:00PM -0500, Peter Xu wrote:
>> > > But that matters to this patch because if
Hi,
I guess the device hasn't been tested with Linux. This is what I'm getting when
trying to boot a Linux guest using the command:
$ ./lkvm run -c4 -m4096 -k /path/to/kernel -d /path/to/disk -p root="/dev/vda2"
-F
flash.img
[ 0.659167] physmap-flash 200.flash: physmap platform flash
On 17.02.2020 19:00, Marc Zyngier wrote:
--
On 2020-02-17 14:54, Tomasz Nowicki wrote:
This small series contains two fixes which were found while testing
Marc's ARM NV patch set, where we are going to have at most 4 timers
and
Hi Marc,
On 2020/2/14 22:57, Marc Zyngier wrote:
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
Hi Marc,
On 2020/2/14 22:57, Marc Zyngier wrote:
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
Hi Marc,
On 2020/2/14 22:57, Marc Zyngier wrote:
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
Hi Marc,
On 2020/2/14 22:57, Marc Zyngier wrote:
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
On 2020/2/14 22:57, Marc Zyngier wrote:
Tell KVM that we support v4.1. Nothing uses this information so far.
Signed-off-by: Marc Zyngier
Reviewed-by: Zenghui Yu
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
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 2020-02-17 12:52, Mark Rutland wrote:
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
Hi Mark,
On 2020-02-10 11:47, Mark Rutland wrote:
With VHE, running a vCPU always requires the sequence:
1. kvm_arm_vhe_guest_enter();
2. kvm_vcpu_run_vhe();
3. kvm_arm_vhe_guest_exit()
... and as we invoke this from the shared arm/arm64 KVM code, 32-bit
arm
has to provide stubs for all
On 2020-02-10 12:27, Mark Rutland wrote:
Across arm64 we use cpus_have_const_cap() to check for a capability
without a runtime check. Prior to capabilities being finalized
cpus_have_const_cap() falls back to a runtime check of the cpu_hwcaps
array. In some cases we know that code is never
23 matches
Mail list logo
