After I managed - with the help of few - to get my old Thinkpad T61p to work fine under -current (with two separate downgrades) I decided - following a recent discussion about hypervisors here - to try again Xen with NetBDSD-current amd64 as DOM0, largely following the Howto document (which is in need of an update - at least to mention that Xen48 is now in pkgsrc). Apart from a few minor problems (i.e. incorrect placement of the ocaml output files in the work tree during compilation, I just copied them where they were expected) all went as expected. I am running now a NetBSD-i386 DOMU which is able to communicate with the DOM0, but for the helll of it I can't figure out how to configure the bridge to pass IP traffic. Bridge(4) says:
Transparent filtering for IP and IPv6 packets can be added with the
kernel configuration option options BRIDGE_IPF.
When filtering is enabled, bridged packets will pass through the filter
inbound on the originating interface and outbound on the appropriate
interfaces. ARP and REVARP packets are forwarded without being filtered and others that are not IP nor IPv6 packets are not forwarded when filtering is enabled.
So with the original netbsd-XEN3PAE_DOMU kernel I can see ARP traffic coming and going (i.e. when an external host tries to ping the DOMU I cn see the arp packet coming into the DOMU, when the DOMU tries to ping an external host I can see its arp packet on that host interface - with tcpdump). As I said earlier, the networking between the DOM0 and DOMU works fine. Then I modified the XEN3PAE kernel to include BRIDGE_IPF and also the options for pf - but I could not get any third party packets to or from the DOMU.
The ifconfig.bridge0 is as follows:
!brconfig bridge0 add iwn0
I don't know if it is significant that the interface in this case is wireless.
Besides that, I got one panic apparently ACPI related of the DOM0:
crash crash -M netbsd.1.core -N netbsd.1
Crash version 8.99.1, image version 8.99.1.
System panicked: trap
Backtrace from time of crash is available.
_KERNEL_OPT_NARCNET() at 0
_KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x5
vpanic() at vpanic+0x149
snprintf() at snprintf
trap() at trap+0xc6b
--- trap (number 6) ---
ahci_intr_port() at ahci_intr_port+0x1e
ahci_intr() at ahci_intr+0xa5
intr_biglock_wrapper() at intr_biglock_wrapper+0x1d
Xintr_ioapic_level3() at Xintr_ioapic_level3+0xf2
--- interrupt ---
x86_mwait() at x86_mwait+0xd
acpicpu_cstate_idle_enter() at acpicpu_cstate_idle_enter+0xdb
acpicpu_cstate_idle() at acpicpu_cstate_idle+0xb6
idle_loop() at idle_loop+0x18c
There are a lot of ACPI error messages in the DOM0 dmesg, so I wasn't too bothered with it, and it happened only once, I have since been able to do a full sysbuild under the DOM0 kernel). There were also a couple of hangs of the DOM0, apparently taking place when the DOMU is being shut down or poweroff-ed, resulting in a system responding to pings, but otherwise unable to do anything - just echoing the CR (I've interrupted this and took a screenshot of the trace here - http://bit.ly/2tVxnvX
(I don't know if current-users is the best list to post this, but as both domains are
NetBSD nt61p 8.99.1 NetBSD 8.99.1 (MYXEN) #0: Sun Jul 30 23:46:27 UTC 2017 root@nt61p:/usr/src/sys/arch/amd64/compile/MYXEN amd64
NetBSD foo 8.99.1 NetBSD 8.99.1 (XEN3PAE_DOMU) #1: Tue Jul 25 17:56:26 UTC 2017 sysbuild@nt61p:/home/sysbuild/i386/obj/home/sysbuild/src/sys/arch/i386/compile/XEN3PAE_DOMU i386
it probably is).