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

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

[Andrea Arcangeli]

From: Andrea Arcangeli <aarcange@redhat.com>

model=2 is not existent when vendor is intel and an errata of P6 says
that any model <= 2 when family is 6 lack sap feature, so windows and
linux 32bit guests disable sap in software and slowdown for no good
reason when running inside kvm on intel CPU.

Fix is to set model = 3 so it'll be the duron cpu when kvm runs on amd bare
metal (not anymore athlon but userland doesn't see the difference) and it'll be
PII that has sysenter functional like all cpus that run KVM have too when on
intel bare metal.

Patch will follow, workaround without this fix is -cpu qemu64,model=3.

There is a bug in skype that it checks if the sep feature is set to
run sysenter on intel chip inside its binary without passing through
ntdll, without verifying the model was <= 2 like windows does, so
windows forbids sysenter but skype calls it anyway and crashes (this
is why recent skype stopped working on KVM). This is skype bug and it
would trigger on real P6 hardware too (but nobody tests skype on
P6). qemu64,-sep fixed skype too. But because every time we have an
intel cpu running kvm, we also have sysenter functioning, we boots the
model to 3 so windows 32bit (and linux32bit) gets a performance boost
with sysenter too.

Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
---

diff --git a/target-i386/helper.c b/target-i386/helper.c
index 8a76abd..636e113 100644
--- a/target-i386/helper.c
+++ b/target-i386/helper.c
@@ -139,7 +139,8 @@ static x86_def_t x86_defs[] = {
         .vendor2 = CPUID_VENDOR_AMD_2,
         .vendor3 = CPUID_VENDOR_AMD_3,
         .family = 6,
-        .model = 2,
+        /* AMD Duron || PII Intel with sep capbility - P6 has no sep */
+        .model = 3,
         .stepping = 3,
         .features = PPRO_FEATURES | 
         /* these features are needed for Win64 and aren't fully implemented */

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

[Jamie Lokier]

Andrea Arcangeli wrote:
> From: Andrea Arcangeli <aarcange@redhat.com>
> 
> model=2 is not existent when vendor is intel and an errata of P6 says
> that any model <= 2 when family is 6 lack sap feature, so windows and
> linux 32bit guests disable sap in software and slowdown for no good
> reason when running inside kvm on intel CPU.

That's right.  Actually the errata applies when model == 3 and
stepping < 3 too.  Good job that structure has stepping == 3 :-)

(I believe some/all of the chips do have the sep feature, but it's
broken and should't be used.)

> Fix is to set model = 3 so it'll be the duron cpu when kvm runs on
> amd bare metal (not anymore athlon but userland doesn't see the
> difference) and it'll be PII that has sysenter functional like all
> cpus that run KVM have too when on intel bare metal.

But the vendor id is AMD not Intel in this structure, and the PPro
workaround is Intel-only.

I've checked Linux kernel code, and it only disables the sep feature
if the vendor is GenuineIntel, on old and current kernels.

So your patch should make no difference to Linux guests.  Did you
check Linux behaviour?  Does Windows ignore the vendor id?

> Patch will follow, workaround without this fix is -cpu qemu64,model=3.

Only on 64-bit host, of course.

I see the "qemu32" version has model=3, stepping =3 already :-)

> There is a bug in skype that it checks if the sep feature is set to
> run sysenter on intel chip inside its binary without passing through
> ntdll, without verifying the model was <= 2 like windows does, so
> windows forbids sysenter but skype calls it anyway and crashes (this
> is why recent skype stopped working on KVM). This is skype bug and it
> would trigger on real P6 hardware too (but nobody tests skype on
> P6). qemu64,-sep fixed skype too. But because every time we have an
> intel cpu running kvm, we also have sysenter functioning, we boots the
> model to 3 so windows 32bit (and linux32bit) gets a performance boost
> with sysenter too.

Linux checks the vendor id first, so this change should make no
difference to Linux guests.

Are you saying Windows doesn't check the vendor id properly?

It makes sense to change the model number for AMD anyway, as AMD
Athlons don't have the sep feature, even though this isn't a real CPU id.

> diff --git a/target-i386/helper.c b/target-i386/helper.c
> index 8a76abd..636e113 100644
> --- a/target-i386/helper.c
> +++ b/target-i386/helper.c
> @@ -139,7 +139,8 @@ static x86_def_t x86_defs[] = {
>          .vendor2 = CPUID_VENDOR_AMD_2,
>          .vendor3 = CPUID_VENDOR_AMD_3,
>          .family = 6,
> -        .model = 2,
> +        /* AMD Duron || PII Intel with sep capbility - P6 has no sep */
> +        .model = 3,
>          .stepping = 3,
>          .features = PPRO_FEATURES | 
>          /* these features are needed for Win64 and aren't fully implemented */

The code comment could be a lot clearer.
I propose this one, to go immediately before ".family = 6,":

    /* Intel sep feature is broken before family/model/stepping 6/3/3,
       and Windows guests wrongly ignore AMD vendor id when checking. */

-- Jamie

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

[Filip Navara]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

On Wed, Jun 24, 2009 at 7:29 PM, Jamie Lokier <jamie@shareable.org> wrote:
[snip]
>
> > Fix is to set model = 3 so it'll be the duron cpu when kvm runs on
> > amd bare metal (not anymore athlon but userland doesn't see the
> > difference) and it'll be PII that has sysenter functional like all
> > cpus that run KVM have too when on intel bare metal.
>
> But the vendor id is AMD not Intel in this structure, and the PPro
> workaround is Intel-only.
>
> I've checked Linux kernel code, and it only disables the sep feature
> if the vendor is GenuineIntel, on old and current kernels.
>
> So your patch should make no difference to Linux guests.  Did you
> check Linux behaviour?  Does Windows ignore the vendor id?


No, it doesn't ignore the vendor, at least not on NT 5.2 (Windows Server
2003) and newer kernels. I'm pretty sure it wasn't ignored even in Windows
XP, older systems didn't implement it.

Best regards,
Filip Navara

[-- Attachment #2: Type: text/html, Size: 1366 bytes --]

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

[Andrea Arcangeli]

On Wed, Jun 24, 2009 at 07:48:55PM +0200, Filip Navara wrote:
> On Wed, Jun 24, 2009 at 7:29 PM, Jamie Lokier <jamie@shareable.org> wrote:
> [snip]
> >
> > > Fix is to set model = 3 so it'll be the duron cpu when kvm runs on
> > > amd bare metal (not anymore athlon but userland doesn't see the
> > > difference) and it'll be PII that has sysenter functional like all
> > > cpus that run KVM have too when on intel bare metal.
> >
> > But the vendor id is AMD not Intel in this structure, and the PPro
> > workaround is Intel-only.
> >
> > I've checked Linux kernel code, and it only disables the sep feature
> > if the vendor is GenuineIntel, on old and current kernels.
> >
> > So your patch should make no difference to Linux guests.  Did you
> > check Linux behaviour?  Does Windows ignore the vendor id?
> 
> 
> No, it doesn't ignore the vendor, at least not on NT 5.2 (Windows Server
> 2003) and newer kernels. I'm pretty sure it wasn't ignored even in Windows
> XP, older systems didn't implement it.

Correct, not only windows, skype also doesn't ignore the vendor and
it doesn't attempt to run sysenter if running KVM on amd host (or qemu
in any amd/intel host).

