Hello,
Some update on this issue, archive:
http://www.mail-archive.com/kvm@vger.kernel.org/msg32600.html
Seems to be that cirrus VGA is now ok (>1000MB/s up to 2000MB/s). But
cirrus has only 320x200x256colors (Mode 13h) mode implemented in VESA
BIOS.
VMWare and std VGA still have the perfo
On 05/12/2010 09:14 AM, Gerhard Wiesinger wrote:
On Mon, 10 May 2010, Avi Kivity wrote:
On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:
For 256 color more the first priority is to find out why direct
mapping is not used. I'd suggest tracing the code that makes this
decision (in hw/*vga.
Gerhard Wiesinger wrote:
> Can one switch to the old software vmm in VMWare?
Perhaps you can install a very old version of VMWare.
Maybe run it under KVM ;-)
> That was one of the reasons why I was looking for alternatives for
> graphical DOS programs. Overall summary so far:
> 1.) QEMU without
Gerhard Wiesinger wrote:
> On Wed, 21 Apr 2010, Jamie Lokier wrote:
>
> >Gerhard Wiesinger wrote:
> >>Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
> >>of QEMU even from KVM must be possible (e.g. memory and port accesses are
> >>done on nearly every virtual device) and
On Mon, 10 May 2010, Avi Kivity wrote:
On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:
For 256 color more the first priority is to find out why direct mapping is
not used. I'd suggest tracing the code that makes this decision (in
hw/*vga.c) and seeing if it's right or not.
I think this
On 05/09/2010 10:35 PM, Gerhard Wiesinger wrote:
Please run kvm_stat and report output for both tests to confirm.
See below. 2nd column is per second statistic when running the test.
efer_reload 0 0
exits 18470836 554582
fpu_reload 214783
On Thu, 22 Apr 2010, Avi Kivity wrote:
On 04/22/2010 09:04 AM, Gerhard Wiesinger wrote:
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.
1MB/s, 500k-1M c
On 04/22/2010 09:04 AM, Gerhard Wiesinger wrote:
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.
1MB/s, 500k-1M changes/s Coincidence? Is it taking a
On 04/22/2010 08:37 AM, Gerhard Wiesinger wrote:
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote:
Can you explain which code files/functions of KVM is involved in
handling VGA memory window and page switching through the port write
to the VGA window re
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
of QEMU even from KVM must be possible (e.g. memory and port accesses are
done on nearly every virtual device) and therefore I'm ending in C code in
the QEM
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.
1MB/s, 500k-1M changes/s Coincidence? Is it taking a page fault
or trap on every write?
To clarify:
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
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote:
Can you explain which code files/functions of KVM is involved in handling
VGA memory window and page switching through the port write to the VGA
window register (or is that part handled through QEMU), so
Gerhard Wiesinger wrote:
> Hmmm. I'm very new to QEMU and KVM but at least accessing the virtual HW
> of QEMU even from KVM must be possible (e.g. memory and port accesses are
> done on nearly every virtual device) and therefore I'm ending in C code in
> the QEMU hw/*.c directory. Therefore also
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(*)
On 04/21/2010 09:50 PM, Gerhard Wiesinger wrote:
I don't think changing VGA window is a problem because there are
500.000-1Mio changes/s possible.
1MB/s, 500k-1M changes/s Coincidence? Is it taking a page fault
or trap on every write?
To clarify:
Memory Performance writing to segmen A00
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
On 04/21/2010 09:14 PM, Gerhard Wiesinger wrote:
Can you explain which code files/functions of KVM is involved in
handling VGA memory window and page switching through the port write
to the VGA window register (or is that part handled through QEMU), so
a little bit architecture explaination w
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
Would it be possible to handle these writes through QEMU directly
(without
KVM), because performance is there very well (looking at the code there
is some pointer arithmetic and some memory write done)?
I've noticed extremely s
Gerhard Wiesinger wrote:
> >>Would it be possible to handle these writes through QEMU directly
> >>(without
> >>KVM), because performance is there very well (looking at the code there
> >>is some pointer arithmetic and some memory write done)?
> >
> >I've noticed extremely slow VGA performance too
On Wed, 21 Apr 2010, Jamie Lokier wrote:
Gerhard Wiesinger wrote:
I'm using VESA mode 0x101 (640x480 256 colors), but performance is
there very low (~1MB/s). Test is also WITHOUT any vga window change, so
there isn't any page switching overhead involved in this test case.
Any ideas for improv
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 p
Gerhard Wiesinger wrote:
> I'm using VESA mode 0x101 (640x480 256 colors), but performance is
> there very low (~1MB/s). Test is also WITHOUT any vga window change, so
> there isn't any page switching overhead involved in this test case.
>
> >>Any ideas for improvement?
> >
> >Currently when the
On Wed, 21 Apr 2010, Avi Kivity wrote:
On 04/21/2010 01:08 PM, Jamie Lokier wrote:
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, QE
On Wed, 21 Apr 2010, 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 perf
On 04/21/2010 01:08 PM, Jamie Lokier wrote:
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
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 perfor
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, functio
28 matches
Mail list logo
