Re: Per-cpu IDT patch

s ymgch <[email protected]>
Newsgroups gmane.os.netbsd.ports.x86-64,gmane.os.netbsd.ports.i386
Message-ID <CAPnD6HqE6y7drg17Z94F1yXVqaZiTv7HTdqHd_fHg9g23UCqmQ@mail.gmail.com>
Hi,

I'm going to commit this in the beginning of next week
if there are no other problems or worries.

Best regards,
-- yamaguchi

On Thu, Jul 9, 2020 at 5:32 AM Frank Kardel <[email protected]> wrote:
>
> Great - works now - Thanks!
>
> Frank
>
>
> On 07/08/20 13:13, Jaromír Doleček wrote:
> > I've just committed a fix for sys/arch/xen/x86/cpu.c to avoid
> > triggering the KASSERT(). It was just missing initialization for the
> > Xen variant, overlooked when the fpu_kern_enter() API was added in
> > November 2019.
> >
> > Jaromir
> >
> > Le mer. 8 juil. 2020 à 12:31, Frank Kardel <[email protected]> a écrit :
> >> The patched GENERIC kernel booted fine directly.
> >>
> >> A patches XEN3_DOM0 kernel with Xen 4.11 hypervisor paniced. That's why
> >>
> >> I am suspecting Xen/AES changes.
> >>
> >> Frank
> >>
> >>
> >>
> >> On 07/08/20 12:10, s ymgch wrote:
> >>> On Mon, Jul 6, 2020 at 10:45 PM Frank Kardel <[email protected]> wrote:
> >>>> Nice progress here:
> >>>>
> >>>> On bare metal 9.99.69 GENERIC boots sees all ixl, wm and nvme devices
> >>>> with all their interrupts initialized - great.
> >>>>
> >>>> BUT... 9.99.69-XEN3_DOM0 digs out following panic:
> >>>>
> >>>> [   2.0100519] panic: kernel diagnostic assertion "ci->ci_kfpu_spl ==
> >>>> -1" failed: file "/src/NetBSD/cur/src/sys/arch/x86/x86/fpu.c", line 389
> >>>> [   2.0100519] cpu3: Begin traceback...
> >>>> [   2.0100519] vpanic() at netbsd:vpanic+0x146
> >>>> [   2.0100519] kern_assert() at netbsd:kern_assert+0x48
> >>>> [   2.0100519] fpu_kern_enter() at netbsd:fpu_kern_enter+0x190
> >>>> [   2.0100519] cpu3: Begin traceback...
> >>>> [   2.0100519] vpanic() at netbsd:vpanic+0x146
> >>>> [   2.0100519] kern_assert() at netbsd:kern_assert+0x48
> >>>> [   2.0100519] fpu_kern_enter() at netbsd:fpu_kern_enter+0x190
> >>>> [   2.0100519] aesni_probe() at netbsd:aesni_probe+0x28
> >>>> [   2.0100519] aes_selftest() at netbsd:aes_selftest+0x13
> >>>> [   2.0100519] aes_modcmd() at netbsd:aes_modcmd+0xff
> >>>> [   2.0100519] module_do_builtin() at netbsd:module_do_builtin+0x173
> >>>> [   2.0100519] module_do_builtin() at netbsd:module_do_builtin+0x12e
> >>>> [   2.0100519] module_init_class() at netbsd:module_init_class+0x145
> >>>> [   2.0100519] main() at netbsd:main+0x472
> >>>> [   2.0100519] cpu3: End traceback...
> >>>> [   2.0100519] fatal breakpoint trap in supervisor mode
> >>>> [   2.0100519] trap type 1 code 0 rip 0xffffffff8023c93d cs 0xe030
> >>>> rflags 0x202 cr2 0 ilevel 0x8 rsp 0xffffffff81981af0
> >>>> [   2.0100519] curlwp 0xffffffff80e5c6c0 pid 0.0 lowest kstack
> >>>> 0xffffffff8197d2c0
> >>>> Stopped in pid 0.0 (system) at  netbsd:breakpoint+0x5:  leave
> >>> Did it only appear when you applied my patch?
> >>> It seems that the assertion happens not in IDT but fpu.
> >>>
> >>> -- yamaguchi
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.