Re: [Xen-devel] [PATCH v5 2/4] xen/shadow: fix shadow_track_dirty_vram to work on hvm guests

[Tim Deegan <tim@xxxxxxx>]

At 15:46 +0200 on 11 May (1431359176), Roger Pau Monné wrote:
> El 08/05/15 a les 17.34, Andrew Cooper ha escrit:
> > On 08/05/15 16:28, Jan Beulich wrote:
> >>>>> On 08.05.15 at 16:34, <roger.pau@xxxxxxxxxx> wrote:
> >>> @@ -3668,21 +3671,19 @@ int shadow_track_dirty_vram(struct domain *d,
> >>>          if ( map_sl1p )
> >>>              sh_unmap_domain_page(map_sl1p);
> >>>  
> >>> -        rc = -EFAULT;
> >>> -        if ( copy_to_guest(dirty_bitmap, dirty_vram->dirty_bitmap, 
> >>> dirty_size) == 0 ) {
> >>> -            memset(dirty_vram->dirty_bitmap, 0, dirty_size);
> >>> -            if (dirty_vram->last_dirty + SECONDS(2) < NOW())
> >>> +        memcpy(dirty_bitmap, dirty_vram->dirty_bitmap, dirty_size);
> >>> +        memset(dirty_vram->dirty_bitmap, 0, dirty_size);
> >> This is certainly a behavioral change; I'm only uncertain whether it's
> >> acceptable. Previously the memset() was done only when the copying
> >> to guest memory succeeded, while now it happens unconditionally.
> > 
> > On the one hand, if the toolstack logdirty buffer suffers an EFAULT,
> > most bets are probably off.
> > 
> > However, it would better if Xen didn't then clobber the dirty bitmap, in
> > case the toolstack's kernel is doing some particularly funky memory
> > management which would succeed on a retry.
> 
> A possible workaround to this would be to do acquire the paging_lock
> again if copy_to_guest fails and set the dirty_bitmap to 0xff, although
> it's not very elegant.

Equivalently, you could set a bit that makes the _next_ pass over the
bitmap return all 0xff.  IIRC, this is what happens when the vram area
changes.  I think it's a reasobnable thing to do if the toolstack
messed up its hypercall buffers.

Tim.

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