Re: panic: mutex pmap not owned at ... efirt_machdep.c:255

On Sat, Aug 04, 2018 at 09:58:43AM -0500, Kyle Evans wrote:
> On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore <ian_at_freebsd.org> wrote:
> > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote:
> >> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov <kostikbel_at_gmail.
> >> com> wrote:
> >> >
> >> > On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote:
> >> > >
> >> > > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov <kostikbel_at_gm
> >> > > ail.com> wrote:
> >> > > >
> >> > > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote:
> >> > > > >
> >> > > > >
> >> > > > > This seems odd- pmap lock is acquired at [1], then asserted
> >> > > > > shortly
> >> > > > > later at [2]... I avoid some of this stuff as well as I can,
> >> > > > > but is it
> >> > > > > actually possible for PCPU_GET(...) acquired curpmap to not
> >> > > > > match
> >> > > > > curthread->td_proc->p_vmspace->vm_pmap in this context?
> >> > > > >
> >> > > > > [1] https://svnweb.freebsd.org/base/head/sys/dev/efidev/efirt
> >> > > > > .c?view=markup#l260
> >> > > > > [2] https://svnweb.freebsd.org/base/head/sys/amd64/amd64/efir
> >> > > > > t_machdep.c?view=markup#l254
> >> > > > There could be that curpcpu not yet synced with proc0 pmap.  It
> >> > > > could be
> >> > > > fixed.
> >> > > >
> >> > > > But it is not clear to me why efi_arch_enter() is called
> >> > > > there.  I see
> >> > > > the check for GetTime belonging to the range described by a map
> >> > > > descriptor.
> >> > > > I do not see why do you need an enter into the EFI context for
> >> > > > comparing
> >> > > > integers.
> >> > > This probably could have been documented better, but efi_runtime
> >> > > pointer may (always?) point into runtime service memory that
> >> > > isn't
> >> > > valid/available at that point, so we get a fault and panic when
> >> > > dereferencing it to grab rt_gettime address. We ran into this
> >> > > wall
> >> > > when adding the check originally.
> >> > Wouldn't it be enough to access it by translating physical address
> >> > into
> >> > DMAP ?
> >> Ah, sure, sure. [1] is proper form, yeah?
> >>
> >> [1] https://people.freebsd.org/~kevans/efi-dmap.diff
> >
> > What do we do on 32-bit arm that has no dmap but may have efi runtime
> > support?
> >
> 
> This should probably just be compiled out for !arm64 && !x86 - its
> sole purpose was to compensate for outdated loader.efi that hasn't
> done the SetVirtualAddressMap. EFI on 32-bit ARM is "new" enough that
> it shouldn't have this problem.
Does EFI on 32bit arm have RT support ?