From owner-freebsd-xen@FreeBSD.ORG Sun Jan 29 12:16:57 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A4A2106566B for ; Sun, 29 Jan 2012 12:16:57 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from alpha.tao.org.uk (alpha.tao.org.uk [95.154.203.106]) by mx1.freebsd.org (Postfix) with ESMTP id BD7218FC12 for ; Sun, 29 Jan 2012 12:16:56 +0000 (UTC) Received: from localhost (alpha.tao.org.uk [95.154.203.106]) by alpha.tao.org.uk (Postfix) with ESMTP id 43A841738C; Sun, 29 Jan 2012 11:59:09 +0000 (GMT) Received: from alpha.tao.org.uk ([95.154.203.106]) by localhost (mail.tao.org.uk [95.154.203.106]) (amavisd-maia, port 10024) with LMTP id 02199-02; Sun, 29 Jan 2012 11:58:51 +0000 (GMT) Received: from p4.dhcp.tao.org.uk (p4.dhcp.tao.org.uk [90.155.77.83]) (Authenticated sender: joemail@alpha.tao.org.uk) by alpha.tao.org.uk (Postfix) with ESMTPA id 1C58117387; Sun, 29 Jan 2012 11:58:50 +0000 (GMT) From: Dr Josef Karthauser Date: Sun, 29 Jan 2012 11:59:18 +0000 To: freebsd-xen@freebsd.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: Maia Mailguard 1.0.2a Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems booting a HVM kernel (8.2) : run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 12:16:57 -0000 I'm trying to boot 8.2 on a XEN HVM kernel, but I'm getting this message = at kernel boot time, and the system is hanging: run_interrupt_driven_hooks: still waiting after 60 seconds for = xenbusb_nop_confighook_cb I've found this thread from May last year: = http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000926.html Am I right in thinking that this is a bug in XEN, rather than a FreeBSD = issue? Do I need to get my hosting provider to upgrade their = environment? I'm desperate for xen native drivers as the qemu disk drivers are = causing me serious performance problems with the ZFS setup I've got. Thanks, Joe= From owner-freebsd-xen@FreeBSD.ORG Sun Jan 29 12:16:57 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A6A3106566C for ; Sun, 29 Jan 2012 12:16:57 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from alpha.tao.org.uk (alpha.tao.org.uk [95.154.203.106]) by mx1.freebsd.org (Postfix) with ESMTP id BD6BF8FC0C for ; Sun, 29 Jan 2012 12:16:56 +0000 (UTC) Received: from localhost (alpha.tao.org.uk [95.154.203.106]) by alpha.tao.org.uk (Postfix) with ESMTP id A5F1A1738E; Sun, 29 Jan 2012 11:59:11 +0000 (GMT) Received: from alpha.tao.org.uk ([95.154.203.106]) by localhost (mail.tao.org.uk [95.154.203.106]) (amavisd-maia, port 10024) with LMTP id 02200-01; Sun, 29 Jan 2012 11:58:50 +0000 (GMT) Received: from p4.dhcp.tao.org.uk (p4.dhcp.tao.org.uk [90.155.77.83]) (Authenticated sender: joemail@alpha.tao.org.uk) by alpha.tao.org.uk (Postfix) with ESMTPA id 835E61737B; Sun, 29 Jan 2012 11:58:47 +0000 (GMT) From: Dr Josef Karthauser Date: Sun, 29 Jan 2012 11:59:13 +0000 To: freebsd-xen@freebsd.org Message-Id: <0527BE7A-19DC-4A25-B2B7-608AACF6AAFA@tao.org.uk> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: Maia Mailguard 1.0.2a Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems booting a HVM kernel (8.2) : run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Jan 2012 12:16:57 -0000 I'm trying to boot 8.2 on a XEN HVM kernel, but I'm getting this message = at kernel boot time, and the system is hanging: run_interrupt_driven_hooks: still waiting after 60 seconds for = xenbusb_nop_confighook_cb I've found this thread from May last year: = http://lists.freebsd.org/pipermail/freebsd-xen/2011-May/000926.html Am I right in thinking that this is a bug in XEN, rather than a FreeBSD = issue? Do I need to get my hosting provider to upgrade their = environment? I'm desperate for xen native drivers as the qemu disk drivers are = causing me serious performance problems with the ZFS setup I've got. Thanks, Joe= From owner-freebsd-xen@FreeBSD.ORG Mon Jan 30 11:07:58 2012 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 404F91065677 for ; Mon, 30 Jan 2012 11:07:58 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 137BB8FC0C for ; Mon, 30 Jan 2012 11:07:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UB7vlX005623 for ; Mon, 30 Jan 2012 11:07:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UB7vPP005621 for freebsd-xen@FreeBSD.org; Mon, 30 Jan 2012 11:07:57 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Jan 2012 11:07:57 GMT Message-Id: <201201301107.q0UB7vPP005621@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-xen@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jan 2012 11:07:58 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/164531 xen [xen] [panic] Boot time crash using XEN HVM enabled ke o kern/164450 xen [xen] Failed to install FreeeBSD 9.0-RELEASE from CD i o kern/162677 xen [xen] FreeBSD not compatible with "Current Stable Xen" o kern/161318 xen [xen] sysinstall crashes with floating point exception o kern/155468 xen [xen] Xen PV i386 multi-kernel CPU system is not worki o kern/155353 xen [xen] [patch] put "nudging TOD" message under boot_ver o kern/154833 xen [xen]: xen 4.0 - DomU freebsd8.2RC3 i386, XEN kernel. o kern/154473 xen [xen] xen 4.0 - DomU freebsd8.1 i386, XEN kernel. Not o kern/154472 xen [xen] xen 4.0 - DomU freebsd8.1 i386 xen kernel reboot o kern/154428 xen [xen] xn0 network interface and PF - Massive performan o kern/153674 xen [xen] i386/XEN idle thread shows wrong percentages o kern/153672 xen [xen] [panic] i386/XEN panics under heavy fork load o kern/153620 xen [xen] Xen guest system clock drifts in AWS EC2 (FreeBS o kern/153477 xen [xen] XEN pmap code abuses vm page queue lock o kern/153150 xen [xen] xen/ec2: disable checksum offloading on interfac o kern/152228 xen [xen] [panic] Xen/PV panic with machdep.idle_mwait=1 o kern/144629 xen [xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor o kern/143398 xen [xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor o kern/143340 xen [xen] FreeBSD 8-RELEASE XEN pvm networking doesn't wor f kern/143069 xen [xen] [panic] Xen Kernel Panic - Memory modified after f kern/135667 xen ufs filesystem corruption on XEN DomU system f kern/135421 xen [xen] FreeBSD Xen PVM DomU network failure - netfronc. f kern/135178 xen [xen] Xen domU outgoing data transfer stall when TSO i p kern/135069 xen [xen] FreeBSD-current/Xen SMP doesn't function at all f i386/124516 xen [xen] FreeBSD-CURRENT Xen Kernel Segfaults when config o kern/118734 xen [xen] FreeBSD 6.3-RC1 and FreeBSD 7.0-BETA 4 fail to b 26 problems total. From owner-freebsd-xen@FreeBSD.ORG Mon Jan 30 16:56:46 2012 Return-Path: Delivered-To: freebsd-xen@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA2741065670; Mon, 30 Jan 2012 16:56:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9F63F8FC14; Mon, 30 Jan 2012 16:56:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0UGukA1033914; Mon, 30 Jan 2012 16:56:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0UGukkR033910; Mon, 30 Jan 2012 16:56:46 GMT (envelope-from linimon) Date: Mon, 30 Jan 2012 16:56:46 GMT Message-Id: <201201301656.q0UGukkR033910@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-xen@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/164630: [xen] XEN HVM kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Mon, 30 Jan 2012 16:56:46 -0000 Old Synopsis: XEN HVM kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb New Synopsis: [xen] XEN HVM kernel: run_interrupt_driven_hooks: still waiting after 60 seconds for xenbusb_nop_confighook_cb Responsible-Changed-From-To: freebsd-bugs->freebsd-xen Responsible-Changed-By: linimon Responsible-Changed-When: Mon Jan 30 16:56:34 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=164630 From owner-freebsd-xen@FreeBSD.ORG Tue Jan 31 10:10:15 2012 Return-Path: Delivered-To: freebsd-xen@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06C2F106567B for ; Tue, 31 Jan 2012 10:10:15 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB3358FC12 for ; Tue, 31 Jan 2012 10:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0VAAEGh017530 for ; Tue, 31 Jan 2012 10:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0VAAEjX017529; Tue, 31 Jan 2012 10:10:14 GMT (envelope-from gnats) Date: Tue, 31 Jan 2012 10:10:14 GMT Message-Id: <201201311010.q0VAAEjX017529@freefall.freebsd.org> To: freebsd-xen@FreeBSD.org From: Sergey Kandaurov Cc: Subject: Re: kern/164531: [xen] [panic] Boot time crash using XEN HVM enabled kernel. X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sergey Kandaurov 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: Tue, 31 Jan 2012 10:10:15 -0000 The following reply was made to PR kern/164531; it has been noted by GNATS. From: Sergey Kandaurov To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/164531: [xen] [panic] Boot time crash using XEN HVM enabled kernel. Date: Tue, 31 Jan 2012 13:07:54 +0300 ---------- Forwarded message ---------- From: Dr Josef Karthauser Date: 31 January 2012 12:59 Subject: Re: kern/164531: [xen] [panic] Boot time crash using XEN HVM enabled kernel. To: Sergey Kandaurov Yes, this works. The patch applied cleanly to 8.2, and the ethernet device probes properly now. (Can we get this MFC'd to 8.2?) From owner-freebsd-xen@FreeBSD.ORG Tue Jan 31 10:49:17 2012 Return-Path: Delivered-To: freebsd-xen@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3F2F1065670; Tue, 31 Jan 2012 10:49:17 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 806F48FC15; Tue, 31 Jan 2012 10:49:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0VAnH1H057481; Tue, 31 Jan 2012 10:49:17 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0VAnH16057476; Tue, 31 Jan 2012 10:49:17 GMT (envelope-from pluknet) Date: Tue, 31 Jan 2012 10:49:17 GMT Message-Id: <201201311049.q0VAnH16057476@freefall.freebsd.org> To: joe@tao.org.uk, pluknet@FreeBSD.org, freebsd-xen@FreeBSD.org From: pluknet@FreeBSD.org Cc: Subject: Re: kern/164531: [xen] [panic] Boot time crash using XEN HVM enabled kernel. X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 31 Jan 2012 10:49:17 -0000 Synopsis: [xen] [panic] Boot time crash using XEN HVM enabled kernel. State-Changed-From-To: open->patched State-Changed-By: pluknet State-Changed-When: Tue Jan 31 10:48:11 UTC 2012 State-Changed-Why: Reflect that the fix is available in HEAD and 9.0 release. http://www.freebsd.org/cgi/query-pr.cgi?pr=164531 From owner-freebsd-xen@FreeBSD.ORG Tue Jan 31 17:32:40 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CB6A1065670 for ; Tue, 31 Jan 2012 17:32:40 +0000 (UTC) (envelope-from baryluk@smp.if.uj.edu.pl) Received: from smp.if.uj.edu.pl (smp.if.uj.edu.pl [149.156.82.206]) by mx1.freebsd.org (Postfix) with ESMTP id 378A38FC15 for ; Tue, 31 Jan 2012 17:32:39 +0000 (UTC) Received: from users.smp.if.uj.edu.pl (users.smp.if.uj.edu.pl [::ffff:10.0.1.244]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by smp.if.uj.edu.pl with esmtp; Tue, 31 Jan 2012 18:22:34 +0100 id 0001C724.4F28235A.00003D0E Received: from baryluk by users.smp.if.uj.edu.pl with local (Exim 4.72) (envelope-from ) id 1RsHPd-0007pb-7C for freebsd-xen@FreeBSD.org; Tue, 31 Jan 2012 18:22:33 +0100 Date: Tue, 31 Jan 2012 18:22:32 +0100 From: Witold Baryluk To: freebsd-xen@FreeBSD.org Message-ID: <20120131172232.GE12978@smp.if.uj.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Is there any prebuild 9.0 PV i386 kernel image? X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 31 Jan 2012 17:32:40 -0000 Hi, I wanted to install FreeBSD 9.0 on my machine with xen 4.1 (Debian testing) on i386 hardware. However only thing I found is a this files: Index of /pub/FreeBSD/releases/i386/i386/ISO-IMAGES/9.0/ Name Size Date Modified [parent directory] CHECKSUM.MD5 309 B 1/7/12 12:44:00 AM CHECKSUM.SHA256 449 B 1/7/12 12:46:00 AM FreeBSD-9.0-RELEASE-i386-bootonly.iso 128 MB 1/3/12 8:51:00 AM FreeBSD-9.0-RELEASE-i386-disc1.iso 502 MB 1/3/12 8:50:00 AM FreeBSD-9.0-RELEASE-i386-dvd1.iso 2.1 GB 1/7/12 12:41:00 AM FreeBSD-9.0-RELEASE-i386-memstick.img 535 MB 1/3/12 8:51:00 AM There is kernel.txz archive also, but it just contains single binary kernel image. There is probably also sources easly available, but I do not think it is possible to cross-compile easly FreeBSD on Linux like netbsd, isn't it? Anyway it is unacasarly complicated. NetBSD or many Linux distros (like Debian), provides kernel/initrd for installation/running just in Xen PV, to make it easier. I found a one kernel in Debian: http://packages.debian.org/sid/kfreebsd-image-9.0-1-xen it actually can be installed as package on Linux i386, and easly used for Xen! It booted for me without much problem: movax-dev:/etc/xen# cat kfreebsd9.cfg name = "kfreebsd9" kernel = "/boot/kfreebsd-9.0-1-xen.gz" memory = 256 movax-dev:/etc/xen# xl create kfreebsd9.cfg -c Parsing config file kfreebsd9.cfg xc: error: panic: xc_dom_bzimageloader.c:556: xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel Daemon running with PID 10546 WARNING: loader(8) metadata is missing! GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. #0 Sat Jan 7 14:06:17 UTC 2012 i386 Xen reported: 2793.110 MHz processor. Timecounter "ixen" frequency 1953125 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.11-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf41 Family = f Model = 4 Stepping = 1 Features=0xbfe3fbff Features2=0x441d AMD Features=0x100000 real memory = 268435456 (256 MB) avail memory = 254488576 (242 MB) [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) xenstore0: on motherboard [XEN] xen_rtc_probe: probing Hypervisor RTC clock rtc0: on motherboard [XEN] xen_rtc_attach: attaching Hypervisor RTC clock xc0: on motherboard Event timer "ixen" quality 600 Timecounters tick every 10.000 msec xenbusb_back0: on xenstor[XEN] hypervisor wallclock nudged; nudging TOD. e0 xctrl0: on xenstore0 xenbusb_front0: on xenstore0 xenbusb_add_device: Device device/suspend/event-channel ignored. State 6 Timecounter "TSC" frequency 2793110000 Hz quality 800 Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> panic: mountroot: unable to (re-)mount root. cpuid = 0 KDB: enter: panic [ thread pid 1 tid 100002 ] Stopped at kdb_enter+0x38: movl $0,kdb_why db> halt movax-dev:/etc/xen# In fact after some more work, I was even able to boot it, and run installer, with Debian's kfreebsd kernel image, and *-dvd1.iso image as sdb, with additional extra = "vfs.root.mountfrom=cd9660:/dev/da1"! :) Installation over serial console works (I selected 'xterm' terminal, and everythings looks to be workking nicly, with colors and arrow keys). Only technical problem so far is that I sometimes get: "[XEN] hypervisor wallclock nudged; nudging TOD." from kernel. It looks same message like reported by Colin: http://lists.freebsd.org/pipermail/freebsd-xen/2010-November/000613.html however I cannot find any solution to it. I still miss upstream binary image for exactly same purpose (because kfreebsd != FreeBSD, and other distributions which uses Xen could also benefit by upstream suplied images), and better documentation in handbook (there is literaly zero informations about Xen or serial console installation in handbook) -- Witold Baryluk JID: witold.baryluk // jabster.pl From owner-freebsd-xen@FreeBSD.ORG Tue Jan 31 18:20:14 2012 Return-Path: Delivered-To: freebsd-xen@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E49D1065676 for ; Tue, 31 Jan 2012 18:20:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 628D28FC08 for ; Tue, 31 Jan 2012 18:20:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q0VIKEn3073391 for ; Tue, 31 Jan 2012 18:20:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q0VIKEF8073390; Tue, 31 Jan 2012 18:20:14 GMT (envelope-from gnats) Date: Tue, 31 Jan 2012 18:20:14 GMT Message-Id: <201201311820.q0VIKEF8073390@freefall.freebsd.org> To: freebsd-xen@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/154302: commit references a PR X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service 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: Tue, 31 Jan 2012 18:20:14 -0000 The following reply was made to PR kern/154302; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154302: commit references a PR Date: Tue, 31 Jan 2012 18:13:59 +0000 (UTC) Author: gibbs Date: Tue Jan 31 18:13:49 2012 New Revision: 230831 URL: http://svn.freebsd.org/changeset/base/230831 Log: MFC r225708 into stable/8: Modify the netfront driver so it can successfully attach to PV devices with the ioemu attribute set. sys/dev/xen/netfront/netfront.c: o If a mac address for the interface cannot be found in the front-side XenStore tree, look for an entry in the back-side tree. With ioemu devices, the emulator does not populate the front side tree and neither does Xend. o Return an error rather than panic when an attach attempt fails. Reported by: Janne Snabb (fix inspired by patch provided) PR: kern/154302 Modified: stable/8/sys/dev/xen/netfront/netfront.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) Modified: stable/8/sys/dev/xen/netfront/netfront.c ============================================================================== --- stable/8/sys/dev/xen/netfront/netfront.c Tue Jan 31 17:51:30 2012 (r230830) +++ stable/8/sys/dev/xen/netfront/netfront.c Tue Jan 31 18:13:49 2012 (r230831) @@ -402,11 +402,33 @@ xen_net_read_mac(device_t dev, uint8_t m { int error, i; char *s, *e, *macstr; + const char *path; - error = xs_read(XST_NIL, xenbus_get_node(dev), "mac", NULL, - (void **) &macstr); - if (error) + path = xenbus_get_node(dev); + error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr); + if (error == ENOENT) { + /* + * Deal with missing mac XenStore nodes on devices with + * HVM emulation (the 'ioemu' configuration attribute) + * enabled. + * + * The HVM emulator may execute in a stub device model + * domain which lacks the permission, only given to Dom0, + * to update the guest's XenStore tree. For this reason, + * the HVM emulator doesn't even attempt to write the + * front-side mac node, even when operating in Dom0. + * However, there should always be a mac listed in the + * backend tree. Fallback to this version if our query + * of the front side XenStore location doesn't find + * anything. + */ + path = xenbus_get_otherend_path(dev); + error = xs_read(XST_NIL, path, "mac", NULL, (void **) &macstr); + } + if (error != 0) { + xenbus_dev_fatal(dev, error, "parsing %s/mac", path); return (error); + } s = macstr; for (i = 0; i < ETHER_ADDR_LEN; i++) { @@ -447,7 +469,7 @@ netfront_attach(device_t dev) err = create_netdev(dev); if (err) { xenbus_dev_fatal(dev, err, "creating netdev"); - return err; + return (err); } #if __FreeBSD_version >= 700000 @@ -457,7 +479,7 @@ netfront_attach(device_t dev) &xn_enable_lro, 0, "Large Receive Offload"); #endif - return 0; + return (0); } @@ -2020,11 +2042,8 @@ create_netdev(device_t dev) } err = xen_net_read_mac(dev, np->mac); - if (err) { - xenbus_dev_fatal(dev, err, "parsing %s/mac", - xenbus_get_node(dev)); + if (err) goto out; - } /* Set up ifnet structure */ ifp = np->xn_ifp = if_alloc(IFT_ETHER); @@ -2066,8 +2085,7 @@ create_netdev(device_t dev) exit: gnttab_free_grant_references(np->gref_tx_head); out: - panic("do something smart"); - + return (err); } /** _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-xen@FreeBSD.ORG Tue Jan 31 20:36:56 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 157A41065672 for ; Tue, 31 Jan 2012 20:36:56 +0000 (UTC) (envelope-from got.andras@deployis.eu) Received: from mail.deployis.eu (mail.deployis.eu [217.20.135.253]) by mx1.freebsd.org (Postfix) with ESMTP id 760058FC15 for ; Tue, 31 Jan 2012 20:36:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=deployis.eu; s=default; h=Message-ID:References:In-Reply-To:Subject:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=x8IfkZS9NpqZuuXGX9X2/PEh4mYbIwarkcD6SdqIs7w=; b=Zt14aR3+lR2xxogqd3jJ6w9bLtO637ckoILMF4ykLF15evGbHO1mGtyROyBq/mPWaNfmrbhhV8rOMcWUJClKpcIrnXz2SLOdlpV98M4llCOhwyOwtJxnJTnxSgCDsKiI; Authentication-Results: mail.deployis.eu dkim=none Received: from localhost ([127.0.0.1]:54302 helo=mail.deployis.eu) by mail.deployis.eu with esmtp (Exim 4.71 #1 (Debian)) id 1RsJkw-0007qW-MY from for ; Tue, 31 Jan 2012 20:52:43 +0100 Received: from pool-232-162.ippark.hu ([31.223.232.162]) by mail.deployis.eu with HTTP (HTTP/1.1 POST); Tue, 31 Jan 2012 20:52:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 31 Jan 2012 20:52:42 +0100 From: =?UTF-8?Q?G=C3=B3t_Andr=C3=A1s?= To: In-Reply-To: <20120131172232.GE12978@smp.if.uj.edu.pl> References: <20120131172232.GE12978@smp.if.uj.edu.pl> Message-ID: <079aa81f893021a200468e57199401fb@deployis.eu> X-Sender: got.andras@deployis.eu User-Agent: RoundCube Webmail/0.2.1 X-Mail-Status-postahivatal: trustedmail (from 127.0.0.1) X-Spam-Score-postahivatal: -43 Subject: Re: Is there any prebuild 9.0 PV i386 kernel image? X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Tue, 31 Jan 2012 20:36:56 -0000 Hi, You may install a "provisioning" HVM instance where you can mount a disk/filesystem. After you compiled the source you can make installworld/installkernel DESTDIR=mynewsystempath and there you go. Also don't forget a make distribution. :) After this you can easily do an image with dd if you're also using LVM for XEN "disks". The provisioning HVM instance might come handy any you have a problem with a PV instance. Regards, Andras On Tue, 31 Jan 2012 18:22:32 +0100, Witold Baryluk wrote: > Hi, > > I wanted to install FreeBSD 9.0 on my machine with xen 4.1 (Debian > testing) > on i386 hardware. However only thing I found is a this files: > > Index of /pub/FreeBSD/releases/i386/i386/ISO-IMAGES/9.0/ > Name Size Date Modified > [parent directory] > CHECKSUM.MD5 309 B 1/7/12 12:44:00 AM > CHECKSUM.SHA256 449 B 1/7/12 12:46:00 AM > FreeBSD-9.0-RELEASE-i386-bootonly.iso 128 MB 1/3/12 8:51:00 AM > FreeBSD-9.0-RELEASE-i386-disc1.iso 502 MB 1/3/12 8:50:00 AM > FreeBSD-9.0-RELEASE-i386-dvd1.iso 2.1 GB 1/7/12 12:41:00 AM > FreeBSD-9.0-RELEASE-i386-memstick.img 535 MB 1/3/12 8:51:00 AM > > There is kernel.txz archive also, but it just contains single binary > kernel image. There is probably also sources easly available, but I > do > not think it is possible to cross-compile easly FreeBSD on Linux like > netbsd, isn't it? Anyway it is unacasarly complicated. NetBSD or many > Linux distros (like Debian), provides kernel/initrd for > installation/running just in Xen PV, to make it easier. > > I found a one kernel in Debian: > > http://packages.debian.org/sid/kfreebsd-image-9.0-1-xen > > it actually can be installed as package on Linux i386, > and easly used for Xen! > > It booted for me without much problem: > > > movax-dev:/etc/xen# cat kfreebsd9.cfg > name = "kfreebsd9" > kernel = "/boot/kfreebsd-9.0-1-xen.gz" > memory = 256 > > > movax-dev:/etc/xen# xl create kfreebsd9.cfg -c > Parsing config file kfreebsd9.cfg > xc: error: panic: xc_dom_bzimageloader.c:556: > xc_dom_probe_bzimage_kernel: kernel is not a bzImage: Invalid kernel > Daemon running with PID 10546 > WARNING: loader(8) metadata is missing! > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2012 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, > 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > #0 Sat Jan 7 14:06:17 UTC 2012 i386 > Xen reported: 2793.110 MHz processor. > Timecounter "ixen" frequency 1953125 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.11-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf41 Family = f Model = 4 > Stepping = 1 > > > Features=0xbfe3fbff > Features2=0x441d > AMD Features=0x100000 > real memory = 268435456 (256 MB) > avail memory = 254488576 (242 MB) > [XEN] IPI cpu=0 irq=128 vector=RESCHEDULE_VECTOR (0) > [XEN] IPI cpu=0 irq=129 vector=CALL_FUNCTION_VECTOR (1) > xenstore0: on motherboard > [XEN] xen_rtc_probe: probing Hypervisor RTC clock > rtc0: on motherboard > [XEN] xen_rtc_attach: attaching Hypervisor RTC clock > xc0: on motherboard > Event timer "ixen" quality 600 > Timecounters tick every 10.000 msec > xenbusb_back0: on xenstor[XEN] hypervisor > wallclock nudged; nudging TOD. > e0 > xctrl0: on xenstore0 > xenbusb_front0: on xenstore0 > xenbusb_add_device: Device device/suspend/event-channel ignored. > State 6 > Timecounter "TSC" frequency 2793110000 Hz quality 800 > > Loader variables: > > Manual root filesystem specification: > : [options] > Mount using filesystem > and with the specified (optional) option list. > > eg. ufs:/dev/da0s1a > zfs:tank > cd9660:/dev/acd0 ro > (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) > > ? List valid disk boot devices > . Yield 1 second (for background tasks) > Abort manual input > > mountroot> > panic: mountroot: unable to (re-)mount root. > cpuid = 0 > KDB: enter: panic > [ thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x38: movl $0,kdb_why > db> halt > movax-dev:/etc/xen# > > > In fact after some more work, I was even able to boot it, and run > installer, > with Debian's kfreebsd kernel image, and *-dvd1.iso image as sdb, > with additional extra = "vfs.root.mountfrom=cd9660:/dev/da1"! :) > Installation over serial console works (I selected 'xterm' terminal, > and everythings looks to be workking nicly, with colors and arrow > keys). > > Only technical problem so far is that I sometimes get: > > "[XEN] hypervisor wallclock nudged; nudging TOD." > > from kernel. It looks same message like reported by Colin: > > > http://lists.freebsd.org/pipermail/freebsd-xen/2010-November/000613.html > > however I cannot find any solution to it. > > > > > I still miss upstream binary image for exactly same purpose (because > kfreebsd != FreeBSD, and other distributions which uses Xen could > also > benefit by upstream suplied images), and better documentation in > handbook (there is literaly zero informations about Xen or serial > console installation in handbook) From owner-freebsd-xen@FreeBSD.ORG Wed Feb 1 03:01:12 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F08C1065670 for ; Wed, 1 Feb 2012 03:01:12 +0000 (UTC) (envelope-from baryluk@smp.if.uj.edu.pl) Received: from smp.if.uj.edu.pl (smp.if.uj.edu.pl [149.156.82.206]) by mx1.freebsd.org (Postfix) with ESMTP id 1669E8FC0C for ; Wed, 1 Feb 2012 03:01:11 +0000 (UTC) Received: from users.smp.if.uj.edu.pl (users.smp.if.uj.edu.pl [::ffff:10.0.1.244]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by smp.if.uj.edu.pl with esmtp; Wed, 01 Feb 2012 04:01:09 +0100 id 0001C73C.4F28AAF5.00004765 Received: from baryluk by users.smp.if.uj.edu.pl with local (Exim 4.72) (envelope-from ) id 1RsQRY-0002nV-Mz; Wed, 01 Feb 2012 04:01:08 +0100 Date: Wed, 1 Feb 2012 04:01:08 +0100 From: Witold Baryluk To: =?iso-8859-1?Q?G=F3t_Andr=E1s?= Message-ID: <20120201030108.GH12978@smp.if.uj.edu.pl> References: <20120131172232.GE12978@smp.if.uj.edu.pl> <079aa81f893021a200468e57199401fb@deployis.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <079aa81f893021a200468e57199401fb@deployis.eu> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-xen@freebsd.org Subject: Re: Is there any prebuild 9.0 PV i386 kernel image? X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 01 Feb 2012 03:01:12 -0000 On 01-31 20:52, Gót András wrote: > Hi, > > You may install a "provisioning" HVM instance where you can mount a > disk/filesystem. After you compiled the source you can make > installworld/installkernel DESTDIR=mynewsystempath and there you go. > Also don't forget a make distribution. :) After this you can easily > do an image with dd if you're also using LVM for XEN "disks". > > The provisioning HVM instance might come handy any you have a > problem with a PV instance. I know I can do this. This is not the point of my post. I can do many akward things, including having separate FreeBSD machine just for building 2MB kernel with Xen enabled. But why not just provide prebuild XEN-enabled kernel image on FTP server? Clearly it is possible, because I just installed fully functional system using kfreebsd-9 kernel from Debian [1]. After building freebsd release, recompile it again with Xen enabled, and extract new kernel. Then just put such kernel on .iso in separate directory or on ftp mirrors as separate image like as in netbsd or debian, and no compilation by user will be needed. It is about 2-4MB, will not harm even -bootonly.iso image. By telling me to compile kernel by own you are just like telling potential user: "To install FreeBSD you need to have FreeBSD installed". It is not the best answer (as clearly I was able to install FreeBSD on Xen without having FreeBSD or any compilation!, just using Debian's kernel, but would like to use or have possibility to use upstream/original kernel). Also not everybody have access to HVM instance (due lack of hardware support). Compilation also takes time, and can be complex task, especially considering there is no mention of Xen or Xen specific kernel compilation in the FreeBSD handbook. It unacassarly makes 10 minut task, a 20+ hours task. For solving some minor problems, I can always just mount ufs under linux or have separate 'administrative' domain, to which I can attach additional disks to check what is wrong. No need to HVM instance. I can also do many other things, including accessing block device using iSCSI, which make it easy to use on another freebsd (virtualized or not) host. Again no need to HVM even when doing serious disaster recovery. So how about providing prebuild binary kernel image with Xen enabled, just like netbsd is doing with own kernel, or like Debian is doing with kfreebsd? Who I need to contact from release / build team to make it happen in 9.1 or 10.0 ? Regards, Witek [1] (only missing thing is that getty is trying to open /dev/vt* but, should actually open xen-specific tty/console, easly fixable by editing /etc/inittab, something which should be actually done by bsdinstaller after detecting it is running on Xen). -- Witold Baryluk From owner-freebsd-xen@FreeBSD.ORG Wed Feb 1 06:53:18 2012 Return-Path: Delivered-To: freebsd-xen@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07C63106564A; Wed, 1 Feb 2012 06:53:18 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CD0DF8FC15; Wed, 1 Feb 2012 06:53:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q116rHQJ074561; Wed, 1 Feb 2012 06:53:17 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q116rHH7074557; Wed, 1 Feb 2012 06:53:17 GMT (envelope-from pluknet) Date: Wed, 1 Feb 2012 06:53:17 GMT Message-Id: <201202010653.q116rHH7074557@freefall.freebsd.org> To: joe@tao.org.uk, pluknet@FreeBSD.org, freebsd-xen@FreeBSD.org From: pluknet@FreeBSD.org Cc: Subject: Re: kern/164531: [xen] [panic] Boot time crash using XEN HVM enabled kernel. X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 01 Feb 2012 06:53:18 -0000 Synopsis: [xen] [panic] Boot time crash using XEN HVM enabled kernel. State-Changed-From-To: patched->closed State-Changed-By: pluknet State-Changed-When: Wed Feb 1 06:52:00 UTC 2012 State-Changed-Why: Merged to stable/8 as svn r230831. http://www.freebsd.org/cgi/query-pr.cgi?pr=164531 From owner-freebsd-xen@FreeBSD.ORG Wed Feb 1 21:36:45 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE73106566B for ; Wed, 1 Feb 2012 21:36:45 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (ns1.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 74DB28FC16 for ; Wed, 1 Feb 2012 21:36:45 +0000 (UTC) Received: from danzmolek-dell.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q11L6OBN097775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 1 Feb 2012 14:06:24 -0700 (MST) (envelope-from gibbs@scsiguy.com) From: "Justin T. Gibbs" Content-Type: multipart/mixed; boundary="Apple-Mail=_D06AA316-BD1F-4F32-9F53-83C356F10EA6" Date: Wed, 1 Feb 2012 14:06:33 -0700 Message-Id: <8FFE3850-7668-48C2-90C1-525213193A33@scsiguy.com> To: freebsd-xen@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [70.89.174.89]); Wed, 01 Feb 2012 14:06:24 -0700 (MST) Subject: [CFT][PATCH] - Rationalize FreeBSD multi-page ring extensions with those from other vendors X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 01 Feb 2012 21:36:45 -0000 --Apple-Mail=_D06AA316-BD1F-4F32-9F53-83C356F10EA6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm spent some time documenting all of the Xen blkif extensions that are = out in the wild and have modified the extensions in FreeBSD so that it = is possible to make a fully interoperable driver. Although I have = performed some of my own testing on different Xen Dom0's, I'm looking = for additional testers before I push this into -current and merge it = down into the -stable branches. I'm most interested in Amazon EC2 = testing since I know that not all of their nodes run exactly the same = software. Feedback always welcome. Thanks, Justin --Apple-Mail=_D06AA316-BD1F-4F32-9F53-83C356F10EA6 Content-Disposition: attachment; filename=blkif.diffs Content-Type: application/octet-stream; name="blkif.diffs" Content-Transfer-Encoding: 7bit diff -x .svn -ur sys/dev/xen/blkback/blkback.c /usr/home/justing/perforce/SpectraBSD/head/sys/dev/xen/blkback/blkback.c --- sys/dev/xen/blkback/blkback.c 2012-01-31 17:31:44.383114171 -0700 +++ /usr/home/justing/perforce/SpectraBSD/head/sys/dev/xen/blkback/blkback.c 2012-02-01 12:55:39.958114726 -0700 @@ -40,6 +40,8 @@ * a FreeBSD domain to other domains. */ +#include "opt_kdtrace.h" + #include #include #include @@ -63,6 +65,7 @@ #include #include #include +#include #include @@ -980,9 +983,10 @@ static uint8_t * xbb_get_kva(struct xbb_softc *xbb, int nr_pages) { - intptr_t first_clear, num_clear; + intptr_t first_clear; + intptr_t num_clear; uint8_t *free_kva; - int i; + int i; KASSERT(nr_pages != 0, ("xbb_get_kva of zero length")); @@ -1681,19 +1685,19 @@ req_ring_idx++; switch (xbb->abi) { case BLKIF_PROTOCOL_NATIVE: - sg = BLKRING_GET_SG_REQUEST(&xbb->rings.native, - req_ring_idx); + sg = BLKRING_GET_SEG_BLOCK(&xbb->rings.native, + req_ring_idx); break; case BLKIF_PROTOCOL_X86_32: { - sg = BLKRING_GET_SG_REQUEST(&xbb->rings.x86_32, - req_ring_idx); + sg = BLKRING_GET_SEG_BLOCK(&xbb->rings.x86_32, + req_ring_idx); break; } case BLKIF_PROTOCOL_X86_64: { - sg = BLKRING_GET_SG_REQUEST(&xbb->rings.x86_64, - req_ring_idx); + sg = BLKRING_GET_SEG_BLOCK(&xbb->rings.x86_64, + req_ring_idx); break; } default: @@ -1817,8 +1821,8 @@ struct xbb_xen_reqlist *reqlist; - xbb = (struct xbb_softc *)context; - rings = &xbb->rings; + xbb = (struct xbb_softc *)context; + rings = &xbb->rings; /* * Work gather and dispatch loop. Note that we have a bias here @@ -2032,6 +2036,13 @@ taskqueue_enqueue(xbb->io_taskqueue, &xbb->io_task); } +SDT_PROVIDER_DEFINE(xbb); +SDT_PROBE_DEFINE1(xbb, kernel, xbb_dispatch_dev, flush, flush, "int"); +SDT_PROBE_DEFINE3(xbb, kernel, xbb_dispatch_dev, read, read, "int", "uint64_t", + "uint64_t"); +SDT_PROBE_DEFINE3(xbb, kernel, xbb_dispatch_dev, write, write, "int", + "uint64_t", "uint64_t"); + /*----------------------------- Backend Handlers -----------------------------*/ /** * Backend handler for character device access. @@ -2087,6 +2098,9 @@ nreq->pendcnt = 1; + SDT_PROBE1(xbb, kernel, xbb_dispatch_dev, flush, + device_get_unit(xbb->dev)); + (*dev_data->csw->d_strategy)(bio); return (0); @@ -2181,6 +2195,17 @@ bios[bio_idx]->bio_bcount); } #endif + if (operation == BIO_READ) { + SDT_PROBE3(xbb, kernel, xbb_dispatch_dev, read, + device_get_unit(xbb->dev), + bios[bio_idx]->bio_offset, + bios[bio_idx]->bio_length); + } else if (operation == BIO_WRITE) { + SDT_PROBE3(xbb, kernel, xbb_dispatch_dev, write, + device_get_unit(xbb->dev), + bios[bio_idx]->bio_offset, + bios[bio_idx]->bio_length); + } (*dev_data->csw->d_strategy)(bios[bio_idx]); } @@ -2193,6 +2218,12 @@ return (error); } +SDT_PROBE_DEFINE1(xbb, kernel, xbb_dispatch_file, flush, flush, "int"); +SDT_PROBE_DEFINE3(xbb, kernel, xbb_dispatch_file, read, read, "int", "uint64_t", + "uint64_t"); +SDT_PROBE_DEFINE3(xbb, kernel, xbb_dispatch_file, write, write, "int", + "uint64_t", "uint64_t"); + /** * Backend handler for file access. * @@ -2237,6 +2268,9 @@ case BIO_FLUSH: { struct mount *mountpoint; + SDT_PROBE1(xbb, kernel, xbb_dispatch_file, flush, + device_get_unit(xbb->dev)); + vfs_is_locked = VFS_LOCK_GIANT(xbb->vn->v_mount); (void) vn_start_write(xbb->vn, &mountpoint, V_WAIT); @@ -2336,6 +2370,10 @@ switch (operation) { case BIO_READ: + SDT_PROBE3(xbb, kernel, xbb_dispatch_file, read, + device_get_unit(xbb->dev), xuio.uio_offset, + xuio.uio_resid); + vn_lock(xbb->vn, LK_EXCLUSIVE | LK_RETRY); /* @@ -2366,6 +2404,10 @@ case BIO_WRITE: { struct mount *mountpoint; + SDT_PROBE3(xbb, kernel, xbb_dispatch_file, write, + device_get_unit(xbb->dev), xuio.uio_offset, + xuio.uio_resid); + (void)vn_start_write(xbb->vn, &mountpoint, V_WAIT); vn_lock(xbb->vn, LK_EXCLUSIVE | LK_RETRY); @@ -3028,6 +3070,8 @@ const char *otherend_path; int error; u_int ring_idx; + u_int ring_page_order; + size_t ring_size; otherend_path = xenbus_get_otherend_path(xbb->dev); @@ -3042,16 +3086,13 @@ /* * Mandatory data (used in all versions of the protocol) first. */ - error = xs_gather(XST_NIL, otherend_path, - "ring-ref", "%" PRIu32, - &xbb->ring_config.ring_ref[0], - "event-channel", "%" PRIu32, - &xbb->ring_config.evtchn, - NULL); + error = xs_scanf(XST_NIL, otherend_path, + "event-channel", NULL, "%" PRIu32, + &xbb->ring_config.evtchn); if (error != 0) { xenbus_dev_fatal(xbb->dev, error, - "Unable to retrieve ring information from " - "frontend %s. Unable to connect.", + "Unable to retrieve event-channel information " + "from frontend %s. Unable to connect.", xenbus_get_otherend_path(xbb->dev)); return (error); } @@ -3065,10 +3106,19 @@ * we must use independant calls in order to guarantee * we don't miss information in a sparsly populated front-end * tree. + * \note xs_scanf() does not update variables for unmatched + * fields. */ + ring_page_order = 0; + (void)xs_scanf(XST_NIL, otherend_path, + "ring-page-order", NULL, "%u", + &ring_page_order); + xbb->ring_config.ring_pages = 1 << ring_page_order; (void)xs_scanf(XST_NIL, otherend_path, "ring-pages", NULL, "%u", &xbb->ring_config.ring_pages); + ring_size = PAGE_SIZE * xbb->ring_config.ring_pages; + xbb->max_requests = BLKIF_MAX_RING_REQUESTS(ring_size); (void)xs_scanf(XST_NIL, otherend_path, "max-requests", NULL, "%u", @@ -3116,22 +3166,39 @@ return (EINVAL); } - /* If using a multi-page ring, pull in the remaining references. */ - for (ring_idx = 1; ring_idx < xbb->ring_config.ring_pages; ring_idx++) { - char ring_ref_name[]= "ring_refXX"; - - snprintf(ring_ref_name, sizeof(ring_ref_name), - "ring-ref%u", ring_idx); - error = xs_scanf(XST_NIL, otherend_path, - ring_ref_name, NULL, "%" PRIu32, - &xbb->ring_config.ring_ref[ring_idx]); + if (xbb->ring_config.ring_pages == 1) { + error = xs_gather(XST_NIL, otherend_path, + "ring-ref", "%" PRIu32, + &xbb->ring_config.ring_ref[0], + NULL); if (error != 0) { xenbus_dev_fatal(xbb->dev, error, - "Failed to retriev grant reference " - "for page %u of shared ring. Unable " - "to connect.", ring_idx); + "Unable to retrieve ring information " + "from frontend %s. Unable to " + "connect.", + xenbus_get_otherend_path(xbb->dev)); return (error); } + } else { + /* Multi-page ring format. */ + for (ring_idx = 0; ring_idx < xbb->ring_config.ring_pages; + ring_idx++) { + char ring_ref_name[]= "ring_refXX"; + + snprintf(ring_ref_name, sizeof(ring_ref_name), + "ring-ref%u", ring_idx); + error = xs_scanf(XST_NIL, otherend_path, + ring_ref_name, NULL, "%" PRIu32, + &xbb->ring_config.ring_ref[ring_idx]); + if (error != 0) { + xenbus_dev_fatal(xbb->dev, error, + "Failed to retriev grant " + "reference for page %u of " + "shared ring. Unable " + "to connect.", ring_idx); + return (error); + } + } } error = xs_gather(XST_NIL, otherend_path, @@ -3197,8 +3264,8 @@ static int xbb_alloc_request_lists(struct xbb_softc *xbb) { - int i; struct xbb_xen_reqlist *reqlist; + int i; /* * If no requests can be merged, we need 1 request list per @@ -3318,7 +3385,7 @@ static void xbb_connect(struct xbb_softc *xbb) { - int error; + int error; if (xenbus_get_state(xbb->dev) == XenbusStateConnected) return; @@ -3399,7 +3466,8 @@ static int xbb_shutdown(struct xbb_softc *xbb) { - int error; + XenbusState frontState; + int error; DPRINTF("\n"); @@ -3413,6 +3481,20 @@ if ((xbb->flags & XBBF_IN_SHUTDOWN) != 0) return (EAGAIN); + xbb->flags |= XBBF_IN_SHUTDOWN; + mtx_unlock(&xbb->lock); + + if (xenbus_get_state(xbb->dev) < XenbusStateClosing) + xenbus_set_state(xbb->dev, XenbusStateClosing); + + frontState = xenbus_get_otherend_state(xbb->dev); + mtx_lock(&xbb->lock); + xbb->flags &= ~XBBF_IN_SHUTDOWN; + + /* The front can submit I/O until entering the closed state. */ + if (frontState < XenbusStateClosed) + return (EAGAIN); + DPRINTF("\n"); /* Indicate shutdown is in progress. */ @@ -3434,19 +3516,6 @@ DPRINTF("\n"); - /* - * Before unlocking mutex, set this flag to prevent other threads from - * getting into this function - */ - xbb->flags |= XBBF_IN_SHUTDOWN; - mtx_unlock(&xbb->lock); - - if (xenbus_get_state(xbb->dev) < XenbusStateClosing) - xenbus_set_state(xbb->dev, XenbusStateClosing); - - mtx_lock(&xbb->lock); - xbb->flags &= ~XBBF_IN_SHUTDOWN; - /* Indicate to xbb_detach() that is it safe to proceed. */ wakeup(xbb); @@ -3573,6 +3642,11 @@ "max_request_segments", CTLFLAG_RD, &xbb->max_request_segments, 0, "maximum number of pages per requests (negotiated)"); + + SYSCTL_ADD_UINT(sysctl_ctx, SYSCTL_CHILDREN(sysctl_tree), OID_AUTO, + "ring_pages", CTLFLAG_RD, + &xbb->ring_config.ring_pages, 0, + "communication channel pages (negotiated)"); } /** @@ -3587,6 +3661,7 @@ { struct xbb_softc *xbb; int error; + u_int max_ring_page_order; DPRINTF("Attaching to %s\n", xenbus_get_node(dev)); @@ -3621,6 +3696,10 @@ return (error); } + /* + * Amazon EC2 client compatility. They refer to max-ring-pages + * instead of to max-ring-page-order. + */ error = xs_printf(XST_NIL, xenbus_get_node(xbb->dev), "max-ring-pages", "%zu", XBB_MAX_RING_PAGES); if (error) { @@ -3629,6 +3708,15 @@ return (error); } + max_ring_page_order = flsl(XBB_MAX_RING_PAGES) - 1; + error = xs_printf(XST_NIL, xenbus_get_node(xbb->dev), + "max-ring-page-order", "%u", max_ring_page_order); + if (error) { + xbb_attach_failed(xbb, error, "writing %s/max-ring-page-order", + xenbus_get_node(xbb->dev)); + return (error); + } + error = xs_printf(XST_NIL, xenbus_get_node(xbb->dev), "max-requests", "%u", XBB_MAX_REQUESTS); if (error) { @@ -3862,12 +3950,16 @@ xbb_connect(xbb); break; case XenbusStateClosing: + /* + * Frontend has acknowledged Closing request. + * Wait for Closed state. + */ + break; case XenbusStateClosed: mtx_lock(&xbb->lock); xbb_shutdown(xbb); mtx_unlock(&xbb->lock); - if (frontend_state == XenbusStateClosed) - xenbus_set_state(xbb->dev, XenbusStateClosed); + xenbus_set_state(xbb->dev, XenbusStateClosed); break; default: xenbus_dev_fatal(xbb->dev, EINVAL, "saw state %d at frontend", diff -x .svn -ur sys/dev/xen/blkfront/blkfront.c /usr/home/justing/perforce/SpectraBSD/head/sys/dev/xen/blkfront/blkfront.c --- sys/dev/xen/blkfront/blkfront.c 2011-12-09 10:56:37.165520312 -0700 +++ /usr/home/justing/perforce/SpectraBSD/head/sys/dev/xen/blkfront/blkfront.c 2012-02-01 12:59:37.312115640 -0700 @@ -226,7 +226,7 @@ sc->xb_disk->d_sectorsize = sector_size; sc->xb_disk->d_mediasize = sectors * sector_size; - sc->xb_disk->d_maxsize = sc->max_request_size; + sc->xb_disk->d_maxsize = sc->max_request_size - PAGE_SIZE; sc->xb_disk->d_flags = 0; disk_create(sc->xb_disk, DISK_VERSION_00); @@ -501,6 +501,7 @@ { const char *otherend_path; const char *node_path; + uint32_t max_ring_page_order; int error; int i; @@ -513,6 +514,7 @@ * Protocol defaults valid even if negotiation for a * setting fails. */ + max_ring_page_order = 0; sc->ring_pages = 1; sc->max_requests = BLKIF_MAX_RING_REQUESTS(PAGE_SIZE); sc->max_request_segments = BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK; @@ -526,12 +528,22 @@ * we must use independant calls in order to guarantee * we don't miss information in a sparsly populated back-end * tree. + * \note xs_scanf() does not update variables for unmatched + * fields. */ otherend_path = xenbus_get_otherend_path(sc->xb_dev); node_path = xenbus_get_node(sc->xb_dev); + + /* Support both backend schemes for relaying ring page limits. */ + (void)xs_scanf(XST_NIL, otherend_path, + "max-ring-page-order", NULL, "%" PRIu32, + &max_ring_page_order); + sc->ring_pages = 1 << max_ring_page_order; (void)xs_scanf(XST_NIL, otherend_path, "max-ring-pages", NULL, "%" PRIu32, &sc->ring_pages); + if (sc->ring_pages < 1) + sc->ring_pages = 1; (void)xs_scanf(XST_NIL, otherend_path, "max-requests", NULL, "%" PRIu32, @@ -552,6 +564,16 @@ sc->ring_pages = XBF_MAX_RING_PAGES; } + if (powerof2(sc->ring_pages) == 0) { + u_int new_page_limit; + + new_page_limit = 0x01 << (fls(sc->ring_pages) - 1); + device_printf(sc->xb_dev, "Back-end specified ring-pages of " + "%u is not a power of 2. Limited to %u.\n", + sc->ring_pages, new_page_limit); + sc->ring_pages = new_page_limit; + } + if (sc->max_requests > XBF_MAX_REQUESTS) { device_printf(sc->xb_dev, "Back-end specified max_requests of " "%u limited to front-end limit of %u.\n", @@ -625,6 +647,7 @@ if (setup_blkring(sc) != 0) return; + /* Support both backend schemes for relaying ring page limits. */ error = xs_printf(XST_NIL, node_path, "ring-pages","%u", sc->ring_pages); if (error) { @@ -633,6 +656,14 @@ node_path); return; } + error = xs_printf(XST_NIL, node_path, + "ring-page-order","%u", fls(sc->ring_pages) - 1); + if (error) { + xenbus_dev_fatal(sc->xb_dev, error, + "writing %s/ring-page-order", + node_path); + return; + } error = xs_printf(XST_NIL, node_path, "max-requests","%u", sc->max_requests); @@ -795,7 +826,7 @@ unsigned int binfo; int err, feature_barrier; - if( (sc->connected == BLKIF_STATE_CONNECTED) || + if( (sc->connected == BLKIF_STATE_CONNECTED) || (sc->connected == BLKIF_STATE_SUSPENDED) ) return; @@ -923,15 +954,13 @@ return (ENXIO); sc->xb_flags &= ~XB_OPEN; if (--(sc->users) == 0) { - /* Check whether we have been instructed to close. We will - have ignored this request initially, as the device was - still mounted. */ - device_t dev = sc->xb_dev; - XenbusState state = - xenbus_read_driver_state(xenbus_get_otherend_path(dev)); - - if (state == XenbusStateClosing) - blkfront_closing(dev); + /* + * Check whether we have been instructed to close. We will + * have ignored this request initially, as the device was + * still mounted. + */ + if (xenbus_get_otherend_state(sc->xb_dev) == XenbusStateClosing) + blkfront_closing(sc->xb_dev); } return (0); } @@ -1033,7 +1062,7 @@ struct xb_command *cm; blkif_request_t *ring_req; struct blkif_request_segment *sg; - struct blkif_request_segment *last_block_sg; + struct blkif_request_segment *last_block_sg; grant_ref_t *sg_ref; vm_paddr_t buffer_ma; uint64_t fsect, lsect; @@ -1104,12 +1133,12 @@ nsegs--; } block_segs = MIN(nsegs, BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK); - if (block_segs == 0) - break; + if (block_segs == 0) + break; - sg = BLKRING_GET_SG_REQUEST(&sc->ring, sc->ring.req_prod_pvt); + sg = BLKRING_GET_SEG_BLOCK(&sc->ring, sc->ring.req_prod_pvt); sc->ring.req_prod_pvt++; - last_block_sg = sg + block_segs; + last_block_sg = sg + block_segs; } if (cm->operation == BLKIF_OP_READ) diff -x .svn -ur sys/xen/interface/io/blkif.h /usr/home/justing/perforce/SpectraBSD/head/sys/xen/interface/io/blkif.h --- sys/xen/interface/io/blkif.h 2010-10-27 22:12:14.560797810 -0600 +++ /usr/home/justing/perforce/SpectraBSD/head/sys/xen/interface/io/blkif.h 2012-01-31 16:11:47.565117660 -0700 @@ -1,8 +1,8 @@ /****************************************************************************** * blkif.h - * + * * Unified block-device I/O interface for Xen guest OSes. - * + * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to * deal in the Software without restriction, including without limitation the @@ -22,6 +22,7 @@ * DEALINGS IN THE SOFTWARE. * * Copyright (c) 2003-2004, Keir Fraser + * Copyright (c) 2012, Spectra Logic Corporation */ #ifndef __XEN_PUBLIC_IO_BLKIF_H__ @@ -35,7 +36,7 @@ * notification can be made conditional on req_event (i.e., the generic * hold-off mechanism provided by the ring macros). Backends must set * req_event appropriately (e.g., using RING_FINAL_CHECK_FOR_REQUESTS()). - * + * * Back->front notifications: When enqueuing a new response, sending a * notification can be made conditional on rsp_event (i.e., the generic * hold-off mechanism provided by the ring macros). Frontends must set @@ -48,37 +49,401 @@ #define blkif_sector_t uint64_t /* + * Feature and Parameter Negotiation + * ================================= + * The two halves of a Xen block driver utilize nodes within the XenStore to + * communicate capabilities and to negotiate operating parameters. This + * section enumerates these nodes which reside in the respective front and + * backend portions of the XenStore, following the XenBus convention. + * + * All data in the XenStore is stored as strings. Nodes specifying numeric + * values are encoded in decimal. Integer value ranges listed below are + * expressed as fixed sized integer types capable of storing the conversion + * of a properly formated node string, without loss of information. + * + * Any specified default value is in effect if the corresponding XenBus node + * is not present in the XenStore. + * + * See the XenBus state transition diagram below for details on when XenBus + * nodes must be published and when they can be queried. + * + ***************************************************************************** + * Backend XenBus Nodes + ***************************************************************************** + * + *--------------------------------- Features --------------------------------- + * + * feature-barrier + * Values: 0/1 (boolean) + * Default Value: 0 + * + * A value of "1" indicates that the backend can process requests + * containing the BLKIF_OP_WRITE_BARRIER request opcode. Requests + * of this type may still be returned at any time with the + * BLKIF_RSP_EOPNOTSUPP result code. + * + * feature-flush-cache + * Values: 0/1 (boolean) + * Default Value: 0 + * + * A value of "1" indicates that the backend can process requests + * containing the BLKIF_OP_FLUSH_DISKCACHE request opcode. Requests + * of this type may still be returned at any time with the + * BLKIF_RSP_EOPNOTSUPP result code. + * + * feature-discard + * Values: 0/1 (boolean) + * Default Value: 0 + * + * A value of "1" indicates that the backend can process requests + * containing the BLKIF_OP_DISCARD request opcode. Requests + * of this type may still be returned at any time with the + * BLKIF_RSP_EOPNOTSUPP result code. + * + *----------------------- Request Transport Parameters ------------------------ + * + * max-ring-page-order + * Values: + * Default Value: 0 + * Notes: 1, 3 + * + * The maximum supported size of the request ring buffer in units of + * lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, + * etc.). + * + * max-ring-pages + * Values: + * Default Value: 1 + * Notes: 2, 3 + * + * The maximum supported size of the request ring buffer in units of + * machine pages. The value must be a power of 2. + * + * max-requests + * Default Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE) + * Maximum Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring-pages) + * + * The maximum number of concurrent requests supported by the backend. + * + * max-request-segments + * Values: + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + * Maximum Value: 255 + * + * The maximum value of blkif_request.nr_segments supported by + * the backend. + * + * max-request-size + * Values: + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE + * Maximum Value: 255 * PAGE_SIZE + * + * The maximum amount of data, in bytes, that can be referenced by a + * request type that accesses frontend memory (currently BLKIF_OP_READ, + * BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER). + * + *----------------------- Backend Device Identification ----------------------- + * mode + * Values: "r" (read only), "w" (writable) + * + * The read or write access permissions to the backing store to be + * granted to the frontend. + * + * params + * Values: string + * + * A free formatted string providing sufficient information for the + * backend driver to open the backing device. (e.g. the path to the + * file or block device representing the backing store.) + * + * type + * Values: "file", "phy", "tap" + * + * The type of the backing device/object. + * + *------------------------- Backend Device Properties ------------------------- + * + * discard-aligment + * Values: + * Default Value: 0 + * Notes: 4, 5 + * + * The offset, in bytes from the beginning of the virtual block device, + * to the first, addressable, discard extent on the underlying device. + * + * discard-granularity + * Values: + * Default Value: 512 + * Notes: 4 + * + * The size, in bytes, of the individually addressable discard extents + * of the underlying device. + * + * discard-secure + * Values: 0/1 (boolean) + * Default Value: 0 + * + * A value of "1" indicates that the backend can process BLKIF_OP_DISCARD + * requests with the BLKIF_DISCARD_SECURE flag set. + * + * info + * Values: (bitmap) + * + * A collection of bit flags describing attributes of the backing + * device. The VDISK_* macros define the meaning of each bit + * location. + * + * sector-size + * Values: + * + * The native sector size, in bytes, of the backend device. + * + * sectors + * Values: + * + * The size of the backend device, expressed in units of its native + * sector size ("sector-size"). + * + ***************************************************************************** + * Frontend XenBus Nodes + ***************************************************************************** + * + *----------------------- Request Transport Parameters ----------------------- + * + * event-channel + * Values: + * + * The identifier of the Xen event channel used to signal activity + * in the ring buffer. + * + * ring-ref + * Values: + * Notes: 6 + * + * The Xen grant reference granting permission for the backend to map + * the sole page in a single page sized ring buffer. + * + * ring-ref%u + * Values: + * Notes: 6 + * + * For a frontend providing a multi-page ring, a "ring-pages" sized + * list of nodes, each containing a Xen grant reference granting + * permission for the backend to map the page of the ring located + * at page index "%u". Page indexes are zero based. + * + * protocol + * Values: string (XEN_IO_PROTO_ABI_*) + * Default Value: XEN_IO_PROTO_ABI_NATIVE + * + * The machine ABI rules governing the format of all ring request and + * response structures. + * + * ring-page-order + * Values: + * Default Value: 0 + * Maximum Value: MAX(ffs(max-ring-pages) - 1, max-ring-page-order) + * Notes: 1, 3 + * + * The size of the frontend allocated request ring buffer in units + * of lb(machine pages). (e.g. 0 == 1 page, 1 = 2 pages, 2 == 4 pages, + * etc.). + * + * ring-pages + * Values: + * Default Value: 1 + * Maximum Value: MAX(max-ring-pages,(0x1 << max-ring-page-order)) + * Notes: 2, 3 + * + * The size of the frontend allocated request ring buffer in units of + * machine pages. The value must be a power of 2. + * + * max-requests + * Values: + * Default Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE) + * Maximum Value: BLKIF_MAX_RING_REQUESTS(PAGE_SIZE * max-ring_pages) + * + * The maximum number of concurrent requests that will be issued by + * the frontend. + * + * max-request-segments + * Values: + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK + * Maximum Value: MIN(255, backend/max-request-segments) + * + * The maximum value the frontend will set in the + * blkif_request.nr_segments field. + * + * max-request-size + * Values: + * Default Value: BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK * PAGE_SIZE + * Maximum Value: max-request-segments * PAGE_SIZE + * Notes: 3 + * + * The maximum amount of data, in bytes, that can be referenced by + * a request type that accesses frontend memory (currently BLKIF_OP_READ, + * BLKIF_OP_WRITE, or BLKIF_OP_WRITE_BARRIER). + * + *------------------------- Virtual Device Properties ------------------------- + * + * device-type + * Values: "disk", "cdrom", "floppy", etc. + * + * virtual-device + * Values: (XEN_*_MAJOR << 8 | Minor) + * + * A value indicating the physical device to virtualize within the + * frontend's domain. (e.g. "The first ATA disk", "The third SCSI + * disk", etc.) + * + * Notes + * ----- + * (1) Multi-page ring buffer scheme first developed in the Citrix XenServer + * PV drivers. + * (2) Multi-page ring buffer scheme first used in some RedHat distributions + * including a distribution deployed on certain nodes of the Amazon + * EC2 cluster. + * (3) Support for multi-page ring buffers was implemented independently, + * in slightly different forms, by both Citrix and RedHat/Amazon. + * For full interoperability, block front and backends should support + * both methods of negotiating this capability. + * (4) Devices that support discard functionality may internally allocate + * space (discardable extents) in units that are larger than the + * exported logical block size. + * (5) The discard-alignment parameter allows a physical device to be + * partitioned into virtual devices that do not necessarily begin or + * end on a discardable extent. + * (6) When there is only a single page allocated to the request ring, + * 'ring-ref' is used to communicate the grant reference for this + * page to the backend. When using a multi-page ring, the 'ring-ref' + * node is not created. Instead 'ring-ref0' - 'ring-refN' are used. + */ + +/* + * STATE DIAGRAMS + * + ***************************************************************************** + * Startup * + ***************************************************************************** + * + * Tool stack creates front and back nodes with state XenbusStateInitialising. + * + * Front Back + * ================================= ===================================== + * XenbusStateInitialising XenbusStateInitialising + * o Query virtual device o Query backend device identification + * properties. data. + * o Setup OS device instance. o Open and validate backend device. + * o Publish backend features and + * transport parameters. + * | + * | + * V + * XenbusStateInitWait + * + * o Query backend features and + * transport parameters. + * o Allocate and initialize the + * request ring. + * o Publish transport parameters + * that will be in effect during + * this connection. + * | + * | + * V + * XenbusStateInitialised + * + * o Query frontend, transport parameters. + * o Connect to the request ring and + * event channel. + * o Publish backend device properties. + * | + * | + * V + * XenbusStateConnected + * + * o Query backend device properties. + * o Finalize OS virtual device + * instance. + * | + * | + * V + * XenbusStateConnected + * + * Note: Drivers that do not support the negotiation of transport + * parameters, can skip certain states in the state machine: + * + * o A frontend may transition to XenbusStateInitialised without + * waiting for the backend to enter XenbusStateInitWait. In this + * case, default transport parameters are in effect and any + * transport parameters published by the frontend must contain + * their default values. + * + * o A backend may transition to XenbusStateInitialed without waiting + * for the backend to first enter the XenbusStateInitialised state. + * In this case, default transport parameters are in effect and any + * transport parameters published by the backend must contain their + * default values. + * + * Drivers that support transport parameter negotiation must tolerate + * these additional state transition paths in order to interoperate + * with drivers that do not. In general this means performing the + * work of any skipped state transition, if it has not already been + * performed, in addition to the work associated with the current state. + */ + +/* * REQUEST CODES. */ #define BLKIF_OP_READ 0 #define BLKIF_OP_WRITE 1 /* - * Recognised only if "feature-barrier" is present in backend xenbus info. - * The "feature-barrier" node contains a boolean indicating whether barrier - * requests are likely to succeed or fail. Either way, a barrier request - * may fail at any time with BLKIF_RSP_EOPNOTSUPP if it is unsupported by - * the underlying block-device hardware. The boolean simply indicates whether - * or not it is worthwhile for the frontend to attempt barrier requests. - * If a backend does not recognise BLKIF_OP_WRITE_BARRIER, it should *not* - * create the "feature-barrier" node! + * All writes issued prior to a request with the BLKIF_OP_WRITE_BARRIER + * operation code ("barrier request") must be completed prior to the + * execution of the barrier request. All writes issued after the barrier + * request must not execute until after the completion of the barrier request. + * + * Optional. See "feature-barrier" XenBus node documentation above. */ #define BLKIF_OP_WRITE_BARRIER 2 /* - * Recognised if "feature-flush-cache" is present in backend xenbus - * info. A flush will ask the underlying storage hardware to flush its - * non-volatile caches as appropriate. The "feature-flush-cache" node - * contains a boolean indicating whether flush requests are likely to - * succeed or fail. Either way, a flush request may fail at any time - * with BLKIF_RSP_EOPNOTSUPP if it is unsupported by the underlying - * block-device hardware. The boolean simply indicates whether or not it - * is worthwhile for the frontend to attempt flushes. If a backend does - * not recognise BLKIF_OP_WRITE_FLUSH_CACHE, it should *not* create the - * "feature-flush-cache" node! + * Commit any uncommitted contents of the backing device's volatile cache + * to stable storage. + * + * Optional. See "feature-flush-cache" XenBus node documentation above. */ #define BLKIF_OP_FLUSH_DISKCACHE 3 +/* + * Used in SLES sources for device specific command packet + * contained within the request. Reserved for that purpose. + */ +#define BLKIF_OP_RESERVED_1 4 +/* + * Indicate to the backend device that a region of storage is no longer in + * use, and may be discarded at any time without impact to the client. If + * BLKIF_DISCARD_SECURE flag is set on the request, all copies of the + * discarded region on the device must be rendered unrecoverable before the + * command returns. + * + * This operation is a analogous to performing a trim (ATA) or unamp (SCSI), + * command on a native device. + * + * More information about trim/unmap operations can be found at: + * http://t13.org/Documents/UploadedDocuments/docs2008/ + * e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc + * http://www.seagate.com/staticfiles/support/disc/manuals/ + * Interface%20manuals/100293068c.pdf + * + * Optional. See "feature-discard", "discard-alignment", + * "discard-granularity", and "discard-secure" in the XenBus node + * documentation above. + */ +#define BLKIF_OP_DISCARD 5 /* * Maximum scatter/gather segments associated with a request header block. + * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE. + * NB. This could be 12 if the ring indexes weren't stored in the same page. */ #define BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK 11 @@ -92,6 +457,13 @@ */ #define BLKIF_MAX_SEGMENTS_PER_REQUEST 255 +/* + * NB. first_sect and last_sect in blkif_request_segment, as well as + * sector_number in blkif_request, are always expressed in 512-byte units. + * However they must be properly aligned to the real sector size of the + * physical disk, which is reported in the "sector-size" node in the backend + * xenbus info. Also the xenbus "sectors" node is expressed in 512-byte units. + */ struct blkif_request_segment { grant_ref_t gref; /* reference to I/O buffer frame */ /* @first_sect: first sector in frame to transfer (inclusive). */ @@ -100,16 +472,60 @@ }; typedef struct blkif_request_segment blkif_request_segment_t; +/* + * Starting ring element for any I/O request. + * + * One or more segment blocks can be inserted into the request ring + * just after a blkif_request_t, allowing requests to operate on + * up to BLKIF_MAX_SEGMENTS_PER_REQUEST. + * + * BLKIF_SEGS_TO_BLOCKS() can be used on blkif_requst.nr_segments + * to determine the number of contiguous ring entries associated + * with this request. + * + * Note: Due to the way Xen request rings operate, the producer and + * consumer indices of the ring must be incremented by the + * BLKIF_SEGS_TO_BLOCKS() value of the associated request. + * (e.g. a response to a 3 ring entry request must also consume + * 3 entries in the ring, even though only the first ring entry + * in the response has any data.) + */ struct blkif_request { uint8_t operation; /* BLKIF_OP_??? */ uint8_t nr_segments; /* number of segments */ blkif_vdev_t handle; /* only for read/write requests */ uint64_t id; /* private guest value, echoed in resp */ blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */ - struct blkif_request_segment seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK]; + blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK]; }; typedef struct blkif_request blkif_request_t; +/* + * A segment block is a ring request structure that contains only + * segment data. + * + * sizeof(struct blkif_segment_block) <= sizeof(struct blkif_request) + */ +struct blkif_segment_block { + blkif_request_segment_t seg[BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK]; +}; +typedef struct blkif_segment_block blkif_segment_block_t; + +/* + * Cast to this structure when blkif_request.operation == BLKIF_OP_DISCARD + * sizeof(struct blkif_request_discard) <= sizeof(struct blkif_request) + */ +struct blkif_request_discard { + uint8_t operation; /* BLKIF_OP_DISCARD */ + uint8_t flag; /* BLKIF_DISCARD_SECURE or zero */ +#define BLKIF_DISCARD_SECURE (1<<0) /* ignored if discard-secure=0 */ + blkif_vdev_t handle; /* same as for read/write requests */ + uint64_t id; /* private guest value, echoed in resp */ + blkif_sector_t sector_number;/* start sector idx on disk */ + uint64_t nr_sectors; /* number of contiguous sectors to discard*/ +}; +typedef struct blkif_request_discard blkif_request_discard_t; + struct blkif_response { uint64_t id; /* copied from request */ uint8_t operation; /* copied from request */ @@ -130,24 +546,48 @@ /* * Generate blkif ring structures and types. */ - DEFINE_RING_TYPES(blkif, struct blkif_request, struct blkif_response); -#define BLKRING_GET_SG_REQUEST(_r, _idx) \ - ((struct blkif_request_segment *)RING_GET_REQUEST(_r, _idx)) +/* + * Index to, and treat as a segment block, an entry in the ring. + */ +#define BLKRING_GET_SEG_BLOCK(_r, _idx) \ + (((blkif_segment_block_t *)RING_GET_REQUEST(_r, _idx))->seg) + +/* + * The number of ring request blocks required to handle an I/O + * request containing _segs segments. + */ +#define BLKIF_SEGS_TO_BLOCKS(_segs) \ + ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) \ + + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1)) \ + / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1) #define VDISK_CDROM 0x1 #define VDISK_REMOVABLE 0x2 #define VDISK_READONLY 0x4 /* - * The number of ring request blocks required to handle an I/O - * request containing _segs segments. + * Xen-defined major numbers for virtual disks. */ -#define BLKIF_SEGS_TO_BLOCKS(_segs) \ - ((((_segs - BLKIF_MAX_SEGMENTS_PER_HEADER_BLOCK) \ - + (BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK - 1)) \ - / BLKIF_MAX_SEGMENTS_PER_SEGMENT_BLOCK) + /*header_block*/1) +#define XEN_IDE0_MAJOR 3 +#define XEN_IDE1_MAJOR 22 +#define XEN_SCSI_DISK0_MAJOR 8 +#define XEN_SCSI_DISK1_MAJOR 65 +#define XEN_SCSI_DISK2_MAJOR 66 +#define XEN_SCSI_DISK3_MAJOR 67 +#define XEN_SCSI_DISK4_MAJOR 68 +#define XEN_SCSI_DISK5_MAJOR 69 +#define XEN_SCSI_DISK6_MAJOR 70 +#define XEN_SCSI_DISK7_MAJOR 71 +#define XEN_SCSI_DISK8_MAJOR 128 +#define XEN_SCSI_DISK9_MAJOR 129 +#define XEN_SCSI_DISK10_MAJOR 130 +#define XEN_SCSI_DISK11_MAJOR 131 +#define XEN_SCSI_DISK12_MAJOR 132 +#define XEN_SCSI_DISK13_MAJOR 133 +#define XEN_SCSI_DISK14_MAJOR 134 +#define XEN_SCSI_DISK15_MAJOR 135 #endif /* __XEN_PUBLIC_IO_BLKIF_H__ */ diff -x .svn -ur sys/xen/xenbus/xenbusvar.h /usr/home/justing/perforce/SpectraBSD/head/sys/xen/xenbus/xenbusvar.h --- sys/xen/xenbus/xenbusvar.h 2011-06-10 22:59:01.723658126 -0600 +++ /usr/home/justing/perforce/SpectraBSD/head/sys/xen/xenbus/xenbusvar.h 2012-01-31 16:41:51.486111080 -0700 @@ -104,6 +104,20 @@ XenbusState xenbus_read_driver_state(const char *path); /** + * Return the state of the "other end" (peer) of a XenBus device. + * + * \param dev The XenBus device whose peer to query. + * + * \return The current state of the peer device or XenbusStateClosed if no + * state can be read. + */ +static inline XenbusState +xenbus_get_otherend_state(device_t dev) +{ + return (xenbus_read_driver_state(xenbus_get_otherend_path(dev))); +} + +/** * Initialize and register a watch on the given path (client suplied storage). * * \param dev The XenBus device requesting the watch service. Only in sys/xen/xenstore: xenstore.c.orig --Apple-Mail=_D06AA316-BD1F-4F32-9F53-83C356F10EA6-- From owner-freebsd-xen@FreeBSD.ORG Thu Feb 2 19:31:37 2012 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50914106564A for ; Thu, 2 Feb 2012 19:31:37 +0000 (UTC) (envelope-from krichy@tvnetwork.hu) Received: from smtp-b.tvnetwork.hu (smtp-b.tvnetwork.hu [109.61.0.52]) by mx1.freebsd.org (Postfix) with SMTP id B4D1F8FC1A for ; Thu, 2 Feb 2012 19:31:36 +0000 (UTC) Received: (qmail 11660 invoked by uid 1001); 2 Feb 2012 20:31:34 +0100 Received: from 109.61.101.194 by smtp-b.tvnetwork.hu (envelope-from , uid 64011) with qmail-scanner-1.25st (clamdscan: 0.88.1/1396. spamassassin: 3.0.3. perlscan: 1.25st. Clear:RC:1(109.61.101.194):SA:0(-1.0/5.0):. Processed in 4.232473 secs); 02 Feb 2012 19:31:34 -0000 X-Spam-Status: No, hits=-1.0 required=5.0 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp-b.tvnetwork.hu X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_20 autolearn=ham version=3.3.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -0.0 BAYES_20 BODY: Bayes spam probability is 5 to 20% * [score: 0.1597] X-Envelope-From: krichy@tvnetwork.hu Received: from unknown (HELO krichy.tvnetwork.hu) (109.61.101.194) by smtp-b.tvnetwork.hu with SMTP; 2 Feb 2012 20:31:30 +0100 Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 35E19892; Thu, 2 Feb 2012 20:31:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 316291E26; Thu, 2 Feb 2012 20:31:30 +0100 (CET) Date: Thu, 2 Feb 2012 20:31:30 +0100 (CET) From: Richard Kojedzinszky To: Colin Percival In-Reply-To: Message-ID: References: <4F1FD67B.3080305@freebsd.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-xen@FreeBSD.org Subject: Re: amd64 xen hvm shutdown X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 02 Feb 2012 19:31:37 -0000 Dear users, I am trying to compare the 8.2 i386 PV mode and 9.0 amd64 hvm mode, regarding $ xm shutdown from outside. While 8.2 PV shuts down well, 9.0 hvm does not. Is it an issue of the xen hypervisor, or of freebsd? What experience do others have? Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Thu, 26 Jan 2012, Richard Kojedzinszky wrote: > Date: Thu, 26 Jan 2012 08:57:13 +0100 (CET) > From: Richard Kojedzinszky > To: Colin Percival > Cc: freebsd-xen@FreeBSD.org > Subject: Re: amd64 xen hvm shutdown > > Dear Colin, > > I am not familiar with the method, but what happens exactly when I issue xm > shutdown on the host ? > How does the inner guest handle it? Does it simply send a signal to init, or > does to host emulate the press of the power button? > > Thanks in advance, > > Kojedzinszky Richard > Euronet Magyarorszag Informatikai Zrt. > > On Wed, 25 Jan 2012, Richard Kojedzinszky wrote: > >> Date: Wed, 25 Jan 2012 11:40:47 +0100 (CET) >> From: Richard Kojedzinszky >> To: Colin Percival >> Cc: freebsd-xen@FreeBSD.org >> Subject: Re: amd64 xen hvm shutdown >> >> Dear Colin, >> >> My config for this domain is here: >> >> kernel = "/usr/lib/xen-4.0/boot/hvmloader" >> builder = "hvm" >> >> name = 'db.real-charts.com' >> memory = 512 >> vcpus = 1 >> cpus = '1-3' >> disk = [ >> 'phy:/dev/sys/db.real-charts.com-root,xvda,w', >> 'phy:/dev/sys/db.real-charts.com-swap,xvdb,w', >> 'phy:/dev/sys/db.real-charts.com-tmp,xvdc,w', >> 'phy:/dev/sys/db.real-charts.com-var,xvdd,w', >> 'phy:/dev/sys/db.real-charts.com-usr,xvde,w' >> ] >> vif = [ 'mac=00:16:3e:00:04:01,bridge=eth0' ] >> >> vnc = 1 >> boot = "c" >> stdvga = 1 >> localtime = 0 >> >> hpet = 1 >> acpi = 1 >> apic = 1 >> pae = 1 >> usb = 0 >> >> on_poweroff = "destroy" >> on_reboot = "restart" >> on_crash = "restart" >> >> But as I read the documentation, on_poweroff means what to do when the >> domain powers itself off. But for me it seems, that xen sends a halt to the >> freebsd domain, exactly as if I issue a >> # halt >> In that case, the domain does halt, and shows that the system is halted, >> and press any key to reboot. Unfortunately I dont have a freebsd on real >> hardware, so I dont know if issue a halt on that does it powers itself off. >> >> But when inside the domain, and I issue poweroff, it works as expected, I >> guess it sends an acpi poweroff to xen, and then tha virtual machine gets >> stopped. >> >> Regards, >> >> Kojedzinszky Richard >> Euronet Magyarorszag Informatikai Zrt. >> >> On Wed, 25 Jan 2012, Colin Percival wrote: >> >>> Date: Wed, 25 Jan 2012 02:16:27 -0800 >>> From: Colin Percival >>> To: Richard Kojedzinszky >>> Cc: freebsd-xen@FreeBSD.org >>> Subject: Re: amd64 xen hvm shutdown >>> >>> On 01/25/12 02:09, Richard Kojedzinszky wrote: >>>> I am looking for a solution to be able to shutdown my freebsd 9.0 amd64 >>>> xen hvm >>>> domain from outside, from the host. Precisely, when the host is halted, >>>> it >>>> issues an >>>> # xm shutdown domain --halt --wait >>>> >>>> to the domain, and the domain does not poweroff. It behaves as if I issue >>>> a halt >>>> inside of it, and not a poweroff. Is there a way to have it power down >>>> itself? >>> >>> That sounds like a Xen configuration issue ("poweroff behaviour"?) rather >>> than a >>> FreeBSD issue to me. >>> >>> -- >>> Colin Percival >>> Security Officer, FreeBSD | freebsd.org | The power to serve >>> Founder / author, Tarsnap | tarsnap.com | Online backups for the truly >>> paranoid >>> >> _______________________________________________ >> freebsd-xen@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-xen >> To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-xen@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-xen > To unsubscribe, send any mail to "freebsd-xen-unsubscribe@freebsd.org" > From owner-freebsd-xen@FreeBSD.ORG Thu Feb 2 21:37:45 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62BA4106564A; Thu, 2 Feb 2012 21:37:45 +0000 (UTC) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [70.89.174.89]) by mx1.freebsd.org (Postfix) with ESMTP id 30B828FC15; Thu, 2 Feb 2012 21:37:44 +0000 (UTC) Received: from kevinmurphy.sldomain.com (207-225-98-3.dia.static.qwest.net [207.225.98.3]) (authenticated bits=0) by aslan.scsiguy.com (8.14.5/8.14.5) with ESMTP id q12LbhNd005444 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 2 Feb 2012 14:37:43 -0700 (MST) (envelope-from gibbs@scsiguy.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Justin T. Gibbs" In-Reply-To: Date: Thu, 2 Feb 2012 14:37:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0ECDE507-94CF-4330-ABCE-59F9079B46F9@scsiguy.com> References: <4F1FD67B.3080305@freebsd.org> To: Richard Kojedzinszky X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (aslan.scsiguy.com [70.89.174.89]); Thu, 02 Feb 2012 14:37:44 -0700 (MST) Cc: freebsd-xen@freebsd.org Subject: Re: amd64 xen hvm shutdown X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 02 Feb 2012 21:37:45 -0000 On Feb 2, 2012, at 12:31 PM, Richard Kojedzinszky wrote: > Dear users, >=20 > I am trying to compare the 8.2 i386 PV mode and 9.0 amd64 hvm mode, = regarding >=20 > $ xm shutdown >=20 > from outside. >=20 > While 8.2 PV shuts down well, 9.0 hvm does not. Is it an issue of the = xen hypervisor, or of freebsd? >=20 > What experience do others have? If you are using a FreeBSD amd64 kernel with Xen PV drivers installed, = shutdown behavior is controlled by the PV "control" driver. This driver notices updates to the = "control/shutdown" node in the XenStore and is supposed to act accordingly. For a reboot or power off event, it = simply calls shutdown_nice(RB_POWEROFF|RB_HALT), or shutdown_nice(0) as appropriate. = If you can capture the value of the shutdown node in the XenStore, it should be pretty easy to = debug this. -- Justin= From owner-freebsd-xen@FreeBSD.ORG Thu Feb 2 23:19:55 2012 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07ECC106564A for ; Thu, 2 Feb 2012 23:19:55 +0000 (UTC) (envelope-from krichy@tvnetwork.hu) Received: from smtp-b.tvnetwork.hu (smtp-b.tvnetwork.hu [109.61.0.52]) by mx1.freebsd.org (Postfix) with SMTP id 4F49B8FC0C for ; Thu, 2 Feb 2012 23:19:53 +0000 (UTC) Received: (qmail 20145 invoked by uid 1001); 3 Feb 2012 00:19:51 +0100 Received: from 109.61.101.194 by smtp-b.tvnetwork.hu (envelope-from , uid 64011) with qmail-scanner-1.25st (clamdscan: 0.88.1/1396. spamassassin: 3.0.3. perlscan: 1.25st. Clear:RC:1(109.61.101.194):SA:0(-2.9/5.0):. Processed in 2.232753 secs); 02 Feb 2012 23:19:51 -0000 X-Spam-Status: No, hits=-2.9 required=5.0 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp-b.tvnetwork.hu X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.1 X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Envelope-From: krichy@tvnetwork.hu Received: from unknown (HELO krichy.tvnetwork.hu) (109.61.101.194) by smtp-b.tvnetwork.hu with SMTP; 3 Feb 2012 00:19:49 +0100 Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 2649A892; Fri, 3 Feb 2012 00:19:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 219891E26; Fri, 3 Feb 2012 00:19:49 +0100 (CET) Date: Fri, 3 Feb 2012 00:19:49 +0100 (CET) From: Richard Kojedzinszky To: "Justin T. Gibbs" In-Reply-To: <0ECDE507-94CF-4330-ABCE-59F9079B46F9@scsiguy.com> Message-ID: References: <4F1FD67B.3080305@freebsd.org> <0ECDE507-94CF-4330-ABCE-59F9079B46F9@scsiguy.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-xen@freebsd.org Subject: Re: amd64 xen hvm shutdown X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 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: Thu, 02 Feb 2012 23:19:55 -0000 Dear Justin, Thanks for your help. You gave me a clue, where to look for the problem. In short, $ xm shutdown issues a poweroff to the control/shutdown node, but with the default debian scripts, /etc/init.d/xendomains issues $ xm shutdown --halt which sends halt instead of a poweroff. So I was blind to skip that argument to xm shutdown, or I did not gave enough attention for it, as a linux pv guest halts/powers itself off for either. Its freebsd's feature to be able to halt only, and the script does this exactly. On the other way, xen's documentation does not mention much about the --halt option, and the behaviour without that given. So to be short, and maybe useful for others, who host freebsd hvm with pv drivers on debian, to remove the "--halt" options from variables in /etc/default/xendomains At least for me, with this, my linux pv, freebsd pv, and freebsd hvm domains do a nice poweroff upon a host reboot/halt. Many thanks for giving that clue. Regards, Kojedzinszky Richard Euronet Magyarorszag Informatikai Zrt. On Thu, 2 Feb 2012, Justin T. Gibbs wrote: > Date: Thu, 2 Feb 2012 14:37:38 -0700 > From: Justin T. Gibbs > To: Richard Kojedzinszky > Cc: Colin Percival , freebsd-xen@freebsd.org > Subject: Re: amd64 xen hvm shutdown > > On Feb 2, 2012, at 12:31 PM, Richard Kojedzinszky wrote: > >> Dear users, >> >> I am trying to compare the 8.2 i386 PV mode and 9.0 amd64 hvm mode, regarding >> >> $ xm shutdown >> >> from outside. >> >> While 8.2 PV shuts down well, 9.0 hvm does not. Is it an issue of the xen hypervisor, or of freebsd? >> >> What experience do others have? > > If you are using a FreeBSD amd64 kernel with Xen PV drivers installed, shutdown behavior is controlled > by the PV "control" driver. This driver notices updates to the "control/shutdown" node in the XenStore and > is supposed to act accordingly. For a reboot or power off event, it simply calls > shutdown_nice(RB_POWEROFF|RB_HALT), or shutdown_nice(0) as appropriate. If you can capture the > value of the shutdown node in the XenStore, it should be pretty easy to debug this. > > -- > Justin