According to its documentation, type_register_static()'s TypeInfo
argument should exist for the life type of the type.
Therefore use type_register() when registering the list of CPU subtypes.

No functional change with the current implementation.

Cf. 918fd083 for arm.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

According to its documentation, type_register_static()'s TypeInfo
argument should exist for the life type of the type.
Therefore use type_register() when registering the list of CPU subtypes.

No functional change with the current implementation.

Cf. 918fd083 for arm.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Fixes -cpu unicore32-cpu asserting.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <afaerber@suse.de>

There is no abstract OpenRISCCPU yet, but that seems a bug of its own.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This fixes -cpu m68k-cpu asserting.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This fixes -cpu arm-cpu asserting.

Cc: qemu-stable@nongnu.org
Acked-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This fixes -cpu alpha-cpu asserting.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This lets a caller check if an ObjectClass as returned by, e.g.,
object_class_by_name() is instantiatable.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Cc: Anthony Liguori <anthony@codemonkey.ws>

Consolidate model checking into a new uc32_cpu_class_by_name().

If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_UNICORE32_CPU.

This fixes, e.g., -cpu puv3_dma asserting.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Consolidate model checking into a new openrisc_cpu_class_by_name().

If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_OPENRISC_CPU.

This fixes, e.g., -cpu open_eth asserting.

Cc: qemu-stable@nongnu.org
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Consolidate model checking into a new m68k_cpu_class_by_name().

If the name matches an existing type, also check whether that type is
(a sub-type of) TYPE_M68K_CPU.

This fixes, e.g., -cpu ide-hd asserting.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Check in alpha_cpu_class_by_name() whether the type found is actually
(a sub-type of) TYPE_ALPHA_CPU.

This fixes, e.g., -cpu typhoon-pcihost asserting.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Consolidate model checking into a new arm_cpu_class_by_name().

If the name matches an existing type, also check whether that type is
actually (a sub-type of) TYPE_ARM_CPU.

This fixes, e.g., -cpu tmp105 asserting.

Cc: qemu-stable <qemu-stable@nongnu.org>
Acked-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Introduce CPUClass::class_by_name and add a default implementation.
Hook up the alpha and ppc implementations.

Introduce a wrapper function cpu_class_by_name().
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Setting tsc-frequency from x86_def_t is NOP because default tsc_khz
in x86_def_t is 0 and CPUX86State.tsc_khz is also initialized to 0
by default. So there is no need to overwrite tsc_khz with default 0
because field was already initialized to 0.

Custom tsc-frequency setting is not affected due to it being set
without using x86_def_t.

Field tsc_khz in x86_def_t becomes unused with this patch, so drop it
as well.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Move custom features parsing after built-in cpu_model defaults are set
and set custom features directly on CPU instance. That allows to make a
clear distinction between built-in cpu model defaults that eventually
should go into class_init() and extra property setting which is done
after defaults are set on CPU instance.

Impl. details:
 * use object_property_parse() property setter so it would be a mechanical
   change to switch to global properties later.
 * And after all current features/properties are converted into static
   properties, it will take a trivial patch to switch to global properties.
   Which will allow to:
   * get CPU instance initialized with all parameters passed on -cpu ...
     cmd. line from object_new() call.
   * call cpu_model/featurestr parsing only once before CPUs are created
   * open a road for removing CPUxxxState.cpu_model_str field, when other
     CPUs are similarly converted to subclasses and static properties.
 - re-factor error handling, to use Error instead of fprintf()s, since
   it is anyway passed in for property setter.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Commit 89354998 makes cpuid return to guest host's vendor value
instead of built-in one by default if kvm_enabled() == true and allows
to override this behavior if 'vendor' is specified on -cpu command line.

But every time guest calls cpuid to get 'vendor' value, host's value is
read again and again in default case.

It complicates semantics of vendor property and makes it harder to use.

Instead of reading 'vendor' value from host every time cpuid[vendor] is
called, override 'vendor' value only once in cpu_x86_find_by_name(), when
built-in CPU model is found and if(kvm_enabled() == true).