skype crashes because windows on intel ignores sep on 6/2/3 (as well
as linux too) and it disables sysenter, but skype runs sysenter in its
binary even on 6/2/3 (tracked with windbg).

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

[Andrea Arcangeli]

Hi Jamie,

thanks for review!

On Wed, Jun 24, 2009 at 06:29:34PM +0100, Jamie Lokier wrote:
> So your patch should make no difference to Linux guests.  Did you
> check Linux behaviour?  Does Windows ignore the vendor id?

Maybe I wasn't clear enough, this patch only makes a difference for
KVM. KVM switches the vendor id to Intel when run on vmx host. It
definitely makes a difference to linux guest, without this patch 32bit
linux run as guest on top of KVM has sep disabled in /proc/cpuinfo and
isn't using sysenter (just like windows, hence the skype crash). I
verified 32bit linux guest has sep enabled with this patch applied
when run on KVM on top of intel.

For AMD the change is a noop because it changes the model from Athlon
to Duron.

> Only on 64-bit host, of course.
> 
> I see the "qemu32" version has model=3, stepping =3 already :-)

Yes, problem only happens on 64bit intel host running a 32bit guest
(windows skype crash or linux slowdown) on KVM.

> It makes sense to change the model number for AMD anyway, as AMD
> Athlons don't have the sep feature, even though this isn't a real CPU id.

