Due to a typo, instead of disabling KVM_FEATURE_PV_EOI (bit
6) these machine types are disabling bits 1 and 2, which are
KVM_FEATURE_NOP_IO_DELAY and KVM_FEATURE_MMU_OP.  Not a big deal
because they aren't very important and KVM_FEATURE_MMU_OP is
disabled anyway.  The worst part is actually that KVM_FEATURE_PV_EOI
is remaining enabled.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The argument is not longer used and the implementation
uses now QOM instead of QemuOpts.
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Message-id: 1420550957-22337-4-git-send-email-marcel@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

Use resizeable ram API so we can painlessly extend ROMs in the
future.  Note: migration is not affected, as we are
not actually changing the used length for RAM, which
is the part that's migrated.

Use this in acpi: reserve x16 more RAM space.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>

The argument is not longer used and the implementation
uses now QOM instead of QemuOpts.
Signed-off-by: NMarcel Apfelbaum <marcel@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>

This allows us to drop the fw_cfg_init() shim and to enforce the possible
mappings at compile time.
Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-id: 1419250305-31062-3-git-send-email-pbonzini@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

QEMU has support for options per machine, keeping
a global list of options is no longer necessary.
Signed-off-by: NMarcel Apfelbaum <marcel.a@redhat.com>
Reviewed-by: NAlexander Graf <agraf@suse.de>
Reviewed-by: NGreg Bellows <greg.bellows@linaro.org>
Message-id: 1418217570-15517-2-git-send-email-marcel.a@redhat.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>

It will be useful for checking when we change traditional
boot order dynamically and propagate error message
to the monitor.
For x86 architecture, we pass &local_err to set_boot_dev()
when vm startup in pc_coms_init().

Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-ppc@nongnu.org
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>

The wait_for_sipi field is set back to 1 after an INIT, so it was not
effective to reset it in kvm_apic_realize.  Introduce a reset callback
and reset wait_for_sipi there.
Reported-by: NIgor Mammedov <imammedo@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Both were added in Ivy Bridge (for which we do not have a CPU model
yet!).
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

vm86 mode extensions date back to the 486.  All models should have
them.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The next patch will differentiate them.
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

g_new(T, n) is neater than g_malloc(sizeof(T) * n).  It's also safer,
for two reasons.  One, it catches multiplication overflowing size_t.
Two, it returns T * rather than void *, which lets the compiler catch
more type errors.

This commit only touches allocations with size arguments of the form
sizeof(T).
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

struct kvm_pit_state2 contains pad fields. Let's use a designated
initializer to avoid false positives from valgrind/memcheck.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

kvm_clock_data contains pad fields. Let's use a designated
initializer to avoid false positives from valgrind/memcheck.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The name is set to "qemu".
Signed-off-by: NDrew DeVault <sir@cmpwn.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NDrew DeVault <sircmpwn@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

c/s 9b23cfb7

or

c/s b154537a

moved the testing of xen_enabled() from pc_init1() to
pc_machine_initfn().

xen_enabled() does not return the correct value in
pc_machine_initfn().

Changed vmport from a bool to an enum.  Added the value "auto" to do
the old way.  Move check of xen_enabled() back to pc_init1().
Acked-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NDon Slutz <dslutz@verizon.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

If QEMU is started with  -numa ... Windows only notices that
CPU has been hot-added but it will not online such CPUs.

It's caused by the fact that possible CPUs are flagged as
not enabled in SRAT and Windows honoring that information
doesn't use corresponding CPU.

ACPI 5.0 Spec regarding to flag says:
"
Table 5-47 Local APIC Flags
...
Enabled: if zero, this processor is unusable, and the operating system
support will not attempt to use it.
"

Fix QEMU to adhere to spec and mark possible CPUs as enabled
in SRAT.

With that Windows onlines hot-added CPUs as expected.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This makes it simpler to keep the SSDT byte-for-byte identical for a
given machine type, which is a goal we want to have for 2.2 and newer
types.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

acpi build modifies internal FW CFG RAM on first access
but we forgot to mark it dirty.
If this RAM has been migrated already, it won't be
migrated again, returning corrupted tables to guest.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

if DIMMs with different size/alignment are interleaved
in creation order, it could lead to hotplug-memory
container fragmentation and following inability to use
all RAM upto maxmem.
For example:
    -m 4G,slots=3,maxmem=7G
    -object memory-backend-file,id=mem-1,size=256M,mem-path=/pagesize-2MB
    -device pc-dimm,id=mem1,memdev=mem-1
    -object memory-backend-file,id=mem-2,size=1G,mem-path=/pagesize-1GB
    -device pc-dimm,id=mem2,memdev=mem-2
    -object memory-backend-file,id=mem-3,size=256M,mem-path=/pagesize-2MB
    -device pc-dimm,id=mem3,memdev=mem-3

fragments hotplug-memory container and doesn't allow
to use 1GB hugepage backend to consume remainig 1Gb.

To ease managment factor count in max 1Gb alignment for
each memory slot when sizing hotplug-memory region so
that regadless of fragmentaion it would be possible to
add max aligned DIMM.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Currently maxmem limit is not checked and depends on
hotplug region container not being able to fit more RAM
than maxmem. Do check explicitly so that it would
be possible to change hotplug container size later
to deal with fragmentation.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

Performance wise it's better to align GVA by the backend's
page size.

Also do not allow to create DIMM device with suboptimal
size (i.e. not aligned to backends page size) to aviod
memory loss.

Do above only for 2.2 and newer machine types to avoid
breaking working configs with 2.1 machine type.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When running in KVM mode, kvm_set_phys_mem() will silently
fail if registered MemoryRegion address/size is not page
aligned. Causing memory hotplug failure in guest.

