At Tue, 26 Dec 2023 12:21:15 -0800, "Greg A. Woods" <woods%planix.ca@localhost> wrote: Subject: Re: Problems booting netbsd DOM0 > > This is the fix in NetBSD which avoids generating this "vec 13"/#13 > general protection fault/trap during early initialisation, which I found > by manually going through all of the seemingly Xen-related pullups > between 9.2 and 9.3: So first off I find this fix is also needed for XEN3_DOMU kernels, _unless_ "msr_relaxed = 1" is set in the domU's config file. Which brings me to realize "dom0=msr_relaxed" on the Xen command line should have allowed the older XEN3_DOM0 kernel to boot, and I thought I had tried that but it didn't work (though perhaps I got the syntax wrong). Anyway my patched XEN3_DOM0, as well as the 9.3 and 10.0_RC2 versions, all boot a dom0 under Xen 4.18. So, also, my initial need to upgrade Xen was to get rid of "xvif... GNTTABOP_copy[0] Rx -3" error storms (that sometimes were so heavy as to cause the Xen watchdog to trigger a reboot!). My understanding was this was patched in Xen: https://xenbits.xen.org/xsa/xsa318.patch And that this patch is in Xen-4.18 too. However it seems one of the other 9.2->9.3 pullups might also be involved? Anyway when I boot an older domU, with "msr_relaxed = 1" to avoid the vec-13 GPF, I still get GNTTABOP_copy error storms: /netbsd: [ 9985.9592949] xbd backend: attach device vnd1d (size 5441536) for domain 9 /netbsd: [ 9985.9792793] xvif9i0: Ethernet address 00:16:3e:71:d1:31 /netbsd: [ 9988.7694590] event_set_handler: id:xenev0 chan 50, xname:xbdb9i4, handler:(*0xffffffff80218375)(), evtch 50, level 6 /netbsd: [ 9988.7694590] event_set_handler: id:xenev0 chan 50, xname:xbdb9i4, attaching and binding evtch 50 to current VCPU vcpu0 0 /netbsd: [ 9988.7694590] xbd backend domain 9 handle 0x4 (4) using event channel 50, protocol x86_64-abi /netbsd: [ 9988.7794602] event_set_handler: id:xenev0 chan 51, xname:xvif9i0, handler:(*0xffffffff80216d17)(), evtch 51, level 6 /netbsd: [ 9988.7794602] event_set_handler: id:xenev0 chan 51, xname:xvif9i0, attaching and binding evtch 51 to current VCPU vcpu0 0 /netbsd: [ 10440.8883908] xvif9i0 GNTTABOP_copy[0] Rx -3 syslogd[616]: last message repeated 3 times /netbsd: [ 10441.4084239] xvif9i0 GNTTABOP_copy[0] Rx -3 [[ ... and on and on until I destroy the domU ... ]] Can anyone confirm if there are related GNTTABOP_copy NetBSD changes too? I don't want to try to upgrade a production Xen box without knowing for sure I've got rid of the GNTTABOP_copy error storms! -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp4LvRv9vtSw.pgp
Description: OpenPGP Digital Signature