From: Jamie Lokier <jamie@shareable.org>
To: Gerhard Wiesinger <lists@wiesinger.com>
Cc: Avi Kivity <avi@redhat.com>, kvm@vger.kernel.org, qemu-devel@nongnu.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-devel] QEMU-KVM and video performance Gerhard Wiesinger
2010-04-21 8:59 ` [Qemu-devel] " Avi Kivity
2010-04-21 10:08 ` Jamie Lokier
2010-04-21 10:49 ` Avi Kivity
2010-04-21 18:14 ` Gerhard Wiesinger
2010-04-21 20:49 ` 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 ` 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).