From: Jamie Lokier <jamie@shareable.org>
To: Gerhard Wiesinger <lists@wiesinger.com>
Cc: Avi Kivity <avi@redhat.com>, qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] Re: QEMU-KVM and video performance
Date: Wed, 12 May 2010 11:23:20 +0100 [thread overview]
Message-ID: <20100512102320.GC16879@shareable.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1004220805250.13868@bbs.intern>
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 therefore I'm ending in C code in
> >>the QEMU hw/*.c directory. Therefore also the VGA memory area should be
> >>able to be accessable from KVM but with the specialized and fast memory
> >>access of QEMU. Am I missing something?
> >
> >What you're missing is that when KVM calls out to QEMU to handle
> >hw/*.c traps, that call is very slow. It's because the hardware-VM
> >support is a bit slow when the trap happens, and then the the call
> >from KVM in the kernel up to QEMU is a bit slow again. Then all the
> >way back. It adds up to a lot, for every I/O operation.
>
> Isn't that then a general problem of KVM virtualization (oder hardware
> virtualization) in general? Is this CPU dependend (AMD vs. Intel)?
Yes it is a general problem, but KVM emulates some time-critical
things in the kernel (like APIC and CPU instructions), so it's not too bad.
KVM is about 5x faster than TCG for most things, and slower for a few
things, so on balance it is usually faster.
The slow 256-colour mode writes sound like just a simple bug, though.
No need for complicated changes.
> >In 256-colour mode, KVM should be writing to the VGA memory at high
> >speed a lot like normal RAM, not trapping at the hardware-VM level,
> >and not calling up to the code in hw/*.c for every byte.
>
> Yes, same picture to me: 256 color mode should be only a memory write (16
> color mode is more difficult as pixel/byte mapping is not the same).
> But it looks like this isn't the case in this test scenario.
>
> >You might double-check if your guest is using VGA "Mode X". (See
> >Wikipedia.)
> >
> >That was a way to accelerate VGA on real PCs, but it will be slow in
> >KVM for the same reasons as 16-colour mode.
>
> Which way do you mean?
Look up Mode X on Wikipedia if you're interested, but it isn't
relevant to the problem you've reported. Mode X cannot be enabled
with a BIOS call; it's a VGA hardware programming trick. It would not
be useful in a VM environment.
-- Jamie
next prev parent reply other threads:[~2010-05-12 10:23 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 19:14 QEMU-KVM and video performance Gerhard Wiesinger
2010-04-21 8:59 ` Avi Kivity
2010-04-21 10:08 ` [Qemu-devel] " Jamie Lokier
2010-04-21 10:49 ` Avi Kivity
2010-04-21 18:14 ` Gerhard Wiesinger
2010-04-21 20:49 ` [Qemu-devel] " Avi Kivity
2010-04-22 5:37 ` Gerhard Wiesinger
2010-04-22 6:57 ` Avi Kivity
2010-04-21 18:39 ` Jamie Lokier
2010-04-21 20:51 ` Avi Kivity
2010-04-21 21:19 ` Jamie Lokier
2010-04-22 5:44 ` Gerhard Wiesinger
2010-05-12 10:34 ` Jamie Lokier
2010-04-21 18:09 ` Gerhard Wiesinger
2010-04-21 18:33 ` Jamie Lokier
2010-04-21 18:50 ` Gerhard Wiesinger
2010-04-21 18:53 ` Jamie Lokier
2010-04-21 19:08 ` Gerhard Wiesinger
2010-04-21 21:30 ` Jamie Lokier
2010-04-22 6:12 ` Gerhard Wiesinger
2010-05-12 10:23 ` Jamie Lokier [this message]
2010-04-21 20:56 ` Avi Kivity
2010-04-22 6:04 ` Gerhard Wiesinger
2010-04-22 7:03 ` Avi Kivity
2010-05-09 19:35 ` Gerhard Wiesinger
2010-05-10 7:32 ` Avi Kivity
2010-05-12 6:14 ` Gerhard Wiesinger
2010-05-12 6:39 ` [Qemu-devel] " Avi Kivity
2011-02-18 7:32 ` [Qemu-devel] Re: QEMU-KVM and video performance - Update Gerhard Wiesinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100512102320.GC16879@shareable.org \
--to=jamie@shareable.org \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lists@wiesinger.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.