From owner-freebsd-xen@FreeBSD.ORG Sun Jan 5 21:55:34 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B932FF1 for ; Sun, 5 Jan 2014 21:55:34 +0000 (UTC) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B18811788 for ; Sun, 5 Jan 2014 21:55:33 +0000 (UTC) Received: by mail-la0-f45.google.com with SMTP id eh20so9317662lab.4 for ; Sun, 05 Jan 2014 13:55:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aFZAtkayilhQJ7rhwgkobHzrUqIslOB12Lt2ONgVhM0=; b=iOqUhv/E+xHrB+uxr6jpZ7qnOZY6oJ7mo3QZyDbolEvA4HR9N0Cx5Z9P1ABTqxCpc1 1+TvgaW5ONWu1J8ZIrcC5ysZVLfBLmZtapX65bdwKTm5kIml4spYT9uZOIsqeQVf8p1R nwCqwhHz/lu+d8ILmspAjJ871xpawVRr7HneD7qfRR2+63s2mnPGNh9or4s5QsPL+OTy j4XaDzIuDcu+h9iT5s1Jxsthri+Bulz8fCEFgHYy6ZvHI75Kf4FGxjEYv74tDM+7EVuo Cwn/95t/3V7nX3wbL5FeBuxssIIA3p/qdTCqZU9R2/YIaMRIkubBKrKpNKy2s6aMMi+i s7Qw== X-Gm-Message-State: ALoCoQlxc6Vvl5G4DOcxr5O9W4zKCmQAoZCn1BEfvwmIISxqrGD25R8/1tS20wZ3jH1mQURnF3Ts X-Received: by 10.152.26.72 with SMTP id j8mr33789lag.85.1388958926488; Sun, 05 Jan 2014 13:55:26 -0800 (PST) Received: from [10.0.0.94] (ti0273a400-0979.bb.online.no. [85.165.250.215]) by mx.google.com with ESMTPSA id mq10sm41398588lbb.12.2014.01.05.13.55.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jan 2014 13:55:25 -0800 (PST) Message-ID: <52C9D4CA.6070403@linaro.org> Date: Sun, 05 Jan 2014 21:55:22 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Roger Pau Monne , freebsd-xen@freebsd.org, freebsd-current@freebsd.org, xen-devel@lists.xen.org, gibbs@freebsd.org, jhb@freebsd.org, kib@freebsd.org, julien.grall@citrix.com Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> In-Reply-To: <1388677433-49525-16-git-send-email-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Jan 2014 21:55:34 -0000 On 01/02/2014 03:43 PM, Roger Pau Monne wrote: > Introduce a Xen specific nexus that is going to be in charge for > attaching Xen specific devices. Now that we have a xenpv bus, do we really need a specific nexus for Xen? We should be able to use the identify callback of xenpv to create the bus. The other part of this patch can be merged in the patch #14 "Introduce xenpv bus and a dummy pvcpu device". -- Julien Grall From owner-freebsd-xen@FreeBSD.ORG Sun Jan 5 21:59:12 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42FAE163 for ; Sun, 5 Jan 2014 21:59:12 +0000 (UTC) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B72F9179F for ; Sun, 5 Jan 2014 21:59:11 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id l4so9547724lbv.27 for ; Sun, 05 Jan 2014 13:59:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Hd7a+G9AczFGRnmFEywXhhbfOAzBN+U2XkAWW/PPKlE=; b=Snx40fKVwfmN9zYI+hx9s//2B8cmmTeVtWXCGMBr0lUiBABIbCyO9r/qsRSqL7C+m4 7WS/ofJO9vO8odNaCA/BaCzAsWSdsd14hwar6JaRM7H7534FmpVOVIAVmYR+Q+B/kzpl EVOM3mk0+OKq2YJFtgHBV7ae3fqI10/wataoCNNwzLpDX/T+v4H8jL7+8xyV2yZPTv7a Wt24fcKu29iKP+yU9KaIDVlf9pEfp+vw5B0nZm6iwpeUK1EFBH1GIzJ12nlVOgw7zCWg 44siZ+g74dRJYcA87sjVCv3i/6KixC4Rf+FIjuJnNwqSoaWPrYZ5dYhGAPGXzVW+19t/ 81Kw== X-Gm-Message-State: ALoCoQmNj9ZjaSpMNiNWLvrx9U73YaunuNGrRIQEMhT3qqt0ZgOcTJ6giaQrX+981VXI4ALJDqP1 X-Received: by 10.152.19.65 with SMTP id c1mr452980lae.49.1388958773550; Sun, 05 Jan 2014 13:52:53 -0800 (PST) Received: from [10.0.0.94] (ti0273a400-0979.bb.online.no. [85.165.250.215]) by mx.google.com with ESMTPSA id mq10sm41404148lbb.12.2014.01.05.13.52.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jan 2014 13:52:52 -0800 (PST) Message-ID: <52C9D432.3040409@linaro.org> Date: Sun, 05 Jan 2014 21:52:50 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Roger Pau Monne , freebsd-xen@freebsd.org, freebsd-current@freebsd.org, xen-devel@lists.xen.org, gibbs@freebsd.org, jhb@freebsd.org, kib@freebsd.org, julien.grall@citrix.com Subject: Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-15-git-send-email-roger.pau@citrix.com> In-Reply-To: <1388677433-49525-15-git-send-email-roger.pau@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 05 Jan 2014 21:59:12 -0000 On 01/02/2014 03:43 PM, Roger Pau Monne wrote: > Since Xen PVH guests doesn't have ACPI, we need to create a dummy > bus so top level Xen devices can attach to it (instead of > attaching directly to the nexus) and a pvcpu device that will be used > to fill the pcpu->pc_device field. > --- > sys/conf/files.amd64 | 1 + > sys/conf/files.i386 | 1 + > sys/x86/xen/xenpv.c | 155 ++++++++++++++++++++++++++++++++++++++++++++++++++ I think it makes more sense to have 2 files: one for xenpv bus and one for a dummy pvcpu device. It would allow us to move xenpv bus to common code (sys/xen or sys/dev/xen). [..] > + > +static int > +xenpv_probe(device_t dev) > +{ > + > + device_set_desc(dev, "Xen PV bus"); > + device_quiet(dev); > + return (0); As I understand, 0 means I can "handle" the current device, in this case if a device is probing, because it doesn't have yet a driver, we will use xenpv and end up with 2 (or even more) xenpv buses. As we only want to probe xenpv bus once, when the bus was added manually, returning BUS_PROBE_NO_WILDCARD would suit better. [..] > +static int > +xenpvcpu_probe(device_t dev) > +{ > + > + device_set_desc(dev, "Xen PV CPU"); > + return (0); Same here: BUS_PROBE_NOWILDCARD. -- Julien Grall From owner-freebsd-xen@FreeBSD.ORG Mon Jan 6 09:35:38 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48C0F840; Mon, 6 Jan 2014 09:35:38 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBA4F171D; Mon, 6 Jan 2014 09:35:36 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,611,1384300800"; d="scan'208";a="87820970" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 06 Jan 2014 09:35:23 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Mon, 6 Jan 2014 04:35:27 -0500 Message-ID: <52CA78DE.9060502@citrix.com> Date: Mon, 6 Jan 2014 10:35:26 +0100 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julien Grall , , , , , , , Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> <52C9D4CA.6070403@linaro.org> In-Reply-To: <52C9D4CA.6070403@linaro.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 09:35:38 -0000 On 05/01/14 22:55, Julien Grall wrote: > > > On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >> Introduce a Xen specific nexus that is going to be in charge for >> attaching Xen specific devices. > > Now that we have a xenpv bus, do we really need a specific nexus for Xen? > We should be able to use the identify callback of xenpv to create the bus. > > The other part of this patch can be merged in the patch #14 "Introduce > xenpv bus and a dummy pvcpu device". On x86 at least we need the Xen specific nexus, or we will fall back to use the legacy nexus which is not what we really want. From owner-freebsd-xen@FreeBSD.ORG Mon Jan 6 09:47:52 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E871D49; Mon, 6 Jan 2014 09:47:52 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E2A341819; Mon, 6 Jan 2014 09:47:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,611,1384300800"; d="scan'208";a="87823046" Received: from accessns.citrite.net (HELO FTLPEX01CL02.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 06 Jan 2014 09:46:52 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.79) with Microsoft SMTP Server id 14.2.342.4; Mon, 6 Jan 2014 04:46:56 -0500 Message-ID: <52CA7B8F.9060402@citrix.com> Date: Mon, 6 Jan 2014 10:46:55 +0100 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julien Grall , , , , , , , Subject: Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-15-git-send-email-roger.pau@citrix.com> <52C9D432.3040409@linaro.org> In-Reply-To: <52C9D432.3040409@linaro.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 09:47:52 -0000 On 05/01/14 22:52, Julien Grall wrote: > > > On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >> Since Xen PVH guests doesn't have ACPI, we need to create a dummy >> bus so top level Xen devices can attach to it (instead of >> attaching directly to the nexus) and a pvcpu device that will be used >> to fill the pcpu->pc_device field. >> --- >> sys/conf/files.amd64 | 1 + >> sys/conf/files.i386 | 1 + >> sys/x86/xen/xenpv.c | 155 >> ++++++++++++++++++++++++++++++++++++++++++++++++++ > > I think it makes more sense to have 2 files: one for xenpv bus and one > for a dummy pvcpu device. It would allow us to move xenpv bus to common > code (sys/xen or sys/dev/xen). Ack. I wasn't thinking other arches will probably use the xenpv bus but not the dummy cpu device. Would you agree to leave xenpv bus inside x86/xen for now and move the dummy PV cpu device to dev/xen/pvcpu/? > > [..] > >> + >> +static int >> +xenpv_probe(device_t dev) >> +{ >> + >> + device_set_desc(dev, "Xen PV bus"); >> + device_quiet(dev); >> + return (0); > > As I understand, 0 means I can "handle" the current device, in this case > if a device is probing, because it doesn't have yet a driver, we will > use xenpv and end up with 2 (or even more) xenpv buses. > > As we only want to probe xenpv bus once, when the bus was added > manually, returning BUS_PROBE_NO_WILDCARD would suit better. > > [..] > >> +static int >> +xenpvcpu_probe(device_t dev) >> +{ >> + >> + device_set_desc(dev, "Xen PV CPU"); >> + return (0); > > Same here: BUS_PROBE_NOWILDCARD. Ack for both, will change it to BUS_PROBE_NOWILDCARD. While at it, we should also change xenstore probe function to return BUS_PROBE_NOWILDCARD. From owner-freebsd-xen@FreeBSD.ORG Mon Jan 6 11:06:59 2014 Return-Path: Delivered-To: freebsd-xen@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB1E9795 for ; Mon, 6 Jan 2014 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D59A210A5 for ; Mon, 6 Jan 2014 11:06:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s06B6wF7045466 for ; Mon, 6 Jan 2014 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id s06B6wss045464 for freebsd-xen@FreeBSD.org; Mon, 6 Jan 2014 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jan 2014 11:06:58 GMT Message-Id: <201401061106.s06B6wss045464@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 Subject: Current problem reports assigned to freebsd-xen@FreeBSD.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 11:06:59 -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/183139 xen [xen] [patch] ifconfig options on xn0 lost after xen v o kern/180788 xen [xen] [panic] XEN PV kernel 9.2-BETA1 panics on boot o kern/180403 xen [xen] Problems with GENERIC and XENHVM kernels with Xe o kern/180402 xen [xen] XEN kernel does not load in XenClient 4.5.5 o kern/179814 xen [xen] mountroot fails with error=19 under Xen on 9-STA o kern/176471 xen [xen] xn driver crash on detach o kern/176053 xen [xen] [patch] i386: Correct wrong usage of vsnprintf() o kern/175954 xen [xen] XENHVM xn network driver extreme packet loss dur o kern/175822 xen [xen] FreeBSD 9.1 does not work with Xen 4.0 o kern/175757 xen [xen] [patch] xen pvhvm looses keyboard input from VNC o kern/171873 xen [xen] xn network device floods warning in dmesg o kern/171118 xen [xen] FreeBSD XENHVM guest doesn't shutdown cleanly o kern/166174 xen [xen] Problems ROOT MOUNT ERROR o kern/165418 xen [xen] Problems mounting root filesystem from XENHVM o kern/164630 xen [xen] XEN HVM kernel: run_interrupt_driven_hooks: stil 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 40 problems total. From owner-freebsd-xen@FreeBSD.ORG Mon Jan 6 11:28:58 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F1FFED3 for ; Mon, 6 Jan 2014 11:28:58 +0000 (UTC) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8246415CB for ; Mon, 6 Jan 2014 11:28:57 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id w7so9691121lbi.38 for ; Mon, 06 Jan 2014 03:28:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wAmz0/AnkdSWtFxyqTbBWmZeac9Tq38a7Gv+UnPnKo0=; b=k2lSoGEd3gPxUitWDHK9RkO3zR0UjrpdLWz86ochaxm/rWw43sfkmlkpMWGAAp+kKn CZMBBfOsa9CW9H3WhIrirEjiEfGg3zSuSoVGiIJ+etjEJZY1ydTWQ+gJvljOY7FZgSxF lGraL5C04/kjiPgc0yNUOE2cebh9fNfb4Xj4ydqS7TEmpo2QynSsQZnmS5DNvoeyzsSu chjfw8eWEtgGE1CnBMlT75pjdQFQqqAWL0pcU/vF9ww3u1owthwmPU9VFuY+S+N+BfP0 vRffgzkZsYCDR4EO9+JfLsKa2p7PU+Am3p13nlPoJ5FHfSJSVvJutijI+eIazyDbhpE8 N7vA== X-Gm-Message-State: ALoCoQmeBj9ad10MC+nFeiwHntM1o9H6TibSwpXw8f8DGrEOxtY3wmHE0UD30r741T5/ju41iifj X-Received: by 10.152.44.225 with SMTP id h1mr44576319lam.22.1389007730321; Mon, 06 Jan 2014 03:28:50 -0800 (PST) Received: from [192.168.42.157] ([195.69.14.50]) by mx.google.com with ESMTPSA id mv9sm42580544lbc.0.2014.01.06.03.28.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 03:28:49 -0800 (PST) Message-ID: <52CA9347.8040901@linaro.org> Date: Mon, 06 Jan 2014 11:28:07 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , freebsd-xen@freebsd.org, freebsd-current@freebsd.org, xen-devel@lists.xen.org, gibbs@freebsd.org, jhb@freebsd.org, kib@freebsd.org, julien.grall@citrix.com Subject: Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-15-git-send-email-roger.pau@citrix.com> <52C9D432.3040409@linaro.org> <52CA7B8F.9060402@citrix.com> In-Reply-To: <52CA7B8F.9060402@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 11:28:58 -0000 On 01/06/2014 09:46 AM, Roger Pau MonnĂ© wrote: > On 05/01/14 22:52, Julien Grall wrote: >> >> >> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>> Since Xen PVH guests doesn't have ACPI, we need to create a dummy >>> bus so top level Xen devices can attach to it (instead of >>> attaching directly to the nexus) and a pvcpu device that will be used >>> to fill the pcpu->pc_device field. >>> --- >>> sys/conf/files.amd64 | 1 + >>> sys/conf/files.i386 | 1 + >>> sys/x86/xen/xenpv.c | 155 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> I think it makes more sense to have 2 files: one for xenpv bus and one >> for a dummy pvcpu device. It would allow us to move xenpv bus to common >> code (sys/xen or sys/dev/xen). > > Ack. I wasn't thinking other arches will probably use the xenpv bus but > not the dummy cpu device. Would you agree to leave xenpv bus inside > x86/xen for now and move the dummy PV cpu device to dev/xen/pvcpu/? As we will attach every xen device to xenpv, it makes more sense to have xenpv bus used on ARM. It will avoid duplication code and keep it nicer. I'm fine with this solution for now. I will update/move the code when I will send the patch series to support FreeBSD on Xen on ARM. >> >> [..] >> >>> + >>> +static int >>> +xenpv_probe(device_t dev) >>> +{ >>> + >>> + device_set_desc(dev, "Xen PV bus"); >>> + device_quiet(dev); >>> + return (0); >> >> As I understand, 0 means I can "handle" the current device, in this case >> if a device is probing, because it doesn't have yet a driver, we will >> use xenpv and end up with 2 (or even more) xenpv buses. >> >> As we only want to probe xenpv bus once, when the bus was added >> manually, returning BUS_PROBE_NO_WILDCARD would suit better. >> >> [..] >> >>> +static int >>> +xenpvcpu_probe(device_t dev) >>> +{ >>> + >>> + device_set_desc(dev, "Xen PV CPU"); >>> + return (0); >> >> Same here: BUS_PROBE_NOWILDCARD. > > Ack for both, will change it to BUS_PROBE_NOWILDCARD. While at it, we > should also change xenstore probe function to return BUS_PROBE_NOWILDCARD. > Right, I have a patch for xenstore. Do you want me to send it? -- Julien Grall From owner-freebsd-xen@FreeBSD.ORG Mon Jan 6 11:33:31 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 88795D6 for ; Mon, 6 Jan 2014 11:33:31 +0000 (UTC) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0910B1695 for ; Mon, 6 Jan 2014 11:33:30 +0000 (UTC) Received: by mail-lb0-f180.google.com with SMTP id x18so9852684lbi.11 for ; Mon, 06 Jan 2014 03:33:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BHCU8QxWQB+7yKHp3kswSx7pa3p/IlbprJea1h0acGc=; b=DdbUFy55oUiEOrAgNp1hXpVrmwRCOX9BBiFMFB8koI5jaodYewU8cUbga6B1KVad9k 7YQJuIT1nf3RnUrzNT7uThiV/+pAUPasZSdTheVf7wg2jieYrH9o79kpscTch69107xS S/V3PkR5wAI9Ztq4B2FGz0eU9gv76hBzvHu85Je4krIEHRKlrJ+LVBoYwMsCLxaYepZS KvfgWa66f3miSQCRw6Zpu3zf6L94a2xv8rlkckhXJTR7a1IEpgO8lgKq2jm4n8tTcF7J Dwhc8+RTdmX4YWXnGNCdj1+k4Q3OEXwX29eA8+DYGMpeweybNCW49f0mRImINTHSZQFF /E/w== X-Gm-Message-State: ALoCoQkBir3BKZYqc9T8pgwDc3+Byn/RDu3Li8F4K6LLWMM7n2Lw2ZZDkEhn2JAIfAycVA66A48T X-Received: by 10.112.13.169 with SMTP id i9mr197869lbc.73.1389008009013; Mon, 06 Jan 2014 03:33:29 -0800 (PST) Received: from [192.168.42.157] ([195.69.14.50]) by mx.google.com with ESMTPSA id rb4sm42585872lbb.1.2014.01.06.03.33.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 03:33:27 -0800 (PST) Message-ID: <52CA9481.4090703@linaro.org> Date: Mon, 06 Jan 2014 11:33:21 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , freebsd-xen@freebsd.org, freebsd-current@freebsd.org, xen-devel@lists.xen.org, gibbs@freebsd.org, jhb@freebsd.org, kib@freebsd.org, julien.grall@citrix.com Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> <52C9D4CA.6070403@linaro.org> <52CA78DE.9060502@citrix.com> In-Reply-To: <52CA78DE.9060502@citrix.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 06 Jan 2014 11:33:31 -0000 On 01/06/2014 09:35 AM, Roger Pau MonnĂ© wrote: > On 05/01/14 22:55, Julien Grall wrote: >> >> >> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>> Introduce a Xen specific nexus that is going to be in charge for >>> attaching Xen specific devices. >> >> Now that we have a xenpv bus, do we really need a specific nexus for Xen? >> We should be able to use the identify callback of xenpv to create the bus. >> >> The other part of this patch can be merged in the patch #14 "Introduce >> xenpv bus and a dummy pvcpu device". > > On x86 at least we need the Xen specific nexus, or we will fall back to > use the legacy nexus which is not what we really want. > Oh right, in any case can we use the identify callback of xenpv to add the bus? With this solution xenpv can add itself no matter FreeBSD use the generic nexus or the nexus Xen, of course with a check if we are running on Xen :). For instance, on ARM side I don't plan to have a specific Xen nexus. Cheers, -- Julien Grall From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 08:20:40 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B49CE19F for ; Tue, 7 Jan 2014 08:20:40 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0EF441D6F for ; Tue, 7 Jan 2014 08:20:39 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,617,1384300800"; d="scan'208";a="88190503" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Jan 2014 08:20:33 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Tue, 7 Jan 2014 03:20:32 -0500 Message-ID: <52CBB8D3.8090508@citrix.com> Date: Tue, 7 Jan 2014 09:20:35 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Mike C. , Subject: Re: Panic with FreeBSD 10 RC2 on Netbsd Xen dom0 References: <20131218001615.GA10501@moore.morphism.de> <52B24E18.7090109@gmail.com> <52B2AC26.2020301@citrix.com> In-Reply-To: <52B2AC26.2020301@citrix.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 08:20:40 -0000 On 19/12/13 09:19, Roger Pau Monné wrote: > On 19/12/13 02:38, Mike C. wrote: >> I've reported this to xen-devel I while ago. >> >> >> It worked in the first FreeBSD-10 current releases but them it stoped, I >> believe a previous issue was re-introduced somehow! >> >> NetBSD Xen backend does not support TSO/GSO at all, there was a very >> similar problem in FreeBSD 9 a while a go, and my guess is that the code >> tried to use TSO again, and leads to problems if the Dom0 is NetBSD. >> >> >> Also more recently I had problems with Windows GPLPV drivers, and the >> dev tracked the issue to the same.. however in windows DomU's if I >> disabled TSO it would work. >> In FreeBSD at least until Aplha 5, I tried to disable TSO but it still >> wouldn't work. > > By looking at relevant commits in netfront, could you try to revert > r251297 and see if that solves the problem? Also, doing a bisect of the > commits in netfront would be very helpful in order to identify the issue. Ping? Any news on this? Roger. From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 08:25:14 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 118F7207; Tue, 7 Jan 2014 08:25:14 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6B19B1DD6; Tue, 7 Jan 2014 08:25:11 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,617,1384300800"; d="scan'208";a="90356747" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 07 Jan 2014 08:25:00 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Tue, 7 Jan 2014 03:24:58 -0500 Message-ID: <52CBB9DB.6080407@citrix.com> Date: Tue, 7 Jan 2014 09:24:59 +0100 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julien Grall , , , , , , , Subject: Re: [Xen-devel] [PATCH v9 14/19] xen: introduce xenpv bus and a dummy pvcpu device References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-15-git-send-email-roger.pau@citrix.com> <52C9D432.3040409@linaro.org> <52CA7B8F.9060402@citrix.com> <52CA9347.8040901@linaro.org> In-Reply-To: <52CA9347.8040901@linaro.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-DLP: MIA1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 08:25:14 -0000 On 06/01/14 12:28, Julien Grall wrote: > > > On 01/06/2014 09:46 AM, Roger Pau MonnĂ© wrote: >> On 05/01/14 22:52, Julien Grall wrote: >>> >>> >>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>> Since Xen PVH guests doesn't have ACPI, we need to create a dummy >>>> bus so top level Xen devices can attach to it (instead of >>>> attaching directly to the nexus) and a pvcpu device that will be used >>>> to fill the pcpu->pc_device field. >>>> --- >>>> sys/conf/files.amd64 | 1 + >>>> sys/conf/files.i386 | 1 + >>>> sys/x86/xen/xenpv.c | 155 >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> I think it makes more sense to have 2 files: one for xenpv bus and one >>> for a dummy pvcpu device. It would allow us to move xenpv bus to common >>> code (sys/xen or sys/dev/xen). >> >> Ack. I wasn't thinking other arches will probably use the xenpv bus but >> not the dummy cpu device. Would you agree to leave xenpv bus inside >> x86/xen for now and move the dummy PV cpu device to dev/xen/pvcpu/? > > As we will attach every xen device to xenpv, it makes more sense to have > xenpv bus used on ARM. It will avoid duplication code and keep it nicer. > > I'm fine with this solution for now. I will update/move the code when I > will send the patch series to support FreeBSD on Xen on ARM. > >>> >>> [..] >>> >>>> + >>>> +static int >>>> +xenpv_probe(device_t dev) >>>> +{ >>>> + >>>> + device_set_desc(dev, "Xen PV bus"); >>>> + device_quiet(dev); >>>> + return (0); >>> >>> As I understand, 0 means I can "handle" the current device, in this case >>> if a device is probing, because it doesn't have yet a driver, we will >>> use xenpv and end up with 2 (or even more) xenpv buses. >>> >>> As we only want to probe xenpv bus once, when the bus was added >>> manually, returning BUS_PROBE_NO_WILDCARD would suit better. >>> >>> [..] >>> >>>> +static int >>>> +xenpvcpu_probe(device_t dev) >>>> +{ >>>> + >>>> + device_set_desc(dev, "Xen PV CPU"); >>>> + return (0); >>> >>> Same here: BUS_PROBE_NOWILDCARD. >> >> Ack for both, will change it to BUS_PROBE_NOWILDCARD. While at it, we >> should also change xenstore probe function to return >> BUS_PROBE_NOWILDCARD. >> > > Right, I have a patch for xenstore. Do you want me to send it? Sure, send it! From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 08:30:00 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27F1594D; Tue, 7 Jan 2014 08:30:00 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A3F601EB4; Tue, 7 Jan 2014 08:29:58 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,617,1384300800"; d="scan'208";a="88192043" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Jan 2014 08:29:56 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 7 Jan 2014 03:29:55 -0500 Message-ID: <52CBBB05.6020104@citrix.com> Date: Tue, 7 Jan 2014 09:29:57 +0100 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julien Grall , , , , , , , Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> <52C9D4CA.6070403@linaro.org> <52CA78DE.9060502@citrix.com> <52CA9481.4090703@linaro.org> In-Reply-To: <52CA9481.4090703@linaro.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-DLP: MIA1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 08:30:00 -0000 On 06/01/14 12:33, Julien Grall wrote: > > > On 01/06/2014 09:35 AM, Roger Pau MonnĂ© wrote: >> On 05/01/14 22:55, Julien Grall wrote: >>> >>> >>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>> Introduce a Xen specific nexus that is going to be in charge for >>>> attaching Xen specific devices. >>> >>> Now that we have a xenpv bus, do we really need a specific nexus for >>> Xen? >>> We should be able to use the identify callback of xenpv to create the >>> bus. >>> >>> The other part of this patch can be merged in the patch #14 "Introduce >>> xenpv bus and a dummy pvcpu device". >> >> On x86 at least we need the Xen specific nexus, or we will fall back to >> use the legacy nexus which is not what we really want. >> > > Oh right, in any case can we use the identify callback of xenpv to add > the bus? AFAICT this kind of bus devices don't have a identify routine, and they are usually added manually from the specific nexus, see acpi or legacy. Could you add the device on ARM when you detect that you are running as a Xen guest, or in the generic ARM nexus if Xen is detected? Roger. From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 11:07:10 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9749C38E; Tue, 7 Jan 2014 11:07:10 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 02A9D1B4C; Tue, 7 Jan 2014 11:07:08 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,618,1384300800"; d="scan'208";a="88227067" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Jan 2014 11:07:01 +0000 Received: from [IPv6:::1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.78) with Microsoft SMTP Server id 14.2.342.4; Tue, 7 Jan 2014 06:07:00 -0500 Message-ID: <52CBDFD2.603@citrix.com> Date: Tue, 7 Jan 2014 12:06:58 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Konrad Rzeszutek Wilk Subject: Re: [Xen-devel] [PATCH v9 04/19] amd64: introduce hook for custom preload metadata parsers References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-5-git-send-email-roger.pau@citrix.com> <20140103205949.GC2732@phenom.dumpdata.com> In-Reply-To: <20140103205949.GC2732@phenom.dumpdata.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-DLP: MIA2 Cc: jhb@freebsd.org, xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, gibbs@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 11:07:10 -0000 On 03/01/14 21:59, Konrad Rzeszutek Wilk wrote: > On Thu, Jan 02, 2014 at 04:43:38PM +0100, Roger Pau Monne wrote: >> --- >> sys/amd64/amd64/machdep.c | 41 ++++++++++++++++------ >> sys/amd64/include/sysarch.h | 12 ++++++ >> sys/x86/xen/pv.c | 82 +++++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 124 insertions(+), 11 deletions(-) >> >> diff --git a/sys/amd64/amd64/machdep.c b/sys/amd64/amd64/machdep.c >> index eae657b..e073eea 100644 >> --- a/sys/amd64/amd64/machdep.c >> +++ b/sys/amd64/amd64/machdep.c >> @@ -126,6 +126,7 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> #include >> +#include >> #ifdef PERFMON >> #include >> #endif >> @@ -165,6 +166,14 @@ static int set_fpcontext(struct thread *td, const mcontext_t *mcp, >> char *xfpustate, size_t xfpustate_len); >> SYSINIT(cpu, SI_SUB_CPU, SI_ORDER_FIRST, cpu_startup, NULL); >> >> +/* Preload data parse function */ >> +static caddr_t native_parse_preload_data(u_int64_t); >> + >> +/* Default init_ops implementation. */ >> +struct init_ops init_ops = { >> + .parse_preload_data = native_parse_preload_data, > > Extra space there. It's for alignment, looks strange now because there's only one hook. >> +}; >> + >> /* >> * The file "conf/ldscript.amd64" defines the symbol "kernphys". Its value is >> * the physical address at which the kernel is loaded. >> @@ -1683,6 +1692,26 @@ do_next: >> msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]); >> } >> >> +static caddr_t >> +native_parse_preload_data(u_int64_t modulep) >> +{ >> + caddr_t kmdp; >> + >> + preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE); > > Two casts? Could it be done via one? > >> + preload_bootstrap_relocate(KERNBASE); >> + kmdp = preload_search_by_type("elf kernel"); >> + if (kmdp == NULL) >> + kmdp = preload_search_by_type("elf64 kernel"); >> + boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int); >> + kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE; >> +#ifdef DDB >> + ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t); >> + ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t); >> +#endif >> + >> + return (kmdp); >> +} >> + >> u_int64_t >> hammer_time(u_int64_t modulep, u_int64_t physfree) >> { >> @@ -1707,17 +1736,7 @@ hammer_time(u_int64_t modulep, u_int64_t physfree) >> */ >> proc_linkup0(&proc0, &thread0); >> >> - preload_metadata = (caddr_t)(uintptr_t)(modulep + KERNBASE); > > Oh, you just moved the code - right, lets not modify it in this patch. Yes, it's just code movement. > >> - preload_bootstrap_relocate(KERNBASE); >> - kmdp = preload_search_by_type("elf kernel"); >> - if (kmdp == NULL) >> - kmdp = preload_search_by_type("elf64 kernel"); >> - boothowto = MD_FETCH(kmdp, MODINFOMD_HOWTO, int); >> - kern_envp = MD_FETCH(kmdp, MODINFOMD_ENVP, char *) + KERNBASE; >> -#ifdef DDB >> - ksym_start = MD_FETCH(kmdp, MODINFOMD_SSYM, uintptr_t); >> - ksym_end = MD_FETCH(kmdp, MODINFOMD_ESYM, uintptr_t); >> -#endif >> + kmdp = init_ops.parse_preload_data(modulep); >> >> /* Init basic tunables, hz etc */ >> init_param1(); >> diff --git a/sys/amd64/include/sysarch.h b/sys/amd64/include/sysarch.h >> index cd380d4..58ac8cd 100644 >> --- a/sys/amd64/include/sysarch.h >> +++ b/sys/amd64/include/sysarch.h >> @@ -4,3 +4,15 @@ >> /* $FreeBSD$ */ >> >> #include >> + >> +/* >> + * Struct containing pointers to init functions whose >> + * implementation is run time selectable. Selection can be made, >> + * for example, based on detection of a BIOS variant or >> + * hypervisor environment. >> + */ >> +struct init_ops { >> + caddr_t (*parse_preload_data)(u_int64_t); >> +}; >> + >> +extern struct init_ops init_ops; >> diff --git a/sys/x86/xen/pv.c b/sys/x86/xen/pv.c >> index db3b7a3..908b50b 100644 >> --- a/sys/x86/xen/pv.c >> +++ b/sys/x86/xen/pv.c >> @@ -46,6 +46,8 @@ __FBSDID("$FreeBSD$"); >> #include >> #include >> >> +#include >> + >> #include >> #include >> >> @@ -54,6 +56,36 @@ extern u_int64_t hammer_time(u_int64_t, u_int64_t); >> /* Xen initial function */ >> extern u_int64_t hammer_time_xen(start_info_t *, u_int64_t); >> >> +/*--------------------------- Forward Declarations ---------------------------*/ >> +static caddr_t xen_pv_parse_preload_data(u_int64_t); >> + >> +static void xen_pv_set_init_ops(void); >> + >> +/*-------------------------------- Global Data -------------------------------*/ >> +/* Xen init_ops implementation. */ >> +struct init_ops xen_init_ops = { >> + .parse_preload_data = xen_pv_parse_preload_data, >> +}; >> + >> +static struct >> +{ >> + const char *ev; >> + int mask; >> +} howto_names[] = { >> + {"boot_askname", RB_ASKNAME}, >> + {"boot_single", RB_SINGLE}, >> + {"boot_nosync", RB_NOSYNC}, >> + {"boot_halt", RB_ASKNAME}, >> + {"boot_serial", RB_SERIAL}, >> + {"boot_cdrom", RB_CDROM}, >> + {"boot_gdb", RB_GDB}, >> + {"boot_gdb_pause", RB_RESERVED1}, >> + {"boot_verbose", RB_VERBOSE}, >> + {"boot_multicons", RB_MULTIPLE}, >> + {NULL, 0} >> +}; >> + >> +/*-------------------------------- Xen PV init -------------------------------*/ >> /* >> * First function called by the Xen PVH boot sequence. >> * >> @@ -118,6 +150,56 @@ hammer_time_xen(start_info_t *si, u_int64_t xenstack) >> } >> load_cr3(((u_int64_t)&PT4[0]) - KERNBASE); >> >> + /* Set the hooks for early functions that diverge from bare metal */ >> + xen_pv_set_init_ops(); >> + >> /* Now we can jump into the native init function */ >> return (hammer_time(0, physfree)); >> } >> + >> +/*-------------------------------- PV specific -------------------------------*/ >> +/* >> + * Functions to convert the "extra" parameters passed by Xen >> + * into FreeBSD boot options (from the i386 Xen port). >> + */ >> +static char * >> +xen_setbootenv(char *cmd_line) >> +{ >> + char *cmd_line_next; >> + >> + /* Skip leading spaces */ >> + for (; *cmd_line == ' '; cmd_line++); > > Spaces? > >> + >> + for (cmd_line_next = cmd_line; strsep(&cmd_line_next, ",") != NULL;); >> + return (cmd_line); >> +} >> + >> +static int >> +xen_boothowto(char *envp) >> +{ >> + int i, howto = 0; >> + >> + /* get equivalents from the environment */ >> + for (i = 0; howto_names[i].ev != NULL; i++) >> + if (getenv(howto_names[i].ev) != NULL) >> + howto |= howto_names[i].mask; > > You don't believe in '{}' do you ? :-) All this code has also been taken from the FreeBSD Xen i386 PV port, but maybe some refactoring wouldn't be bad :). >> + return (howto); >> +} >> + >> +static caddr_t >> +xen_pv_parse_preload_data(u_int64_t modulep) >> +{ >> + /* Parse the extra boot information given by Xen */ >> + if (HYPERVISOR_start_info->cmd_line) >> + kern_envp = xen_setbootenv(HYPERVISOR_start_info->cmd_line); >> + boothowto |= xen_boothowto(kern_envp); >> + >> + return (NULL); >> +} >> + >> +static void >> +xen_pv_set_init_ops(void) >> +{ >> + /* Init ops for Xen PV */ >> + init_ops = xen_init_ops; >> +} >> -- >> 1.7.7.5 (Apple Git-26) >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 12:30:13 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9FCE775A for ; Tue, 7 Jan 2014 12:30:13 +0000 (UTC) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3268D12AB for ; Tue, 7 Jan 2014 12:30:13 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id bz8so628775wib.11 for ; Tue, 07 Jan 2014 04:30:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:in-reply-to:references:mime-version:content-type:subject :from:date:to:message-id; bh=x4jXAsXUzD+Ksq82jJD89T/2waKnE+hQtaSKgE7JgRE=; b=B5c4jf2/H77hT6eks1adJt3wJvemNkiAiluFutVPcIebrnQuAUQjnTSfcoakg9blSK cbcjZJ5AEpgtmUHtYs/Y76Xfb7qG3Vis8kkTLwmdpROARzpqYh4GOpG0tblpWt0/eSR+ ywBquXb76KtJyCk01ziCFYZm2HNumpCKqhWNbpmvLtJ3v4t2mVBCQPXieB04qozbRMQR 0wOOP9MiOopJJkOR59eLF4uj+GdjDYejCcFGEaRXpYoZYGewpJqtDWCxL1a3EtpyFGlW JD9uZQAl4iCvlEj6MKYNw8a9HLtuuddOycAkyjBS4fWBaYCBojCcQJfR4VgnTcJiff1s W8mQ== X-Received: by 10.194.178.135 with SMTP id cy7mr22319346wjc.21.1389097811634; Tue, 07 Jan 2014 04:30:11 -0800 (PST) Received: from [10.10.250.6] (20.234.54.77.rev.vodafone.pt. [77.54.234.20]) by mx.google.com with ESMTPSA id kr10sm45274480wjc.22.2014.01.07.04.30.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 04:30:10 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: <52CBB8D3.8090508@citrix.com> References: <20131218001615.GA10501@moore.morphism.de> <52B24E18.7090109@gmail.com> <52B2AC26.2020301@citrix.com> <52CBB8D3.8090508@citrix.com> MIME-Version: 1.0 Subject: Re: Panic with FreeBSD 10 RC2 on Netbsd Xen dom0 From: "Mike C." Date: Tue, 07 Jan 2014 12:30:05 +0000 To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= , freebsd-xen@freebsd.org Message-ID: <6153b6b3-8ea9-4dc8-b039-7ab678e33b5e@email.android.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 12:30:13 -0000 Without network reverting to previous commits to test is painful. I tried some before not that one specifically but I do know for sure that somewhere before that release it was working. I have to find some time to make a IMG with that release from my laptop, sadly the laptop is just going to repair because I'm having disk read issues so I won't be able to do it this week, maybe someone else can try? >From the commit however it does seems like the code assumes tso features are available? but I'm not that much of a coder just guessing. That would explain however why even if I disable tso in the domu it still fails. Sorry if the feedback is not much helpful at this time and thanks for following up on this. "Roger Pau MonnĂ©" wrote: >On 19/12/13 09:19, Roger Pau MonnĂ© wrote: >> On 19/12/13 02:38, Mike C. wrote: >>> I've reported this to xen-devel I while ago. >>> >>> >>> It worked in the first FreeBSD-10 current releases but them it >stoped, I >>> believe a previous issue was re-introduced somehow! >>> >>> NetBSD Xen backend does not support TSO/GSO at all, there was a very >>> similar problem in FreeBSD 9 a while a go, and my guess is that the >code >>> tried to use TSO again, and leads to problems if the Dom0 is NetBSD. >>> >>> >>> Also more recently I had problems with Windows GPLPV drivers, and >the >>> dev tracked the issue to the same.. however in windows DomU's if I >>> disabled TSO it would work. >>> In FreeBSD at least until Aplha 5, I tried to disable TSO but it >still >>> wouldn't work. >> >> By looking at relevant commits in netfront, could you try to revert >> r251297 and see if that solves the problem? Also, doing a bisect of >the >> commits in netfront would be very helpful in order to identify the >issue. > >Ping? Any news on this? > >Roger. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 14:28:04 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 581CD3A8 for ; Tue, 7 Jan 2014 14:28:04 +0000 (UTC) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DC73C1CFF for ; Tue, 7 Jan 2014 14:28:03 +0000 (UTC) Received: by mail-ee0-f43.google.com with SMTP id c13so108051eek.30 for ; Tue, 07 Jan 2014 06:27:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oJrmNayZ7gcSCDVuYE0I7/7StUnf4uKZIdoVqCdk1rs=; b=O92EWoPkEUSSOLddrIBEKBpPdZWE3ni2CeknH9N2FcZ7gVuwlh+DaCDNKKQ7V8Ghu2 Dx6D4qRpBXp4nov20X0PHgvVb+WLlE3YMXP7yqPczHA0ebHBOoZb2FQKtb9772+ThTQX Rlz9A6hjjjUjiUqJjap3nZX+JiMC1GLdBJZ7wNtUtQNiDTxFsQid77CtJLZj5kbS9TwF JWVMv4xwilWZiHol+kSs9KiVrqzB3sya59MiX4PH6COMMjBNwDJCb6+Jp7x9cbEjf2Hm uuykgvGVA3rwoiQLPnVBXpgbG2Kb0o0VZRiJ+ddHjlQpd3R4opB/HTHG4SEFSYz/kkQa P7vw== X-Gm-Message-State: ALoCoQmCOtZRitCdjelSDdGkz1CTNu6EKkhijmuWmyqAYGdhy5X2owyUp4HWroRFN9uHqHRQ5alw X-Received: by 10.14.99.66 with SMTP id w42mr90958eef.63.1389104875724; Tue, 07 Jan 2014 06:27:55 -0800 (PST) Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id 7sm35571011eee.12.2014.01.07.06.27.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 06:27:54 -0800 (PST) Message-ID: <52CC0EE8.6060205@linaro.org> Date: Tue, 07 Jan 2014 14:27:52 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131104 Icedove/17.0.10 MIME-Version: 1.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> <52C9D4CA.6070403@linaro.org> <52CA78DE.9060502@citrix.com> <52CA9481.4090703@linaro.org> <52CBBB05.6020104@citrix.com> In-Reply-To: <52CBBB05.6020104@citrix.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: jhb@freebsd.org, xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, gibbs@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 14:28:04 -0000 On 01/07/2014 08:29 AM, Roger Pau MonnĂ© wrote: > On 06/01/14 12:33, Julien Grall wrote: >> >> >> On 01/06/2014 09:35 AM, Roger Pau MonnĂ© wrote: >>> On 05/01/14 22:55, Julien Grall wrote: >>>> >>>> >>>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>>> Introduce a Xen specific nexus that is going to be in charge for >>>>> attaching Xen specific devices. >>>> >>>> Now that we have a xenpv bus, do we really need a specific nexus for >>>> Xen? >>>> We should be able to use the identify callback of xenpv to create the >>>> bus. >>>> >>>> The other part of this patch can be merged in the patch #14 "Introduce >>>> xenpv bus and a dummy pvcpu device". >>> >>> On x86 at least we need the Xen specific nexus, or we will fall back to >>> use the legacy nexus which is not what we really want. >>> >> >> Oh right, in any case can we use the identify callback of xenpv to add >> the bus? > > AFAICT this kind of bus devices don't have a identify routine, and they > are usually added manually from the specific nexus, see acpi or legacy. > Could you add the device on ARM when you detect that you are running as > a Xen guest, or in the generic ARM nexus if Xen is detected? Is there any reason to not add identify callback? If it's possible, I would like to avoid as much as possible #ifdef XENHVM in ARM code. -- Julien Grall From owner-freebsd-xen@FreeBSD.ORG Tue Jan 7 21:33:22 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8F5A970 for ; Tue, 7 Jan 2014 21:33:22 +0000 (UTC) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4A0B910E6 for ; Tue, 7 Jan 2014 21:33:22 +0000 (UTC) Received: by mail-ea0-f170.google.com with SMTP id k10so461698eaj.29 for ; Tue, 07 Jan 2014 13:33:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0SxlaLUou9Ffhh1tUeK/tDf4/FBO2J7S66YOw1gDYJ8=; b=VT4NakzKda+av9+mQacoebfA3WwjzyNLhh7eLV4689MUGBwvk0VsGJbv/MtgDIscgy 6g+49BDAzgpTWpMEoo40nyPT2PBqgiO5l2cJK+vUSLvisnBVUi4MZq+vTZdJV2sHRMlM ObefTywNFiZAIvxb+RZ+1GEUknulL9Qjnt3vH6oT7XnjRKv0v/klVQM0LHOzZavKCOXw SnLr2kDuUKNYnbY7MehzjfEx0dFNUxC6lOOSoVqJ26/8+kkAaWb9qyXDlzUeGNZhRpTj KBAY/x+xc7uKJe/qZ/leaMIbK0AINvCbGPG2hQmVj0fVo8XRwme9Z5TZyywyYEhhKwmD 3W6Q== X-Gm-Message-State: ALoCoQnfFQ+3UC9elsInv6isDBX1M7Wd5FE08LSmyQcKgt4yYDv11sUlrg3zSbckij9c7meyjaxO X-Received: by 10.14.200.197 with SMTP id z45mr10150331een.98.1389129976815; Tue, 07 Jan 2014 13:26:16 -0800 (PST) Received: from [10.80.2.139] ([185.25.64.249]) by mx.google.com with ESMTPSA id a45sm183519622eem.6.2014.01.07.13.26.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 13:26:15 -0800 (PST) Message-ID: <52CC70F6.5060502@linaro.org> Date: Tue, 07 Jan 2014 21:26:14 +0000 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131104 Icedove/17.0.10 MIME-Version: 1.0 To: Roger Pau Monne Subject: Re: [Xen-devel] [PATCH v9 03/19] xen: add and enable Xen console for PVH guests References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-4-git-send-email-roger.pau@citrix.com> In-Reply-To: <1388677433-49525-4-git-send-email-roger.pau@citrix.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: jhb@freebsd.org, xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, gibbs@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Jan 2014 21:33:22 -0000 On 01/02/2014 03:43 PM, Roger Pau Monne wrote: > This adds and enables the console used on XEN kernels. > --- [..] > +/* Debug function, prints directly to hypervisor console */ > +void xc_printf(const char *, ...); > + Can you add __printflike(...)? It will be easier to catch bad format. -- Julien Grall From owner-freebsd-xen@FreeBSD.ORG Thu Jan 9 16:30:56 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (unknown [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24B1C997; Thu, 9 Jan 2014 16:30:56 +0000 (UTC) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DBB315D0; Thu, 9 Jan 2014 16:30:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.95,631,1384300800"; d="scan'208";a="89200731" Received: from accessns.citrite.net (HELO FTLPEX01CL03.citrite.net) ([10.9.154.239]) by FTLPIPO02.CITRIX.COM with ESMTP; 09 Jan 2014 16:30:36 +0000 Received: from [127.0.0.1] (10.80.16.47) by smtprelay.citrix.com (10.13.107.80) with Microsoft SMTP Server id 14.2.342.4; Thu, 9 Jan 2014 11:30:35 -0500 Message-ID: <52CECEAA.107@citrix.com> Date: Thu, 9 Jan 2014 17:30:34 +0100 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Julien Grall Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> <52C9D4CA.6070403@linaro.org> <52CA78DE.9060502@citrix.com> <52CA9481.4090703@linaro.org> <52CBBB05.6020104@citrix.com> <52CC0EE8.6060205@linaro.org> In-Reply-To: <52CC0EE8.6060205@linaro.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 Cc: jhb@freebsd.org, xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, gibbs@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 16:30:56 -0000 On 07/01/14 15:27, Julien Grall wrote: > On 01/07/2014 08:29 AM, Roger Pau MonnĂ© wrote: >> On 06/01/14 12:33, Julien Grall wrote: >>> >>> >>> On 01/06/2014 09:35 AM, Roger Pau MonnĂ© wrote: >>>> On 05/01/14 22:55, Julien Grall wrote: >>>>> >>>>> >>>>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>>>> Introduce a Xen specific nexus that is going to be in charge for >>>>>> attaching Xen specific devices. >>>>> >>>>> Now that we have a xenpv bus, do we really need a specific nexus for >>>>> Xen? >>>>> We should be able to use the identify callback of xenpv to create the >>>>> bus. >>>>> >>>>> The other part of this patch can be merged in the patch #14 "Introduce >>>>> xenpv bus and a dummy pvcpu device". >>>> >>>> On x86 at least we need the Xen specific nexus, or we will fall back to >>>> use the legacy nexus which is not what we really want. >>>> >>> >>> Oh right, in any case can we use the identify callback of xenpv to add >>> the bus? >> >> AFAICT this kind of bus devices don't have a identify routine, and they >> are usually added manually from the specific nexus, see acpi or legacy. >> Could you add the device on ARM when you detect that you are running as >> a Xen guest, or in the generic ARM nexus if Xen is detected? > > Is there any reason to not add identify callback? If it's possible, I > would like to avoid as much as possible #ifdef XENHVM in ARM code. Maybe the x86 world is really different from the ARM world in how nexus works, but I rather prefer to have a #ifdef XENHVM and a BUS_ADD_CHILD that attaches the xenpv bus in the generic ARM nexus rather than having something that completely diverges from what buses usually do in FreeBSD. It's going to be much more difficult to track in case of bugs, and it's not what people expects, but that's just my opinion. I can certainly add the identify routine if there's an agreement that it's the best way to deal with it. Roger. From owner-freebsd-xen@FreeBSD.ORG Thu Jan 9 18:50:56 2014 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 157068D1; Thu, 9 Jan 2014 18:50:56 +0000 (UTC) Received: from smtpauth3.wiscmail.wisc.edu (wmauth3.doit.wisc.edu [144.92.197.226]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF75B12CB; Thu, 9 Jan 2014 18:50:55 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from avs-daemon.smtpauth3.wiscmail.wisc.edu by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MZ500200CXBNW00@smtpauth3.wiscmail.wisc.edu>; Thu, 09 Jan 2014 12:50:48 -0600 (CST) X-Spam-PmxInfo: Server=avs-3, Version=6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.1.9.183915, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (pool-72-66-107-173.washdc.fios.verizon.net [72.66.107.173]) by smtpauth3.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MZ500510DOK7500@smtpauth3.wiscmail.wisc.edu>; Thu, 09 Jan 2014 12:50:46 -0600 (CST) Message-id: <52CEEF84.2070701@freebsd.org> Date: Thu, 09 Jan 2014 13:50:44 -0500 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= , Julien Grall Subject: Re: [Xen-devel] [PATCH v9 15/19] xen: create a Xen nexus to use in PV/PVH References: <1388677433-49525-1-git-send-email-roger.pau@citrix.com> <1388677433-49525-16-git-send-email-roger.pau@citrix.com> <52C9D4CA.6070403@linaro.org> <52CA78DE.9060502@citrix.com> <52CA9481.4090703@linaro.org> <52CBBB05.6020104@citrix.com> <52CC0EE8.6060205@linaro.org> <52CECEAA.107@citrix.com> In-reply-to: <52CECEAA.107@citrix.com> X-Enigmail-Version: 1.6 Cc: xen-devel@lists.xen.org, julien.grall@citrix.com, freebsd-xen@freebsd.org, freebsd-current@freebsd.org, kib@freebsd.org, gibbs@freebsd.org X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.17 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, 09 Jan 2014 18:50:56 -0000 On 01/09/14 11:30, Roger Pau MonnĂ© wrote: > On 07/01/14 15:27, Julien Grall wrote: >> On 01/07/2014 08:29 AM, Roger Pau MonnĂ© wrote: >>> On 06/01/14 12:33, Julien Grall wrote: >>>> >>>> On 01/06/2014 09:35 AM, Roger Pau MonnĂ© wrote: >>>>> On 05/01/14 22:55, Julien Grall wrote: >>>>>> >>>>>> On 01/02/2014 03:43 PM, Roger Pau Monne wrote: >>>>>>> Introduce a Xen specific nexus that is going to be in charge for >>>>>>> attaching Xen specific devices. >>>>>> Now that we have a xenpv bus, do we really need a specific nexus for >>>>>> Xen? >>>>>> We should be able to use the identify callback of xenpv to create the >>>>>> bus. >>>>>> >>>>>> The other part of this patch can be merged in the patch #14 "Introduce >>>>>> xenpv bus and a dummy pvcpu device". >>>>> On x86 at least we need the Xen specific nexus, or we will fall back to >>>>> use the legacy nexus which is not what we really want. >>>>> >>>> Oh right, in any case can we use the identify callback of xenpv to add >>>> the bus? >>> AFAICT this kind of bus devices don't have a identify routine, and they >>> are usually added manually from the specific nexus, see acpi or legacy. >>> Could you add the device on ARM when you detect that you are running as >>> a Xen guest, or in the generic ARM nexus if Xen is detected? >> Is there any reason to not add identify callback? If it's possible, I >> would like to avoid as much as possible #ifdef XENHVM in ARM code. > Maybe the x86 world is really different from the ARM world in how nexus > works, but I rather prefer to have a #ifdef XENHVM and a BUS_ADD_CHILD > that attaches the xenpv bus in the generic ARM nexus rather than having > something that completely diverges from what buses usually do in > FreeBSD. It's going to be much more difficult to track in case of bugs, > and it's not what people expects, but that's just my opinion. I can > certainly add the identify routine if there's an agreement that it's the > best way to deal with it. > > Roger. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Attaching sub-devices to nexus using device_identify() is the usual way to do this kind of thing. Note that if you do this, your device_probe() routine should return BUS_PROBE_NOWILDCARD to deal with platforms (ARM, MIPS, PowerPC, sparc64) with real autoconfigured devices hanging directly from nexus. -Nathan