public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Neo Jia <neojia@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: 32-bit qemu + 64-bit kvm be a problem?
Date: Thu, 11 Mar 2010 00:12:06 +0300	[thread overview]
Message-ID: <4B980B26.5080903@msgid.tls.msk.ru> (raw)
In-Reply-To: <5d649bdb1003100159i7edb6b62u24bf0e934d2a94bf@mail.gmail.com>

Neo Jia wrote:
> hi,
> 
> I have to keep a 32-bit qmeu user space to work with some legacy
> library I have but still want to use 64-bit host Linux to explore
> 64-bit advantage.
> 
> So I am wondering if I can use a 32-bit qemu + 64-bit kvm-kmod
> configuration. Will there be any limitation or drawback for this
> configuration? I already get one that we can't assign guest physical
> memory more than 2047 MB.

I use 32bit kvm on 64bit kernel since the day one.  Nothing of interest
since that, everything just works.

Recently (this week) I come across a situation when something does not
work in 64/32 mode.  Namely it is linux aio (see the other thread in
kvm@ a few days back) - but this is not due to kvm but due to other
kernel subsystem (in this case aio) which lacks proper compat handlers
in place.

Generally I reported quite several issues in this config - here or there
there were issues, something did not work.  Now the places where we've
issues are decreasing (hopefully anyway), at least I haven't seen issues
recently, except of this aio stuff.

But strictly speaking, I don't see any good reason to run 32bit kvm on
64 bit kernel either.  Most distributions nowadays provide a set of
64bit libraries for their 32bit versions so that limited support for
64bit binaries are available.  This is mostly enough for kvm - without
X and SDL support it works just fine (using vnc display).  Historically
I've 32bit userspace, but most guests now are running with 64bit kvm -
either because the guests switched to 64bit kernel or because aio thing
or just because I looks like it is more efficient (less syscall/ioctl
32=>64 translation and the like).  kvm itself uses only very few memory
so here it almost makes no difference between 32 and 64 bits (in 64bit
pointers are larger and hence usually more memory is used).  Yes, it is
difficult to provide everything needed for sdl, but for our tasks SDL
windows aren't really necessary, and for testing 32bit mode works just
fine too...

/mjt

  parent reply	other threads:[~2010-03-10 21:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-10  9:59 32-bit qemu + 64-bit kvm be a problem? Neo Jia
2010-03-10 10:07 ` Avi Kivity
2010-03-10 21:12 ` Michael Tokarev [this message]
2010-06-02  5:44   ` Neo Jia
2010-06-02  6:52     ` Michael Tokarev

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=4B980B26.5080903@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=kvm@vger.kernel.org \
    --cc=neojia@gmail.com \
    /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