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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew

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