WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: Fwd: [Xen-devel] [Patch 4/4] Refining Xsave/Xrestore support

To: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Subject: Re: Fwd: [Xen-devel] [Patch 4/4] Refining Xsave/Xrestore support
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Thu, 28 Oct 2010 19:28:58 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir Fraser <Keir.Fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 28 Oct 2010 04:32:27 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eYtsqgsb4PknlNZVJiTFb4vcOl5GB8UkBXwpc4Su7jY=; b=mwsBwUrjvyJbRc71CfGZdpMq9u9tyiYJOrz9Rd3tsw9mvfwiHkfQw6/sYpVfzCq460 XsT2dwHQjJMVSby865xEoYmX5asCyZ2GSu2zoCq/BMvWw5uSkTIs9mO2IrZAMS7zckDh klEzDUArpLJK/ZNd8iSEXh9QEqwekd0rEA9PA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VSHlpJladVa/nmuzI9ycPIkjQPj1s7xx+yLHOxe6hjoTVHMNyuKy1dQxvnBjcI5Ohr f5shL5gvqYdNHlf6PGhTu1N4jZ7RhUbzcWktjddkkNZEVak/7PnfsShm+p2uOTJ3/Vpf ExJbKhNsXUBCg82RTDm9a9eCWr2/4zQO5e+58=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20101028091828.GA4007@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTi=ppSKUtJNEmpqUtCHZDqG8zfkLVKZf_1QWNhBM@xxxxxxxxxxxxxx> <20101027102530.GY4007@xxxxxxxxxxxxxxxxxxxxxxx> <AANLkTi=1fW3rQL+8SRAzYv3D6Lqo2PGC7uYzd5VkX8hw@xxxxxxxxxxxxxx> <AANLkTikLpG=xQRkdWWkc4xU0DW1kS5mCQbNvSKAH6v4+@xxxxxxxxxxxxxx> <20101028091828.GA4007@xxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
OK. I will update the patch according to the policy you described. Thanks!

Shan Haitao

2010/10/28 Tim Deegan <Tim.Deegan@xxxxxxxxxx>:
> Hi,
>
> At 03:32 +0100 on 28 Oct (1288236759), Haitao Shan wrote:
>> >> diff -r 9bf6b4030d70 xen/arch/x86/hvm/hvm.c
>> >> --- a/xen/arch/x86/hvm/hvm.c  Wed Oct 27 21:55:45 2010 +0800
>> >> +++ b/xen/arch/x86/hvm/hvm.c  Wed Oct 27 22:17:24 2010 +0800
>> >> @@ -575,8 +575,13 @@ static int hvm_save_cpu_ctxt(struct doma
>> >>          vc = &v->arch.guest_context;
>> >>
>> >>          if ( v->fpu_initialised )
>> >> -            memcpy(ctxt.fpu_regs, &vc->fpu_ctxt, sizeof(ctxt.fpu_regs));
>> >> -        else
>> >> +            if ( cpu_has_xsave )
>> >> +                /* to restore guest img saved on xsave-incapable host */
>> >> +                memcpy(v->arch.xsave_area, ctxt.fpu_regs,
>> >> +                       sizeof(ctxt.fpu_regs));
>> >> +            else
>> >> +                memcpy(&vc->fpu_ctxt, ctxt.fpu_regs, 
>> >> sizeof(ctxt.fpu_regs));
>> >
>> > I think this hunk belongs in hvm_LOAD_cpu_ctxt()!
>> I once did the same as you said. But doing this in hvm_load_cpu_ctxt
>> will depends on two:
>> 1. hvm_load_cpu_ctxt can not be executed before xsave restore routine
>> is executed. Otherwise, xsave_area contains no useful data at the time
>> of copying.
>
> OK; then you should copy the other way in in the xsave load routine as
> well.  Xsave load will always happen after the CPU load since save
> records are always written in increasing order of type.
>
> That way, if the save file has no xsave record, the new domain's xsave
> state is initalized from the fpu record, and if it does then the fpu
> state is initialized from the xsave record.  I think that's the
> behaviour you want.
>
> In any case this is *definitely* wrong where it is because the memcpy
> arguments are the wrong way round. :)
>
>> 2. It seems to break restore when HVM guest (no touching eXtended
>> States at all) saved on a Xsave-capable host is later restored on a
>> Xsave-incapable host.
>
> That not a safe thing to do anyway -- once you've told the guest (via
> CPUID) that XSAVE is available you can't migrate it to a host where it's
> not supported.
>
> Cheers,
>
> Tim.
>
> --
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Principal Software Engineer, XenServer Engineering
> Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel