Re: Xen 4.8 on -current

Hi,

I went through my configuration with a fine comb, comparing it with a multitude of setups one can easily find on the net - and with the fine manuals, of course. I could not find anything apparently wrong. For the sake of the test I added another DOMU, this time 64 bit, with the same results - the DOMUs communicate fine with the DOM0 and between themselves, but they see only arp traffic from the rest of the wireless network (and the rest of the network also can see their arp requests).

Today it came to me that it might be a peculiarity of the wireless router ( a Virgin SuperHub 3 ) or with the driver wireless interface - iwn - so I switched to wired interface (wm), connected to the same SuperHub 3. The guest networking through the bridge now works as expected, but I am none the wiser as to where the problem is with the wireless interface (I'd rather keep it wireless, don't like CAT5 cables across the room...).

One weird peculiarity of the iwn interface on this laptop is that - while it is kept running all the time and (almost) never loses network connection, the other hosts lose connection to it after they are restarted or came from sleep, the only way of restoring the connection from them to the NetBSD machine is to do a ping from the NetBSD machine to the others... Go figure.

The (almost) above refers to the occasional firmware error this interface gives, perhaps once a week, which is resolved by downing and upping it.

So the question (finally) is: should we expect bridging to work when using a wireless device (especially a iwn driver).

Chavdar Ivanov

On Mon, 31 Jul 2017 at 11:47 Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:

One more hang shutting down the DOMU, happens with 'xl shutdown foo' in the DOMU console:

---
foo# xenbus_shutdown_handler: xenbus_rm 13

*** FINAL System shutdown message from root@foo ***
System going down IMMEDIATELY

power button pressed

Jul 31 10:43:13 foo shutdown: poweroff by root: power button pressed
Jul 31 10:43:21 foo syslogd[189]: Exiting on signal 15
syncing disks... done
xenbus: can't get state for device/suspend/event-channel (2)
➜ xci
----

From this moment onward the system responds to ping and the CR is echoed, but that is all. Only hard reset clears it.

On Mon, 31 Jul 2017 at 09:28 Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
Hi,

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:

create
up
!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.
crash> bt
_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 ).

Any ideas?

Chavdar Ivanov

(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

and

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).