| Message ID | 20210408040537.2703241-4-pasha.tatashin@soleen.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | arm64: MMU enabled kexec relocation | expand |
On 2021-04-08 05:05, Pavel Tatashin wrote: > From: James Morse <james.morse@arm.com> > > The hyp-stub's el1_sync code doesn't do very much, this can easily fit > in the vectors. > > With this, all of the hyp-stubs behaviour is contained in its vectors. > This lets kexec and hibernate copy the hyp-stub when they need its > behaviour, instead of re-implementing it. > > Signed-off-by: James Morse <james.morse@arm.com> > > [Fixed merging issues] That's a pretty odd fix IMO. > > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> > --- > arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------ > 1 file changed, 29 insertions(+), 30 deletions(-) > > diff --git a/arch/arm64/kernel/hyp-stub.S > b/arch/arm64/kernel/hyp-stub.S > index ff329c5c074d..d1a73d0f74e0 100644 > --- a/arch/arm64/kernel/hyp-stub.S > +++ b/arch/arm64/kernel/hyp-stub.S > @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label) > .align 7 > b \label > SYM_CODE_END(\label) > +.endm > + > +.macro hyp_stub_el1_sync > +SYM_CODE_START_LOCAL(hyp_stub_el1_sync) > + .align 7 > + cmp x0, #HVC_SET_VECTORS > + b.ne 2f > + msr vbar_el2, x1 > + b 9f > + > +2: cmp x0, #HVC_SOFT_RESTART > + b.ne 3f > + mov x0, x2 > + mov x2, x4 > + mov x4, x1 > + mov x1, x3 > + br x4 // no return > + > +3: cmp x0, #HVC_RESET_VECTORS > + beq 9f // Nothing to reset! > + > + /* Someone called kvm_call_hyp() against the hyp-stub... */ > + mov_q x0, HVC_STUB_ERR > + eret > + > +9: mov x0, xzr > + eret > +SYM_CODE_END(hyp_stub_el1_sync) You said you tested this on a TX2. I guess you don't care whether it runs VHE or not... M. > .endm > > .text > @@ -39,7 +67,7 @@ SYM_CODE_START(__hyp_stub_vectors) > invalid_vector hyp_stub_el2h_fiq_invalid // FIQ EL2h > invalid_vector hyp_stub_el2h_error_invalid // Error EL2h > > - ventry el1_sync // Synchronous 64-bit EL1 > + hyp_stub_el1_sync // Synchronous 64-bit EL1 > invalid_vector hyp_stub_el1_irq_invalid // IRQ 64-bit EL1 > invalid_vector hyp_stub_el1_fiq_invalid // FIQ 64-bit EL1 > invalid_vector hyp_stub_el1_error_invalid // Error 64-bit EL1 > @@ -55,35 +83,6 @@ SYM_CODE_END(__hyp_stub_vectors) > # Check the __hyp_stub_vectors didn't overflow > .org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K > > - > -SYM_CODE_START_LOCAL(el1_sync) > - cmp x0, #HVC_SET_VECTORS > - b.ne 1f > - msr vbar_el2, x1 > - b 9f > - > -1: cmp x0, #HVC_VHE_RESTART > - b.eq mutate_to_vhe > - > -2: cmp x0, #HVC_SOFT_RESTART > - b.ne 3f > - mov x0, x2 > - mov x2, x4 > - mov x4, x1 > - mov x1, x3 > - br x4 // no return > - > -3: cmp x0, #HVC_RESET_VECTORS > - beq 9f // Nothing to reset! > - > - /* Someone called kvm_call_hyp() against the hyp-stub... */ > - mov_q x0, HVC_STUB_ERR > - eret > - > -9: mov x0, xzr > - eret > -SYM_CODE_END(el1_sync) > - > // nVHE? No way! Give me the real thing! > SYM_CODE_START_LOCAL(mutate_to_vhe) > // Sanity check: MMU *must* be off
On Thu, Apr 8, 2021 at 6:24 AM Marc Zyngier <maz@kernel.org> wrote: > > On 2021-04-08 05:05, Pavel Tatashin wrote: > > From: James Morse <james.morse@arm.com> > > > > The hyp-stub's el1_sync code doesn't do very much, this can easily fit > > in the vectors. > > > > With this, all of the hyp-stubs behaviour is contained in its vectors. > > This lets kexec and hibernate copy the hyp-stub when they need its > > behaviour, instead of re-implementing it. > > > > Signed-off-by: James Morse <james.morse@arm.com> > > > > [Fixed merging issues] > > That's a pretty odd fix IMO. > > > > > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> > > --- > > arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------ > > 1 file changed, 29 insertions(+), 30 deletions(-) > > > > diff --git a/arch/arm64/kernel/hyp-stub.S > > b/arch/arm64/kernel/hyp-stub.S > > index ff329c5c074d..d1a73d0f74e0 100644 > > --- a/arch/arm64/kernel/hyp-stub.S > > +++ b/arch/arm64/kernel/hyp-stub.S > > @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label) > > .align 7 > > b \label > > SYM_CODE_END(\label) > > +.endm > > + > > +.macro hyp_stub_el1_sync > > +SYM_CODE_START_LOCAL(hyp_stub_el1_sync) > > + .align 7 > > + cmp x0, #HVC_SET_VECTORS > > + b.ne 2f > > + msr vbar_el2, x1 > > + b 9f > > + > > +2: cmp x0, #HVC_SOFT_RESTART > > + b.ne 3f > > + mov x0, x2 > > + mov x2, x4 > > + mov x4, x1 > > + mov x1, x3 > > + br x4 // no return > > + > > +3: cmp x0, #HVC_RESET_VECTORS > > + beq 9f // Nothing to reset! > > + > > + /* Someone called kvm_call_hyp() against the hyp-stub... */ > > + mov_q x0, HVC_STUB_ERR > > + eret > > + > > +9: mov x0, xzr > > + eret > > +SYM_CODE_END(hyp_stub_el1_sync) > > You said you tested this on a TX2. I guess you don't care whether > it runs VHE or not... Hi Marc, Thank you for noticing this. Not sure how this missmerge happened. I have added the missing case, and VHE is initialized correctly during boot. [ 14.698175] kvm [1]: VHE mode initialized successfully During normal boot, kexec reboot, and kdump reboot. I will respin the series and send the version 14 soon. Thanks, Pasha > > M. > > > .endm > > > > .text > > @@ -39,7 +67,7 @@ SYM_CODE_START(__hyp_stub_vectors) > > invalid_vector hyp_stub_el2h_fiq_invalid // FIQ EL2h > > invalid_vector hyp_stub_el2h_error_invalid // Error EL2h > > > > - ventry el1_sync // Synchronous 64-bit EL1 > > + hyp_stub_el1_sync // Synchronous 64-bit EL1 > > invalid_vector hyp_stub_el1_irq_invalid // IRQ 64-bit EL1 > > invalid_vector hyp_stub_el1_fiq_invalid // FIQ 64-bit EL1 > > invalid_vector hyp_stub_el1_error_invalid // Error 64-bit EL1 > > @@ -55,35 +83,6 @@ SYM_CODE_END(__hyp_stub_vectors) > > # Check the __hyp_stub_vectors didn't overflow > > .org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K > > > > - > > -SYM_CODE_START_LOCAL(el1_sync) > > - cmp x0, #HVC_SET_VECTORS > > - b.ne 1f > > - msr vbar_el2, x1 > > - b 9f > > - > > -1: cmp x0, #HVC_VHE_RESTART > > - b.eq mutate_to_vhe > > - > > -2: cmp x0, #HVC_SOFT_RESTART > > - b.ne 3f > > - mov x0, x2 > > - mov x2, x4 > > - mov x4, x1 > > - mov x1, x3 > > - br x4 // no return > > - > > -3: cmp x0, #HVC_RESET_VECTORS > > - beq 9f // Nothing to reset! > > - > > - /* Someone called kvm_call_hyp() against the hyp-stub... */ > > - mov_q x0, HVC_STUB_ERR > > - eret > > - > > -9: mov x0, xzr > > - eret > > -SYM_CODE_END(el1_sync) > > - > > // nVHE? No way! Give me the real thing! > > SYM_CODE_START_LOCAL(mutate_to_vhe) > > // Sanity check: MMU *must* be off > > -- > Jazz is not dead. It just smells funny...
On Thu, 08 Apr 2021 15:45:18 +0100, Pavel Tatashin <pasha.tatashin@soleen.com> wrote: > > On Thu, Apr 8, 2021 at 6:24 AM Marc Zyngier <maz@kernel.org> wrote: > > > > On 2021-04-08 05:05, Pavel Tatashin wrote: > > > From: James Morse <james.morse@arm.com> > > > > > > The hyp-stub's el1_sync code doesn't do very much, this can easily fit > > > in the vectors. > > > > > > With this, all of the hyp-stubs behaviour is contained in its vectors. > > > This lets kexec and hibernate copy the hyp-stub when they need its > > > behaviour, instead of re-implementing it. > > > > > > Signed-off-by: James Morse <james.morse@arm.com> > > > > > > [Fixed merging issues] > > > > That's a pretty odd fix IMO. > > > > > > > > Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> > > > --- > > > arch/arm64/kernel/hyp-stub.S | 59 ++++++++++++++++++------------------ > > > 1 file changed, 29 insertions(+), 30 deletions(-) > > > > > > diff --git a/arch/arm64/kernel/hyp-stub.S > > > b/arch/arm64/kernel/hyp-stub.S > > > index ff329c5c074d..d1a73d0f74e0 100644 > > > --- a/arch/arm64/kernel/hyp-stub.S > > > +++ b/arch/arm64/kernel/hyp-stub.S > > > @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label) > > > .align 7 > > > b \label > > > SYM_CODE_END(\label) > > > +.endm > > > + > > > +.macro hyp_stub_el1_sync > > > +SYM_CODE_START_LOCAL(hyp_stub_el1_sync) > > > + .align 7 > > > + cmp x0, #HVC_SET_VECTORS > > > + b.ne 2f > > > + msr vbar_el2, x1 > > > + b 9f > > > + > > > +2: cmp x0, #HVC_SOFT_RESTART > > > + b.ne 3f > > > + mov x0, x2 > > > + mov x2, x4 > > > + mov x4, x1 > > > + mov x1, x3 > > > + br x4 // no return > > > + > > > +3: cmp x0, #HVC_RESET_VECTORS > > > + beq 9f // Nothing to reset! > > > + > > > + /* Someone called kvm_call_hyp() against the hyp-stub... */ > > > + mov_q x0, HVC_STUB_ERR > > > + eret > > > + > > > +9: mov x0, xzr > > > + eret > > > +SYM_CODE_END(hyp_stub_el1_sync) > > > > You said you tested this on a TX2. I guess you don't care whether > > it runs VHE or not... > > Hi Marc, > > Thank you for noticing this. Not sure how this missmerge happened. I > have added the missing case, and VHE is initialized correctly during > boot. > [ 14.698175] kvm [1]: VHE mode initialized successfully > > During normal boot, kexec reboot, and kdump reboot. I will respin the > series and send the version 14 soon. Please give people a chance to review this lot first. This isn't code that is easy to digest, and immediate re-spinning does more harm than good (this isn't targeting 5.13, I would assume). Thanks, M.
> > Thank you for noticing this. Not sure how this missmerge happened. I > > have added the missing case, and VHE is initialized correctly during > > boot. > > [ 14.698175] kvm [1]: VHE mode initialized successfully > > > > During normal boot, kexec reboot, and kdump reboot. I will respin the > > series and send the version 14 soon. > > Please give people a chance to review this lot first. This isn't code > that is easy to digest, and immediate re-spinning does more harm than > good (this isn't targeting 5.13, I would assume). > There are people who are testing this series, this is why I wanted to respin. But, I will wait for review comments before sending the next version. In the meantime I will send a fixed version of this patch as a reply to this thread instead. Thanks, Pasha
Hi Marc Are you planning to send more review comments, or should I send the new version? Thanks, Pasha On Thu, Apr 8, 2021 at 12:28 PM Pavel Tatashin <pasha.tatashin@soleen.com> wrote: > > > > Thank you for noticing this. Not sure how this missmerge happened. I > > > have added the missing case, and VHE is initialized correctly during > > > boot. > > > [ 14.698175] kvm [1]: VHE mode initialized successfully > > > > > > During normal boot, kexec reboot, and kdump reboot. I will respin the > > > series and send the version 14 soon. > > > > Please give people a chance to review this lot first. This isn't code > > that is easy to digest, and immediate re-spinning does more harm than > > good (this isn't targeting 5.13, I would assume). > > > > There are people who are testing this series, this is why I wanted to > respin. But, I will wait for review comments before sending the next > version. In the meantime I will send a fixed version of this patch as > a reply to this thread instead. > > Thanks, > Pasha
> > > Please give people a chance to review this lot first. This isn't code > > > that is easy to digest, and immediate re-spinning does more harm than > > > good (this isn't targeting 5.13, I would assume). Sorry for top posting, the previous e-mail intended as a reply to the above. Pasha
On 2021-04-26 19:10, Pavel Tatashin wrote: > Hi Marc > > Are you planning to send more review comments, or should I send the new > version? Yeah, I'll hopefully have a bit more bandwidth in a few days. You shouldn't post this kind of code during the merge window anyway... ;-) Thanks, M.
diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index ff329c5c074d..d1a73d0f74e0 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -21,6 +21,34 @@ SYM_CODE_START_LOCAL(\label) .align 7 b \label SYM_CODE_END(\label) +.endm + +.macro hyp_stub_el1_sync +SYM_CODE_START_LOCAL(hyp_stub_el1_sync) + .align 7 + cmp x0, #HVC_SET_VECTORS + b.ne 2f + msr vbar_el2, x1 + b 9f + +2: cmp x0, #HVC_SOFT_RESTART + b.ne 3f + mov x0, x2 + mov x2, x4 + mov x4, x1 + mov x1, x3 + br x4 // no return + +3: cmp x0, #HVC_RESET_VECTORS + beq 9f // Nothing to reset! + + /* Someone called kvm_call_hyp() against the hyp-stub... */ + mov_q x0, HVC_STUB_ERR + eret + +9: mov x0, xzr + eret +SYM_CODE_END(hyp_stub_el1_sync) .endm .text @@ -39,7 +67,7 @@ SYM_CODE_START(__hyp_stub_vectors) invalid_vector hyp_stub_el2h_fiq_invalid // FIQ EL2h invalid_vector hyp_stub_el2h_error_invalid // Error EL2h - ventry el1_sync // Synchronous 64-bit EL1 + hyp_stub_el1_sync // Synchronous 64-bit EL1 invalid_vector hyp_stub_el1_irq_invalid // IRQ 64-bit EL1 invalid_vector hyp_stub_el1_fiq_invalid // FIQ 64-bit EL1 invalid_vector hyp_stub_el1_error_invalid // Error 64-bit EL1 @@ -55,35 +83,6 @@ SYM_CODE_END(__hyp_stub_vectors) # Check the __hyp_stub_vectors didn't overflow .org . - (__hyp_stub_vectors_end - __hyp_stub_vectors) + SZ_2K - -SYM_CODE_START_LOCAL(el1_sync) - cmp x0, #HVC_SET_VECTORS - b.ne 1f - msr vbar_el2, x1 - b 9f - -1: cmp x0, #HVC_VHE_RESTART - b.eq mutate_to_vhe - -2: cmp x0, #HVC_SOFT_RESTART - b.ne 3f - mov x0, x2 - mov x2, x4 - mov x4, x1 - mov x1, x3 - br x4 // no return - -3: cmp x0, #HVC_RESET_VECTORS - beq 9f // Nothing to reset! - - /* Someone called kvm_call_hyp() against the hyp-stub... */ - mov_q x0, HVC_STUB_ERR - eret - -9: mov x0, xzr - eret -SYM_CODE_END(el1_sync) - // nVHE? No way! Give me the real thing! SYM_CODE_START_LOCAL(mutate_to_vhe) // Sanity check: MMU *must* be off