Re: [Xen-devel] [PATCH v2 3/5] tools/libxendevicemodel: extract functions and add a compat layer

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 22/02/17 14:37, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH v2 3/5] 
> tools/libxendevicemodel: extract functions and add a compat layer"):
>> On 22/02/17 14:20, Ian Jackson wrote:
>>> As I think we discussed some time last week (?), this function cannot
>>> be a DMOP.  This is because enabling track_dirty_vram causes the
>>> hypervisor to remember the memory referred to by dirty_bitmap, but the
>>> dmop privcmd restriction mechanism only guarantees that the memory is
>>> valid and belonging to this guest _during the hypercall_.
>> Sorry to jump in here, but what?  Since when?
> Maybe I have misunderstood.
>
>> track-dirty-vram stashes where the DM thinks the vram is in guest
>> physical address space, so if a new range is requested, we can set
>> appropriate bits in the dirty map.
> Does this ...
>
>>>> +    return xendevicemodel_op(dmod, domid, 2, &op, sizeof(op),
>>>> +                             dirty_bitmap, (size_t)(nr + 7) / 8);
>>>> +}
> ... not result in the hypervisor asynchronously updating the contents
> of dirty_bitmap[whatever], later ?

No.

>
>> However, the interesting pointer for the DMOP (i.e. where the DM would
>> like Xen to write the bitmap to) is not stored across distinct calls at
>> all.  It is stored as part of a continuation, but that is still
>> logically part of a single invocation.
> Is the bitmap copied in each dmop call ?

Yes, and hence...

... one optimisation I want to do in the future is for the DM to be able
to make a Read-only mapping of Xens logdirty bitmap, so the bitmap can
be passed by shared memory rather than memcpy(), because I expect it
would be rather more efficient during some of the time-sensitive bits of
live migrate.

~Andrew

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