No I don't think Duron has sep either... this should be noop for qemu
and a noop for KVM run on AMD.

>     /* Intel sep feature is broken before family/model/stepping 6/3/3,
>        and Windows guests wrongly ignore AMD vendor id when checking. */

I think we should specify this makes the cpu a duron on AMD and a PII
on intel and your comment removed that info but sure you're welcome to
change it ;).

Another approach is to switch model to 3 along with vendor_id in KVM
but because qemu is already using 6/3/3 when emulating a 32bit x86
hardware, I don't think this is simpler and more consistent.

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

[Jamie Lokier]

Andrea Arcangeli wrote:
> Hi Jamie,
> 
> thanks for review!
> 
> On Wed, Jun 24, 2009 at 06:29:34PM +0100, Jamie Lokier wrote:
> > So your patch should make no difference to Linux guests.  Did you
> > check Linux behaviour?  Does Windows ignore the vendor id?
> 
> Maybe I wasn't clear enough, this patch only makes a difference for
> KVM. KVM switches the vendor id to Intel when run on vmx host. It
> definitely makes a difference to linux guest, without this patch 32bit
> linux run as guest on top of KVM has sep disabled in /proc/cpuinfo and
> isn't using sysenter (just like windows, hence the skype crash). I
> verified 32bit linux guest has sep enabled with this patch applied
> when run on KVM on top of intel.

That was not at all clear.

What's missing is a comment saying "KVM changes this vendor id to
Intel when run on a VMX-capable host".

So what happens if you have a guest which worked fine under QEMU, then
breaks because it sees a changed vendor id when you run it under KVM?
I guess the guest, being Windows, tells you to make a phone call to
Microsoft because you changed the CPU, if you're out of luck.

It looks like it could be a KVM mis-feature.

Is the changing vendor id actually useful for anything, without
updating the family/model/stepping at the same time?  E.g. does it
make some guest things work, even though other parts of the cpuid
don't reflect the host?

> Another approach is to switch model to 3 along with vendor_id in KVM
> but because qemu is already using 6/3/3 when emulating a 32bit x86
> hardware, I don't think this is simpler and more consistent.

No, I'm happy with 6/3/3.  Like that part of the patch :-)

Although... there aren't any 64-bit Pentium Pros, so maybe 6/3/3 is a
bit... small? :-)

Now I'm just wondering why the vendor id needs to change dynamically,
if the other cpuid fields aren't changed.  If that's useful, then at
least a comment around the qemu64 CPU type to say that happens would
be good.  If that's not really a useful feature, then better not to do
it.

Maybe it's not useful any more, as "-cpu host" can be used instead (a
recent patch).  That had better not break Skype :-)

For Windows guests, which are sensitive to CPU changes, I prefer not
to change CPU type dynamically without the user knowing.  Even with
"-cpu host", I hope (eventually) the chosen CPU type will be stored
when saving/migrating and loaded exactly the same on other hosts, when
it's technically possible.

-- Jamie

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

[Andrea Arcangeli]

On Wed, Jun 24, 2009 at 10:39:44PM +0100, Jamie Lokier wrote:
> What's missing is a comment saying "KVM changes this vendor id to
> Intel when run on a VMX-capable host".

Ok.

