Re: [Xen-devel] [PATCH v2 2/2] x86/HVM: correct page dirty marking in hvm_map_guest_frame_rw()

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 12.08.15 at 19:24, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 12/08/15 16:26, Jan Beulich wrote:
>>>>> On 12.08.15 at 17:13, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 12/08/15 15:19, Jan Beulich wrote:
>>>> @@ -422,6 +423,14 @@ static int paging_log_dirty_op(struct do
>>>>  
>>>>      if ( !resuming )
>>>>      {
>>>> +        /*
>>>> +         * Mark dirty all currently write-mapped pages on the final 
>>>> iteration
>>>> +         * of a HVM save operation.
>>>> +         */
>>>> +        if ( has_hvm_container_domain(d) && d->is_shut_down &&
>>>> +             d->shutdown_code == SHUTDOWN_suspend )
>>>> +            hvm_mapped_guest_frames_mark_dirty(d);
>>> I am not sure whether this is useful.  There are situations such as
>>> memory snapshot where it is insufficient, as the domain doesn't suspend.
>> Perhaps the condition could be refined then? And then - isn't
>> memory snapshot what Remus does (which I checked does a
>> suspend in the tool stack)?
> 
> XenServer live memory snapshots of windows VMs uses a windows API to
> quiesce IO, pauses the domain, performs a non-live save, then unpauses
> the domain.
> 
> Such an action would want the these bits in the bitmap, but would not
> match those conditions.

As said - the conditions could be adjusted (e.g. to also include
tool stack paused domains).

>>> It would probably be better to hook this off a specific request from the
>>> toolstack, as the migration code is in a far better position to know
>>> whether this information is needed or can be deferred to the next iteration.
>> Which next iteration (when we're talking about the final one)?
>>
>> I considered tool stack involvement, but would like to go that
>> route only if unavoidable.
> 
> It is wrong for Xen to guess.  The toolstack should explicitly ask for
> them when it wants them.
> 
> I have just written my slides for Seattle, which cover some of the
> outstanding issues with regards to guests and logdirty.  As migration
> with nested virt doesn't function at all, fixing these entries in the
> logdirty bitmap is not urgent if you don't fancy extending/tweaking
> xen_domctl_shadow_op.

Agreed - while I'd like patch 1 to go in for 4.6, this one can wait.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel