Now "enum AIOContext" will generate AIO_CONTEXT instead of A_I_O_CONTEXT,
"X86CPU" will generate X86_CPU instead of X86_C_P_U.
Signed-off-by: NWenchao Xia <wenchaoqemu@gmail.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

The correct size of cpuid 0x0d sub-leaf 4 is 0x40, not 0x10.
This is confirmed by Anvin H Peter and Mallick Asit K.
Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Asit K Mallick <asit.k.mallick@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NLiu, Jinsong <jinsong.liu@intel.com>

As we will not have a cpu_x86_find_by_name() function anymore,
move the KVM default-vendor hack to instance_init.

Unfortunately we can't move that code to class_init because it depends
on KVM being initialized.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

As eventually the x86_def_t data is going to be provided by the CPU
class, it's better to not touch it, and handle the special cases on the
X86CPU object itself.

Current behavior of the code should stay exactly the same.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The compiler is already able to eliminate the kvm_arch_get_supported_cpuid()
calls in kvm_cpu_fill_host() and filter_features_for_kvm(), so we can
eliminate the CONFIG_KVM #ifdefs there.

Also, kvm_cpu_fill_host() and host_cpuid() don't need to check
CONFIG_KVM, as they don't have any KVM-specific function calls.

Tested to build successfully with CONFIG_KVM disabled, using the
following CFLAGS combinations: "-DNDEBUG", "-DNDEBUG -O', "-DNDEBUG
-O0", "-DNDEBUG -O1", "-DNDEBUG -O2".
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

http://msdn.microsoft.com/en-us/library/windows/hardware/ff541625%28v=vs.85%29.aspx

This code is generic for activating reference time counter or virtual reference time stamp counter
Signed-off-by: NVadim Rozenfeld <vrozenfe@redhat.com>
Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

We don't need the ft[] array on kvm_check_features_against_host()
anymore, as we can simply use the feature_word_info[] array, that has
everything we need.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Now that the kvm_cpu_fill_host() code is simplified, we can simply set
the feature word array using a simple loop.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Reorder the code so all the code that sets x86_cpu_def->features is at
the end of the function.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

There's no need to check CPU xlevel2 before calling
kvm_arch_get_supported_cpuid(s, 0xC0000001, 0, R_EDX), because:

 * The kernel won't return any entry for 0xC0000000 if host CPU vendor
   is not Centaur (See kvm_dev_ioctl_get_supported_cpuid() on the kernel
   code)
 * Similarly, the kernel won't return any entry for 0xC0000001 if
   CPUID[0xC0000000].EAX is < 0xC0000001
 * kvm_arch_get_supported_cpuid() will return 0 if no entry is returned
   by the kernel for the requested leaf

For similar reasons, we can simply set x86_cpu_def->xlevel2 directly
instead of making it conditional, because it will be set to 0 CPU vendor
is not Centaur.