> So what happens if you have a guest which worked fine under QEMU, then
> breaks because it sees a changed vendor id when you run it under KVM?

For windows to run sysenter, the vendor id has to be intel.

> It looks like it could be a KVM mis-feature.

If we don't turn to intel it won't ever run sysenter I think, AMD
duron/athlon has syscall, not sysenter.

> Is the changing vendor id actually useful for anything, without
> updating the family/model/stepping at the same time?  E.g. does it

Sure it is useful, without the switch not even linux can run sysenter.

> No, I'm happy with 6/3/3.  Like that part of the patch :-)

Then just update the comment to clarify that on kvm we need vendor id
intel if run on intel host ;)

> Although... there aren't any 64-bit Pentium Pros, so maybe 6/3/3 is a
> bit... small? :-)

Yes, I thought about it, but I didn't want to make more aggressive
changes other than the sysenter fix.

[Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host)

[Andre Przywara]

[CCing kvm@vger]
Jamie Lokier wrote:
> Andrea Arcangeli wrote:
>> Hi Jamie,
 >...
> 
> It looks like it could be a KVM mis-feature.
> 
> Is the changing vendor id actually useful for anything, without
> updating the family/model/stepping at the same time?  E.g. does it
> make some guest things work, even though other parts of the cpuid
> don't reflect the host?
(sysenter/sysexit in 32bit compat mode, see below)
> 
>> Another approach is to switch model to 3 along with vendor_id in KVM
>> but because qemu is already using 6/3/3 when emulating a 32bit x86
>> hardware, I don't think this is simpler and more consistent.
> 
> No, I'm happy with 6/3/3.  Like that part of the patch :-)
> 
> Although... there aren't any 64-bit Pentium Pros, so maybe 6/3/3 is a
> bit... small? :-)
There aren't any K7 Athlons with 64bit, either ;-)
I think this whole family 6 thing comes actually from QEMU and it's 
emulation capabilities and makes no sense in KVM.

I think we should go away from using qemu64 as a default for KVM. In my 
opinion we should target -cpu host as KVM's default, while in parallel 
create a -cpu migrate type (still fiddling with the CPUID details of 
that), which takes over the qemu64 role of being some kind of least 
common denominator. This should be a family 15 CPU (AMD K8 or Intel P4) 
with a constant vendor ID (in my experiments Intel showed less problems 
with guests). Since 64bit Windows has a whitelist of known vendor IDs 
(AMD, Intel on XP, additionally Via on Win7) we cannot use a bogus 
vendor, although this should impose the least problems.

> Now I'm just wondering why the vendor id needs to change dynamically,
> if the other cpuid fields aren't changed.  If that's useful, then at
> least a comment around the qemu64 CPU type to say that happens would
> be good.  If that's not really a useful feature, then better not to do
> it.
The dynamic vendor change was introduced to avoid compatibility problems 
with 32-on-64 compat mode, wherein AMD does not support sysenter 
(although it does in legacy mode) and Intel does not support syscall 
(although it does in 64bit mode). See the comment around line 1500 in 
target-i386/helper.c (or search for vendor_override in current git).
Linux's decision whether to use syscall or sysenter depends on the 
vendor string, so it uses syscall on AMD even when sysenter is advertised.
With the sysenter/syscall emulation patches I sent lately and the -cpu 
host type I think this dynamic vendor ID kludge can go away, since it 
creates problem with cross-vendor migration (where the vendor ID changes 
during the guest's runtime)

> Maybe it's not useful any more, as "-cpu host" can be used instead (a
> recent patch).  That had better not break Skype :-)
> 
> For Windows guests, which are sensitive to CPU changes, I prefer not
> to change CPU type dynamically without the user knowing.  Even with
> "-cpu host", I hope (eventually) the chosen CPU type will be stored
> when saving/migrating and loaded exactly the same on other hosts, when
> it's technically possible.
You do not want to use -cpu host if you plan to migrate, another safer 
CPU type should be used then (the aforementioned -cpu migrate).
Although preserving the boot CPU's vendor/family/model/stepping is 
something that one can think about...


