qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] memory: synchronize dirty bitmap before unmappi


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] memory: synchronize dirty bitmap before unmapping a range
Date: Mon, 01 Aug 2011 11:16:09 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110621 Fedora/3.1.11-1.fc15 Thunderbird/3.1.11

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]