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

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.