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