This will simplify the kvm_cpu_fill_host() code a little.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
[Remove unparseable comment. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

There's no need to check CPU vendor before calling
kvm_arch_get_supported_cpuid(s, 0xC0000000, 0, R_EAX), because:

 * The kernel won't return any entry for 0xC0000000 if host CPU vendor
   is not Centaur (See kvm_dev_ioctl_get_cpuid() on the kernel code);
 * kvm_arch_get_supported_cpuid() will return 0 if no entry is returned
   by the kernel for the requested leaf.

This will simplify the kvm_cpu_fill_host() code a little.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

There's no need to check level (CPUID[0].EAX) before calling
kvm_arch_get_supported_cpuid(s, 0x7, 0, R_EBX), because:

 * The kernel won't return any entry for CPUID 7 if CPUID[0].EAX is < 7
   on the host (See kvm_dev_ioctl_get_cpuid() on the kernel code);
 * kvm_arch_get_supported_cpuid() will return 0 if no entry is returned
   by the kernel for the requested leaf.

This will simplify the kvm_cpu_fill_host() code a little.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Those host_cpuid() calls are useless. They are leftovers from when the
old code using host_cpuid() was removed.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Replace an assert_no_error() usage with the error_abort system.
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

Features family, model, stepping, level, hv_spinlocks are treated similarly
when passed from command line, so it's not necessary to handle each of them
individually. Collapse them to one catch-all branch which will treat
any not explicitly handled feature in format 'foo=val'.

Any unknown feature will be rejected by property setter so there is no
need to check for unknown feature in cpu_x86_parse_featurestr(), therefore
it's replaced by above mentioned catch-all handler.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Features check, enforce, hv_relaxed and hv_vapic are treated as boolean
set to 'on' when passed from command line, so it's not necessary to
handle each of them separately. Collapse them to one catch-all branch
which will treat any feature in format 'foo' as boolean set to 'on'.

Any unknown feature will be rejected by CPU property setter so there is no
need to check for unknown feature in cpu_x86_parse_featurestr(), therefore
it's replaced by above mentioned catch-all handler.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

* Additionally convert check_cpuid & enforce_cpuid to bool and make them
  members of X86CPU
* Make 'enforce' feature independent from 'check'
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This motion is preparing for refactoring vCPU APIC subsequently.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

VCPU TSC is not cleared by a warm reset (*), which leaves some types of Linux
 guests (non-pvops guests and those with the kernel parameter no-kvmclock set)
vulnerable to the overflow in cyc2ns_offset fixed by upstream commit
9993bc635d01a6ee7f6b833b4ee65ce7c06350b1 ("sched/x86: Fix overflow in
cyc2ns_offset").

To put it in a nutshell, if such a Linux guest without the patch above applied
has been up more than 208 days and attempts a warm reset chances are that
the newly booted kernel will panic or hang.

(*) Intel Xeon E5 processors show the same broken behavior due to
    the errata "TSC is Not Affected by Warm Reset" (Intel® Xeon®
    Processor E5 Family Specification Update - August 2013): "The
    TSC (Time Stamp Counter MSR 10H) should be cleared on
    reset. Due to this erratum the TSC is not affected by warm
    reset."

Cc: Will Auld <will.auld@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NFernando Luis Vázquez Cao <fernando_b1@lab.ntt.co.jp>

Add some MPX related definiation, and hardcode sizes and offsets
of xsave features 3 and 4. It also add corresponding part to
kvm_get/put_xsave, and vmstate.
Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Fix cpuid leaf 0x0d which incorrectly parsed eax and ebx.

However, before this patch the CPUID worked fine -- the .offset
field contained the size _and_ was stored in the register that
is supposed to hold the size (eax), and likewise the .size field
contained the offset _and_ was stored in the register trhat is
supposed to hold the offset (ebx).
Signed-off-by: NLiu Jinsong <jinsong.liu@intel.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit 787aaf57 (target-i386: forward CPUID cache leaves when -cpu host is
used, 2013-09-02) brings bits 31..26 of CPUID leaf 04h out of sync with
the APIC IDs that QEMU reserves for each package.  This number must come
from "-smp" options rather than from the host CPUID.

It also turns out that this unsyncing makes Windows Server 2012R2 fail
to boot.
Tested-by: NPeter Lieven <pl@kamp.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NBenoit Canet <benoit@irqsave.net>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Message-id: 1384879786-6721-1-git-send-email-pbonzini@redhat.com
Signed-off-by: NAnthony Liguori <aliguori@amazon.com>

Since this is only read in cpu_copy() and linux-user has a global
cpu_model, drop the field from generic code.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The data in leaf 0Dh depends on information from other feature bits.
Instead of passing it blindly from the host, compute it based on
whether these feature bits are enabled.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGleb Natapov <gleb@redhat.com>

On KVM, the KVM_SET_XSAVE would be executed with a 0 xstate_bv,
and not restore anything.

Since FP and SSE data are always valid, set them in xstate_bv at reset
time.  In fact, that value is the same that KVM_GET_XSAVE returns on
pre-XSAVE hosts.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NGleb Natapov <gleb@redhat.com>

There's no Intel CPU with family=6,model=2, and Linux and Windows guests
disable SEP when seeing that combination due to Pentium Pro erratum #82.

In addition to just having SEP ignored by guests, Skype (and maybe other
applications) runs sysenter directly without passing through ntdll on
Windows, and crashes because Windows ignored the SEP CPUID bit.

So, having model > 2 is a better default on qemu64 and qemu32 for two
reasons: making SEP really available for guests, and avoiding crashing
applications that work on bare metal.

model=3 would fix the problem, but it causes CPU enumeration problems
for Windows guests[1]. So let's set model=6, that matches "Athlon
(PM core)" on AMD and "P2 with on-die L2 cache" on Intel and it allows
Windows to use all CPUs as well as fixing sysenter.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=508623

Cc: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

I don't know yet if want this feature on by default, so for now I'm
just adding support for "-cpu ...,+kvm_pv_unhalt".
Signed-off-by: NAndrew Jones <drjones@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Some users running cpu intensive tasks checking the cache CPUID leaves at
startup and making decisions based on the result reported that the guest was
not reflecting the host CPUID leaves when -cpu host is used.

This patch fix this.
Signed-off-by: NBenoît Canet <benoit@irqsave.net>
[Rename new field to cache_info_passthrough - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This is an attempt to make the CPUID cache topology code clearer, by
replacing the magic numbers in the code with #defines, and moving all
the cache information to the same place in the file.

I took care of comparing the assembly output of compiling
target-i386/cpu.c before and after applying this change, to make sure
not a single bit was changed on cpu_x86_cpuid() before and after
applying this patch (unfortunately I had to manually check existing
differences, because of __LINE__ expansions on
object_class_dynamic_cast_assert() calls).

This even keeps the code bug-compatible with the previous version: today
the cache information returned on AMD cache information leaves (CPUID
0x80000005 & 0x80000006) do not match the information returned on CPUID
leaves 2 and 4. The L2 cache information on CPUID leaf 2 also doesn't
match the information on CPUID leaf 2. The new constants should make it
easier to eventually fix those inconsistencies. All inconsistencies I
have found are documented in code comments.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: Nliguang <lig.fnst@cn.fujitsu.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Convert stderr messages calling error_get_pretty()
to error_report().

Timestamp is prepended by -msg timstamp option with it.

Per Markus's comment below, A conversion from fprintf() to
error_report() is always an improvement, regardless of
error_get_pretty().

http://marc.info/?l=qemu-devel&m=137513283408601&w=2

But, it is not reasonable to convert them at one time
because fprintf() is used everwhere in qemu.

So, it should be done step by step with avoiding regression.
Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NLuiz Capitulino <lcapitulino@redhat.com>

- since hyperv_* helper functions are used only in target-i386/kvm.c
  move them there as static helpers
Requested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Error **errp argument is not for emitting warnings, it means an error
has occurred and the caller should not make any assumptions about the
state of other return values (unless otherwise documented).

Therefore cpu_x86_create() must unref the new X86CPU itself, and
pc_new_cpu() must check for an Error rather than NULL return value.

While at it, clean up a superfluous NULL check.
Reported-by: NJan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-stable@nongnu.org
Cc: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Bug description: QEMU currently gets all bits from GET_SUPPORTED_CPUID
for CPUID leaf 0xA and passes them directly to the guest. This makes
the guest ABI depend on host kernel and host CPU capabilities, and
breaks live migration if we migrate between hosts with different
capabilities (e.g., different number of PMU counters).

Add a "pmu" property to X86CPU, and set it to true only on "-cpu host",
or on pc-*-1.5 and older machine-types.

For now, setting pmu=on will enable the current passthrough mode that
doesn't have any ABI stability guarantees, but in the future we may
implement a mode where the PMU CPUID bits are stable and configurable.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This will help us change the initialization code to not require carrying
some intermediate values in a x86_def_t struct (and eventually kill the
x86_def_t struct entirely).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Commit c643bed9 moved qemu_init_vcpu() calls to common CPUState code.
This causes x86 cpu-add to fail with "KVM: setting VAPIC address failed".

The reason for the failure is that CPUClass::kvm_fd is not yet
initialized in the following call graph:
->x86_cpu_realizefn
 ->x86_cpu_apic_realize
  ->qdev_init
   ->device_set_realized
    ->device_reset (hotplugged == 1)
     ->apic_reset_common
      ->vapic_base_update
       ->kvm_apic_vapic_base_update
This causes attempted KVM vCPU ioctls to fail.

By contrast, in the non-hotplug case the APIC is reset much later, when
the vCPU is already initialized.

As a quick and safe solution, move the qemu_init_vcpu() call back into
the targets' realize functions.
Reported-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Acked-by: Igor Mammedov <imammedo@redhat.com> (for i386)
Tested-by: Jia Liu <proljc@gmail.com> (for openrisc)
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Completes migration of target-specific code to new target-*/gdbstub.c.

Acked-by: Michael Walle <michael@walle.cc> (for lm32)
Acked-by: Max Filippov <jcmvbkbc@gmail.com> (for xtensa)
Signed-off-by: NAndreas Färber <afaerber@suse.de>

CPUState::gdb_num_regs replaces num_g_regs.
CPUClass::gdb_num_core_regs replaces NUM_CORE_REGS.

Allows building gdb_register_coprocessor() for xtensa, too.

As a side effect this should fix coprocessor register numbering for SMP.

Acked-by: Michael Walle <michael@walle.cc> (for lm32)
Acked-by: Max Filippov <jcmvbkbc@gmail.com> (for xtensa)
Signed-off-by: NAndreas Färber <afaerber@suse.de>