Mapping non aligned MemoryRegion in TCG mode 'works', but
sane guest OS still expects page aligned memory module
and fails to initialize it if it's not aligned.

So do not allow non aligned (i.e. valid) address/size
values for DIMM to avoid either KVM failure or guest
issues caused by it.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

split addr initialization from declaration so that
later when new local vars are added property getter
wouldn't drift off of error check.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

When more memory devices are used than available
KVM memory slots, QEMU crashes with:

kvm_alloc_slot: no free slot available
Aborted (core dumped)

Fix this by checking that KVM has a free slot before
attempting to map memory in guest address space.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

If user starts QEMU with "-machine pc,accel=xen", then
compat property in xenfv won't work and it would cause error:
"Unsupported bus. Bus doesn't have property 'acpi-pcihp-bsel' set"
when PCI device is added with -device on QEMU CLI.

From: Igor Mammedov <imammedo@redhat.com>

In case of Xen instead of using compat property, just use the fact
that xen doesn't use QEMU's fw_cfg/acpi tables to switch piix4_pm
into legacy PCI hotplug mode when Xen is enabled.
Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NLi Liang <liang.z.li@intel.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>

ram_addr_t should not be used except if referring to a RAMBlobk.
Using 'uint64_t' avoids a -Wconstant-conversion warning, which
clang >= 3.4 produces in "smbios_get_tables()".
Signed-off-by: NSeokYeon Hwang <syeon.hwang@samsung.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Try to explain why commit 317b0a6d
needed a cpu_clean_all_dirty() call just after calling
cpu_synchronize_all_states().
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Cc: Andrey Korolyov <andrey@xdel.ru>
Cc: Marcin Gibuła <m.gibula@beyond.pl>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This patch adds missed sipi_vector and wait_for_sipi fields to a new
subsection of the vmstate of the apic_common module. Saving and loading
of these fields makes migration of the apic state deterministic.
Signed-off-by: NPavel Dovgalyuk <Pavel.Dovgaluk@ispras.ru>
[Initialize the field in pre_load and kvm_apic_realize. - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Make SVM be disabled by default on all CPU models when in KVM mode.
Nested SVM is enabled by default in the KVM kernel module, but it is
probably less stable than nested VMX (which is already disabled by
default).

Add a new compat function, x86_cpu_compat_kvm_no_autodisable(), to keep
compatibility on previous machine-types.
Suggested-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

TCG doesn't support VMX, and nested VMX is not enabled by default in the
KVM kernel module.

So, there's no reason to have VMX enabled by default on the core2duo and
coreduo CPU models, today. Even the newer Intel CPU model definitions
don't have it enabled.

In this case, we need machine-type compat code, as people may be running
the older machine-types on hosts that had VMX nesting enabled.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

The x86_cpu_compat_disable_kvm_features() name was a bit confusing, as
it won't forcibly disable the feature for all CPU models (i.e. add it to
kvm_default_unset_features), but it will instead turn off the KVM
auto-enabling of the feature (i.e. remove it from kvm_default_features),
meaning the feature may still be enabled by default in some CPU models).
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

We will need new compat code for the 2.1 machine-types.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NAndreas Färber <afaerber@suse.de>

This patch switches the default display from cirrus to vga
for the new (qemu 2.2+) machine types.  Old machines types
stay as-is for compatibility reasons.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This allows machine classes to specify which display device they want
as default.  If unspecified the current behavior (try cirrus, failing
that try stdvga, failing that use no display) will be used.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

There are three ACPI tables: 'linker_data', 'rsdp' and 'table_data'. They are
used differently. Two of them are being copied before using and only the copy
is used later. But the third is used directly. Because of that we need to free
two tables completely and delete only wrapper for the third one.

Valgrind output:
==23931== 131,072 bytes in 1 blocks are definitely lost in loss record 7,729 of 7,734
==23931==    at 0x4C2CE8E: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==23931==    by 0x2EA920: realloc_and_trace (vl.c:2811)
==23931==    by 0x509E6AE: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==23931==    by 0x506DB32: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==23931==    by 0x506E463: g_array_set_size (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4000.0)
==23931==    by 0x256A4F: acpi_align_size (acpi-build.c:487)
==23931==    by 0x259F92: acpi_build (acpi-build.c:1601)
==23931==    by 0x25A212: acpi_setup (acpi-build.c:1682)
==23931==    by 0x24F346: pc_guest_info_machine_done (pc.c:1110)
==23931==    by 0x55FAAB: notifier_list_notify (notify.c:39)
==23931==    by 0x2EA704: qemu_run_machine_init_done_notifiers (vl.c:2759)
==23931==    by 0x2EEC3C: main (vl.c:4504)
Signed-off-by: NNikita Belov <zodiac@ispras.ru>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>

Differently from older versions, SMBIOS version 2.6 is explicit about
the encoding of UUID fields:

> Although RFC 4122 recommends network byte order for all fields, the PC
> industry (including the ACPI, UEFI, and Microsoft specifications) has
> consistently used little-endian byte encoding for the first three fields:
> time_low, time_mid, time_hi_and_version. The same encoding, also known as
> wire format, should also be used for the SMBIOS representation of the UUID.
>
> The UUID {00112233-4455-6677-8899-AABBCCDDEEFF} would thus be represented
> as 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.

The dmidecode tool implements this and decodes the above "wire format"
when SMBIOS version >= 2.6. We moved from SMBIOS version 2.4 to 2.8 when
we started building the SMBIOS entry point inside QEMU, on commit
c97294ec.

Change smbios_build_type_1_table() to encode the UUID as specified.

To make sure we won't change the guest-visible UUID when upgrading to a
newer QEMU version, keep the old behavior on pc-*-2.1 and older.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>