[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 5/6] xen/x86: use flag byte for decision whether xen_cr3 is valid
>>> On 02.03.18 at 09:14, <jgross@xxxxxxxx> wrote: > This reduces the number of branches in interrupt handling and results > in better performance (e.g. parallel make of the Xen hypervisor on my > system was using about 3% less system time). 3% seems an awful lot for a single conditional branch on each of the three affected entry paths. > --- a/xen/arch/x86/domain.c > +++ b/xen/arch/x86/domain.c > @@ -1698,6 +1698,7 @@ void context_switch(struct vcpu *prev, struct vcpu > *next) > ASSERT(local_irq_is_enabled()); > > get_cpu_info()->xen_cr3 = 0; > + get_cpu_info()->use_xen_cr3 = false; Don't you need this to be the other way around _and_ a barrier() in between? As the context above shows, interrupts are enabled here (and NMI/#MC can occur at any time anyway), so with the order above it seems to me as if restore_all_xen might write zero into CR3. While the ordering appears to be right elsewhere, the barrier() part may apply to changes further down as well. > @@ -523,18 +516,17 @@ ENTRY(common_interrupt) > > .Lintr_cr3_start: > mov STACK_CPUINFO_FIELD(xen_cr3)(%r14), %rcx > + mov STACK_CPUINFO_FIELD(use_xen_cr3)(%r14), %bl > mov %rcx, %r15 > - neg %rcx > + test %rcx, %rcx > jz .Lintr_cr3_okay > - jns .Lintr_cr3_load > - mov %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%r14) > - neg %rcx > -.Lintr_cr3_load: > + movb $0, STACK_CPUINFO_FIELD(use_xen_cr3)(%r14) > mov %rcx, %cr3 > xor %ecx, %ecx > mov %rcx, STACK_CPUINFO_FIELD(xen_cr3)(%r14) > testb $3, UREGS_cs(%rsp) > cmovnz %rcx, %r15 > + cmovnz %cx, %bx 32-bit operation please. > @@ -831,6 +820,7 @@ handle_ist_exception: > * and copy the context to stack bottom. > */ > xor %r15, %r15 > + xor %bl, %bl Same here. > @@ -68,6 +65,12 @@ struct cpu_info { > */ > bool root_pgt_changed; > > + /* > + * use_xen_cr3 is set in case the value of xen_cr3 is to be written into > + * CR3 when entering the hypervisor. > + */ > + bool use_xen_cr3; When entering the hypervisor? Afaics the flag is evaluated only to trigger the unlikely code in restore_all_xen, which is an exit path (as the comment portion you remove from xen_cr3 also says). 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 |