| Message ID | 585917DA020000780012ADBB@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Dec 20, 2016 at 10:36 AM, Jan Beulich <JBeulich@suse.com> wrote: > This is in preparation of eliminating the mis-naming of 64-bit fields > with 32-bit register names (eflags instead of rflags etc). Use the > guaranteed 32-bit underscore prefixed names for now where appropriate. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Any particular reason to use _eflags rather than just using rflags here? Either way: Acked-by: George Dunlap <george.dunlap@citrix.com>
>>> George Dunlap <George.Dunlap@eu.citrix.com> 12/28/16 12:18 PM >>> >On Tue, Dec 20, 2016 at 10:36 AM, Jan Beulich <JBeulich@suse.com> wrote: >> This is in preparation of eliminating the mis-naming of 64-bit fields >> with 32-bit register names (eflags instead of rflags etc). Use the >> guaranteed 32-bit underscore prefixed names for now where appropriate. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > >Any particular reason to use _eflags rather than just using rflags here? 32-bit accesses are shorter instruction byte wise on average (not requiring REX.W). And the ultimate goal is to switch to eflags (without the underscore here), just that this can't be easily done in a single step (hence the "part I" in the title of the overview mail). And using _eflags now allows us to easily find such uses (once that field name goes away), whereas rflags is to stay (and hence would need to be grep-ed for instead of the compiler pointing out any leftover uses). >Either way: > >Acked-by: George Dunlap <george.dunlap@citrix.com> Thanks. Jan
--- a/xen/arch/x86/mm/guest_walk.c +++ b/xen/arch/x86/mm/guest_walk.c @@ -196,7 +196,7 @@ guest_walk_tables(struct vcpu *v, struct * - Page fault in kernel mode */ smap = hvm_smap_enabled(v) && - ((hvm_get_cpl(v) == 3) || !(regs->eflags & X86_EFLAGS_AC)); + ((hvm_get_cpl(v) == 3) || !(regs->_eflags & X86_EFLAGS_AC)); break; case SMAP_CHECK_ENABLED: smap = hvm_smap_enabled(v);