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

[Haitao Shan <maillists.shan@xxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel