Avi Kivity wrote: > On 04/19/2010 10:14 PM, Gerhard Wiesinger wrote: > >Hello, > > > >Finally I got QEMU-KVM to work but video performance under DOS is very > >low (QEMU 0.12.3 stable and QEMU GIT master branch is fast, QEMU KVM > >is slow) > > > >I'm measuring 2 performance critical video performance parameters: > >1.) INT 10h, function AX=4F05h (set same window/set window/get window) > >2.) Memory performance to segment page A000h > > > >So BIOS performance (which might be port performance to VGA > >index/value port) is about factor 5 slower, memory performance is > >about factor 100 slower. > > > >QEMU 0.12.3 and QEMU GIT performance is the same (in the measurement > >tolerance) and listed only once, QEMU KVM is much more slower (details > >see below). > > > >Test programs can be provided, source code will be release soon. > > > >Any ideas why KVM is so slow? > > 16-color vga is slow because kvm cannot map the framebuffer to the guest > (writes are not interpreted as RAM writes). 256+-color vga should be > fast, except when switching the vga window. Note it's only fast on > average, the first write into a page will be slow as kvm maps it in. I don't understand: why is 256+-colour mappable and 16-colour not mappable? Is this a case where TCG would run significantly faster for code blocks that have been detected to access the VGA memory? > Which mode are you using? > > >Any ideas for improvement? > > Currently when the physical memory map changes (which is what happens > when the vga window is updated), kvm drops the entire shadow cache. > It's possible to do this only for vga memory, but not easy. If it's a page fault handled in the kernel, I would expect it to be about as fast as those old VGA DOS-extender drivers which provide the illusion of a single flat mapping, and bank switch on page faults - multiplied by the speed of modern CPUs compared with then. For many graphics things those DOS-extender drivers worked perfectly well. If it's a trap out to qemu on every vga window change, perhaps not quite so well. -- Jamie -- 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
