Re: [PATCH 09/13] arm64: KVM: VHE: Add alternatives for VHE-enabled world-switch
On 07/09/2015 01:06 AM, Marc Zyngier wrote: > Hi Mario, > > On 09/07/15 02:29, Mario Smarduch wrote: >> On 07/08/2015 09:19 AM, Marc Zyngier wrote: >>> In order to switch between host and guest, a VHE-enabled kernel >>> must use different accessors for certain system registers. >>> >>> This patch uses runtime patching to use the right instruction >>> when required... >>> >>> Signed-off-by: Marc Zyngier >>> --- >>> arch/arm64/include/asm/kvm_asm.h | 40 ++-- >>> arch/arm64/kvm/hyp.S | 210 >>> ++- >>> arch/arm64/kvm/vhe-macros.h | 18 >>> 3 files changed, 191 insertions(+), 77 deletions(-) >>> >> [] >>> * Author: Marc Zyngier >>> * >>> * This program is free software; you can redistribute it and/or modify >>> @@ -67,40 +67,52 @@ >>> stp x29, lr, [x3, #80] >>> >>> mrs x19, sp_el0 >>> - mrs x20, elr_el2// pc before entering el2 >>> - mrs x21, spsr_el2 // pstate before entering el2 >>> + str x19, [x3, #96] >>> +.endm >>> >>> - stp x19, x20, [x3, #96] >>> - str x21, [x3, #112] >> >> Hi Marc, >> >> trying to make a little sense out of this :) > > Don't even try, it hurts... ;-) > >> In the case of VHE kernel the two 'mrs_hyp()' and 'mrs_el1()' >> calls would be accessing same registers - namely EL1 variants? >> For non VHE EL2, EL1? >> >> The mrs_s and sysreg_EL12 are new, not sure what these mean. > > mrs_s and msr_s are just macros to that deal with system registers that > the assembler doesn't know about (yet). They have been in (moderate) use > for about a year, and have been introduced with the GICv3 support. > > See arch/arm64/include/asm/sysreg.h for the gory details. > > Now, on to sysreg_EL12: The main idea with VHE is that anything that > used to run at EL1 (the kernel) can now run unmodified at EL2, and that > it is the EL2 software that has to change to deal with it. > > So when the kernel uses VHE and runs at EL2, an access to sysreg_EL1 > really accesses sysreg_EL2, transparently. This is what makes it > possible to run the kernel at EL2 without any change. > > But when the KVM world switch wants to access a guest register, it > cannot use sysreg_EL1 anymore (that would hit on the EL2 register > because of the above rule). For this, it must use sysreg_EL12 which > effectively means "access the EL1 register from EL2". > > As a consequence, we have the following rules: > - non-VHE: msr_el1 uses EL1, msr_hyp uses EL2 > - VHE: msr_el1 uses EL12, msr_hyp uses EL1 > > Does this help? Yep it sure does, msr/mrs_hyp() and 12 naming had me confused. Thanks! > > M. > >> - Mario >> >>> +.macro save_el1_state >>> + mrs_hyp(x20, ELR) // pc before entering el2 >>> + mrs_hyp(x21, SPSR) // pstate before entering el2 >>> >>> mrs x22, sp_el1 >>> - mrs x23, elr_el1 >>> - mrs x24, spsr_el1 >>> + >>> + mrs_el1(x23, elr) >>> + mrs_el1(x24, spsr) >>> + >>> + add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 >>> + stp x20, x21, [x3, #8] // HACK: Store to the regs after >>> SP_EL0 >>> >>> str x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)] >>> str x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)] >>> str x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)] >>> .endm >>> >>> -.macro restore_common_regs >>> +.macro restore_el1_state >>> // x2: base address for cpu context >>> // x3: tmp register >>> >>> + add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 >>> + ldp x20, x21, [x3, #8] // Same hack again, get guest PC and pstate >>> + >>> ldr x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)] >>> ldr x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)] >>> ldr x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)] >>> >>> + msr_hyp(ELR, x20) // pc on return from el2 >>> + msr_hyp(SPSR, x21) // pstate on return from el2 >>> + >>> msr sp_el1, x22 >>> - msr elr_el1, x23 >>> - msr spsr_el1, x24 >>> >>> - add x3, x2, #CPU_XREG_OFFSET(31)// SP_E
Re: [PATCH 09/13] arm64: KVM: VHE: Add alternatives for VHE-enabled world-switch
On 07/08/2015 09:19 AM, Marc Zyngier wrote: > In order to switch between host and guest, a VHE-enabled kernel > must use different accessors for certain system registers. > > This patch uses runtime patching to use the right instruction > when required... > > Signed-off-by: Marc Zyngier > --- > arch/arm64/include/asm/kvm_asm.h | 40 ++-- > arch/arm64/kvm/hyp.S | 210 > ++- > arch/arm64/kvm/vhe-macros.h | 18 > 3 files changed, 191 insertions(+), 77 deletions(-) > [] > * Author: Marc Zyngier > * > * This program is free software; you can redistribute it and/or modify > @@ -67,40 +67,52 @@ > stp x29, lr, [x3, #80] > > mrs x19, sp_el0 > - mrs x20, elr_el2// pc before entering el2 > - mrs x21, spsr_el2 // pstate before entering el2 > + str x19, [x3, #96] > +.endm > > - stp x19, x20, [x3, #96] > - str x21, [x3, #112] Hi Marc, trying to make a little sense out of this :) In the case of VHE kernel the two 'mrs_hyp()' and 'mrs_el1()' calls would be accessing same registers - namely EL1 variants? For non VHE EL2, EL1? The mrs_s and sysreg_EL12 are new, not sure what these mean. - Mario > +.macro save_el1_state > + mrs_hyp(x20, ELR) // pc before entering el2 > + mrs_hyp(x21, SPSR) // pstate before entering el2 > > mrs x22, sp_el1 > - mrs x23, elr_el1 > - mrs x24, spsr_el1 > + > + mrs_el1(x23, elr) > + mrs_el1(x24, spsr) > + > + add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 > + stp x20, x21, [x3, #8] // HACK: Store to the regs after SP_EL0 > > str x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)] > str x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)] > str x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)] > .endm > > -.macro restore_common_regs > +.macro restore_el1_state > // x2: base address for cpu context > // x3: tmp register > > + add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 > + ldp x20, x21, [x3, #8] // Same hack again, get guest PC and pstate > + > ldr x22, [x2, #CPU_GP_REG_OFFSET(CPU_SP_EL1)] > ldr x23, [x2, #CPU_GP_REG_OFFSET(CPU_ELR_EL1)] > ldr x24, [x2, #CPU_SPSR_OFFSET(KVM_SPSR_EL1)] > > + msr_hyp(ELR, x20) // pc on return from el2 > + msr_hyp(SPSR, x21) // pstate on return from el2 > + > msr sp_el1, x22 > - msr elr_el1, x23 > - msr spsr_el1, x24 > > - add x3, x2, #CPU_XREG_OFFSET(31)// SP_EL0 > - ldp x19, x20, [x3] > - ldr x21, [x3, #16] > + msr_el1(elr, x23) > + msr_el1(spsr, x24) > +.endm > > +.macro restore_common_regs > + // x2: base address for cpu context > + // x3: tmp register > + > + ldr x19, [x2, #CPU_XREG_OFFSET(31)] // SP_EL0 > msr sp_el0, x19 > - msr elr_el2, x20// pc on return from el2 > - msr spsr_el2, x21 // pstate on return from el2 > > add x3, x2, #CPU_XREG_OFFSET(19) > ldp x19, x20, [x3] > @@ -113,9 +125,15 @@ > > .macro save_host_regs > save_common_regs > +ifnvhe nop,"b skip_el1_save" > + save_el1_state > +skip_el1_save: > .endm > > .macro restore_host_regs > +ifnvhe nop,"b > skip_el1_restore" > + restore_el1_state > +skip_el1_restore: > restore_common_regs > .endm > > @@ -159,6 +177,7 @@ > stp x6, x7, [x3, #16] > > save_common_regs > + save_el1_state > .endm > > .macro restore_guest_regs > @@ -184,6 +203,7 @@ > ldr x18, [x3, #144] > > // x19-x29, lr, sp*, elr*, spsr* > + restore_el1_state > restore_common_regs > > // Last bits of the 64bit state > @@ -203,6 +223,38 @@ > * In other words, don't touch any of these unless you know what > * you are doing. > */ > + > +.macro save_shared_sysregs > + // x2: base address for cpu context > + // x3: tmp register > + > + add x3, x2, #CPU_SYSREG_OFFSET(TPIDR_EL0) > + > + mrs x4, tpidr_el0 > + mrs x5, tpidrro_el0 > + mrs x6, tpidr_el1 > + mrs x7, actlr_el1 > + > + stp x4, x5, [x3] > + stp x6, x7, [x3, #16] > +.endm > + > +.macro restore_shared_sysregs > + // x2: base address for cpu context > + // x3: tmp register > + > + add x3, x2, #CPU_SYSREG_OFFSET(TPIDR_EL0) > + > + ldp x4, x5, [x3] > + ldp x6, x7, [x3, #16] > + > + msr tpidr_el0, x4 > + msr tpidrro_el0,x5 > + msr tpidr_el1, x6 > + msr actlr_el1, x7 > +.endm > + > + > .macro save_sysregs > // x2: base address for cpu context > // x3: tmp register > @@ -211,26 +263,27 @@ > > mrs x4, vmpidr_el2 > mrs
Re: KVM: CONFIG_LOCK_DEP and CONFIG_LOCK_DETECTOR?
On 01/22/2015 01:34 AM, Paul Bolle wrote:
> Mario,
>
> Your commit c64735554c0a ("KVM: arm: Add initial dirty page locking
> support") is included in today's linux-next (ie, next-20150122). I
> noticed because a script I use to check linux-next spotted a minor
> problem with it.
>
> This commit added a comment that mentions CONFIG_LOCK_DEP and
> CONFIG_LOCK_DETECTOR. It seems CONFIG_LOCKDEP and CONFIG_LOCKUP_DETECTOR
> should be used instead. Is a trivial patch to fix these typos queued
> somewhere?
>
> Thanks,
>
>
> Paul Bolle
>
Hi Paul,
thanks for spotting that. No there is no trivial patch
queued, didn't notice it until now. Can I submit a follow
up trivial patch later?
- Mario
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: KVM: HAVE_KVM_ARCH_DIRTY_LOG_PROTECT?
On 01/22/2015 03:46 AM, Paolo Bonzini wrote:
>
>
> On 22/01/2015 10:19, Paul Bolle wrote:
>> Mario,
>>
>> Your commit ba0513b5b8ff ("KVM: Add generic support for dirty page
>> logging") is included in today's linux-next (ie, next-20150122). I
>> noticed because a script I use to check linux-next spotted a problem
>> with it.
>>
>> That commit added a Kconfig symbol HAVE_KVM_ARCH_DIRTY_LOG_PROTECT. But
>> nothing in linux-next uses that symbol. Why was it added?
>
> That's a bug. I'll fix it when pulling from the kvm-arm tree.
>
> Paolo
>
Paolo,
thanks, left over from early iteration.
- Mario
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fwd: show_interrupts() after free_irq issue 3.10-rc4?
I've been working with device passthrough & irq on armv7 after disassociating the device from guest free_irq() is executed on host. Display of /proc/interrupts still shows the IRQ info with no irq name associated, and there is no irq_action associated with the IRQ. 'show_interrupts()' in 'kernel/irq/proc.c' displays info on the IRQ due to prior stats accumulated. Few other arch specific ones only on irq_action. Is there some specific reason for that? To me it appears misleading to display dormant IRQ info. For the end user - use case like above or unloading driver and seeing the irq show up is confusing as well. Also not sure what you gain by displaying old IRQ info. Please cc on responses. - Mario -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
