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 02:06:07 +0200

On Fri, Jun 26, 2009 at 12:49:06AM +0100, Paul Brook wrote:
> No. According to others in this thread, migration between different hosts is 
> also important, as is isolation from host machine specifics. 

Which is exactly why I'm not patching to -cpu host as it can have
other implications.

> In fact I'm skeptical how much benefit using an Intel/AMD vendor ID gets you 
> by way of performance. While you may be running code "natively", there's 
> still 
> an awful lot of things that trap back to the hypervisor, so you're liable to 
> get different performance characteristics to a native CPU.

You didn't answer: what is the hardware in the marketplace with
vendor_id=unknown_to_guest_os_qemu? which hardware do you intend to
emulate? Not existent hardware? Or just want to create gratuitous pain
to guest OS implementations for the sake of intel/amd not giving guest
OS enough performance?

Besides when int 0x80 is run instead of sysenter by guest OS I'm quite
sure there is slowdown in KVM as sysenter will better run natively
without exists, or we definitely must disable it for good
unconditionally.

> You're missing the point. "-cpu host" or "-cpu p6" (where p6 is lowest-common-
> denominator) may be a reasonable default for KVM. What's not acceptable (as 
> evidenced by this bug) is taking an arbitrary CPUID and blindly sticking an 
> Intel vendor ID on it.

We don't take arbitrary cpuid, we take 6/3/3 which is lowest common
denominator that we know is not troublesome (6/2/3 is troublesome on
intel). Does troublesome pain segfault adjectives are enough to
warrant the change from 6/2/3 to 6/3/3?

If 6/3/3 wasn't a good enough common denominator for both amd and
intel vendor_ID, we'd be proposing a different change indeed.

There's probably some screwup to fix in kvm -cpu
different_vendor_id_than_host, plus there's likely some screwup in
qemu that sets SEP on -cpu athlon (how can it be?), but this patch has
only the scope of gettig rid of a troublesome 6/2/3 unlucky
combination. If I would patch more than one problem at once you'd be
telling me that I'm doing too many things in the same patch and I need
to split...




reply via email to

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