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

Avi Kivity
2011-08-01T08:16:17Z

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

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