From owner-freebsd-virtualization@FreeBSD.ORG Tue Mar 19 17:23:36 2013 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 88EED80F; Tue, 19 Mar 2013 17:23:36 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) by mx1.freebsd.org (Postfix) with ESMTP id 852467E8; Tue, 19 Mar 2013 17:23:34 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="2664769" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 19 Mar 2013 17:23:27 +0000 Received: from [192.168.1.30] (10.30.249.104) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Tue, 19 Mar 2013 17:23:27 +0000 Message-ID: <51489F0D.7070105@citrix.com> Date: Tue, 19 Mar 2013 18:23:25 +0100 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Justin T. Gibbs" Subject: Re: Difference in event channel implementation for Xen PV vs HVM guests References: <51470A2B.5040609@citrix.com> <9AE68E59-739C-499C-9991-0C84D4584981@freebsd.org> In-Reply-To: <9AE68E59-739C-499C-9991-0C84D4584981@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: "freebsd-xen@freebsd.org" , "dfr@freebsd.org" , "freebsd-virtualization@freebsd.org" X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:23:36 -0000 On 18/03/13 14:08, Justin T. Gibbs wrote: > On Mar 18, 2013, at 6:35 AM, Roger Pau Monné wrote: > >> Hello, >> >> While working on improving XENHVM (I've been looking at adding PV >> timers), I've realized that the event channel implementation in PV vs >> HVM mode differs greatly. Xen PV port uses sys/xen/evtchn/evtchn.c while >> Xen HVM uses sys/dev/xenpci/evtchn.c, and the Xen HVM implementation is >> greatly reduced (only contains the necessary functions to operate >> backends/frontends). >> >> To implement PV timers I need to expand the event channel interface for >> XENHVM, and I was wondering why FreeBSD choose to have two different >> implementations, the main difference between PV and HVM is the event >> callback, but I guess this can be abstracted between the two different >> implementations, and then everything else could be reused. Am I missing >> something obvious? >> >> Is there any known technical problem in modifying XENHVM to use the full >> event channel implementation present in sys/xen/evtchn/evtchn.c that >> prevented XENHVM from using it in the first place? >> >> (Sorry if I've Cc'ed someone not related) >> >> Thanks, Roger. >> _______________________________________________ >> freebsd-virtualization@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization >> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe@freebsd.org" > > Hi Roger, Hello Justin, > > I know of no reasons why XENHVM cannot use the full event channel > interface. In fact, Spectra Logic implemented PV timers and a > general cleanup of the HVM event channel interface. I haven't merged > it back yet because I know the changes break PV and I haven't found > time to clean up the PV code, merge the HVM and PV event channel > systems, and move IPI/MSI delivery to event channels. That sounds great, then FreeBSD will have a fully working PVHVM port. > I've uploaded Spectra's changes here: > > http://people.freebsd.org/~gibbs/xen_ev/ > > The diffs file provides the history of the original checkins to our > Perforce repository. The tar file includes all the files that have > been modified and reflects our efforts to keep our code base in > sync with stable/9. Apart from the PV issues outlined above, I > would expect the code provided to just drop right in to stable/9. Wow, this is a lot of work to keep in a closet, I will start by rebasing those on top of HEAD, and probably try to split them into smaller commits that make logical sense. > > Unfortunately, Xen support is not a current priority for Spectra > so I don't have a lot of day job time to focus on getting this code back > into FreeBSD. However, if this code looks like it would suite > your needs, and you have resources for testing i386/PV, I'd be happy > to collaborate with you and will make the time to help get this > committed. Definitely, you guys did already a lot of work, and it will a shame to lose it, right now I got my plate quite full, but I expect to get on with this in a couple of weeks. Thanks, Roger.