Function pc_acpi_init() is not used anymore.

Remove the definition and declaration.
Signed-off-by: NWei Yang <richardw.yang@linux.intel.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Message-Id: <20190214084939.20640-2-richardw.yang@linux.intel.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

Let's avoid manually looking up the hotplug handler class. Use the
existing wrappers instead.
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181212095707.19358-1-david@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Since linux commit: cf8fa920cb42 ("i386: handle an initrd in highmem (version 2)")
linux has supported initrd up to 4 GB, but the header field
ramdisk_max is still set to 2 GB to avoid "possible bootloader bugs".

When use '-kernel vmlinux -initrd initrd.cgz' to launch a VM,
the firmware(it could be linuxboot_dma.bin) helps to read initrd
contents into guest memory(below ramdisk_max) and jump to kernel.
that's similar with what bootloader does, like grub.

In addition, initrd_max is uint32_t simply because QEMU doesn't support
the 64-bit boot protocol (specifically the ext_ramdisk_image field).

Therefore here just limit initrd_max to UINT32_MAX simply as well to
allow initrd to be loaded below 4 GB.

NOTE: it's possible that linux protocol within [0x208, 0x20c]
supports up to 4 GB initrd as well.

CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Eduardo Habkost <ehabkost@redhat.com>
CC: "Michael S. Tsirkin" <mst@redhat.com>
CC: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

it's from v4.20-rc5.

CC: Stefano Garzarella <sgarzare@redhat.com>
CC: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

In order to avoid migration issues, we enable PVH only for
machine type >= 4.0
Suggested-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Use pvh.bin option rom when we are booting an uncompressed
kernel using the x86/HVM direct boot ABI.
Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NLiam Merwick <liam.merwick@oracle.com>
Based-on: <1547554687-12687-1-git-send-email-liam.merwick@oracle.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

When initrd is specified, load and expose it to the guest firmware
through fw_cfg. The firmware will fill the hvm_start_info for the
kernel.
Signed-off-by: NStefano Garzarella <sgarzare@redhat.com>
Based-on: <1545422632-24444-5-git-send-email-liam.merwick@oracle.com>
Signed-off-by: NLiam Merwick <Liam.Merwick@oracle.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

These changes (along with corresponding Linux kernel and qboot changes)
enable a guest to be booted using the x86/HVM direct boot ABI.

This commit adds a load_elfboot() routine to pass the size and
location of the kernel entry point to qboot (which will fill in
the start_info struct information needed to to boot the guest).
Having loaded the ELF binary, load_linux() will run qboot
which continues the boot.