Regards,
Andre.

-- 
Andre Przywara
AMD-OSRC (Dresden)
Tel: x29712

Re: [Qemu-devel] KVMs default CPU type

[Avi Kivity]

On 06/25/2009 11:11 AM, Andre Przywara wrote:
> I think we should go away from using qemu64 as a default for KVM. In 
> my opinion we should target -cpu host as KVM's default, while in 
> parallel create a -cpu migrate type (still fiddling with the CPUID 
> details of that), which takes over the qemu64 role of being some kind 
> of least common denominator. This should be a family 15 CPU (AMD K8 or 
> Intel P4) with a constant vendor ID (in my experiments Intel showed 
> less problems with guests). Since 64bit Windows has a whitelist of 
> known vendor IDs (AMD, Intel on XP, additionally Via on Win7) we 
> cannot use a bogus vendor, although this should impose the least 
> problems.

-cpu host may have issues other than migration; for example if you 
upgrade your host processor guests will notice and perhaps trigger a 
revalidation.  It also means every host offers something slightly 
different to guests, increasing the test matrix.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host)

[Andrea Arcangeli]

Hi everyone,

On Thu, Jun 25, 2009 at 10:11:58AM +0200, Andre Przywara wrote:
> common denominator. This should be a family 15 CPU (AMD K8 or Intel P4) 
> with a constant vendor ID (in my experiments Intel showed less problems 
> with guests). Since 64bit Windows has a whitelist of known vendor IDs 
> (AMD, Intel on XP, additionally Via on Win7) we cannot use a bogus 
> vendor, although this should impose the least problems.

I don't mind which vendor_id is used in the default common denominator
as long as we don't create a not-existing-hardware-vendor-id which
doesn't make much sense to me and it looks like gratuitous
complication for guest OS ;). The model string as qemu may be kind of
eye-candy in /proc/cpuinfo and it didn't break stuff yet, but that's
about it.

> The dynamic vendor change was introduced to avoid compatibility problems 
> with 32-on-64 compat mode, wherein AMD does not support sysenter 
> (although it does in legacy mode) and Intel does not support syscall 
> (although it does in 64bit mode). See the comment around line 1500 in 
> target-i386/helper.c (or search for vendor_override in current git).

This afternooon I was trying to test the 6/3/3 with amd vendor id with
32bit linux and 32bit windows on my laptop with qemu (my SVM test
system is down and it's troublesome to fix it now but I'll fix it
tomorrow), but I noticed that qemu seems to ignore that so I don't
think my testing of 6/3/3 with SEP feature enabled (sep is enabled
with qemu because of inheriting from PPRO even on -cpu athlon) was
reliable:

    case 0x134: /* sysenter */
        /* For Intel SYSENTER is valid on 64-bit */
        if (CODE64(s) && cpu_single_env->cpuid_vendor1 != CPUID_VENDOR_INTEL_1)
            goto illegal_op;
        if (!s->pe) {
            gen_exception(s, EXCP0D_GPF, pc_start - s->cs_base);
        } else {
            if (s->cc_op != CC_OP_DYNAMIC) {
                gen_op_set_cc_op(s->cc_op);
                s->cc_op = CC_OP_DYNAMIC;
            }
            gen_jmp_im(pc_start - s->cs_base);
            gen_helper_sysenter();
            gen_eob(s);
        }
        break;

qemu apparently allows sysenter without segfaults always on code32,
even if -cpu athlon is set and syscall feature disabled in cpuid, so
the fact sep is enabled on -cpu athlon probably won't trigger
breakages for qemu and it can be unnoticed (even if it fails to
emulate real athlon hardware) but I'm now worried it may break KVM as
I couldn't test it yet. This is the stuff I'd like to discuss...

