Re: [PATCH v11 00/43] KVM: arm64: Nested Virtualization support (FEAT_NV2 only)

[Marc Zyngier <maz@kernel.org>]

On Fri, 24 Nov 2023 12:34:41 +0000,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
> 
> 
> 
> On 24-11-2023 03:49 pm, Marc Zyngier wrote:
> > On Fri, 24 Nov 2023 09:50:33 +0000,
> > Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com> wrote:
> >> 
> >> 
> >> 
> >> On 23-11-2023 10:14 pm, Marc Zyngier wrote:
> >>> On Thu, 23 Nov 2023 16:21:48 +0000,
> >>> Miguel Luis <miguel.luis@oracle.com> wrote:
> >>>> 
> >>>> Hi Marc,
> >>>> 
> >>>> On 21/11/2023 18:02, Marc Zyngier wrote:
> >>>>> On Tue, 21 Nov 2023 16:49:52 +0000,
> >>>>> Miguel Luis <miguel.luis@oracle.com> wrote:
> >>>>>> Hi Marc,
> >>>>>> 
> >>>>>>> On 20 Nov 2023, at 12:09, Marc Zyngier <maz@kernel.org> wrote:
> >>>>>>> 
> >>>>>>> This is the 5th drop of NV support on arm64 for this year, and most
> >>>>>>> probably the last one for this side of Christmas.
> >>>>>>> 
> >>>>>>> For the previous episodes, see [1].
> >>>>>>> 
> >>>>>>> What's changed:
> >>>>>>> 
> >>>>>>> - Drop support for the original FEAT_NV. No existing hardware supports
> >>>>>>>    it without FEAT_NV2, and the architecture is deprecating the former
> >>>>>>>    entirely. This results in fewer patches, and a slightly simpler
> >>>>>>>    model overall.
> >>>>>>> 
> >>>>>>> - Reorganise the series to make it a bit more logical now that FEAT_NV
> >>>>>>>    is gone.
> >>>>>>> 
> >>>>>>> - Apply the NV idreg restrictions on VM first run rather than on each
> >>>>>>>    access.
> >>>>>>> 
> >>>>>>> - Make the nested vgic shadow CPU interface a per-CPU structure rather
> >>>>>>>    than per-vcpu.
> >>>>>>> 
> >>>>>>> - Fix the EL0 timer fastpath
> >>>>>>> 
> >>>>>>> - Work around the architecture deficiencies when trapping WFI from a
> >>>>>>>    L2 guest.
> >>>>>>> 
> >>>>>>> - Fix sampling of nested vgic state (MISR, ELRSR, EISR)
> >>>>>>> 
> >>>>>>> - Drop the patches that have already been merged (NV trap forwarding,
> >>>>>>>    per-MMU VTCR)
> >>>>>>> 
> >>>>>>> - Rebased on top of 6.7-rc2 + the FEAT_E2H0 support [2].
> >>>>>>> 
> >>>>>>> The branch containing these patches (and more) is at [3]. As for the
> >>>>>>> previous rounds, my intention is to take a prefix of this series into
> >>>>>>> 6.8, provided that it gets enough reviewing.
> >>>>>>> 
> >>>>>>> [1] https://lore.kernel.org/r/20230515173103.1017669-1-maz@kernel.org
> >>>>>>> [2] https://lore.kernel.org/r/20231120123721.851738-1-maz@kernel.org
> >>>>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/nv-6.8-nv2-only
> >>>>>>> 
> >>>>>> While I was testing this with kvmtool for 5.16 I noted the following on dmesg:
> >>>>>> 
> >>>>>> [  803.014258] kvm [19040]: Unsupported guest sys_reg access at: 8129fa50 [600003c9]
> >>>>>>                   { Op0( 3), Op1( 5), CRn( 1), CRm( 0), Op2( 2), func_read },
> >>>>>> 
> >>>>>> This is CPACR_EL12.
> >>>>> CPACR_EL12 is redirected to VNCR[0x100]. It really shouldn't trap...
> >>>>> 
> >>>>>> Still need yet to debug.
> >>>>> Can you disassemble the guest around the offending PC?
> >>>> 
> >>>> [ 1248.686350] kvm [7013]: Unsupported guest sys_reg access at: 812baa50 [600003c9]
> >>>>                   { Op0( 3), Op1( 5), CRn( 1), CRm( 0), Op2( 2), func_read },
> >>>> 
> >>>>    12baa00:    14000008     b    0x12baa20
> >>>>    12baa04:    d000d501     adrp    x1, 0x2d5c000
> >>>>    12baa08:    91154021     add    x1, x1, #0x550
> >>>>    12baa0c:    f9400022     ldr    x2, [x1]
> >>>>    12baa10:    f9400421     ldr    x1, [x1, #8]
> >>>>    12baa14:    8a010042     and    x2, x2, x1
> >>>>    12baa18:    d3441c42     ubfx    x2, x2, #4, #4
> >>>>    12baa1c:    b4000082     cbz    x2, 0x12baa2c
> >>>>    12baa20:    d2a175a0     mov    x0, #0xbad0000                 // #195887104
> >>>>    12baa24:    f2994220     movk    x0, #0xca11
> >>>>    12baa28:    d69f03e0     eret
> >>>>    12baa2c:    d2c00080     mov    x0, #0x400000000               // #17179869184
> >>>>    12baa30:    f2b10000     movk    x0, #0x8800, lsl #16
> >>>>    12baa34:    f2800000     movk    x0, #0x0
> >>>>    12baa38:    d51c1100     msr    hcr_el2, x0
> >>>>    12baa3c:    d5033fdf     isb

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This.

> >>>>    12baa40:    d53c4100     mrs    x0, sp_el1
> >>>>    12baa44:    9100001f     mov    sp, x0
> >>>>    12baa48:    d538d080     mrs    x0, tpidr_el1
> >>>>    12baa4c:    d51cd040     msr    tpidr_el2, x0
> >>>>    12baa50:    d53d1040     mrs    x0, cpacr_el12
> >>>>    12baa54:    d5181040     msr    cpacr_el1, x0
> >>>>    12baa58:    d53dc000     mrs    x0, vbar_el12
> >>>>    12baa5c:    d518c000     msr    vbar_el1, x0
> >>>>    12baa60:    d53c1120     mrs    x0, mdcr_el2
> >>>>    12baa64:    9272f400     and    x0, x0, #0xffffffffffffcfff
> >>>>    12baa68:    9266f400     and    x0, x0, #0xfffffffffcffffff
> >>>>    12baa6c:    d51c1120     msr    mdcr_el2, x0
> >>>>    12baa70:    d53d2040     mrs    x0, tcr_el12
> >>>>    12baa74:    d5182040     msr    tcr_el1, x0
> >>>>    12baa78:    d53d2000     mrs    x0, ttbr0_el12
> >>>>    12baa7c:    d5182000     msr    ttbr0_el1, x0
> >>>>    12baa80:    d53d2020     mrs    x0, ttbr1_el12
> >>>>    12baa84:    d5182020     msr    ttbr1_el1, x0
> >>>>    12baa88:    d53da200     mrs    x0, mair_el12
> >>>>    12baa8c:    d518a200     msr    mair_el1, x0
> >>>>    12baa90:    d5380761     mrs    x1, s3_0_c0_c7_3
> >>>>    12baa94:    d3400c21     ubfx    x1, x1, #0, #4
> >>>>    12baa98:    b4000141     cbz    x1, 0x12baac0
> >>>>    12baa9c:    d53d2060     mrs    x0, s3_5_c2_c0_3
> >>> 
> >>> OK, this is suspiciously close to the location Ganapatrao was having
> >>> issues with. Are you running on the same hardware?
> >>> 
> >>> In any case, we should never take a trap for this access. Can you dump
> >>> HCR_EL2 at the point where the guest traps (in switch.c)?
> >>> 
> >> 
> >> I have dumped HCR_EL2 before entry to L1 in both V11 and V10.
> >> on V10 HCR_EL2=0x2743c827c263f
> >> on V11 HCR_EL2=0x27c3c827c263f
> >> 
> >> on V11 the function vcpu_el2_e2h_is_set(vcpu) is returning false
> >> resulting in NV1 bit set along with NV and NV2.
> >> AFAIK, For L1 to be in VHE, NV1 bit should be zero and NV=NV2=1.
> >> 
> >> I could boot L1 then L2, if I hack vcpu_el2_e2h_is_set to return true.
> >> There could be a bug in V11 or E2H0 patchset resulting in
> >> vcpu_el2_e2h_is_set() returning false?
> > 
> > The E2H0 series should only force vcpu_el2_e2h_is_set() to return
> > true, but not set it to false. Can you dump the *guest's* version of
> > HCR_EL2 at this point?
> > 
> 
> with V11: vhcr_el2=0x100030080000000 mask=0x100af00ffffffff

How is this value possible if the write to HCR_EL2 has taken place?
When do you sample this?

> with V10: vhcr_el2=0x488000000
> with hack+V11: vhcr_el2=0x488000000 mask=0x100af00ffffffff

Well, of course, if you constrain the value of HCR_EL2...

	M.

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel