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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