It provides the same default semantics
 if (kvm_enabled() == true)  vendor = host's vendor
 else vendor = built-in vendor

and then later:
 if (custom vendor) vendor = custom vendor

'vendor' value is overridden when user provides it on -cpu command line,
and there is no need for vendor_override field anymore, remove it.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Vendor property setter takes string as vendor value but cpudefs
use uint32_t vendor[123] fields to define vendor value. It makes it
difficult to unify and use property setter for values from cpudefs.

Simplify code by using vendor property setter, vendor[123] fields
are converted into vendor[13] array to keep its value. And vendor
property setter is used to access/set value on CPU.

 - Make for() cycle reusable for the next patch by adding
   x86_cpu_vendor_words2str()

Intel's CPUID spec[1] says:
"
5.1.1 ...
These registers contain the ASCII string: GenuineIntel
...
"

List[2] of known vendor values shows that they all are 12 ASCII
characters long, padded where necessary with space.

Current supported values are all ASCII characters packed in
ebx, edx, ecx. So lets state that QEMU supports 12 printable ASCII
characters packed in ebx, edx, ecx registers for cpuid(0) instruction.

*1 - http://www.intel.com/Assets/PDF/appnote/241618.pdf
*2 - http://en.wikipedia.org/wiki/CPUID#EAX.3D0:_Get_vendor_IDSigned-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

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

It is no longer needed since dropping cpudef config file support.
Cleaning this up removes knowledge about other models from x86_def_t,
in preparation for reusing x86_def_t as intermediate step towards pure
QOM X86CPU subclasses.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Catch NULL name argument early to avoid repeated checks.
Similarly, check for -cpu host early and untangle from iterating through
model definitions. This prepares for introducing X86CPU subclasses.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This keeps compatibility on machine-types pc-1.2 and older, and prints a
warning in case the requested configuration won't get the correct
topology.

I couldn't think of a better way to warn about broken topology when in
compat mode other than using error_report(). The warning message will
probably be buried in a log file somewhere, but it's better than
nothing.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This introduces utility functions for the APIC ID calculation, based on:
  Intel® 64 Architecture Processor Topology Enumeration
  http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/

