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

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Sat, 4 Aug 2018 18:43:27 +0300
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.
Received on Sat Aug 04 2018 - 13:43:39 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:17 UTC