From owner-freebsd-xen@freebsd.org Sun Aug 19 18:50:59 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC4F8107455A for ; Sun, 19 Aug 2018 18:50:58 +0000 (UTC) (envelope-from nathan.friess@gmail.com) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C039854A6 for ; Sun, 19 Aug 2018 18:50:58 +0000 (UTC) (envelope-from nathan.friess@gmail.com) Received: by mail-pf1-x443.google.com with SMTP id b11-v6so5661834pfo.3 for ; Sun, 19 Aug 2018 11:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=sIP71a+fHy9YjMG5XmaBM7snzpe5ucn3rSJ2pG91/0M=; b=QXlo4PCElY7gnR3N+l//W2NqKP/jehMM3ti97zWIQmvpkA9eH+nG1ROlBGfeU4pCII oP21CxL4u838dQjKH1KuFeHWahaTziqqMxLo+24wx13gdr2bHs4/iQ8IavvL56p/Pqd/ O8vjFKuGpzLA0l0eWIYyqkpibD1n64lzvU10qlOcaspmMQeXGONcjmuebsVVgBznrVnl XkY1ghtLSvvGBjnyEaxtz0+kBExdWd0mt1l+od0nnWRtXmbbQg5bqjpsuc+FN84xqM9N jw9cryKNITv9efW6z75gwXgY6mfyXC1Pe9uFFzPL4Y6UN/y3QHzkGdkLNsVlTEpd9VtR lU9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=sIP71a+fHy9YjMG5XmaBM7snzpe5ucn3rSJ2pG91/0M=; b=Khd58iKnUT2RaxWmS/XIx6SiuJ8kPcUkcpAUqT9acRnjwiAZAiGsEWcW/Wf6kq0nYy 3Victe7P4OisRG8b98JBQ73DVflqQpgmbIerzuqJ3SBdzQQQJF6LsRXvTQzy8JpQ4zb0 c4LZJqM4vDiGvuxBA0cO4FBlP3ZNRovm9LRARNgc5547u9E0UWAA1CLqpVBjY/QeQyk+ bYMij+lMXbUj77kM2k4jI63nzyufG5B799o7QLt+LS+fEWQ+vXaI7P/5agNIt+j5Vk9r SnukSwQYKdJ4ZrbzumaioAsn02enD1iNlGr345AbCimDEKloDXnSnFv4lXRkns4Q08ny O7Vg== X-Gm-Message-State: AOUpUlE5aLkYKD3M3u342j4uKgjCAuvw2BnCeBwI73KsdtFU5Yt1eVUD OlMaqv8JUorr+1hKugzlaLE+jlIV X-Google-Smtp-Source: AA+uWPz2r5igQgS9XVLbXCGdTEvuyCuAd/ZEOO/ZeHoGrzyyF1kURSWKBlFjEf1XnG2aNUV5pcjCww== X-Received: by 2002:a63:9248:: with SMTP id s8-v6mr1424470pgn.141.1534704656985; Sun, 19 Aug 2018 11:50:56 -0700 (PDT) Received: from [10.2.1.1] (S01060018e7c4b870.cg.shawcable.net. [70.72.182.108]) by smtp.gmail.com with ESMTPSA id z8-v6sm9520016pfe.163.2018.08.19.11.50.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Aug 2018 11:50:56 -0700 (PDT) To: freebsd-xen@freebsd.org From: Nathan Friess Subject: xen+vimage kernel panic Message-ID: <1f010180-30c3-3a28-a2ca-b9f6279aee9c@gmail.com> Date: Sun, 19 Aug 2018 12:50:55 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2018 18:50:59 -0000 Hi, While testing out the new PVH support in a domU (which is running great!), I discovered a kernel panic related to xen and vimage support when trying to add an xn interface into a bridge. I'm running r337024 from svn. Removing vimage (which seems to be turned on in 12-CURRENT now) allows using the bridge with no panics. As part of attempting to debug this I enabled vimage in my 11.2 domU and that also panics in the same code. I'm not sure if the problem is a xen issue or a vimage issue so I haven't submitted a PR yet. The kernel output is listed below. It looks like netfront_backend_changed() calls netfront_send_fake_arp(), which calls arp_ifinit() on the interface. The first line of the call stack with arprequest+0x454 corresponds to a call to ARPSTAT_INC(txrequests) at the end of arprequest, which expands to VNET_PCPUSTAT_ADD(). I tried to debug further and I got a little lost, but that's where I figured out that vimage is involved somehow. Are there any thoughts on why the xn interface would cause a panic there? Thanks, Nathan ======= Steps to reproduce: # ifconfig bridge create bridge0 # ifconfig bridge0 addm xn0 (panic...) ====== Kernel output: xn0: performing interface reset due to feature change (... lock reversal) xn0: backend features: feature-sg feature-gso-tcp4 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80d15db4 stack pointer = 0x0:0xfffffe0000483840 frame pointer = 0x0:0xfffffe0000483940 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (xenwatch) [ thread pid 14 tid 100033 ] Stopped at arprequest+0x454: movq ll+0x7(%rax),%rax db> bt Tracing pid 14 tid 100033 td 0xfffff800032f5000 arprequest() at arprequest+0x454/frame 0xfffffe0000483940 arp_ifinit() at arp_ifinit+0x58/frame 0xfffffe0000483980 netfront_backend_changed() at netfront_backend_changed+0x144/frame 0xfffffe0000483a40 xenwatch_thread() at xenwatch_thread+0x182/frame 0xfffffe0000483a70 fork_exit() at fork_exit+0x84/frame 0xfffffe0000483ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0000483ab0 ======