From: Jocelyn Mayer <l_indien@magic.fr>
To: Avi Kivity <avi@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>, qemu-devel@nongnu.org
Subject: Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Date: Tue, 25 Sep 2007 15:07:44 +0200 [thread overview]
Message-ID: <1190725664.13490.14.camel@jma4.dev.netgem.com> (raw)
In-Reply-To: <46F8F2B8.1080203@qumranet.com>
On Tue, 2007-09-25 at 13:36 +0200, Avi Kivity wrote:
> J. Mayer wrote:
> > On Tue, 2007-09-25 at 12:40 +0200, Avi Kivity wrote:
> >
> >> Avi Kivity wrote:
> >>
> >>>>>
> >>>>>
> >>>>>
> >>>> I've got a remark about this: why this has to be added to the Qemu
> >>>> code ?
> >>>> Imho, all is needed is an implementation of the -cpu option for
> >>>> x86/x86_64 target. Then, an external tool (even a shell script) can be
> >>>> used to determine what is the host CPU if you want to select the exact
> >>>> same CPU to be emulated in Qemu. It seems to me that trying to do so is
> >>>> out of the scope of Qemu code and just add unneeded complexity.
> >>>>
> >>>>
> >>>>
> >>> Indeed for regular qemu this is useless. But it is useful for kqemu
> >>> (for which there is support in mainline qemu), and for kvm (which we
> >>> hope to merge one day).
> >>>
> >>>
> >>>
> >> Actually (as Izik Eidus reminds me), this isn't very useful for kqemu as
> >> it can't trap cpuid in all circumstances.
> >>
> >> So this is mainly useful for kvm. I hope it will be applied regardless
> >> of that, as there is agreement that kvm support should be merged. I'd
> >> much rather pull the feature from qemu rather than carry it as an
> >> additional patch.
> >>
> >
> > Still I don't understand why it's usefull to put it inside the emulator
> > and why:
> > # qemu -cpu `guess_host_cpu`
> > would not do the work properly. Adding a specific case for '-cpu host'
> > seems useless to me.
> > And this way of doing potentially work for any family of emulated
> > targets, without any modification in Qemu. If the string returned by
> > 'guess_host_cpu' is not recognized for the specific target you used it
> > with, Qemu just stops telling it cannot find this CPU model, no more, no
> > less.
> >
>
> It's a usability issue. I agree your suggestion would work, but I'd
> like the default for kvm to be using the host cpu features, whereas
> managed environments would specify some subset to enable live migration.
>
> > The only case it could be interresting, imho, is if you do not allow the
> > -cpu option in KVM case and force the cpu model instead using this
> > function. This behavior does not seem to be great idea to me.
> >
>
> I think we can move the host cpu checks to kvm-specific code, since it
> is not useful for kqemu.
>
> So, running qemu without any parameters would use host capabilities if
> kvm is available and the default qemu cpu if not. The -cpu option can
> be used to override this if necessary.
Well, it may be needed to integrate the "-cpu host" option.
But I think it's a really bad idea that running qemu without the -cpu
option would not act the same on different host. When I want to test
qemu with the same command line, I want it to behave exactly the same,
whatever the host I'm running on, like any other tool. Think about gcc,
for example, if you launch it without option, it compiles for a generic
CPU. If you want to tune the generated code, even for the host you're
running on, you have to use -mcpu/-march/-mtune. Using one command line
always have gives the same result.
Then, my opinion is that running qemu without any -cpu option should
always use a default target.
next prev parent reply other threads:[~2007-09-25 13:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-05 17:45 [Qemu-devel] expose host CPU features to guests danken
2007-09-05 19:26 ` [Qemu-devel] Re: [kvm-devel] " Anthony Liguori
2007-09-05 19:34 ` Avi Kivity
2007-09-05 19:44 ` Daniel P. Berrange
2007-09-06 0:30 ` Paul Brook
2007-09-06 8:46 ` Avi Kivity
2007-09-07 10:47 ` Jamie Lokier
2007-09-09 7:51 ` [kvm-devel] [Qemu-devel] " Avi Kivity
2007-09-09 12:47 ` Jamie Lokier
2007-09-09 12:55 ` Avi Kivity
2007-09-09 13:07 ` Jamie Lokier
2007-09-09 13:14 ` Avi Kivity
2007-09-09 15:25 ` Paul Brook
2007-09-09 15:29 ` Avi Kivity
2007-09-09 15:47 ` Jamie Lokier
2007-09-09 16:12 ` Paul Brook
2007-09-09 16:38 ` Avi Kivity
2007-09-10 16:53 ` Jamie Lokier
2007-09-10 7:40 ` [Qemu-devel] expose host CPU features to guests: Take 2 Dan Kenigsberg
2007-09-10 11:47 ` Natalia Portillo
2007-09-10 12:01 ` Dan Kenigsberg
2007-09-07 16:18 ` Natalia Portillo
2007-09-11 19:48 ` Luke -Jr
2007-09-10 17:16 ` Jamie Lokier
2007-09-24 17:41 ` [Qemu-devel] expose host CPU features to guests: Take 3 Dan Kenigsberg
2007-09-25 1:28 ` andrzej zaborowski
2007-09-25 8:48 ` [kvm-devel] " Dan Kenigsberg
2007-09-25 9:01 ` Avi Kivity
2007-09-25 9:19 ` J. Mayer
2007-09-25 9:31 ` Avi Kivity
2007-09-25 10:40 ` Avi Kivity
2007-09-25 11:09 ` J. Mayer
2007-09-25 11:36 ` Avi Kivity
2007-09-25 12:05 ` Fabrice Bellard
2007-09-25 13:07 ` Jocelyn Mayer [this message]
2007-09-25 13:12 ` Avi Kivity
2007-09-25 13:27 ` Dan Kenigsberg
2007-09-25 15:54 ` Jamie Lokier
2007-09-25 16:15 ` Avi Kivity
2007-09-25 12:51 ` Paul Brook
2007-09-25 13:13 ` Avi Kivity
2007-09-25 9:29 ` Fabrice Bellard
2007-10-07 12:38 ` [Qemu-devel] x86 -cpu option: Take 4 Dan Kenigsberg
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=1190725664.13490.14.camel@jma4.dev.netgem.com \
--to=l_indien@magic.fr \
--cc=avi@qumranet.com \
--cc=kvm-devel@lists.sourceforge.net \
--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).