----- "Dave Airlie" <airl...@gmail.com> wrote: > On Thu, Dec 24, 2009 at 1:33 AM, Izik Eidus <iei...@redhat.com> > wrote: > > On Wed, 23 Dec 2009 10:04:03 +1000 > > Dave Airlie <airl...@gmail.com> wrote: > > > >> Just wondering why the spice BIOS sets up an MTRR at this point, > >> > >> When X starts and tries to setup a write combining mtrr on the > video > >> device it throws an > >> error because it conflicts with this. > > > > The vesa framebuffer start at 0xc0000000 and than after 16mb(?) the > pci > > hole start, it is needed so you can run 4 moniters with 4 diffrent > qxl > > devices.. (each device need 64mb memory allocation) > > > > I dont really understand the problem here?, are we doing something > > wrong here? > > (oops missed list reply first time). > > It just doesn't look like real hw (at least any of the current real hw > I have) > > Normal hw sets itself up as uncached by default and adds mtrrs for > RAM > to write-back, then that allows the OS to setup write-combined access > to the things like the framebuffer and PCI devices selectively > (granted > mainly only GPUs do this and we use PAT on newer hw with kernel > drivers). > > But on RHEL5 at least we just try to add write-combined mtrrs, these > conflict with the hardcoded uncached MTRR. > > Now I've no idea if mtrrs make any difference to speed on an emulated > kvm/qemu CPU, so this might all be moot, but if it does, then you > really > really want write-combining on the framebuffer.
VM memory allocation is from std user-space allocation so you can't really use MTRR unless we'll have spical API to allocat consecutive blocks. As far as I can remember KVM ignores MTRR. Furthermore unlick real HW you need to access the memory agine from SW so a different cache police need to be applied for bust performance. Yaniv > > Dave. > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Spice-space-devel mailing list > Spice-space-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/spice-space-devel ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Spice-space-devel mailing list Spice-space-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/spice-space-devel
