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

>>> 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?


Xen-devel mailing list