Re: [Qemu-devel] [PATCH] memory: synchronize dirty bitmap before unmapping a range

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-08-01 10:16, Avi Kivity wrote:
> On 08/01/2011 10:52 AM, Jan Kiszka wrote:
>> On 2011-08-01 09:34, Jan Kiszka wrote:
>> >  On 2011-07-31 21:47, Avi Kivity wrote:
>> >>  When a range is being unmapped, ask accelerators (e.g. kvm) to
>> synchronize the
>> >>  dirty bitmap to avoid losing information forever.
>> >>
>> >>  Fixes grub2 screen update.
>> >
>> >  I does.
>> >
>> >  But something is still broken. As I reported before, the
>> performance of
>> >  grub2 startup is an order of magnitude slower than with the existing
>> >  code. According to ftrace, we are getting tons of additional
>> >  EPT_MISCONFIG exits over the 0xA0000 segment. But I haven't spot the
>> >  difference yet. The effective slot setup as communicated to kvm looks
>> >  innocent.
>>
>> I take it back: We obviously once in a while resume the guest with the
>> vga segment unmapped. And that, of course, ends up doing mmio instead of
>> plain ram accesses.
>>
> 
> qemu-kvm.git 6b5956c573 and its predecessor fix the issue (and I think
> they're even faster than upstream, but perhaps I'm not objective).
> 

Just updated to the latest memory-region branch - how did you test it?
It does not link here due to forgotten rwhandler in Makefile.target.

Anyway, that commit has no impact on the issue I'm seeing. I'm also
carrying transaction changes for cirrus here, but they have no
noticeable impact. That indicates that the new API is not actually slow,
it likely just has some bug.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux