Re: [Qemu-devel] Re: QEMU-KVM and video performance

[Gerhard Wiesinger]

On Wed, 21 Apr 2010, Avi Kivity wrote:

> On 04/21/2010 09:39 PM, Jamie Lokier wrote:
> > Avi Kivity wrote:
> >
> > > Writes to vga in 16-color mode don't change set a memory location to a
> > > value, instead they change multiple memory locations.
> > While code is just writing to the VGA memory, not reading(*) and not
> > touching the VGA I/O register that control the write latches, is it
> > possible in principle to swizzle the format around in memory to make
> > regular writes work?
>
> Not in software.  We can map pages, not cross address lines.
>
> > (*) Reading should be ok for some settings of the write latches, I
> > think.
> >
> > I wonder if guests of interest behave like that.
>
> Guests that use 16 color vga are usually of little interest.

I tested 256 color modes.

> > > > Is this a case where TCG would run significantly faster for code blocks
> > > > that have been detected to access the VGA memory?
> > > Yes.
> > $ date
> > Wed Apr 21 19:37:38 2015
> > $ modprobe ktcg
>
> That's why the vmware software vmm was faster than the hardware vmm for the 
> initial iterations of vmx.

On VMWare Server 2.0: same picture:
Calling INT10h interrupts is fast, Writing to VGA Memory is also very slow 
(1.0MB/s). Can one switch to the old software vmm in VMWare?

That was one of the reasons why I was looking for alternatives for 
graphical DOS programs. Overall summary so far:
1.) QEMU without KVM: Problem with 286 DOS Extender instruction set, but 
fast VGA
2.) QEMU with KVM: 286 DOS Extender apps ok, but slow VGA memory 
performance
3.) VMWare Server 2.0 under Linux, application ok, but slow VGA memory 
performance
4.) Virtual PC: Problems with 286 DOS Extender
5.) Bochs: Works well, but very slow.

Looks like that VMWare Server and QEMU with KVM maybe have the same 
architectural problems going through the whole slow chain from Guest OS to 
virtualization layer for VGA writes.

Thnx.

Ciao,
Gerhard

--
http://www.wiesinger.com/