The code should be compatible with AMD's "Extended Method" described at:
  AMD CPUID Specification (Publication #25481)
  Section 3: Multiple Core Calcuation
as long as:
 - nr_threads is set to 1;
 - OFFSET_IDX is assumed to be 0;
 - CPUID Fn8000_0008_ECX[ApicIdCoreIdSize[3:0]] is set to
   apicid_core_width().

Unit tests included.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This changes FW_CFG_MAX_CPUS and FW_CFG_NUMA to use apic_id_for_cpu(),
so the NUMA table can be based on the APIC IDs, instead of CPU index
(SeaBIOS knows nothing about CPU indexes, just APIC IDs).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The code that calculates the APIC ID will use smp_cores/smp_threads, so
just define them as 1 on *-user to avoid #ifdefs in the code.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

PC will not use max_cpus for that field, so move it outside the common
code so it can use a different value on PC.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This function will be used by both the CPU initialization code and the
fw_cfg table initialization code.

Later this function will be updated to generate APIC IDs according to
the CPU topology.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The CPU ID in KVM is supposed to be the APIC ID, so change the
KVM_CREATE_VCPU call to match it. The current behavior didn't break
anything yet because today the APIC ID is assumed to be equal to the CPU
index, but this won't be true in the future.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
Acked-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This will allow each architecture to define how the VCPU ID is set on
the KVM_CREATE_VCPU ioctl call.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NGleb Natapov <gleb@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Currently, the pc-1.4 machine init function enables PV EOI and then
calls the pc-1.2 machine init function. The problem with this approach
is that now we can't enable any additional compatibility code inside the
pc-1.2 init function because it would end up enabling the compatibility
behavior on pc-1.3 and pc-1.4 as well.

This reverses the logic so that the pc-1.2 machine init function will
disable PV EOI, and then call the pc-1.4 machine init function.

This way we can change older machine-types to enable compatibility
behavior, and the newer machine-types (pc-1.3, pc-q35-1.4 and
pc-i440fx-1.4) would just use the default behavior.

(This means that one nice side-effect of this change is that pc-q35-1.4
will get PV EOI enabled by default, too)

It would be interesting to eventually change pc_init_pci_no_kvmclock()
and pc_init_isa() to reuse pc_init_pci_1_2() as well (so we don't need
to duplicate compatibility code on those two functions). But this will
be probably much easier to do after we create a PCInitArgs struct for
the PC initialization arguments, and/or after we use global-properties
to implement the compatibility modes present in pc_init_pci_1_2().
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This is a cleanup that tries to solve two small issues:

 - We don't need a separate kvm_pv_eoi_features variable just to keep a
   constant calculated at compile-time, and this style would require
   adding a separate variable (that's declared twice because of the
   CONFIG_KVM ifdef) for each feature that's going to be
   enabled/disabled by machine-type compat code.
 - The pc-1.3 code is setting the kvm_pv_eoi flag on cpuid_kvm_features
   even when KVM is disabled at runtime. This small inconsistency in
   the cpuid_kvm_features field isn't a problem today because
   cpuid_kvm_features is ignored by the TCG code, but it may cause
   unexpected problems later when refactoring the CPUID handling code.

This patch eliminates the kvm_pv_eoi_features variable and simply uses
kvm_enabled() inside the enable_kvm_pv_eoi() compat function, so it
enables kvm_pv_eoi only if KVM is enabled. I believe this makes the
behavior of enable_kvm_pv_eoi() clearer and easier to understand.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NGleb Natapov <gleb@redhat.com>
Reviewed-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Acked-by: NMarcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Instead of calling openrisc_env_get_cpu(), casting to CPU() via the
ENV_GET_CPU() compatibility macro and casting back to OPENRISC_CPU(),
just call openrisc_env_get_cpu() directly.

ENV_GET_CPU() is meant as workaround for target-independent code only.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

It was missed in 92a31361 (cpu:
Introduce CPUListState struct) because its naming did not match the
*CPUListState pattern. Use the generalized CPUListState instead.
Signed-off-by: NAndreas Färber <afaerber@suse.de>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

Default to moving back to the IDLE state after the COLLECTING_DATA
state. For a well behaved guest this patch has no consequence, but
A bad guest could crash QEMU by using one of the erase commands
followed by a longer than 5 byte argument (undefined behaviour).
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

Software services a received packet by clearing the CTRL_S bit in the RX_CTRLn
register. If this bit is cleared, flush any packets queued for the device.
Reported-by: NJohn Williams <john.williams@xilinx.com>
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

The eth_can_rx() function only checks the first buffers status ("ping"). The
controller should be able to receive into "pong" when ping-pong is enabled.
Checks the active buffer (either "ping" or "pong") when determining can_rx()
rather than just testing "ping".
Signed-off-by: NPeter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

* 'ppc-for-upstream' of git://repo.or.cz/qemu/agraf:
  PPC: e500: Select MPIC v4.2 on ppce500 platform
  PPC: e500: fix mpic_iack address
  openpic: add basic support for MPIC v4.2
  openpic: fix timer address decoding
  openpic: fix remaining issues from idr-to-destmask conversion
  pseries: Adjust default VIO address allocations to play better with libvirt
  pseries: Improve handling of multiple PCI host bridges
  target-ppc: Give a meaningful error if too many threads are specified
  cuda: Move ADB bus into CUDA state
  adb: QOM'ify ADB devices
  adb: QOM'ify Apple Desktop Bus
  cuda: QOM'ify CUDA
  ide/macio: QOM'ify MacIO IDE
  mac_nvram: QOM'ify MacIO NVRAM
  mac_nvram: Mark as Big Endian
  mac_nvram: Clean up public API
  macio: Split MacIO in two
  macio: Delay qdev init until all fields are initialized
  macio: QOM'ify some more
  ppc: Move Mac machines to hw/ppc/

Since x86_64 is a superset of i386 and reuses all its test cases, adopt
all the i386 gcov source files as well, substituting their paths
appropriately.
Signed-off-by: NAndreas Färber <afaerber@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>