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

Avi Kivity
2011-08-01T09:30:33Z

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