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: [Xen-devel] [Patch 2/4] Refining Xsave/Xrestore support

To: Keir Fraser <keir@xxxxxxx>
Subject: Re: [Xen-devel] [Patch 2/4] Refining Xsave/Xrestore support
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Thu, 28 Oct 2010 19:28:03 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Weidong Han <weidong.han@xxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Thu, 28 Oct 2010 04:28:49 -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=akXFSnzBDvnPEbeld9+gI87kB0jH1wwoeV+uVO2o2vI=; b=maGEFNYVxjxDRJ/O85YSz/lnth8Ox8GXDAivtXqY8L3BV3xntDi51WOA6PAjCf1r6h un1l47dFm30mt5fhdETFhjZ+Fr5NnbY55VgyeHPoRJcChDXWdqjc6AJCc3lBLDk6nZHN TnD+NiURuEsiPcOO3Q1gPMAXk3KsAHoAjgjco=
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=rnz/RKDlxKCflaHYsvSSsvARm5xm6m4NxLKvAf5dPivj7ULZpDRZnF97hmuilMACpY IMPY5vENjPRrnnq8s8G2yPc7yXJlhY8KQd6gpNfVK0VTWyWGo9t72LcPlAqfx+NgI16Q YFg75vs42y9wg57Cj7aza8atnlIr2w4er4aYo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8EF0F71.2684E%keir@xxxxxxx>
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: <AANLkTinNtX_DRr5NLxPtJz-Dtd4-wTF+LLMiiaLnd5C9@xxxxxxxxxxxxxx> <C8EF0F71.2684E%keir@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thanks! I will update and send the patch out later.

Shan Haitao

2010/10/28 Keir Fraser <keir@xxxxxxx>:
> On 28/10/2010 08:52, "Haitao Shan" <maillists.shan@xxxxxxxxx> wrote:
>
>> Then I would prefer to write XCR0 unconditionally. Otherwise, I can
>> only refer to the approach for handling CR4 switches: reading CR4
>> first and checking whether there is a need to write actually.
>> But I don't think <a read to XCR0 plus a data comparison> can save any
>> compared with one unconditional write to XCR0.
>> Are you OK with this?
>
> Note that read_cr4() actually returns a cached copy of cr4, as stashed by
> write_cr4(). You should use the same trick for XCR0, and then do the
> cached-read-and-compare on context switch, again just as we do for cr4.
>
>  -- Keir
>
>> Thanks for pointing out the memory leak when hvm_vcpu_initialize
>> fails. I will update accordingly.
>>
>> Shan Haitao
>>
>> 2010/10/28 Jan Beulich <JBeulich@xxxxxxxxxx>:
>>>>>> On 28.10.10 at 06:58, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
>>>> This is the updated patch#2. Thanks.
>>>
>>> Sorry, but this is worse than not checking at all: You didn't consider
>>> the idle vCPU case here, and hence you may end up having more
>>> features enabled in xcr0 for a guest than it should have.
>>>
>>> Also I only now noticed that you're leaking the xsave_area allocation
>>> in vcpu_initialize() if hvm_vcpu_initialise() fails.
>>>
>>> Jan
>>>
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
>
>

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

<Prev in Thread] Current Thread [Next in Thread>