Re: [Xen-devel] [PATCH 1/3] x86/alternatives: fully leverage automatic NOP filling

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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