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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.05.15 at 17:12, <roger.pau@xxxxxxxxxx> wrote:
> El 14/04/15 a les 14.22, Jan Beulich ha escrit:
>>>>> On 10.04.15 at 19:29, <roger.pau@xxxxxxxxxx> wrote:
>>> Modify shadow_track_dirty_vram to use a local buffer and then flush to the
>>> guest without the paging_lock held. This is modeled after
>>> hap_track_dirty_vram.
>> 
>> And hence introduces the same issue: The HVMOP_track_dirty_vram
>> handler explicitly allows for up to 1Gb of VRAM, yet here you
>> effectively limit things to 128Mb (one page worth of bits each taking
>> care of one guest page) considering heavily fragmented memory.
> 
> Where does this limitation come from? We allocate a temporary bitmap
> that has enough size to accommodate for the number of entries passed to
> the function in nr.
> 
> I guess there's some limitation I'm not seeing.

You allocate a buffer via xzalloc(). When memory is heavily
fragmented, the largest contiguous chunk you can expect to be
able to successfully allocate is 1 page. And 1 page is worth
128Mb of tracked guest address space (4k * 8 bits each covering
a 4k guest page).

Jan


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