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

[Avi Kivity]

On 08/01/2011 12:05 PM, Jan Kiszka wrote:
> 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?

opensuse 11.4

> It does not link here due to forgotten rwhandler in Makefile.target.

I probably still have it in my tree, will update and re-push.

> 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.

It should be visible from the memory map dump.

--
error compiling committee.c: too many arguments to function