On 13/05/16 17:06, Jan Beulich wrote: >>>> On 13.05.16 at 17:57, <andrew.coop...@citrix.com> wrote: >> On 17/03/16 08:03, Jan Beulich wrote: >>> Alternatives patching code picks the most suitable NOPs for the >>> running system, so simply use it to replace the pre-populated ones. >>> >>> Use an arbitrary, always available feature to key off from, but >>> hide this behind the new X86_FEATURE_ALWAYS. >>> >>> Signed-off-by: Jan Beulich <jbeul...@suse.com> >>> --- >>> v3: Re-base. >>> v2: Introduce and use X86_FEATURE_ALWAYS. >>> >>> --- a/xen/arch/x86/x86_64/compat/entry.S >>> +++ b/xen/arch/x86/x86_64/compat/entry.S >>> @@ -175,12 +175,7 @@ compat_bad_hypercall: >>> ENTRY(compat_restore_all_guest) >>> ASSERT_INTERRUPTS_DISABLED >>> .Lcr4_orig: >>> - ASM_NOP8 /* testb $3,UREGS_cs(%rsp) */ >>> - ASM_NOP2 /* jpe .Lcr4_alt_end */ >>> - ASM_NOP8 /* mov CPUINFO_cr4...(%rsp), %rax */ >>> - ASM_NOP6 /* and $..., %rax */ >>> - ASM_NOP8 /* mov %rax, CPUINFO_cr4...(%rsp) */ >>> - ASM_NOP3 /* mov %rax, %cr4 */ >>> + .skip (.Lcr4_alt_end - .Lcr4_alt) - (. - .Lcr4_orig), 0x90 >>> .Lcr4_orig_end: >>> .pushsection .altinstr_replacement, "ax" >>> .Lcr4_alt: >> This hunk should live in patch 2. > No. In patch 2 we want to leverage multi-byte NOPs. Here, knowing > they're going to be replaced anyway, we are fine with using the > simpler .fill (producing many single byte ones). > >> Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com> > Does this stand nevertheless?
Yes. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
