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

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

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 ?

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

Ian.

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