[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [V10 1/3] x86/xsaves: enable xsaves/xrstors/xsavec in xen



>>> On 19.11.15 at 08:00, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
> On Wed, Nov 18, 2015 at 03:40:50AM -0700, Jan Beulich wrote:
>> > For this save side. As cpu_has_xsaveopt should be handled indenpently.
>> > If we just use alternative asm for xsaves or xsavec, the following code
>> > handle xsaveopt/xsave should be like this:
>> > if ( !cpu_has_xsavec && !cpu_has_xsaves && cpu_has_xsaveopt)
>> > ......
>> > ....
>> > else if ( !cpu_has_xsavec && !cpu_has_xsaves )
>> > .......
>> > ......
>> > 
>> > if you think it is ok to do it like this. I will add this.
>> > 
>> > Also, for instruction without REX.W in save side, alternavitve asm can
>> > be used, but a new alternative marco which must handle 4 instruction
>> > base on 4 cpu_features will be added. So do this in this patchset or
>> > another patchset ? which one is ok to you?
>> 
>> I'm confused - first you suggest using chains of if()s (which I dislike)
>> and then you talk about a 4-variant alternative (which is what I'm
>> after)? 
> Let me make it clear(may show some code).
> For xsave code. There is two cases: 
> 
> 1:Use 64-bit operand size. 
> 
> The origin code will refine FPU selector handling code for XSAVEOPT. So if 
> we
> use alternative asm for 64-bit opreand size 
> instruction(xsaves/xsavec/xsaveopt
> /xsave) like below. 
> 
> alternative_io_3(".byte 0x48,0x0f,0xae,0x27",
>                ".byte 0x48,0x0f,0xae,0x37", X86_FEATURE_XSAVEOPT,
>                ".byte 0x48,0x0f,0xc7,0x27", X86_FEATURE_XSAVEC,
>                ".byte 0x48,0x0f,0xc7,0x2f", X86_FEATURE_XSAVES
>                : "=m" (*ptr),
>                : "a" (lmask), "d" (hmask), "D" (ptr) );
> 
> It may break the handling code for XSAVEOPT(code below). 

Ah, no I understand. The question is - how do XSAVES/XSAVEC
behave in this regard? I'd expect like XSAVEOPT, not like XSAVE.
In either case this would indeed end up being a 3-way alternative.

>>Yes, this will need extending the base infrastructure
>> (depending on how involved a change that would be, perhaps in a
>> separate patch).
> I will introduce two new macros in "alternative.h".
> Change save part to alternative.
> 
> So do it in this patchset or do it totally in another separate 
> patchset (leave save part as none-alternative in xsave patchset)? 
> Which one is ok to you ? 

Again use your judgment, i.e. - as already said - depending on how
involved the change would be.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.