qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, Avi Kivity <avi@redhat.com>,
	Erik Rull <webmaster@rdsoftware.de>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm?
Date: Tue, 22 May 2012 15:05:05 +0200	[thread overview]
Message-ID: <4FBB8F01.8090008@redhat.com> (raw)
In-Reply-To: <4FBB8647.4060307@siemens.com>

  Hi,

> BTW, if someone could have a look at the VGA diffs and resolve them,
> that would be great.

There isn't much ...

--- a/hw/vga_int.h
+++ b/hw/vga_int.h
@@ -31,8 +31,8 @@

-#define VBE_DISPI_MAX_XRES              1600
-#define VBE_DISPI_MAX_YRES              1200
+#define VBE_DISPI_MAX_XRES              2560
+#define VBE_DISPI_MAX_YRES              1600

The vgabios (both lgpl'ed and seavgabios) filters the mode list by
available memory anyway, so there is no need to keep those low enougth
that the xmax * ymax * 32bpp fits into vga memory.  And when the vgamem
becomes configurable (see below) this will be moot anyway.

I think we should just make them large enougth that they are practically
unlimited.  Those are 16bit registers in virtual hardware.  Guess we
better leave the high bit clear to avoid possible issues with signed
integers.  So (1<<14) aka 16384 maybe?  Or 16000?

-#define VGA_RAM_SIZE (8192 * 1024)
+#define VGA_RAM_SIZE (16 * 1024 * 1024)

That one is more tricky as it breaks migration.  I guess qemu has to
stick to 8M by default for that reason.  We certainly can make the vga
memory size configurable via property though, so you can easily go for
16M or even more (or 1M to reduce the memory footprint of your guests
when using text mode only).

> Gerd, what's the state of switching the BIOS?

Postponed to 1.2.  Too risky for 1.1, also malc vetoed the switch
without seavgabios supporting the vesa protected mode interface which
still needs to be done.

cheers,
  Gerd

  reply	other threads:[~2012-05-22 13:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-21 16:54 [Qemu-devel] Current differences between qemu --enable-kvm and qemu-kvm? Erik Rull
2012-05-22 10:04 ` Stefan Hajnoczi
2012-05-22 10:34   ` Jan Kiszka
2012-05-22 12:27     ` Jan Kiszka
2012-05-22 13:05       ` Gerd Hoffmann [this message]
2012-05-22 16:12       ` Erik Rull
2012-05-22 17:56         ` Jan Kiszka
  -- strict thread matches above, loose matches on Subject: below --
2012-05-21 16:55 Erik Rull

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=4FBB8F01.8090008@redhat.com \
    --to=kraxel@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=mtosatti@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=webmaster@rdsoftware.de \
    /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).