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/
Home Products Support Community News


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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 4/4] Refining Xsave/Xrestore support
From: Haitao Shan <maillists.shan@xxxxxxxxx>
Date: Thu, 28 Oct 2010 15:34:09 +0800
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Weidong Han <weidong.han@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 28 Oct 2010 00:35:24 -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=U8jYwSmMnEHwmsxfpeArBBsJECqh8aaxiKPwBJRcBhw=; b=omaOu326CC4FLvszu5AzrgQDH+n2BrYSTiGmvXUDtDPUJ01ZVKZt4M3Fz/Tv7YSc6U uBI3IgrBYHHSHNoZz83BIzoqVaLJbb+fUIRMOnYHtUsZFKmF9rHaK6vFoS8sh3iO8bze KvuBwGmQKQIcm6nOQlIoCFzqr9eIWTPRZebYg=
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=GcTDVmHwrzJSt8h5InGnxIFs0oOYd0Jj2+rkE2r+sStq1j3unEOLlpFfhrGsjHgx7c AQRFKNqM55rz/Scm0+thiDND+HVs3L+N6YdlYs6vsa8lwApvikYZHN6Y2fJUdRQvn0mu CMevXPxap5ZgD+SLc1qI9jdQ5A4hS+xEGwu4U=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4CC940AD020000780001FA3A@xxxxxxxxxxxxxxxxxx>
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> <4CC81D9F020000780001F6D6@xxxxxxxxxxxxxxxxxx> <AANLkTi=0r+zkvoEYLVC-PBXkCanT25RManwb_7VqVR=w@xxxxxxxxxxxxxx> <4CC940AD020000780001FA3A@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Ah, good point! I will update the patch accordingly.

Shan Haitao

2010/10/28 Jan Beulich <JBeulich@xxxxxxxxxx>:
>>>> On 28.10.10 at 04:52, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
>> 2010/10/27 Jan Beulich <JBeulich@xxxxxxxxxx>:
>>>>@@ -189,7 +189,8 @@ static int uncanonicalize_pagetable(
>>>> /* Load the p2m frame list, plus potential extended info chunk */
>>>> static xen_pfn_t *load_p2m_frame_list(
>>>>     xc_interface *xch, struct restore_ctx *ctx,
>>>>-    int io_fd, int *pae_extended_cr3, int *ext_vcpucontext)
>>>>+    int io_fd, int *pae_extended_cr3, int *ext_vcpucontext,
>>>>+    int *vcpuextstate, uint64_t *vcpuextstate_size)
>>> What value is it to have vcpuextstate_size (here any elsewhere in
>>> the patch) be a 64-bit quantity? In 32-bit tools exceeding 4G here
>>> wouldn't work anyway, and iirc the value really can't exceed 32 bits
>>> anyway.
>> Yes. Using 64-bit is my preference when I cannot guarantee the size is
>> below 4G. The size of XSAVE_AREA is 4G max since it is reported by
>> ECX. :) However, I have currently two (maybe future more XCRx)
>> registers to save. So........ But it unlikely to reach the 4G bound in
>> real life.
> This would make sense only if the value later didn't get truncated.
> And I don't think one could even theoretically expect the size to
> get anywhere near 4G - what would the performance of the save/
> restore instruction be in that case?
> Jan

Xen-devel mailing list