RE: [EXTERNAL] Re: enabling same PPI interrupt to all CPU in ARM64 SMP

>-----Original Message-----
>From: Kyle Evans <kevans@freebsd.org>
>Sent: Monday, May 15, 2023 11:05 PM
>To: Souradeep Chakrabarti <schakrabarti@microsoft.com>
>Cc: Wei Hu <weh@microsoft.com>; freebsd-hackers@FreeBSD.org
>Subject: Re: [EXTERNAL] Re: enabling same PPI interrupt to all CPU in ARM64 SMP
>
>On Mon, May 15, 2023 at 12:27 PM Souradeep Chakrabarti
><schakrabarti@microsoft.com> wrote:
>>
>>
>>
>>
>> >-----Original Message-----
>> >From: owner-freebsd-hackers@freebsd.org
>> ><owner-freebsd-hackers@freebsd.org>
>> >On Behalf Of Souradeep Chakrabarti
>> >Sent: Monday, May 15, 2023 10:37 PM
>> >To: Kyle Evans <kevans@freebsd.org>
>> >Cc: Wei Hu <weh@microsoft.com>; freebsd-hackers@FreeBSD.org
>> >Subject: RE: [EXTERNAL] Re: enabling same PPI interrupt to all CPU in
>> >ARM64 SMP
>> >
>> >
>> >
>> >
>> >>-----Original Message-----
>> >>From: Kyle Evans <kevans@freebsd.org>
>> >>Sent: Monday, May 15, 2023 7:24 PM
>> >>To: Souradeep Chakrabarti <schakrabarti@microsoft.com>
>> >>Cc: Wei Hu <weh@microsoft.com>; freebsd-hackers@FreeBSD.org
>> >>Subject: Re: [EXTERNAL] Re: enabling same PPI interrupt to all CPU
>> >>in
>> >>ARM64 SMP
>> >>
>> >[Souradeep] It has worked! Thanks a lot. We should get it committed in src.
>> >Before I commit the SMP related changes for Hyper-V driver.
>> >>Thanks,
>>
>
>Awesome- I posted the PPI patch for review here:
>https://reviews.fr/
>eebsd.org%2FD40112&data=05%7C01%7Cschakrabarti%40microsoft.com%7Cfda
>4373a3bcc4c609d4008db556abf09%7C72f988bf86f141af91ab2d7cd011db47%
>7C1%7C0%7C638197689239710088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%
>7C%7C%7C&sdata=9zvKA%2BnmS1j6ENQiP4bLxd1lTCWmMhxWYTD4wAI90kc%3
>D&reserved=0 -- I'm travelling to Ottawa for most of today and tomorrow, but we'll
>see if we can get this taken care of this week.
>
>> [Souradeep] But after install it is keep getting rebooted after
>> hitting a panic
>>
>>
>> mbus0: vmbus_handle_intr1 for cpu 0
>> vmbus0: the irq 18
>> vmbus0: smp_started = 0
>> KDvmbus0: vmbus_handle_intr1 for cpu 0
>> B: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>> mi_switch() at mi_switch+0x27c
>> sleepq_switch() at sleepq_switch+0xfc
>> _sleep() at _sleep+0x294
>> vmbus_xact_wait1() at vmbus_xact_wait1+0x120
>> vmbus_sysinit() at vmbus_sysinit+0x6a4
>> mi_startup() at mi_startup+0x1fc
>> virtdone() at virtdone+0x70
>> KDB: reentering
>> KDB: stack backtrace:
>> db_trace_self() at db_trace_self
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x30
>> kdb_reenter() at kdb_reenter+0x44
>> mi_switch() at mi_switch+0x280
>> sleepq_switch() at sleepq_switch+0xfc
>> _sleep() at _sleep+0x294
>> vmbus_xact_wait1() at vmbus_xact_wait1+0x120
>> vmbus_sysinit() at vmbus_sysinit+0x6a4
>> mi_startup() at mi_startup+0x1fc
>> virtdone() at virtdone+0x70
>>
>> Looks like vmbus_sysinit() is getting called even before SMP has started after
>installation.
>> Wondering what could be the reason.
>> Also any idea how to disable this reboot cycle post post panic, so that I can get the
>backtrace properly.
>
>Odd- I thought we had pushed that back to SI_SUB_SMP late or SI_SUB_SMP + 1.
>The backtrace here looks reasonably complete-
>mi_startup() does invoke sysinits directly. Can you post your full diff against
>sys/dev/hyperv somewhere, please?
[Souradeep]  I have pasted my diff here https://pastebin.com/BNUQLGD1 .
Also this time panic was different after install : https://pastebin.com/CEmTM1sa .
>
>Thanks,
>
>Kyle Evans