El 14/04/15 a les 14.22, Jan Beulich ha escrit: >>>> On 10.04.15 at 19:29, <roger....@citrix.com> 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. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
