Date: Thu, 5 Sep 2013 16:21:10 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= <roger.pau@citrix.com> To: "Justin T. Gibbs" <gibbs@FreeBSD.org> Cc: Konstantin Belousov <kib@FreeBSD.org>, "xen@FreeBSD.org" <xen@FreeBSD.org> Subject: Re: [CFR] Xen IPI patch Message-ID: <52289356.5090007@citrix.com> In-Reply-To: <B44826A9-C835-4DF1-BBE5-621E0151CB58@FreeBSD.org> References: <B44826A9-C835-4DF1-BBE5-621E0151CB58@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52289356.5090007>