[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [V9 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen
On Wed, Nov 04, 2015 at 10:04:33AM -0700, Jan Beulich wrote: > >>> On 03.11.15 at 07:27, <shuai.ruan@xxxxxxxxxxxxxxx> wrote: > > diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c > > index fe3be30..108d4f8 100644 > > --- a/xen/arch/x86/domain.c > > +++ b/xen/arch/x86/domain.c > > @@ -883,7 +883,12 @@ int arch_set_info_guest( > > { > > memcpy(v->arch.fpu_ctxt, &c.nat->fpu_ctxt, > > sizeof(c.nat->fpu_ctxt)); > > if ( v->arch.xsave_area ) > > + { > > v->arch.xsave_area->xsave_hdr.xstate_bv = XSTATE_FP_SSE; > > + if ( cpu_has_xsaves || cpu_has_xsavec ) > > + v->arch.xsave_area->xsave_hdr.xcomp_bv = XSTATE_FP_SSE | > > + > > XSTATE_COMPACTION_ENABLED; > > + } > > So here you nicely extend the existing conditional. > > > @@ -1568,6 +1573,8 @@ static void __context_switch(void) > > if ( xcr0 != get_xcr0() && !set_xcr0(xcr0) ) > > BUG(); > > } > > + if ( cpu_has_xsaves && has_hvm_container_vcpu(n) ) > > + set_msr_xss(n->arch.hvm_vcpu.msr_xss); > > Why not also here (the previous if() uses cpu_has_xsave, which > you surely depend on)? Agreed the difference is minor for modern > CPUs, but I wanted to ask anyway. I.e. an explanation will do, > no need to re-submit just because of this. > Yes. It is better to put the cpu_has_xsaves into the previous if(). > > @@ -158,6 +334,20 @@ void xsave(struct vcpu *v, uint64_t mask) > > ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET] = word_size; > > } > > +#define XSTATE_FIXUP ".section .fixup,\"ax\" \n" \ > > + "2: mov %5,%%ecx \n" \ > > + " xor %1,%1 \n" \ > > + " rep stosb \n" \ > > + " lea %2,%0 \n" \ > > + " mov %3,%1 \n" \ > > + " jmp 1b \n" \ > > + ".previous \n" \ > > + _ASM_EXTABLE(1b, 2b) \ > > + : "+&D" (ptr), "+&a" (lmask) \ > > + : "m" (*ptr), "g" (lmask), "d" (hmask), \ > > + "m" (xsave_cntxt_size) \ > > + : "ecx" > > + > > void xrstor(struct vcpu *v, uint64_t mask) > > { > > uint32_t hmask = mask >> 32; > > @@ -187,39 +377,22 @@ void xrstor(struct vcpu *v, uint64_t mask) > > switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) ) > > { > > default: > > - asm volatile ( "1: .byte 0x48,0x0f,0xae,0x2f\n" > > - ".section .fixup,\"ax\" \n" > > - "2: mov %5,%%ecx \n" > > - " xor %1,%1 \n" > > - " rep stosb \n" > > - " lea %2,%0 \n" > > - " mov %3,%1 \n" > > - " jmp 1b \n" > > - ".previous \n" > > - _ASM_EXTABLE(1b, 2b) > > - : "+&D" (ptr), "+&a" (lmask) > > - : "m" (*ptr), "g" (lmask), "d" (hmask), > > - "m" (xsave_cntxt_size) > > - : "ecx" ); > > + alternative_input("1: "".byte 0x48,0x0f,0xae,0x2f", > > + ".byte 0x48,0x0f,0xc7,0x1f", > > + X86_FEATURE_XSAVES, > > + "D" (ptr), "m" (*ptr), "a" (lmask), "d" (hmask)); > > + asm volatile (XSTATE_FIXUP); > > break; > > case 4: case 2: > > - asm volatile ( "1: .byte 0x0f,0xae,0x2f\n" > > - ".section .fixup,\"ax\" \n" > > - "2: mov %5,%%ecx \n" > > - " xor %1,%1 \n" > > - " rep stosb \n" > > - " lea %2,%0 \n" > > - " mov %3,%1 \n" > > - " jmp 1b \n" > > - ".previous \n" > > - _ASM_EXTABLE(1b, 2b) > > - : "+&D" (ptr), "+&a" (lmask) > > - : "m" (*ptr), "g" (lmask), "d" (hmask), > > - "m" (xsave_cntxt_size) > > - : "ecx" ); > > + alternative_input("1: "".byte 0x0f,0xae,0x2f", > > + ".byte 0x0f,0xc7,0x1f", > > + X86_FEATURE_XSAVES, > > + "D" (ptr), "m" (*ptr), "a" (lmask), "d" (hmask)); > > + asm volatile (XSTATE_FIXUP); > > break; > > } > > } > > +#undef XSTATE_FIXUP > > Repeating my comment on v8: "I wonder whether at least for the > restore side alternative asm wouldn't result in better readable code > and at the same time in a smaller patch." Did you at least look into > that option? > I may misunderstand your meaning. I have adressed the comment by changing the restor side using alternative_input. Does "alternative_input" not what you want ? if it is not what you want, please give me some suggestions how to address this ? Thanks > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |