On 05/02/18 18:04, Julien Grall wrote:
On 12/01/18 12:07, Christoffer Dall wrote:
@@ -436,37 +446,31 @@ static void __hyp_text __hyp_call_panic_nvhe(u64
spsr, u64 elr, u64 par,
read_sysreg(hpfar_el2), par, vcpu);
}
-static void __hyp_text __hyp_call_panic_vhe(u64 spsr, u64
Hi Christoffer,
On 12/01/18 12:07, Christoffer Dall wrote:
VHE actually doesn't rely on clearing the VTTBR when returning to the
host kernel, and that is the current key mechanism of hyp_panic to
figure out how to attempt to return to a state good enough to print a
panic statement.
Therefore,
Hi Christoffer,
On 12/01/18 12:07, Christoffer Dall wrote:
diff --git a/arch/arm64/include/asm/kvm_host.h
b/arch/arm64/include/asm/kvm_host.h
index 048f5db120f3..6ce0b428a4db 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -350,10 +350,15 @@ int
Hi Dave,
On Fri, Jan 26, 2018 at 05:28:49PM +, Dave Martin wrote:
> New feature KVM_ARM_VCPU_SVE:
>
> * enables exposure of SVE to the guest
>
> * enables visibility of / access to KVM_REG_ARM_SVE_*() via KVM reg
>ioctls. The main purposes of this are a) is to allow userspace to hide
Hi Christoffer,
On 12/01/18 12:07, Christoffer Dall wrote:
Moving the call to vcpu_load() in kvm_arch_vcpu_ioctl_run() to after
we've called kvm_vcpu_first_run_init() simplifies some of the vgic and
there is also no need to do vcpu_load() for things such as handling the
immediate_exit flag.
Hi Christoffer,
On 12.01.2018 13:07, Christoffer Dall wrote:
We can finally get completely rid of any calls to the VGICv3
save/restore functions when the AP lists are empty on VHE systems. This
requires carefully factoring out trap configuration from saving and
restoring state, and carefully
Hi Christoffer,
On 12/01/18 12:07, Christoffer Dall wrote:
Calling vcpu_load() registers preempt notifiers for this vcpu and calls
kvm_arch_vcpu_load(). The latter will soon be doing a lot of heavy
lifting on arm/arm64 and will try to do things such as enabling the
virtual timer and setting us
[...]
>
> > Yes, I know you are dong that. Your serial's patch will consider all above
> things, right?
>
> Assuming I got it right, yes. It currently makes the race Xie XiuQi spotted
> worse,
> which I want to fix too. (details on the cover letter)
Ok.
>
>
> > If your patch can be consider
On 05/02/18 10:50, Christoffer Dall wrote:
> On Mon, Feb 05, 2018 at 10:42:44AM +, Marc Zyngier wrote:
>> On 05/02/18 09:58, Andrew Jones wrote:
>>> On Mon, Feb 05, 2018 at 09:24:33AM +, Marc Zyngier wrote:
On 04/02/18 12:37, Christoffer Dall wrote:
>>
>> [...]
>>
> Given the
On Mon, Feb 05, 2018 at 10:42:44AM +, Marc Zyngier wrote:
> On 05/02/18 09:58, Andrew Jones wrote:
> > On Mon, Feb 05, 2018 at 09:24:33AM +, Marc Zyngier wrote:
> >> On 04/02/18 12:37, Christoffer Dall wrote:
>
> [...]
>
> >>> Given the urgency of adding mitigation towards variant 2
On 05/02/18 09:58, Andrew Jones wrote:
> On Mon, Feb 05, 2018 at 09:24:33AM +, Marc Zyngier wrote:
>> On 04/02/18 12:37, Christoffer Dall wrote:
[...]
>>> Given the urgency of adding mitigation towards variant 2 which is the
>>> driver for this work, I think we should drop the compat
On Mon, Feb 05, 2018 at 09:08:31AM +, Marc Zyngier wrote:
> On 04/02/18 18:39, Christoffer Dall wrote:
> > On Thu, Feb 01, 2018 at 11:46:51AM +, Marc Zyngier wrote:
> >> We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible.
> >> So let's intercept it as early as we can by
Hi Tomasz,
On Wed, Jan 31, 2018 at 01:17:36PM +0100, Tomasz Nowicki wrote:
> On 12.01.2018 13:07, Christoffer Dall wrote:
> >There is no need to enable/disable traps to FP registers on every switch
> >to/from the VM, because the host kernel does not use this resource
> >without calling vcpu_put.
On Mon, Feb 05, 2018 at 09:24:33AM +, Marc Zyngier wrote:
> On 04/02/18 12:37, Christoffer Dall wrote:
> > On Sat, Feb 03, 2018 at 11:59:32AM +, Marc Zyngier wrote:
> >> On Fri, 2 Feb 2018 21:17:06 +0100
> >> Andrew Jones wrote:
> >>
> >>> On Thu, Feb 01, 2018 at
On Sun, Feb 04, 2018 at 01:37:01PM +0100, Christoffer Dall wrote:
> On Sat, Feb 03, 2018 at 11:59:32AM +, Marc Zyngier wrote:
> > On Fri, 2 Feb 2018 21:17:06 +0100
> > Andrew Jones wrote:
> >
> > > On Thu, Feb 01, 2018 at 11:46:47AM +, Marc Zyngier wrote:
> > > >
On 04/02/18 12:38, Christoffer Dall wrote:
> Hi Marc,
>
> [ I know we're discussing the overall approach in parallel, but here are
> some comments on the specifics of this patch, should it end up being
> used in some capacity ]
>
> On Thu, Feb 01, 2018 at 11:46:47AM +, Marc Zyngier
On Sat, Feb 03, 2018 at 11:59:32AM +, Marc Zyngier wrote:
> On Fri, 2 Feb 2018 21:17:06 +0100
> Andrew Jones wrote:
>
> > On Thu, Feb 01, 2018 at 11:46:47AM +, Marc Zyngier wrote:
> > > Although we've implemented PSCI 1.0 and 1.1, nothing can select them
> > > Since
On 04/02/18 12:37, Christoffer Dall wrote:
> On Sat, Feb 03, 2018 at 11:59:32AM +, Marc Zyngier wrote:
>> On Fri, 2 Feb 2018 21:17:06 +0100
>> Andrew Jones wrote:
>>
>>> On Thu, Feb 01, 2018 at 11:46:47AM +, Marc Zyngier wrote:
Although we've implemented PSCI 1.0
On 04/02/18 18:39, Christoffer Dall wrote:
> On Thu, Feb 01, 2018 at 11:46:51AM +, Marc Zyngier wrote:
>> We want SMCCC_ARCH_WORKAROUND_1 to be fast. As fast as possible.
>> So let's intercept it as early as we can by testing for the
>> function call number as soon as we've identified a HVC
On Sun, Feb 04, 2018 at 09:57:49PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 4, 2018 at 7:45 PM, Christoffer Dall
> wrote:
> > Hi Arnd,
> >
> > On Fri, Feb 02, 2018 at 04:07:34PM +0100, Arnd Bergmann wrote:
> >> In banked-sr.c, we use a top-level
20 matches
Mail list logo