All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Don Koch <dkoch@verizon.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Keir Fraser <keir@xen.org>, Jan Beulich <JBeulich@suse.com>,
	xen-devel@lists.xen.org
Subject: Re: [for-xen-4.5 PATCH] Ignore non-zero data in unused xsave area.
Date: Tue, 18 Nov 2014 11:32:47 -0500	[thread overview]
Message-ID: <20141118163247.GF17095@laptop.dumpdata.com> (raw)
In-Reply-To: <1416324391-21118-1-git-send-email-dkoch@verizon.com>

On Tue, Nov 18, 2014 at 10:26:31AM -0500, Don Koch 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. Since we are told that said area was not written to
> during the save or migration, there is no need to restore it.
> 
> Signed-off-by: Don Koch <dkoch@verizon.com>
> ---
> Turns out the assertion that the unused xsave area is zero
> is wrong. Unfortunately, that leaves the following as the
> only way I can think of to work around it (and is no worse
> than xsave/xrestore during context switches). Alternate
> suggestions welcome.

This is Xen 4.5 material I presume.

> 
>  xen/arch/x86/hvm/hvm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index 8f49b44..b2c0bc4 100644
> --- 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
> -- 
> 1.8.3.1
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

  reply	other threads:[~2014-11-18 16:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-18 15:26 [PATCH] Ignore non-zero data in unused xsave area Don Koch
2014-11-18 16:32 ` Konrad Rzeszutek Wilk [this message]
2014-11-18 16:36   ` [for-xen-4.5 PATCH] " Andrew Cooper
2014-11-18 16:35 ` [PATCH] " Jan Beulich
2014-11-18 16:47   ` Don Koch
2014-11-20 14:35 ` Don Koch
2014-11-20 14:45   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141118163247.GF17095@laptop.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dkoch@verizon.com \
    --cc=keir@xen.org \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.