[PATCH v8 0/6] KVM: arm64: Hypervisor stack enhancements

[Marc Zyngier]

On Mon, 02 May 2022 17:54:45 +0100,
Kalesh Singh <kaleshsingh at google.com> wrote:
> 
> On Thu, Apr 28, 2022 at 12:55 PM Marc Zyngier <maz at kernel.org> wrote:
> >
> > On Wed, 20 Apr 2022 14:42:51 -0700, Kalesh Singh wrote:
> > > This is v8 of the nVHE hypervisor stack enhancements. This version is based
> > > on 5.18-rc3.
> > >
> > > Previous versions can be found at:
> > > v7: https://lore.kernel.org/r/20220408200349.1529080-1-kaleshsingh@google.com/
> > > v6: https://lore.kernel.org/r/20220314200148.2695206-1-kaleshsingh@google.com/
> > > v5: https://lore.kernel.org/r/20220307184935.1704614-1-kaleshsingh@google.com/
> > > v4: https://lore.kernel.org/r/20220225033548.1912117-1-kaleshsingh@google.com/
> > > v3: https://lore.kernel.org/r/20220224051439.640768-1-kaleshsingh@google.com/
> > > v2: https://lore.kernel.org/r/20220222165212.2005066-1-kaleshsingh@google.com/
> > > v1: https://lore.kernel.org/r/20220210224220.4076151-1-kaleshsingh@google.com/
> > >
> > > [...]
> >
> > Applied to next, thanks!
> >
> > [1/6] KVM: arm64: Introduce hyp_alloc_private_va_range()
> >       commit: 92abe0f81e1385afd8f1dc66206b5be9a514899b
> > [2/6] KVM: arm64: Introduce pkvm_alloc_private_va_range()
> >       commit: f922c13e778d6d5343d4576be785a8204c595113
> > [3/6] KVM: arm64: Add guard pages for KVM nVHE hypervisor stack
> >       commit: ce3354318a57875dc59f4bb841662e95bfba03db
> > [4/6] KVM: arm64: Add guard pages for pKVM (protected nVHE) hypervisor stack
> >       commit: 1a919b17ef012ca0572bae759c27e5ea02bfb47f
> > [5/6] KVM: arm64: Detect and handle hypervisor stack overflows
> >       commit: 66de19fad9ef47c5376a99bb2b00661f1c788a94
> > [6/6] KVM: arm64: Symbolize the nVHE HYP addresses
> >       commit: 6ccf9cb557bd32073b0d68baed97f1bd8a40ff1d
> 
> Thanks for applying these Marc.
> 
> I was wondering if instead of taking these through kvm-arm64/next,
> could Catalin consolidated these in arm64 for-next/core with Mark
> Ruthland's and Madhavan's stacktrace patches[1]? This avoids conflict
> and would allow for the hypervisor unwinding changes[2] to apply
> cleanly.

So far, there hasn't been any reported conflict. If Catalin needs to
merge the branch or part of it, it is stable anyway and can be pulled
from anywhere.

As for the rest of the stacktrace stuff, I haven't had a look yet.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.