Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Wed, Aug 08, 2018 at 01:42:07AM +0300, Konstantin Belousov wrote:
| On Tue, Aug 07, 2018 at 02:49:10PM -0700, Doug Ambrisko wrote:
| > On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote:
| > | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
| > | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
| > | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
| > | > >>
| > | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
wrote:
| > | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
| > | > >> >>
| > | > >> >> He now gets a little further, but ends up with the same panic due
to
| > | > >> >> efirtc_probe trying to get time to verify the rtc's actually
| > | > >> >> implemented. What kind of approach must we take to ensure curcpu
is
| > | > >> >> synced?
| > | > >> >
| > | > >> > It does not panic for me, when I load efirt.ko from the loader
prompt.
| > | > >> > Anyway, try this
| > | > >>
| > | > >> Right, I also don't get a panic on any of my machines from this.
| > | > >> Hopefully he'll have a chance to try this soon.
| > | > >
| > | > > This change has no impact: it still panics in the same way as without
the patch.
| > | > >
| > | >
| > | > That seems indicative of a bigger problem, since we use proc0
| > | > throughout all these bits so we should still be dealing with the same
| > | > pmap that got passed to pmap_pinit0 when we grab
| > | > curthread->td_proc->p_vmspace->vm_pmap.
| > |
| > | Can you confirm that you get the early efi_enter() call from rtc code,
| > | when you preload the module or compile it into the kernel ?
| >
| > When I ran into this, I did this change:
| >
| > Index: dev/efidev/efirt.c
| > ===
| > --- dev/efidev/efirt.c (revision 337264)
| > +++ dev/efidev/efirt.c (working copy)
| > @@ -257,7 +257,8 @@
| > if (efi_runtime == NULL)
| > return (ENXIO);
| > td = curthread;
| > - curpmap = >td_proc->p_vmspace->vm_pmap;
| > +// curpmap = >td_proc->p_vmspace->vm_pmap;
| > + curpmap = PCPU_GET(curpmap);
| > PMAP_LOCK(curpmap);
| > mtx_lock(_lock);
| > fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
| > @@ -272,7 +273,8 @@
| >
| > efi_arch_leave();
| >
| > - curpmap = >p_vmspace->vm_pmap;
| > +// curpmap = >p_vmspace->vm_pmap;
| > + curpmap = PCPU_GET(curpmap);
| > td = curthread;
| > fpu_kern_leave(td, NULL);
| > mtx_unlock(_lock);
| >
| > Don't know if it is right. Some previous code used both
| > curpmap = PCPU_GET(curpmap);
| > and
| > curpmap = >td_proc->p_vmspace->vm_pmap;
| > recently it was changes to only use
| > curpmap = >td_proc->p_vmspace->vm_pmap;
| >
| > Things seem to work after that. I was able to repro. it with
| > qemu-system-x86_64 in UEFI mode. I think it also failed in
| > bhyve UEFI mode.
|
| The pcpu curpmap and curproc vmspace pmap should be synced. Esp. since
| there is code relying on this early. I do not want to paper it over.
|
| In fact, try this please. Ignore my previous change.
|
| diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
| index 572b2197453..4bce36cc0e5 100644
| --- a/sys/amd64/amd64/pmap.c
| +++ b/sys/amd64/amd64/pmap.c
| @@ -7536,7 +7536,8 @@ pmap_activate_sw(struct thread *td)
| PCPU_SET(kcr3, pmap->pm_cr3);
| PCPU_SET(ucr3, pmap->pm_ucr3);
| }
| - }
| + } else
| + PCPU_SET(curpmap, pmap);
| if (pmap->pm_ucr3 != PMAP_NO_CR3) {
| rsp0 = ((vm_offset_t)PCPU_PTR(pti_stack) +
| PC_PTI_STACK_SZ * sizeof(uint64_t)) & ~0xful;
That works for qemu and bhyve booting in UEFI PXE mode. I backed
out my other change and synced to head.
Thanks,
Doug A.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 02:49:10PM -0700, Doug Ambrisko wrote:
> On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote:
> | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote:
> | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote:
> | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote:
> | > >>
> | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov
> wrote:
> | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote:
> | > >> >>
> | > >> >> He now gets a little further, but ends up with the same panic due to
> | > >> >> efirtc_probe trying to get time to verify the rtc's actually
> | > >> >> implemented. What kind of approach must we take to ensure curcpu is
> | > >> >> synced?
> | > >> >
> | > >> > It does not panic for me, when I load efirt.ko from the loader
> prompt.
> | > >> > Anyway, try this
> | > >>
> | > >> Right, I also don't get a panic on any of my machines from this.
> | > >> Hopefully he'll have a chance to try this soon.
> | > >
> | > > This change has no impact: it still panics in the same way as without
> the patch.
> | > >
> | >
> | > That seems indicative of a bigger problem, since we use proc0
> | > throughout all these bits so we should still be dealing with the same
> | > pmap that got passed to pmap_pinit0 when we grab
> | > curthread->td_proc->p_vmspace->vm_pmap.
> |
> | Can you confirm that you get the early efi_enter() call from rtc code,
> | when you preload the module or compile it into the kernel ?
>
> When I ran into this, I did this change:
>
> Index: dev/efidev/efirt.c
> ===
> --- dev/efidev/efirt.c(revision 337264)
> +++ dev/efidev/efirt.c(working copy)
> @@ -257,7 +257,8 @@
> if (efi_runtime == NULL)
> return (ENXIO);
> td = curthread;
> - curpmap = >td_proc->p_vmspace->vm_pmap;
> +// curpmap = >td_proc->p_vmspace->vm_pmap;
> + curpmap = PCPU_GET(curpmap);
> PMAP_LOCK(curpmap);
> mtx_lock(_lock);
> fpu_kern_enter(td, NULL, FPU_KERN_NOCTX);
> @@ -272,7 +273,8 @@
>
> efi_arch_leave();
>
> - curpmap = >p_vmspace->vm_pmap;
> +// curpmap = >p_vmspace->vm_pmap;
> + curpmap = PCPU_GET(curpmap);
> td = curthread;
> fpu_kern_leave(td, NULL);
> mtx_unlock(_lock);
>
> Don't know if it is right. Some previous code used both
> curpmap = PCPU_GET(curpmap);
> and
> curpmap = >td_proc->p_vmspace->vm_pmap;
> recently it was changes to only use
> curpmap = >td_proc->p_vmspace->vm_pmap;
>
> Things seem to work after that. I was able to repro. it with
> qemu-system-x86_64 in UEFI mode. I think it also failed in
> bhyve UEFI mode.
The pcpu curpmap and curproc vmspace pmap should be synced. Esp. since
there is code relying on this early. I do not want to paper it over.
In fact, try this please. Ignore my previous change.
diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
index 572b2197453..4bce36cc0e5 100644
--- a/sys/amd64/amd64/pmap.c
+++ b/sys/amd64/amd64/pmap.c
@@ -7536,7 +7536,8 @@ pmap_activate_sw(struct thread *td)
PCPU_SET(kcr3, pmap->pm_cr3);
PCPU_SET(ucr3, pmap->pm_ucr3);
}
- }
+ } else
+ PCPU_SET(curpmap, pmap);
if (pmap->pm_ucr3 != PMAP_NO_CR3) {
rsp0 = ((vm_offset_t)PCPU_PTR(pti_stack) +
PC_PTI_STACK_SZ * sizeof(uint64_t)) & ~0xful;
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 08:29:49PM +0300, Konstantin Belousov wrote: | On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote: | > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: | > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: | > >> | > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov wrote: | > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: | > >> >> | > >> >> He now gets a little further, but ends up with the same panic due to | > >> >> efirtc_probe trying to get time to verify the rtc's actually | > >> >> implemented. What kind of approach must we take to ensure curcpu is | > >> >> synced? | > >> > | > >> > It does not panic for me, when I load efirt.ko from the loader prompt. | > >> > Anyway, try this | > >> | > >> Right, I also don't get a panic on any of my machines from this. | > >> Hopefully he'll have a chance to try this soon. | > > | > > This change has no impact: it still panics in the same way as without the patch. | > > | > | > That seems indicative of a bigger problem, since we use proc0 | > throughout all these bits so we should still be dealing with the same | > pmap that got passed to pmap_pinit0 when we grab | > curthread->td_proc->p_vmspace->vm_pmap. | | Can you confirm that you get the early efi_enter() call from rtc code, | when you preload the module or compile it into the kernel ? When I ran into this, I did this change: Index: dev/efidev/efirt.c === --- dev/efidev/efirt.c (revision 337264) +++ dev/efidev/efirt.c (working copy) @@ -257,7 +257,8 @@ if (efi_runtime == NULL) return (ENXIO); td = curthread; - curpmap = >td_proc->p_vmspace->vm_pmap; +// curpmap = >td_proc->p_vmspace->vm_pmap; + curpmap = PCPU_GET(curpmap); PMAP_LOCK(curpmap); mtx_lock(_lock); fpu_kern_enter(td, NULL, FPU_KERN_NOCTX); @@ -272,7 +273,8 @@ efi_arch_leave(); - curpmap = >p_vmspace->vm_pmap; +// curpmap = >p_vmspace->vm_pmap; + curpmap = PCPU_GET(curpmap); td = curthread; fpu_kern_leave(td, NULL); mtx_unlock(_lock); Don't know if it is right. Some previous code used both curpmap = PCPU_GET(curpmap); and curpmap = >td_proc->p_vmspace->vm_pmap; recently it was changes to only use curpmap = >td_proc->p_vmspace->vm_pmap; Things seem to work after that. I was able to repro. it with qemu-system-x86_64 in UEFI mode. I think it also failed in bhyve UEFI mode. Thanks, Doug A. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 07, 2018 at 11:50:44AM -0500, Kyle Evans wrote: > On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: > > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: > >> > >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov > >> wrote: > >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: > >> >> > >> >> He now gets a little further, but ends up with the same panic due to > >> >> efirtc_probe trying to get time to verify the rtc's actually > >> >> implemented. What kind of approach must we take to ensure curcpu is > >> >> synced? > >> > > >> > It does not panic for me, when I load efirt.ko from the loader prompt. > >> > Anyway, try this > >> > >> Right, I also don't get a panic on any of my machines from this. > >> Hopefully he'll have a chance to try this soon. > > > > This change has no impact: it still panics in the same way as without the > > patch. > > > > That seems indicative of a bigger problem, since we use proc0 > throughout all these bits so we should still be dealing with the same > pmap that got passed to pmap_pinit0 when we grab > curthread->td_proc->p_vmspace->vm_pmap. Can you confirm that you get the early efi_enter() call from rtc code, when you preload the module or compile it into the kernel ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Tue, Aug 7, 2018 at 12:09 AM, Eitan Adler wrote: > On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: >> >> On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov >> wrote: >> > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: >> >> >> >> He now gets a little further, but ends up with the same panic due to >> >> efirtc_probe trying to get time to verify the rtc's actually >> >> implemented. What kind of approach must we take to ensure curcpu is >> >> synced? >> > >> > It does not panic for me, when I load efirt.ko from the loader prompt. >> > Anyway, try this >> >> Right, I also don't get a panic on any of my machines from this. >> Hopefully he'll have a chance to try this soon. > > This change has no impact: it still panics in the same way as without the > patch. > That seems indicative of a bigger problem, since we use proc0 throughout all these bits so we should still be dealing with the same pmap that got passed to pmap_pinit0 when we grab curthread->td_proc->p_vmspace->vm_pmap. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Mon, 6 Aug 2018 at 11:27, Kyle Evans wrote: > > On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov > wrote: > > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: > >> > >> He now gets a little further, but ends up with the same panic due to > >> efirtc_probe trying to get time to verify the rtc's actually > >> implemented. What kind of approach must we take to ensure curcpu is > >> synced? > > > > It does not panic for me, when I load efirt.ko from the loader prompt. > > Anyway, try this > > Right, I also don't get a panic on any of my machines from this. > Hopefully he'll have a chance to try this soon. This change has no impact: it still panics in the same way as without the patch. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sun, Aug 5, 2018 at 5:43 AM, Konstantin Belousov wrote: > On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: >> >> He now gets a little further, but ends up with the same panic due to >> efirtc_probe trying to get time to verify the rtc's actually >> implemented. What kind of approach must we take to ensure curcpu is >> synced? > > It does not panic for me, when I load efirt.ko from the loader prompt. > Anyway, try this Right, I also don't get a panic on any of my machines from this. Hopefully he'll have a chance to try this soon. > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c > index 572b2197453..f84f56b98e2 100644 > --- a/sys/amd64/amd64/pmap.c > +++ b/sys/amd64/amd64/pmap.c > @@ -2655,7 +2655,7 @@ pmap_pinit0(pmap_t pmap) > __pcpu[i].pc_ucr3 = PMAP_NO_CR3; > } > } > - PCPU_SET(curpmap, kernel_pmap); > + PCPU_SET(curpmap, pmap); > pmap_activate(curthread); > CPU_FILL(_pmap->pm_active); > } ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 04, 2018 at 09:46:39PM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov > wrote: > > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote: > >> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote: > >> > Hi all, > >> > > >> > After installing the latest current kernel I get the following panic: > >> > > >> > panic: mutex pmap not owned at ... efirt_machdep.c:255 > >> > cpuid =3 > >> > time = 1 > >> > ... > >> > mtx_assert() > >> > efi_arch_enter() > >> > efirt_modevents() > >> > module_register_init() > >> > mi_startup() > >> > btext() > >> > > >> > >> 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/efirt_machdep.c?view=markup#l254 > > There could be that curpcpu not yet synced with proc0 pmap. It could be > > fixed. > > > > He now gets a little further, but ends up with the same panic due to > efirtc_probe trying to get time to verify the rtc's actually > implemented. What kind of approach must we take to ensure curcpu is > synced? It does not panic for me, when I load efirt.ko from the loader prompt. Anyway, try this diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 572b2197453..f84f56b98e2 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -2655,7 +2655,7 @@ pmap_pinit0(pmap_t pmap) __pcpu[i].pc_ucr3 = PMAP_NO_CR3; } } - PCPU_SET(curpmap, kernel_pmap); + PCPU_SET(curpmap, pmap); pmap_activate(curthread); CPU_FILL(_pmap->pm_active); } ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov wrote: > On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote: >> On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote: >> > Hi all, >> > >> > After installing the latest current kernel I get the following panic: >> > >> > panic: mutex pmap not owned at ... efirt_machdep.c:255 >> > cpuid =3 >> > time = 1 >> > ... >> > mtx_assert() >> > efi_arch_enter() >> > efirt_modevents() >> > module_register_init() >> > mi_startup() >> > btext() >> > >> >> 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/efirt_machdep.c?view=markup#l254 > There could be that curpcpu not yet synced with proc0 pmap. It could be > fixed. > He now gets a little further, but ends up with the same panic due to efirtc_probe trying to get time to verify the rtc's actually implemented. What kind of approach must we take to ensure curcpu is synced? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 04, 2018 at 08:28:25PM +0100, Warner Losh wrote: > When I looked at it, I'd assumed there would be VA range we'd assign to the > PAs in the EFI table that at the loader and kernel would agree on. The DMAP > does this on x64 and aarch64, but that's not an option for armv7 nor i386. It is not DMAP. Amd64 works by assumption that ROM BIOS and its memory are located at the physical addresses below 4G. Since kernel is always mapped at upper half of the virtual address space, we hope that identity mapping for RT memory can be established over the user half of the VA. Apparently arm64 makes the same assumption. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 4, 2018, 8:21 PM Emmanuel Vadot wrote: > On Sat, 04 Aug 2018 09:47:11 -0600 > Ian Lepore wrote: > > > On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote: > > > 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 > wrote: > > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > 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. > > > > I didn't realize the kernel implementation was arch-specific. So I > > guess this comes under the category of "we'll solve that problem when > > something comes along that provides efi rt for arm32." > > U-Boot doesn't provide a runtime service, I never tested the available > port of EDK2 for BBB or RPI, I guess they boot the kernel in > HYP/non-secure mode and install an runtime in secure world along with > some > When I looked at it, I'd assumed there would be VA range we'd assign to the PAs in the EFI table that at the loader and kernel would agree on. The DMAP does this on x64 and aarch64, but that's not an option for armv7 nor i386. Warner > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, 04 Aug 2018 09:47:11 -0600 Ian Lepore wrote: > On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote: > > 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 wrote: > > > > > > > > > > > > > > > > > > > [...] > > > > > > 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. > > I didn't realize the kernel implementation was arch-specific. So I > guess this comes under the category of "we'll solve that problem when > something comes along that provides efi rt for arm32." U-Boot doesn't provide a runtime service, I never tested the available port of EDK2 for BBB or RPI, I guess they boot the kernel in HYP/non-secure mode and install an runtime in secure world along with some psci firmware. -- Emmanuel Vadot ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, 2018-08-04 at 18:43 +0300, Konstantin Belousov wrote: > 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 wrote: > > > > > > > > > > > > > > > [...] > > > > > 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. I didn't realize the kernel implementation was arch-specific. So I guess this comes under the category of "we'll solve that problem when something comes along that provides efi rt for arm32." -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 wrote: > > > > > > > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote: > > > > > > > > > > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > > > > 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 > > > > > > bel@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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
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 wrote: > > > > > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote: > > > > > > > > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > > > 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 > > > > > bel@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. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 wrote: > > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote: > >> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov >> 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 >> > > 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 ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 4, 2018 at 9:51 AM, Ian Lepore wrote: > On Sat, 2018-08-04 at 08:56 -0500, Kyle Evans wrote: >> On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > 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 > > > 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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
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 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 > > 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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 04, 2018 at 08:56:58AM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov > 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 > >> 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/efirt_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 I would brace it with #ifdef PHYS_TO_DMAP, #error otherwise. Also, it might make sense to check against dmaplimit as well (on arm64 it is called PHYS_IN_DMAP(), sight). So it might make sense to define MD function in arch/efirt_machdep.c to translate table' address into the KVA. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 4, 2018 at 8:13 AM, Konstantin Belousov 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 >> 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/efirt_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 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 04, 2018 at 08:05:24AM -0500, Kyle Evans wrote: > On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov > 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/efirt_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 ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Sat, Aug 4, 2018 at 3:37 AM, Konstantin Belousov 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/efirt_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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Fri, Aug 03, 2018 at 11:27:02PM -0500, Kyle Evans wrote: > On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote: > > Hi all, > > > > After installing the latest current kernel I get the following panic: > > > > panic: mutex pmap not owned at ... efirt_machdep.c:255 > > cpuid =3 > > time = 1 > > ... > > mtx_assert() > > efi_arch_enter() > > efirt_modevents() > > module_register_init() > > mi_startup() > > btext() > > > > 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/efirt_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. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: mutex pmap not owned at ... efirt_machdep.c:255
On Fri, Aug 3, 2018 at 10:10 PM, Eitan Adler wrote: > Hi all, > > After installing the latest current kernel I get the following panic: > > panic: mutex pmap not owned at ... efirt_machdep.c:255 > cpuid =3 > time = 1 > ... > mtx_assert() > efi_arch_enter() > efirt_modevents() > module_register_init() > mi_startup() > btext() > 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/efirt_machdep.c?view=markup#l254 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
