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

On Sat, Aug 04, 2018 at 09:25:47AM -0600, Ian Lepore wrote:
> On Sat, 2018-08-04 at 18:22 +0300, Konstantin Belousov wrote:
> > 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 <kostik
> > > > > > > bel_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/amd6
> > > > > > > > > 4/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 ?
> 
> I suspect the uboot implementation doesn't, but I can't think of any
> reason why other implementations are not possible/available. In
> particular, even 32bit arm supports virtualization and such an
> environment could provide rt support.

No, I mean, does our kernel has RT support on armv7 ?  I only implemented
necessary VM tricks for amd64, then it was ported to arm64, and in both
cases it relies on 64bit address space and specific location of the KVA.