|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 03/12] libxenguest: short-circuit "all-dirty" handling
On 25.06.2021 19:02, Andrew Cooper wrote:
> On 25/06/2021 14:18, Jan Beulich wrote:
>> For one it is unnecessary to fill a perhaps large chunk of memory with
>> all ones. Add a new parameter to send_dirty_pages() for callers to
>> indicate so.
>>
>> Then it is further unnecessary to allocate the dirty bitmap altogether
>> when all that's ever going to happen is a single all-dirty run.
>
> The allocation is deliberate, and does want to stay where it is IMO.
>
> Single all-dirty runs are a debugging technique only. All production
> cases are live, and you don't want to fail midway through because a
> late, large, memory allocation failed.
I'm afraid I don't understand: I don't move _when_ the allocation
occurs; I only suppress the allocation (altogether) when the allocated
memory remains unused.
> As for the send_{dirty,all}_pages() split, that was deliberate to keep
> the logic simple. The logdirty bitmap is tiny (in comparison to other
> structures) outside of artificial cases like this.
>
> What you've done with this change is rendered send_all_pages()
> redundant, but not actually taken it out of the code, thereby
> complicating it. At the moment, this doesn't look to be an improvement.
I view the remaining send_all_pages() as similarly useful (or not) as
e.g. send_domain_memory_checkpointed() (being merely a wrapper around
suspend_and_send_dirty()).
>> @@ -807,8 +798,11 @@ static int setup(struct xc_sr_context *c
>> if ( rc )
>> goto err;
>>
>> - dirty_bitmap = xc_hypercall_buffer_alloc_pages(
>> - xch, dirty_bitmap, NRPAGES(bitmap_size(ctx->save.p2m_size)));
>> + dirty_bitmap = ctx->save.live || ctx->stream_type != XC_STREAM_PLAIN
>> + ? xc_hypercall_buffer_alloc_pages(
>> + xch, dirty_bitmap, NRPAGES(bitmap_size(ctx->save.p2m_size)))
>> + : (void *)-1L;
>
> This is a pointer loaded with a timebomb, which doesn't trigger NULL
> pointer checks, and for which {set,clear}_bit(dirty_bitmap, large_pfn)
> won't fault and will instead corrupt random areas of the address space.
Yeah, this isn't very nice, and gets done away with again in a later
patch. I'd prefer to keep it like it is (assuming the later change
will also go in), but if really deemed necessary I can move that code
re-arrangement here, such that the use of (void *)-1L wouldn't be
necessary anymore. (You may have noticed that all I did this for is
to be able to pass the !dirty_bitmap later in the function, and that
I deliberately only update the local variable, not the hbuf, making
pretty certain that this pointer isn't going to be de-referenced.)
Jan
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |