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