Re: merge bouyer-xenpvh to HEAD

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

Out of interest, I tried today to build XEN3_PVHVM kernel and got:
...
#      link  XEN3_PVHVM/netbsd
ld -Map netbsd.map --cref -T netbsd.ldscript -Ttext 0xffffffff80200000
-e start -X -o netbsd ${SYSTEM_OBJ:[@]:Nswapnetbsd.o} ${EXTRA_OBJ}
vers.o swapnetbsd.o
ld: hypervisor.o: in function `hypervisor_attach':
hypervisor.c:(.text+0x7be): undefined reference to `xenbus_bus_dma_tag'
*** Error code 1
....


Should I presume I've updated in the wrong moment?


On Wed, 22 Apr 2020 at 22:11, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
>
> On Wed, Apr 22, 2020 at 11:08:27PM +0200, Jaromír Dole?ek wrote:
> > Le mer. 22 avr. 2020 à 22:26, Manuel Bouyer <bouyer%antioche.eu.org@localhost> a écrit :
> > > Maybe the backend block and network drivers too; I think they are protected
> > > by KERNEL_LOCK but I'm not completely sure (especially xbdback).
> >
> > xenneback processing is protected by KERNEL_LOCK, both the event
> > handler and the softint. So should be fine. If we get MULTIPROCESSOR
> > for Dom0 it's also relatively straightforward to adjust to not rely on
> > KERNEL_LOCK.
> >
> > xbdback is actually not MPSAFE. It runs request processing in a kernel
> > thread with held spinlock. The thread is created with KTHREAD_MPSAFE
> > and thus doesn't take KERNEL_LOCK() implicitly. Amusingly enough the
> > only MP-unsafe part is xbdback_iodone(), which takes KERNEL_LOCK()
> > explicitely, but this doesn't prevent the xbdback thread from
> > modifying internal state on other cpu. A quickest fix would be just to
> > remove the KTHREAD_MPSAFE from the thread. I'll fix this up, I'm
> > familiar with the area having recendly done some changes there.
>
> Good, thanks !
>
> --
> Manuel Bouyer <bouyer%antioche.eu.org@localhost>
>      NetBSD: 26 ans d'experience feront toujours la difference
> --



-- 
----