On 30/07/2020 10:37, Mark Kettenis wrote: >> From: Mike Belopuhov <m...@belopuhov.com> >> Date: Thu, 30 Jul 2020 09:21:32 +0200 >> >> On 29/07/2020 15:23, Mark Kettenis wrote: >>>> Date: Wed, 29 Jul 2020 23:01:15 +1000 >>>> From: Jonathan Gray <j...@jsg.id.au> >>>> >>>> On Wed, Jul 29, 2020 at 02:05:18PM +0200, Andre Stoebe wrote: >>>>>> Synopsis: Panic on boot with Hyper-V since Jun 17 snapshot >>>>>> Category: kernel >>>>>> Environment: >>>>> System : OpenBSD 6.7 >>>>> Details : OpenBSD 6.7-current (GENERIC.MP) #375: Sun Jul 26 >>>>> 11:26:37 MDT 2020 >>>>> >>>>> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >>>>> >>>>> Architecture: OpenBSD.amd64 >>>>> Machine : amd64 >>>>>> Description: >>>>> Booting -current on Hyper-V with hvn(4) results in a panic after >>>>> "starting network". >>>>> >>>>> This seems to only affect the multi-user boot; hvn(4) still >>>>> works flawlessly on the ramdisk. >>>>> >>>>> Last working snapshot: >>>>> OpenBSD 6.7-current (GENERIC.MP) #273: Mon Jun 15 19:13:12 MDT 2020 >>>>> >>>>> First non-working snapshot: >>>>> OpenBSD 6.7-current (GENERIC.MP) #278: Wed Jun 17 12:18:35 MDT 2020 >>>>> >>>>> Below is the serial output including ddb trace and ps. >>>>>> How-To-Repeat: >>>>> Boot OpenBSD-current on Hyper-V with a hvn(4) network adapter. >>>>>> Fix: >>>>> Unknown. As a workaround, disabling hvn(4) via "boot -c" does >>>>> not result in a panic. >>>> >>>> more fallout of intr_barrier() now using the argument >>> >>> The change doesn't make an awful lot of sense though. Just like the >>> current code doesn't make any sense since the driver doesn't do >>> interrupts. It is unclear to me what the call is trying to achive. >>> My guess would be that if anything needs to be done here it is >>> flushing any pending work associated with the channel. Which would >>> imply a taskq_barrier() on the task associated with the channel. >>> >>> >> >> Hi Mark, >> >> hvn is interrupt driven; hvn_nvs_intr is the interrupt handler. >> It lacks a conventional PCI interrupt establish dance because of >> Hyper-V specifics: interrupts and device communication happens >> over channels, not conventional buses. > > Ah, now I remember. The interrupts bypass the normal interrupt > establish logic. These interrupts always run on cpu0? >
All interrupts for PV devices are delivered via hv_intr which is called by the IDTVEC(intr_hyperv_upcall) -- a handler for LAPIC_HYPERV_VECTOR interrupt vector. hv_init_interrupts and hv_init_synic set it up for the boot CPU currently. >> I cannot attest to Jonathan's diff, but if that worked for xnf, >> I don't see a reason why it wouldn't work here. > > Slightly better there though since the operation is abstracted into > xen_intr_barrier(). Something similar should be done for hyperv. > > Maybe for now it is good enough to add a hv_channel_intr_barier() > function that takes the channel as an argument and simply calls > sched_barrier(NULL)? > Sure, I must say I haven't followed recent improvements of interrupt barriers, but AFAIR, neither Xen nor Hyper-V codebases aren't really prepared to make a proper use of the intr barrier with an argument. IIRC, these barriers are used to synchronize interrupt threads when disabling interrupts during <if>_stop routines.
