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: "Haitao Shan" <maillists.shan@xxxxxxxxx>
Subject: Re: [Xen-devel] [Patch 4/4] Refining Xsave/Xrestore support
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Wed, 27 Oct 2010 11:39:59 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Weidong Han <weidong.han@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Wed, 27 Oct 2010 03:40:57 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=ppSKUtJNEmpqUtCHZDqG8zfkLVKZf_1QWNhBM@xxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>@@ -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

>@@ -781,6 +781,31 @@ struct xen_domctl_mem_sharing_op {
> typedef struct xen_domctl_mem_sharing_op xen_domctl_mem_sharing_op_t;
> DEFINE_XEN_GUEST_HANDLE(xen_domctl_mem_sharing_op_t);
>+/* XEN_DOMCTL_setvcpuextstate */
>+/* XEN_DOMCTL_getvcpuextstate */
>+struct xen_domctl_vcpuextstate {
>+    /* IN: VCPU that this call applies to. */
>+    uint32_t         vcpu;
>+    /*
>+     * SET: xfeature support mask of struct (IN)
>+     * GET: xfeature support mask of struct (IN/OUT)
>+     * xfeature mask is served as identifications of the saving format
>+     * so that compatible CPUs can have a check on format to decide
>+     * whether it can restore.
>+     */
>+    uint64_t         xfeature_mask;


>+    /*
>+     * SET: Size of struct (IN)
>+     * GET: Size of struct (IN/OUT)
>+     */
>+    uint64_t         size;

Here too.

>+#if defined(__i386__) || defined(__x86_64__)

Why? The structure makes no sense without the following field, so
either the whole structure is x86-specific, or the field is generic as
is the rest of the structure.

>+    XEN_GUEST_HANDLE_64(uint64) buffer;


Xen-devel mailing list