The address for the kernel entry point is read from an ELF Note
in the uncompressed kernel binary by a helper routine passed
to load_elf().
Co-developed-by: NGeorge Kennedy <George.Kennedy@oracle.com>
Signed-off-by: NGeorge Kennedy <George.Kennedy@oracle.com>
Signed-off-by: NLiam Merwick <liam.merwick@oracle.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Modern AMD CPUs support NPT and NRIPSAVE features and KVM exposes these
when present. NRIPSAVE apeared somewhere in Opteron_G3 lifetime (e.g.
QuadCore AMD Opteron 2378 has is but QuadCore AMD Opteron HE 2344 doesn't),
NPT was introduced a bit earlier.

Add the FEAT_SVM leaf to Opteron_G4/G5 and EPYC/EPYC-IBPB cpu models.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Message-Id: <20190121155051.5628-1-vkuznets@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Update the stepping from 5 to 6, in order that
the Cascadelake-Server CPU model can support AVX512VNNI
and MSR based features exposed by ARCH_CAPABILITIES.
Signed-off-by: NTao Xu <tao3.xu@intel.com>
Message-Id: <20181227024304.12182-2-tao3.xu@intel.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Rename pc_get_hotpug_handler to pc_get_hotplug_handler.

No functional change.
Signed-off-by: NWei Yang <richardw.yang@linux.intel.com>
Reviewed-by: NStefano Garzarella <sgarzare@redhat.com>
Message-Id: <20190124073626.20534-1-richardw.yang@linux.intel.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

MPX support is being phased out by Intel; GCC has dropped it, Linux
is also going to do that.  Even though KVM will have special code
to support MPX after the kernel proper stops enabling it in XCR0,
we probably also want to deprecate that in a few years.  As a start,
do not enable it by default for any named CPU model starting with
the 4.0 machine types; this include Skylake, Icelake and Cascadelake.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <20181220121100.21554-1-pbonzini@redhat.com>
Reviewed-by: N  Wainer dos Santos Moschetta <wainersm@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

The missing functionality was added ~3 years ago with the Linux commit

  46896c73c1a4 ("KVM: svm: add support for RDTSCP")

so reenable RDTSCP support on those CPU models.

Opteron_G2 - being family 15, model 6, doesn't have RDTSCP support
(the real hardware doesn't have it. K8 got RDTSCP support with the NPT
models, i.e., models >= 0x40).

Document the host's minimum required kernel version, while at it.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Message-ID: <20181212200803.GG6653@zn.tnic>
[ehabkost: moved compat properties code to pc.c]
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Instead of verbose arrays with 4 lines for each entry, make each
entry take only one line.  This makes long arrays that couldn't
fit in the screen become short and readable.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190107193020.21744-4-ehabkost@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

stringify() is useful when we need to use macros in compat_props
(like when we set virtio-baloon-pci.class=PCI_CLASS_MEMORY_RAM at
pc_i440fx_1_0_machine_options()), but it is pointless when we are
already providing a number literal.

Replace stringify() with string literals when appropriate.
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <20190107193020.21744-3-ehabkost@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Make them more QOMConventional.
Cc:qemu-trivial@nongnu.org
Signed-off-by: NLi Qiang <liq3ea@163.com>
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Message-Id: <20190105023831.66910-1-liq3ea@163.com>
Signed-off-by: NLaurent Vivier <laurent@vivier.eu>

Use static arrays instead.  I decided to rename the conflicting
pc_compat_2_1() function with pc_compat_2_1_fn().
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.  I decided to rename the conflicting
pc_compat_2_1() function with pc_compat_2_1_fn().
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.  I decided to rename the conflicting
pc_compat_2_2() function with pc_compat_2_2_fn().
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.  I decided to rename the conflicting
pc_compat_2_3() function with pc_compat_2_3_fn().
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Use static arrays instead.
Suggested-by: NEduardo Habkost <ehabkost@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NCornelia Huck <cohuck@redhat.com>
Acked-by: NEduardo Habkost <ehabkost@redhat.com>

Switch the intr_supported variable from a boolean to OnOffAuto type so
that we can know whether the user specified it or not.  With that
we'll have a chance to help the user to choose more wisely where
possible.  Introduce x86_iommu_ir_supported() to mask these changes.

No functional change at all.
Signed-off-by: NPeter Xu <peterx@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>

SMBIOS is just another firmware interface used by some QEMU models.
We will later introduce more firmware interfaces in this subdirectory.
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

The load_image() function is deprecated, as it does not let the
caller specify how large the buffer to read the file into is.
Use the glib g_file_get_contents() function instead, which does
the whole "allocate memory for the file and read it in" operation.
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
Reviewed-by: NRichard Henderson <richard.henderson@linaro.org>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 20181130151712.2312-6-peter.maydell@linaro.org

This makes their function more clear and prevents conflicts when adding
the actual devices to the machine state, if necessary.
Signed-off-by: NCorey Minyard <cminyard@mvista.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Message-Id: <20181107152434.22219-1-minyard@acm.org>
Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

We're plugging/unplugging a PCDIMMDevice, so directly pass this type
instead of a more generic DeviceState.
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Reviewed-by: NEric Auger <eric.auger@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20181005092024.14344-5-david@redhat.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>

Calling error_report() in a function that takes an Error ** argument
is suspicious.  pc.c's pc_machine_set_nvdimm_persistence() does that,
and then exit()s.  Wrong.  Attempting to set machine property
nvdimm-persistence to a bad value instantly kills the VM:

    $ qemu-system-x86_64 -nodefaults -S -display none -qmp stdio
    {"QMP": {"version": {"qemu": {"micro": 50, "minor": 0, "major": 3}, "package": "v3.0.0-837-gc5e4e492"}, "capabilities": []}}
    {"execute": "qmp_capabilities"}
    {"return": {}}
    {"execute": "qom-set", "arguments": {"path": "/machine", "property": "nvdimm-persistence", "value": "instadeath"}}
    -machine nvdimm-persistence=instadeath: unsupported option
    $ echo $?
    1

Broken when commit 11c39b5c (v3.0.0) replaced error_propagate();
return by error_report(); exit() instead of error_setg(); return.  Fix
that.

Fixes: 11c39b5c
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20181017082702.5581-10-armbru@redhat.com>

Previously, if the size of initrd >=2G, qemu exits with error:
root@haswell-OptiPlex-9020:/home/lizj# /home/lizhijian/lkp/qemu-colo/x86_64-softmmu/qemu-system-x86_64 -kernel ./vmlinuz-4.16.0-rc4 -initrd large.cgz -nographic
qemu: error reading initrd large.cgz: No such file or directory
root@haswell-OptiPlex-9020:/home/lizj# du -sh large.cgz
2.5G	large.cgz

this patch changes the caller side that use this function to calculate
size of initrd file as well.

v2: update error message and int64_t printing format
Signed-off-by: NLi Zhijian <lizhijian@cn.fujitsu.com>
Message-Id: <1536833233-14121-1-git-send-email-lizhijian@cn.fujitsu.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

We can assign and verify the address before realizing and trying to plug.
reading/writing the address property should never fail for DIMMs, so let's
reduce error handling a bit by using &error_abort. Getting access to the
memory region now might however fail. So forward errors from
get_memory_region() properly.

As all memory devices should use the alignment of the underlying memory
region for guest physical address asignment, do detection of the
alignment in pc_dimm_pre_plug(), but allow pc.c to overwrite the
alignment for compatibility handling.
Reviewed-by: NEric Auger <eric.auger@redhat.com>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20180801133444.11269-5-david@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

All applicable memory regions always have an alignment > 0. All memory
backends result in file_ram_alloc() or qemu_anon_ram_alloc() getting
called, setting the alignment to > 0.

So a PCDIMM memory region always has an alignment > 0. NVDIMM copy the
alignment of the original memory memory region into the handcrafted memory
region that will be used at this place.

So the check for 0 can be dropped and we can reduce the special
handling.

Dropping this check makes factoring out of alignment handling easier as
compat handling only has to look at pcmc->enforce_aligned_dimm and not
care about the alignment of the memory region.
Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
Reviewed-by: NIgor Mammedov <imammedo@redhat.com>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Message-Id: <20180801133444.11269-4-david@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>