Re: [Xen-devel] [PATCH] Ignore non-zero data in unused xsave area.

[Don Koch <dkoch@xxxxxxxxxxx>]

On Tue, 18 Nov 2014 16:35:42 +0000
Jan Beulich <JBeulich@xxxxxxxx> wrote:

> >>> On 18.11.14 at 16:26, <dkoch@xxxxxxxxxxx> wrote:
> > If we restore an xsave area from an older xen that has a larger
> > size than the xcr0 bit call for, it is possible to have non-zero
> > data in the unused area if an xsave has ever been done that used
> > that area (e.g. during a context switch). Since the vcpu's xsave
> > area is never zeroed after the initial allocation, that data is
> > still there.
> 
> This needs more explanation: xcr0_accum is named this way
> because bits never disappear from it. Hence afaics any piece of
> the xsave area ever having got written with a non-zero value
> would be part of the data actually used on migration.

Let me investigate this further. Since the initial xsave area is cleared
when allocated, I see no other way to get anything in there.

> > --- a/xen/arch/x86/hvm/hvm.c
> > +++ b/xen/arch/x86/hvm/hvm.c
> > @@ -2044,7 +2044,7 @@ static int hvm_load_cpu_xsave_states(struct domain 
> > *d, hvm_domain_context_t *h)
> >                  printk(XENLOG_G_WARNING
> >                         "HVM%d.%u restore mismatch: xsave length %#x > %#x 
> > (non-zero data at %#x)\n",
> >                         d->domain_id, vcpuid, desc->length, size, i);
> > -                return -EOPNOTSUPP;
> > +                break;
> >              }
> >          }
> >          printk(XENLOG_G_WARNING
> 
> Even if we really have to go this route, you should recall the
> discussion on the earlier patch of yours: The end result should
> not be that two messages get logged for a single event.

Ah, yes. Agreed. Will fix if my investigation reveals what occurred.

> Jan
> 

Konrad: Yes, this will be 4.5 fodder, pending the aforementioned
investigation.

Thanks,
-d

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