qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host


From: Andrea Arcangeli
Subject: Re: [Qemu-devel] allow sysenter on 32bit guests running on vmx host
Date: Fri, 26 Jun 2009 01:27:11 +0200

On Thu, Jun 25, 2009 at 11:12:08PM +0100, Paul Brook wrote:
> I don't buy this. I'd expect a a good proportion of users to care more about 
> correct operation over absolute performance. A fast VM is no good if it 
> doesn't actually work.

Be sure CPUs with vendor_id intel provides correct operation too :).

I fail to see what's wrong in telling the guest it's running on a
intel CPU when the physical CPU is intel. We're not emulating a CPU,
we're virtualizing it. This is not QEMU we're talking about.

> On closer inspection I notice that we use an AMD vendor ID for the "qemu64" 
> cpu. IMO this is wrong, we should be using our own ID. However this does not 
> change the underlying problem - KVM absolutely should not be unilaterally 
> changing the reported vendor ID.  Maybe select a different CPU by default, 
> and 
> probably fail to run if the selected CPU ID is incompatible with the host 
> hardware features, but not arbitrarily mutate the provided CPUID.

KVM users wants performance in their apps anything else is secondary,
otherwise they would be fine using qemu, no? What's wrong with qemu
besides performance?

Besides I think there is breakage in setting the SEP feature on athlon
definition for example, I don't have an hardware athlon around to
check /proc/cpuinfo though, but I don't think SEP would be enabled
there.

Let's focus on performance (and facts like SEP being enabled on
athlon) without shooting ourself in the foot by breaking all guest OS
assumptions with an unknown qemu vendor ID.

Or if you really want to argue, in most others thread you pretend qemu
should be as close as possible as hardware (no matter if guest
breaks), and I know no hardware with your brand new qemu vendor_id, do
you? (yeah not even the model name is reflecting hardware very well I
know, but that didn't happen to break stuff yet so it can stay as
default for now)




reply via email to

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