From owner-freebsd-xen@FreeBSD.ORG Thu Sep 5 14:21:21 2013 Return-Path: Delivered-To: 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 ESMTP id 84DB9737; Thu, 5 Sep 2013 14:21:21 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8EB2C2264; Thu, 5 Sep 2013 14:21:20 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.90,847,1371081600"; d="scan'208";a="8463029" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 05 Sep 2013 14:21:12 +0000 Received: from [172.16.1.30] (10.68.19.166) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Thu, 5 Sep 2013 15:21:11 +0100 Message-ID: <52289356.5090007@citrix.com> Date: Thu, 5 Sep 2013 16:21:10 +0200 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/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Justin T. Gibbs" Subject: Re: [CFR] Xen IPI patch References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , "xen@FreeBSD.org" X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 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, 05 Sep 2013 14:21:21 -0000 On 03/09/13 05:49, Justin T. Gibbs wrote: > In my continuing effort to get all of Roger's Xen enhancements into > FreeBSD, I'm just about finished reviewing the next patch in his > series. The current status of the patch can be found here: > > http://people.freebsd.org/~gibbs/xen_ipi.diff > > The main, and late breaking, wrinkle for this patch is the newly > committed PCID support form AMD64. I've done my best to translate > the updated assembly IPI handlers into the C equivalents needed for > Xen. But, I'm by no means an x86 assembly expert, and my current > Xen installation doesn't advertise PCID, so all of the new branches > I've added have yet to be tested. I also wonder if PVHVM guests > are supposed to perform the PCID work natively or use some other > Hypervisor functionality. PCID is supported inside of HVM containers, nothing special should be done in order to use this instructions. I've been able to test this on a system with PCID support, and everything seems to work fine, PCID is correctly detected and used by FreeBSD (when running under Xen). I've just rebased the PV IPI patch on top of Konstantin's latest PCID change: http://xenbits.xen.org/people/royger/0001-Implement-PV-IPIs-for-PVHVM-guests-and-further-conve.patch > > Other things I'm not happy about with the patch: > - hvm.c wants to use invltlb_globpcid(), but it is private > to pmap.c. I've moved it to cpufunc.h to be next to > invltlb(), but the definition of CR4_PGE (from specialreg.h) > isn't visible in all of the contexts that include cpufunc.h. > So I hackishly define it if necessary. Ick. There seems to be other places were cpufunc.h does this kind of nasty tricks. > - With the divergence of IPI handling between i386 and > amd64, x86/xen/hvm.c is growing too many ifdefs. Should > we delegate the definitions of the ipi functions to > amd64/xen/hvm.c and i386/xen/hvm.c? I will wait for this until we have a plan to merge native and Xen IPIs, right now I would leave all of them inside x86/xen/hvm.c > > - There's too much code duplication in xen_invlrng() > and some of the logic in the other handlers can probably > be tightened up. I've reduced code duplication a little bit there by creating a small inline function that contains the basic invlrng using invlpg. > Unfortunately, I'm out of time for tonight. Hopefully the list > will have some great suggestions/fixes/improvements for this patch > before I pick it up again tomorrow. > > Thanks, > Justin