> Linux's decision whether to use syscall or sysenter depends on the 
> vendor string, so it uses syscall on AMD even when sysenter is advertised.
> With the sysenter/syscall emulation patches I sent lately and the -cpu 
> host type I think this dynamic vendor ID kludge can go away, since it 
> creates problem with cross-vendor migration (where the vendor ID changes 
> during the guest's runtime)

I have to test 6/3/3 vendor_id = AMD with KVM ASAP...

Also if we want to really emulate real hardware in qemu we'd need to
allow syscall/sysret not just on the x86-64 target and set
CPUID_EXT2_SYSCALL and clear SEP again on athlon, no?

> You do not want to use -cpu host if you plan to migrate, another safer 
> CPU type should be used then (the aforementioned -cpu migrate).
> Although preserving the boot CPU's vendor/family/model/stepping is 
> something that one can think about...

Maybe it makes sense to use -cpu host, but that could have other
implications, also if it makes sense for qemu to have a model name
reflecting qemu cpu, I think we should be consistent and have a common
denominator with a qemu model name even for kvm, but on kvm we must
get certain bitflags right, and on intel move away from that 6/2/3
that purely asks for troubles I think. At the same time I doubt we
want to deviate much from qemu code here, this seems messy enough
already without big changes to maintain in this area, and I guess this
explains why kvm is only flipping the vendor_id right now...

Re: [Qemu-devel] KVMs default CPU type (was: allow sysenter on 32bit guests running on vmx host)

[Andrea Arcangeli]

On Fri, Jun 26, 2009 at 02:42:17AM +0200, Andrea Arcangeli wrote:
> that purely asks for troubles I think. At the same time I doubt we
> want to deviate much from qemu code here, this seems messy enough
> already without big changes to maintain in this area, and I guess this
> explains why kvm is only flipping the vendor_id right now...

Basically it seems athlon and other cpu definitions are tuned for cpus
having vmx/svm and running in legacy mode, that always support sep in
legacy mode and always supports syscall in long mode, so while qemu
seem to be cheating and not really emulating real hardware, those are
good tradeoffs definitions for KVM and it explains why it's enough to
flip the vendor_id to match the host vendor_id to get compatibility
mode right on 64bit guests, but only as long as 6/3/3 is set (hence
the reason of the patch).

So in short, we can't make any further change in KVM in addition to
waiting the common denominator to move to 6/3/3. First qemu has to
decide if it goes ahead not emulating real 32bit athlon but by
providing feature flags definition of a svm/vmx cpu in legacy mode.

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

[Paul Brook]

> What's missing is a comment saying "KVM changes this vendor id to
> Intel when run on a VMX-capable host".

I don't see how this is anything other than a KVM bug. The user requested an 
AMD vendor ID. Arbitrarily changing it to something else is just plain wrong.

Paul

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

[Andrea Arcangeli]

On Thu, Jun 25, 2009 at 06:39:19PM +0100, Paul Brook wrote:
> > What's missing is a comment saying "KVM changes this vendor id to
> > Intel when run on a VMX-capable host".
> 
> I don't see how this is anything other than a KVM bug. The user requested an 
> AMD vendor ID. Arbitrarily changing it to something else is just plain wrong.

Oh my, no -cpu is passed on the command line, and by default the only
thing the user asks is always only one: performance.

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

[Paul Brook]

On Thursday 25 June 2009, Andrea Arcangeli wrote:
> On Thu, Jun 25, 2009 at 06:39:19PM +0100, Paul Brook wrote:
> > > What's missing is a comment saying "KVM changes this vendor id to
> > > Intel when run on a VMX-capable host".
> >
> > I don't see how this is anything other than a KVM bug. The user requested
> > an AMD vendor ID. Arbitrarily changing it to something else is just plain
> > wrong.
>
> Oh my, no -cpu is passed on the command line, and by default the only
> thing the user asks is always only one: performance.

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.

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.

Paul

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

[Andrea Arcangeli]

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)

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

[Paul Brook]

> KVM users wants performance in their apps anything else is secondary,
> otherwise they would be fine using qemu, no?

No. According to others in this thread, migration between different hosts is 
also important, as is isolation from host machine specifics. 

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.

> 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)

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.

Paul

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

[Andrea Arcangeli]

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...