qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3


From: Fabrice Bellard
Subject: Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Date: Tue, 25 Sep 2007 14:05:21 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1

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.

Rectification: this is useful for kqemu too. I strongly suggest to look at kqemu.c:kqemu_update_cpuid() !

Moreover I believe that using the same CPU as host can be useful for pure emulation too, for example if code to do cache profiling is added.

Regards,

Fabrice.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]