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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.09.15 at 15:02, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 22/09/15 13:53, Jan Beulich wrote:
>> Rather than dirtying a page when establishing a (permanent) mapping,
>> dirty it when the page gets unmapped, or - if still mapped - on the
>> final iteration of a save operation (or in other cases where the guest
>> is paused or already shut down). (Transient mappings continue to get
>> dirtied upon getting mapped, to avoid the overhead of tracking.)
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> v2: Refine predicate for calling hvm_mapped_guest_frames_mark_dirty()
>>      (now including all shut down domains as well as tool stack paused
>>      ones).
> 
> I am still convinced that it is wrong for Xen to second-guess what libxc 
> is actually doing.
> 
> libxc should explicitly ask for the permanent mappings (or not) via 
> another bit in a shadow op.  Anything else risks not getting the bits 
> set (so memory corruption), or having too many bits set in 
> non-interested cases (unwanted overhead).

Well, okay. Looking around what this would mean on the tools side,
this doesn't even seem to be too bad to implement: We could use the
(so far unused) mode field of the interface structure. While the two
uses of XEN_DOMCTL_SHADOW_OP_CLEAN seem straightforward to
adjust, it's not immediately clear to me which variant the single
XEN_DOMCTL_SHADOW_OP_PEEK would want. Could you advise?

Jan


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