On 20/12/2019 18:22, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH] libxc/restore: Don't duplicate state in
> process_vcpu_basic()"):
>> vcpu_guest_context_any_t is currently allocated on the stack, and copied from
>> a mutable buffer which is freed immediately after its use here.
>>
>> Mutate the buffer in place instead of duplicating it.
> It is not obvious to me that nothing uses the modified fields after
> process_vcpu_basic has edited things. The ctx of which the vcpu is
> part is passed to process_vcpu_<various> by update_vcpu_context.
>
> Why do you think this copying (which is extra code) was introduced ?
Yes. It was a consequence of adding Remus support (which happened on
xen-devel, post actually-getting-migration-v2-working).
Originally, this was copied out of the incoming xc_sr_record* pointer
which was const. Adding Remus support required buffering these records
on each checkpoint, which is why they are stashed sideways now.
By the time we get process_vcpu_basic(), we are committed to completing
state restoration and unpausing the guest.
In particular, it is not possible to process any further memory pages
because the hypercall used here changes typerefs on pagetables, which
makes them immutable from the toolstacks point of view (technically not,
but we can't map them and memcpy them any more).
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
