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:20, Ian Jackson wrote:
> Paul Durrant writes ("[PATCH v2 3/5] tools/libxendevicemodel: extract 
> functions and add a compat layer"):
>> This patch extracts all functions resulting in a dm_op hypercall from
>> libxenctrl and moves them into libxendevicemodel. It also adds a compat
>> layer into libxenctrl, which can be selected by defining
>> XC_WANT_COMPAT_DEVICEMODEL_API to 1 before including xenctrl.h.
>>
>> With this patch the core of libxendevicemodel still uses libxencall to
>> issue the dm_op hypercalls, but this is done by calling through code that
>> can be modified on a per-OS basis. A subsequent patch will add a Linux-
>> specific variant.
> ...
>> +int xendevicemodel_track_dirty_vram(
>> +    xendevicemodel_handle *dmod, domid_t domid, uint64_t first_pfn,
>> +    uint32_t nr, unsigned long *dirty_bitmap)
>> +{
>> +    struct xen_dm_op op;
>> +    struct xen_dm_op_track_dirty_vram *data;
>> +
>> +    memset(&op, 0, sizeof(op));
>> +
>> +    op.op = XEN_DMOP_track_dirty_vram;
>> +    data = &op.u.track_dirty_vram;
>> +
>> +    data->first_pfn = first_pfn;
>> +    data->nr = nr;
>> +
>> +    return xendevicemodel_op(dmod, domid, 2, &op, sizeof(op),
>> +                             dirty_bitmap, (size_t)(nr + 7) / 8);
>> +}
> 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?

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.

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.

~Andrew

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