On 04.06.2011, at 18:49, Sasha Levin wrote: > On Sat, 2011-06-04 at 17:40 +0200, Alexander Graf wrote: >> On 04.06.2011, at 17:34, Sasha Levin wrote: >> >>> On Sat, 2011-06-04 at 17:21 +0200, Alexander Graf wrote: >>>> On 04.06.2011, at 16:19, Sasha Levin wrote: >>>> >>>>> On Sat, 2011-06-04 at 15:48 +0200, Alexander Graf wrote: >>>>>> On 04.06.2011, at 14:04, Sasha Levin wrote: >>>>>> >>>>>>> On Sat, 2011-06-04 at 13:53 +0200, Ingo Molnar wrote: >>>>>>>> * Alexander Graf <agraf@xxxxxxx> wrote: >>>>>>>> >>>>>>>>> Why would you need panning/scrolling for a fast FB? It's really an >>>>>>>>> optimization that helps a lot with VNC, but on local machines or >>>>>>>>> SDL you shouldn't see a major difference. >>>>>>>> >>>>>>>> Qemu's fb console scrolling graphics is pretty slow to me even >>>>>>>> locally so i assume that the dirty bitmap trick is not enough. >>>>>>>> >>>>>>>> VirtualBox graphics is very fast, but it probably has its own console >>>>>>>> abstraction and scrolling/2D/3D acceleration. >>>>>>>> >>>>>>>> Also, since tools/kvm/ is really also about learning interesting >>>>>>>> stuff, smooth scrolling was the historic first 'acceleration' usecase >>>>>>>> that video graphics cards added - before they evolved more complex 2D >>>>>>>> acceleration and then started doing 3D. >>>>>>>> >>>>>>>> Walking that path would allow us to do a gradual approach, while >>>>>>>> still having relevant functionality and enhancements at every step. >>>>>>>> >>>>>>>>> Unless you use the FB as MMIO. Qemu just maps the FB as RAM and >>>>>>>>> checks for dirty bitmap updates periodically. That way you don't >>>>>>>>> constantly exit due to MMIO and are good on speed. The slowness you >>>>>>>>> describe sounds a lot as if you don't do that trick. >>>>>>>> >>>>>>>> Correct, and i assumed we already do the dirty-bitmap trick: >>>>>>>> >>>>>>>> KVM_MEM_LOG_DIRTY_PAGES >>>>>>>> KVM_GET_DIRTY_LOG >>>>>>>> >>>>>>>> But you are right, we do not actually do that! >>>>>>>> >>>>>>>> Pekka, i think this should be the next step. We'll need scrolling >>>>>>>> after that ... >>>>>>>> >>>>>>>> In theory it would also be nice to tunnel the VGA text frame buffer >>>>>>>> over to the KVM tool - as serial console is not supported by most >>>>>>>> installers and default distro images. We could actually do a rather >>>>>>>> good job of emulating it via Slang/Curses. >>>>>>> >>>>>>> I doubt we could use dirty pages because unless guest VESA driver >>>>>>> supports panning, it will redraw the entire FB - which means that all >>>>>>> pages will be dirty. >>>>>> >>>>>> Please recheck the math and compare 60 dirty bitmap checks+flushes per second to a few million MMIO exits for every single pixel :). >>>>> >>>>> I might be missing something here, but if every single pixel changes due >>>>> to scrolling, doesn't it mean that all the pages will be marked as >>>>> 'dirty' anyway? >>>> >>>> Sure, but you don't need to exit to user space for every single pixel, but instead process the whole thing asynchronously. Just run kvm_stat while running your current implementation and you'll pretty soon realize what I'm talking about :). >>> >>> I we use coalesced MMIO we only exit when the shared page is full. >> >> Yes, which will be very often for full redrawing guests. Remember, we're talking about megabytes of graphics data. Plus you still need to call your internal MMIO handler for every single access then. And I hope I don't even have to mention read performance (which is abysmal on real graphics cards too though). >> >>> If we mark a memory region as log dirty we won't get MMIO exits on it? >> >> [..] If you mark a memory region as coalesced you also don't get MMIO exits on it. [..] >> > > We get MMIO exits on it when the ring is full, which is pretty often > with the graphics card. > > I'll try the dirty log method later tonight. I don't see anything about > no exits in the documentation though - if it actually prevents MMIO > exits to the region it should probably be documented. It's documented. Just look up the documentation for KVM_GET_DIRTY_LOG and KVM_SET_USER_MEMORY_REGION. Alex -- 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
