On Mon, Feb 29, 2016 at 02:33:49AM -0700, Jan Beulich wrote:
> > Thanks.
> >
> > Ok , I will do the performace test. And can you suggest me some
> > workload/benchmark
> > can be used here to the xsave related performance test ?
>
> Measuring just instruction execution time should be fine for
>>> On 29.02.16 at 10:06, wrote:
> On Fri, Feb 26, 2016 at 01:42:35AM -0700, Jan Beulich wrote:
>> >>> On 26.02.16 at 08:41, wrote:
>> > On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
>> >> >> The description lacks any mention
On Fri, Feb 26, 2016 at 01:42:35AM -0700, Jan Beulich wrote:
> >>> On 26.02.16 at 08:41, wrote:
> > On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
> >> >> The description lacks any mention of the performance impact,
> >> >> and what investigation was done
>>> On 26.02.16 at 08:41, wrote:
> On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
>> >> > --- a/xen/arch/x86/i387.c
>> >> > +++ b/xen/arch/x86/i387.c
>> >> > @@ -118,7 +118,7 @@ static inline uint64_t vcpu_xsave_mask(const struct
>> >> > vcpu *v)
>> >> >
On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
> > I send the bugs-fix patch as whole. I just get the Cc lists using the
> > script based on the whole patchset. May be I will send the patch
> > seperately.
>
> Thank you. Please also see
>
>>> On 22.02.16 at 06:35, wrote:
First of all I wonder on what basis you collect your Cc lists on
patches.
> --- a/xen/arch/x86/i387.c
> +++ b/xen/arch/x86/i387.c
> @@ -118,7 +118,7 @@ static inline uint64_t vcpu_xsave_mask(const struct vcpu
> *v)
> if (
The offset at which components xsaved by xsave[sc] are not fixed.
So when when a save with v->fpu_dirtied set is followed by one
with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data
written by the lazy one.
When xsave[sc] is enable, vcpu_xsave_mask will return XSTATE_ALL when