[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] x86/alternatives: fully leverage automatic NOP filling
>>> On 15.03.18 at 13:43, <andrew.cooper3@xxxxxxxxxx> wrote: > On 14/03/18 08:29, Jan Beulich wrote: >> As of commit 4008c71d7a ("x86/alt: Support for automatic padding >> calculations") there's no point having explict ASM_NOPn instances in >> alternatives anymore - drop them. As a result also drop the asm/nops.h >> inclusion from alternative.h, adding explicit inclusions in the two >> remaining C files needing them. >> >> While touching it also move the CR4_PV32_RESTORE definition out of the >> SMAP-specific conditional into a more general one. >> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx> > > I had considered doing this, but decided against it. At the moment, the > majority of hardware Xen runs on (being Intel pre-broadwell) doesn't > need to touch the STAC/CLAC patch sites, and this change means we will > always touch those sites. > > OTOH, (following up from later discussion) doing this does mean that we > would end up replacing with K8 nops when appropriate. > > I'd like the toolchain-nops change to go in first, so we don't regress > the majority status quo, but I have no other issues with this change. So what are the perspectives of this happening, not the least in light of our disagreement on the usefulness of that change? I continue to be unconvinced of the "avoid patching whenever possible" argument - if patching is broken, we're hosed anyway. I don't think there's a common configuration nowadays in which no patching whatsoever would be happening (and the amount of patching we do is going to grow anyway). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |