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/
--
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
