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

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?

-- Ian